From charles.perkins@earthlink.net Tue Sep 1 00:41:41 2009 Return-Path: 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 A362D28C43D for ; Tue, 1 Sep 2009 00:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599] 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 57KrSHtRXxue for ; Tue, 1 Sep 2009 00:41:37 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 6FAA128C512 for ; Tue, 1 Sep 2009 00:41:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=J7TKpDhgT3uUEiqJtMF+PepRCde9P7xT1eTOsVt0BeLQFWdS5N599fuEtGVE+QNX; 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 [99.51.74.16] (helo=[192.168.1.102]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MiNzx-0005BP-5V; Tue, 01 Sep 2009 03:41:49 -0400 Message-ID: <4A9CD038.1060007@earthlink.net> Date: Tue, 01 Sep 2009 00:41:44 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ryuji Wakikawa References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52f9928ab2d041b970f64072a7c302ab61350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 07:41:41 -0000 Hello Ryuji, I support (b). In fact, I very strongly support it. And, if further reasoning is needed, I would supply it in a different note. Bottom line is, I think that requiring link-local will drastically limit our solution space and eliminate some very useful solutions (such as those which have already been built). To be accurate, I think we ought to support unique-local -INCLUSIVE OR- global addresses. In some situations (disconnected networks) global address autoconfiguration may not be possible. Regards, Charlie P. Ryuji Wakikawa wrote: > Hi all, > > This is consensus call about the link-local address support in MANET. > Please review the following call for consensus and vote your opinion > by Sep10th. > > DT will update the document according to our consensus. > > thanks, > Thomas & ryuji > > ------------------------------------------------------------------ > CALL FOR CONSENSUS > > Deadline: 2009-09-10 6:00PM PST. > > Target ID: Design Team Document > "IP Addressing Model in Ad Hoc Networks" > http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model-01 > > Issue (cited from the above draft): > - Use of Link Local Addresses - while the use of link local addresses on > interfaces connecting to a MANET link is not prohibited, the semantics > of "link local" in this context is yet to be defined, taking into > account the unusual requirements that follow, concerning such > addresses. These requirements include for example uniqueness within a > scope spanning beyond a single IP hop. > > Some discussions can be found at the IETF75 AUTOCONF minutes > http://www.ietf.org/proceedings/75/minutes/autoconf.txt > > Please vote your preference between the following two alternatives. > If you have another alternative, please propose it and give your > reasons why you prefer that alternative. > > a) The document shall support link-local addresses as required > for nodes in a MANET in addition to unique-local and global > addresses. > > b) Support unique-local and global addresses as required for MANET > nodes. The document shall not prohibit using link-local addresses, > but shall describe the difficulties inhibiting compliance in MANET > with the standardized IPv6 properties that characterize the use of > link-local addresses. > ------------------------------------------------------------------ > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > > From ulrich@herberg.name Tue Sep 1 01:30:18 2009 Return-Path: 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 61AD73A6F63 for ; Tue, 1 Sep 2009 01:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 HGOdvCYG7syo for ; Tue, 1 Sep 2009 01:30:17 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id DDFAB3A6F55 for ; Tue, 1 Sep 2009 01:30:16 -0700 (PDT) Received: by bwz19 with SMTP id 19so3337841bwz.37 for ; Tue, 01 Sep 2009 01:30:25 -0700 (PDT) MIME-Version: 1.0 Sender: ulrich@herberg.name Received: by 10.204.153.13 with SMTP id i13mr5239088bkw.161.1251793824944; Tue, 01 Sep 2009 01:30:24 -0700 (PDT) In-Reply-To: <4A9CD038.1060007@earthlink.net> References: <4A9CD038.1060007@earthlink.net> Date: Tue, 1 Sep 2009 10:30:24 +0200 X-Google-Sender-Auth: 8ca7e671947ede89 Message-ID: <25c114b90909010130h38d3a580pf54fc7be5dba8f24@mail.gmail.com> From: Ulrich Herberg To: "Charles E. Perkins" Content-Type: multipart/alternative; boundary=0015175cd33e44937804727ff66c Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 08:30:18 -0000 --0015175cd33e44937804727ff66c Content-Type: text/plain; charset=ISO-8859-1 Hello Ryuji, I agree with Charlie and support (b). In my opinion, there are still many unresolved issues with link-locals in MANETs and could delay or even limit solutions. The document should not prohibit link-locals though (which it does not), it just does not require them. Regards, Ulrich On Tue, Sep 1, 2009 at 9:41 AM, Charles E. Perkins < charles.perkins@earthlink.net> wrote: > > Hello Ryuji, > > I support (b). In fact, I very strongly support it. > > And, if further reasoning is needed, I would supply it in a > different note. Bottom line is, I think that requiring link-local > will drastically limit our solution space and eliminate some > very useful solutions (such as those which have already > been built). > > To be accurate, I think we ought to support unique-local > -INCLUSIVE OR- global addresses. In some situations > (disconnected networks) global address autoconfiguration > may not be possible. > > Regards, > Charlie P. > > > > > Ryuji Wakikawa wrote: > >> Hi all, >> >> This is consensus call about the link-local address support in MANET. >> Please review the following call for consensus and vote your opinion by >> Sep10th. >> >> DT will update the document according to our consensus. >> >> thanks, >> Thomas & ryuji >> >> ------------------------------------------------------------------ >> CALL FOR CONSENSUS >> >> Deadline: 2009-09-10 6:00PM PST. >> >> Target ID: Design Team Document >> "IP Addressing Model in Ad Hoc Networks" >> http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model-01 >> >> Issue (cited from the above draft): >> - Use of Link Local Addresses - while the use of link local addresses on >> interfaces connecting to a MANET link is not prohibited, the semantics >> of "link local" in this context is yet to be defined, taking into >> account the unusual requirements that follow, concerning such >> addresses. These requirements include for example uniqueness within a >> scope spanning beyond a single IP hop. >> >> Some discussions can be found at the IETF75 AUTOCONF minutes >> http://www.ietf.org/proceedings/75/minutes/autoconf.txt >> >> Please vote your preference between the following two alternatives. >> If you have another alternative, please propose it and give your >> reasons why you prefer that alternative. >> >> a) The document shall support link-local addresses as required >> for nodes in a MANET in addition to unique-local and global >> addresses. >> >> b) Support unique-local and global addresses as required for MANET >> nodes. The document shall not prohibit using link-local addresses, >> but shall describe the difficulties inhibiting compliance in MANET >> with the standardized IPv6 properties that characterize the use of >> link-local addresses. >> ------------------------------------------------------------------ >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >> >> >> > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > --0015175cd33e44937804727ff66c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Ryuji,

I agree with Charlie and support (b). In my opinion, th= ere are still many unresolved issues with link-locals in MANETs and could d= elay or even limit solutions. The document should not prohibit link-locals = though (which it does not), it just does not require them.

Regards,
Ulrich

On Tue, Sep 1, 200= 9 at 9:41 AM, Charles E. Perkins <charles.perkins@earthlink.net> w= rote:

Hello Ryuji,

I support (b). =A0In fact, I very strongly support it.

And, if further reasoning is needed, I would supply it in a
different note. =A0Bottom line is, I think that requiring link-local
will drastically limit our solution space and eliminate some
very useful solutions (such as those which have already
been built).

To be accurate, I think we ought to support unique-local
-INCLUSIVE OR- global addresses. =A0In some situations
(disconnected networks) global address autoconfiguration
may not be possible.

Regards,
Charlie P.




Ryuji Wakikawa wrote:
Hi all,

This is consensus call about the link-local address support in MANET.
Please review the following call for consensus and vote your opinion by Sep= 10th.

DT will update the document according to our consensus.

thanks,
Thomas & ryuji

------------------------------------------------------------------
CALL FOR CONSENSUS

Deadline: 2009-09-10 6:00PM PST.

Target ID: Design Team Document
"IP Addressing Model in Ad Hoc Networks"
http://tools.ietf.org/html/draft-baccelli-autocon= f-adhoc-addr-model-01

Issue (cited from the above draft):
- Use of Link Local Addresses - while the use of link local addresses on =A0interfaces connecting to a MANET link is not prohibited, the semantics =A0of "link local" in this context is yet to be defined, taking i= nto
=A0account the unusual requirements that follow, concerning such
=A0addresses. These requirements include for example uniqueness within a =A0scope spanning beyond a single IP hop.

Some discussions can be found at the IETF75 AUTOCONF minutes
http://www.ietf.org/proceedings/75/minutes/autoconf.txt

Please vote your preference between the following two alternatives.
If you have another alternative, please propose it and give your
reasons why you prefer that alternative.

a) The document shall support link-local addresses as required
=A0for nodes in a MANET in addition to unique-local and global
=A0addresses.

b) Support unique-local and global addresses as required for MANET
=A0nodes. =A0The document shall not prohibit using link-local addresses, =A0but shall describe the difficulties inhibiting compliance in MANET
=A0with the standardized IPv6 properties that characterize the use of
=A0link-local addresses.
------------------------------------------------------------------
_______________________________________________
Autoconf mailing list
Autoconf@ietf.org
https://www.ietf.org/mailman/listinfo/autoconf



_______________________________________________
Autoconf mailing list
Autoconf@ietf.org
https://www.ietf.org/mailman/listinfo/autoconf

--0015175cd33e44937804727ff66c-- From alexandru.petrescu@gmail.com Tue Sep 1 01:47:26 2009 Return-Path: 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 7E81428C583 for ; Tue, 1 Sep 2009 01:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 JDgNhwjnHXod for ; Tue, 1 Sep 2009 01:47:25 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 23B0028C194 for ; Tue, 1 Sep 2009 01:47:01 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n818lAwS003162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Sep 2009 10:47:10 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n818lA8P020984; Tue, 1 Sep 2009 10:47:10 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n818l9sr025542; Tue, 1 Sep 2009 10:47:10 +0200 Message-ID: <4A9CDF8D.7000509@gmail.com> Date: Tue, 01 Sep 2009 10:47:09 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ryuji Wakikawa References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 08:47:26 -0000 Hi Ryuji, Ryuji Wakikawa a écrit : > ------------------------------------------------------------------ > CALL FOR CONSENSUS > > Deadline: 2009-09-10 6:00PM PST. [...] > a) The document shall support link-local addresses as required for > nodes in a MANET in addition to unique-local and global addresses. I support a). This means AUTOCONF supports link-local addresses as any other IPv6 node does support them. It does not eliminate solutions for global and unique-local addresses. I am running a prototype in a AUTOCONF situation - link-local addresses are used exclusively between several Mobile Routers, without infrastructure. It works ok. In my prototype some problematic issues may show up but they are are related to the way the link-layer works and is implemented, and not to the fact that these are IPv6 link-local addresses. Alex > > b) Support unique-local and global addresses as required for MANET > nodes. The document shall not prohibit using link-local addresses, > but shall describe the difficulties inhibiting compliance in MANET > with the standardized IPv6 properties that characterize the use of > link-local addresses. > ------------------------------------------------------------------ > _______________________________________________ Autoconf mailing list > Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf > From ulrich@herberg.name Tue Sep 1 01:51:08 2009 Return-Path: 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 BC95F28C194 for ; Tue, 1 Sep 2009 01:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 4x7YTNjiIiS6 for ; Tue, 1 Sep 2009 01:51:07 -0700 (PDT) Received: from mail-fx0-f217.google.com (mail-fx0-f217.google.com [209.85.220.217]) by core3.amsl.com (Postfix) with ESMTP id 78D0D3A67DB for ; Tue, 1 Sep 2009 01:51:07 -0700 (PDT) Received: by fxm17 with SMTP id 17so3344548fxm.37 for ; Tue, 01 Sep 2009 01:51:17 -0700 (PDT) MIME-Version: 1.0 Sender: ulrich@herberg.name Received: by 10.204.23.11 with SMTP id p11mr5271454bkb.29.1251795077099; Tue, 01 Sep 2009 01:51:17 -0700 (PDT) In-Reply-To: <4A9CDF8D.7000509@gmail.com> References: <4A9CDF8D.7000509@gmail.com> Date: Tue, 1 Sep 2009 10:51:17 +0200 X-Google-Sender-Auth: 03fe2904e383fb58 Message-ID: <25c114b90909010151g39a2c869la8b58a75dca4ea8b@mail.gmail.com> From: Ulrich Herberg To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=0003255528e2e6f26a04728040a8 Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 08:51:08 -0000 --0003255528e2e6f26a04728040a8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alexandru, I am interested to know about your prototype. How do you assure uniqueness of the LL addresses? Are your nodes mobile? (I mean, do they actually move around?) Ulrich On Tue, Sep 1, 2009 at 10:47 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Hi Ryuji, > > Ryuji Wakikawa a =E9crit : > >> ------------------------------------------------------------------ CALL >> FOR CONSENSUS >> >> Deadline: 2009-09-10 6:00PM PST. >> > > [...] > > a) The document shall support link-local addresses as required for >> nodes in a MANET in addition to unique-local and global addresses. >> > > I support a). This means AUTOCONF supports link-local addresses as any > other IPv6 node does support them. It does not eliminate solutions for > global and unique-local addresses. > > I am running a prototype in a AUTOCONF situation - link-local addresses > are used exclusively between several Mobile Routers, without > infrastructure. It works ok. > > In my prototype some problematic issues may show up but they are are > related to the way the link-layer works and is implemented, and not to > the fact that these are IPv6 link-local addresses. > > Alex > > > >> b) Support unique-local and global addresses as required for MANET nodes= . >> The document shall not prohibit using link-local addresses, but shall >> describe the difficulties inhibiting compliance in MANET with the >> standardized IPv6 properties that characterize the use of link-local >> addresses. >> ------------------------------------------------------------------ >> _______________________________________________ Autoconf mailing list >> Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf >> >> > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > --0003255528e2e6f26a04728040a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alexandru,

I am interested to know about your prototype. How do y= ou assure uniqueness of the LL addresses? Are your nodes mobile? (I mean, d= o they actually move around?)

Ulrich

On Tue, Sep 1, 2009 at 10:47 AM, Alexandru Petrescu <<= a href=3D"mailto:alexandru.petrescu@gmail.com">alexandru.petrescu@gmail.com= > wrote:
Hi Ryuji,

Ryuji Wakikawa a =E9crit :
------------------------------------------------------------------ CALL FOR= CONSENSUS


Deadline: 2009-09-10 6:00PM PST.

[...]


a) The document shall support link-local addresses as required for
nodes in a MANET in addition to unique-local and global addresses.

I support a). =A0This means AUTOCONF supports link-local addresses as any other IPv6 node does support them. =A0It does not eliminate solutions for global and unique-local addresses.

I am running a prototype in a AUTOCONF situation - link-local addresses
are used exclusively between several Mobile Routers, without
infrastructure. =A0It works ok.

In my prototype some problematic issues may show up but they are are
related to the way the link-layer works and is implemented, and not to
the fact that these are IPv6 link-local addresses.

Alex



b) Support unique-local and global addresses as required for MANET nodes. = =A0The document shall not prohibit using link-local addresses, but shall de= scribe the difficulties inhibiting compliance in MANET with the standardize= d IPv6 properties that characterize the use of link-local addresses. ------= ------------------------------------------------------------ ______________= _________________________________ Autoconf mailing list
=A0Autoconf@ietf.org= https://www.ietf.org/mailman/listinfo/autoconf



_______________________________________________
Autoconf mailing list
Autoconf@ietf.org
https://www.ietf.org/mailman/listinfo/autoconf

--0003255528e2e6f26a04728040a8-- From cjbc@it.uc3m.es Tue Sep 1 01:55:13 2009 Return-Path: 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 8C6313A6F55 for ; Tue, 1 Sep 2009 01:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 zLHhOQ-tt9zv for ; Tue, 1 Sep 2009 01:55:12 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 624343A67DB for ; Tue, 1 Sep 2009 01:55:12 -0700 (PDT) Received: from [192.168.4.118] (24.Red-80-36-142.staticIP.rima-tde.net [80.36.142.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 8E400B4D258; Tue, 1 Sep 2009 10:55:22 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Ryuji Wakikawa In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-mHC4JTQ48eKOm4ebidDL" Organization: Universidad Carlos III de Madrid Date: Tue, 01 Sep 2009 10:55:57 +0200 Message-Id: <1251795357.5821.5.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16860.003 Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 08:55:13 -0000 --=-mHC4JTQ48eKOm4ebidDL Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable I vote a). Carlos On Mon, 2009-08-31 at 18:59 +0900, Ryuji Wakikawa wrote: > Hi all, >=20 > This is consensus call about the link-local address support in MANET. > Please review the following call for consensus and vote your opinion =20 > by Sep10th. >=20 > DT will update the document according to our consensus. >=20 > thanks, > Thomas & ryuji >=20 > ------------------------------------------------------------------ > CALL FOR CONSENSUS >=20 > Deadline: 2009-09-10 6:00PM PST. >=20 > Target ID: Design Team Document > "IP Addressing Model in Ad Hoc Networks" > http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model-01 >=20 > Issue (cited from the above draft): > - Use of Link Local Addresses - while the use of link local addresses on > interfaces connecting to a MANET link is not prohibited, the semantics > of "link local" in this context is yet to be defined, taking into > account the unusual requirements that follow, concerning such > addresses. These requirements include for example uniqueness within a > scope spanning beyond a single IP hop. >=20 > Some discussions can be found at the IETF75 AUTOCONF minutes > http://www.ietf.org/proceedings/75/minutes/autoconf.txt >=20 > Please vote your preference between the following two alternatives. > If you have another alternative, please propose it and give your > reasons why you prefer that alternative. >=20 > a) The document shall support link-local addresses as required > for nodes in a MANET in addition to unique-local and global > addresses. >=20 > b) Support unique-local and global addresses as required for MANET > nodes. The document shall not prohibit using link-local addresses, > but shall describe the difficulties inhibiting compliance in MANET > with the standardized IPv6 properties that characterize the use of > link-local addresses. > ------------------------------------------------------------------ > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-mHC4JTQ48eKOm4ebidDL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkqc4ZgACgkQNdy6TdFwT2dUmQCgisFHAWr1meCTGHENqqPzTssR tLoAoLTXkDWEqsdx8Oq6u8wHlfglB8i7 =29Kj -----END PGP SIGNATURE----- --=-mHC4JTQ48eKOm4ebidDL-- From alexandru.petrescu@gmail.com Tue Sep 1 02:10:01 2009 Return-Path: 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 B7AB528C480 for ; Tue, 1 Sep 2009 02:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 AR6dfF++3OGz for ; Tue, 1 Sep 2009 02:10:01 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id AC3D23A6875 for ; Tue, 1 Sep 2009 02:10:00 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n819ABlc019996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Sep 2009 11:10:12 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n819ABEn030135; Tue, 1 Sep 2009 11:10:11 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n819AAxJ003608; Tue, 1 Sep 2009 11:10:11 +0200 Message-ID: <4A9CE4F2.70307@gmail.com> Date: Tue, 01 Sep 2009 11:10:10 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ulrich Herberg References: <4A9CDF8D.7000509@gmail.com> <25c114b90909010151g39a2c869la8b58a75dca4ea8b@mail.gmail.com> In-Reply-To: <25c114b90909010151g39a2c869la8b58a75dca4ea8b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 09:10:01 -0000 Hi Ulrich, Ulrich Herberg a écrit : > Hi Alexandru, > > I am interested to know about your prototype. How do you assure > uniqueness of the LL addresses? With DAD. The subnet is stable. > Are your nodes mobile? (I mean, do they > actually move around?) Yes, I move them around within a range of cca 50meters and some obstacles. They are intended to be mostly static but they can also move within the acceptable limits of this particular wireless link-layer. Comments? Alex > > Ulrich > > On Tue, Sep 1, 2009 at 10:47 AM, Alexandru Petrescu > > wrote: > > Hi Ryuji, > > Ryuji Wakikawa a écrit : > > ------------------------------------------------------------------ > CALL FOR CONSENSUS > > > Deadline: 2009-09-10 6:00PM PST. > > > [...] > > > a) The document shall support link-local addresses as required for > nodes in a MANET in addition to unique-local and global addresses. > > > I support a). This means AUTOCONF supports link-local addresses as any > other IPv6 node does support them. It does not eliminate solutions for > global and unique-local addresses. > > I am running a prototype in a AUTOCONF situation - link-local addresses > are used exclusively between several Mobile Routers, without > infrastructure. It works ok. > > In my prototype some problematic issues may show up but they are are > related to the way the link-layer works and is implemented, and not to > the fact that these are IPv6 link-local addresses. > > Alex > > > > b) Support unique-local and global addresses as required for > MANET nodes. The document shall not prohibit using link-local > addresses, but shall describe the difficulties inhibiting > compliance in MANET with the standardized IPv6 properties that > characterize the use of link-local addresses. > ------------------------------------------------------------------ > _______________________________________________ Autoconf mailing > list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > > From rogge@fgan.de Tue Sep 1 02:15:18 2009 Return-Path: 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 1E7003A63EB for ; Tue, 1 Sep 2009 02:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.189 X-Spam-Level: X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 gw5FQ4ptpdBc for ; Tue, 1 Sep 2009 02:15:13 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id BD7B53A68C8 for ; Tue, 1 Sep 2009 02:15:13 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MiPSX-0002Sp-ES for autoconf@ietf.org; Tue, 01 Sep 2009 11:15:25 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MiPSX-0004RB-4N for autoconf@ietf.org; Tue, 01 Sep 2009 11:15:25 +0200 From: Henning Rogge To: autoconf@ietf.org Date: Tue, 1 Sep 2009 11:15:15 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.30-10-generic; KDE/4.2.2; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5494030.Xt1sxvTnhg"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200909011115.21259.rogge@fgan.de> X-Virus-Scanned: yes (ClamAV 0.95.2/9763/Tue Sep 1 09:02:27 2009) by mailguard.fgan.de X-Scan-Signature: c3a72cca7e04b8bd13992b8311b2dfed Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 09:15:18 -0000 --nextPart5494030.Xt1sxvTnhg Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I vote for sollution b) > b) Support unique-local and global addresses as required for MANET > nodes. The document shall not prohibit using link-local addresses, > but shall describe the difficulties inhibiting compliance in MANET > with the standardized IPv6 properties that characterize the use of > link-local addresses. Link-local addresses can be useful for interface IPs in MANETs, but because= =20 the default IPv6 link-local scope is not transitive (link-local scopes=20 overlap, but they are have differences) they can be a problem for a MANET (= or=20 a manet autoconf implementation). Because of movement in the MANET LL might have to change on the fly because= =20 two nodes which have chosen the same LL because they were out of communicat= ion=20 range get into range later. If an autoconf implementation supports link-local IPs for interfaces (eithe= r=20 because of limitation of movement or clever design or the implementation) i= t=20 should state this feature, but support for link-local IPs should not be=20 mandatory. Of course the Autoconf WG documents should not forbid the usage of link-loc= al=20 IPs. Henning Rogge ************************************************* Diplom Informatiker Henning Rogge =46orschungsgesellschaft f=FCr Angewandte Naturwissenschaften e. V. (FGAN)=20 Neuenahrer Str. 20, 53343 Wachtberg, Germany Tel.: 0049 (0)228 9435-961 =46ax: 0049 (0)228 9435-685 E-Mail: rogge@fgan.de Web: www.fgan.de ************************************************ Sitz der Gesellschaft: Bonn Registergericht: Amtsgericht Bonn VR 2530 Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim Ender=20 (Stellv.) --nextPart5494030.Xt1sxvTnhg Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkqc5iMACgkQRIfGfFXsz+BwEACeKIV9x+LvwRVd0s5+AI1mu4Yl LCoAn0Rcv1zdC0YgVBdgJ2cALxWjfcdX =8efD -----END PGP SIGNATURE----- --nextPart5494030.Xt1sxvTnhg-- From rogge@fgan.de Tue Sep 1 02:16:11 2009 Return-Path: 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 B9E9E3A63EB for ; Tue, 1 Sep 2009 02:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 hN1u6RAMdJRs for ; Tue, 1 Sep 2009 02:16:11 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id E1E6F3A6906 for ; Tue, 1 Sep 2009 02:16:10 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MiPTR-0002Tn-KV; Tue, 01 Sep 2009 11:16:21 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MiPTR-0004Ru-Bh; Tue, 01 Sep 2009 11:16:21 +0200 From: Henning Rogge To: autoconf@ietf.org Date: Tue, 1 Sep 2009 11:16:22 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.30-10-generic; KDE/4.2.2; i686; ; ) References: <25c114b90909010151g39a2c869la8b58a75dca4ea8b@mail.gmail.com> <4A9CE4F2.70307@gmail.com> In-Reply-To: <4A9CE4F2.70307@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2998423.TNZ9iU3tgb"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200909011116.23020.rogge@fgan.de> X-Virus-Scanned: yes (ClamAV 0.95.2/9763/Tue Sep 1 09:02:27 2009) by mailguard.fgan.de X-Scan-Signature: d42e7dfe6399d6e5eb526d1844917fec Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 09:16:11 -0000 --nextPart2998423.TNZ9iU3tgb Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Tue September 1 2009 11:10:10 schrieb Alexandru Petrescu: > Hi Ulrich, > > Ulrich Herberg a =E9crit : > > Hi Alexandru, > > > > I am interested to know about your prototype. How do you assure > > uniqueness of the LL addresses? > > With DAD. The subnet is stable. > > > Are your nodes mobile? (I mean, do they > > actually move around?) > > Yes, I move them around within a range of cca 50meters and some > obstacles. They are intended to be mostly static but they can also move > within the acceptable limits of this particular wireless link-layer. > > Comments? How do DAD deal with the case of three nodes A-B-C (B can see both A and C,= A=20 and C cannot see each other) when node A and C choose the same link-local I= P=20 for their interface ? Henning Rogge ************************************************* Diplom Informatiker Henning Rogge =46orschungsgesellschaft f=FCr Angewandte Naturwissenschaften e. V. (FGAN)=20 Neuenahrer Str. 20, 53343 Wachtberg, Germany Tel.: 0049 (0)228 9435-961 =46ax: 0049 (0)228 9435-685 E-Mail: rogge@fgan.de Web: www.fgan.de ************************************************ Sitz der Gesellschaft: Bonn Registergericht: Amtsgericht Bonn VR 2530 Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim Ender=20 (Stellv.) --nextPart2998423.TNZ9iU3tgb Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkqc5mYACgkQRIfGfFXsz+AtUgCfcVHCRgKh4g4FXfO7sI1gVfAB VsUAn0U/Z3Q4kO/Bf3MUhyEV+Mp1eHrQ =PSsE -----END PGP SIGNATURE----- --nextPart2998423.TNZ9iU3tgb-- From Chris.Dearlove@baesystems.com Tue Sep 1 02:19:16 2009 Return-Path: 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 B5BAF3A6918 for ; Tue, 1 Sep 2009 02:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] 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 QHhXWIaDNdJq for ; Tue, 1 Sep 2009 02:19:15 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 993803A63EB for ; Tue, 1 Sep 2009 02:19:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,311,1249254000"; d="scan'208";a="19853198" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 01 Sep 2009 10:19:28 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id n819JTQ8032256; Tue, 1 Sep 2009 10:19:30 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 10:19:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 1 Sep 2009 10:19:26 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] call for consensus about link local address support thread-index: AcoqIdDIKNmLb6IxQlqNdRo8Y1cysQAw3csA References: From: "Dearlove, Christopher (UK)" To: "Ryuji Wakikawa" , X-OriginalArrivalTime: 01 Sep 2009 09:19:27.0512 (UTC) FILETIME=[4DD45980:01CA2AE5] Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 09:19:16 -0000 b. Getting into a debate about what link local addresses are and are not allowed to do in a MANET would delay yet further, and possibly to the point of failure, the real work that has not started. This was, as I read it, pretty much the only position that all in the room and online in Stockholm could agree on. If, and preferably after this is agreed and the WG is rechartered to avoid muddying the waters, someone were to raise an ID discussing link local addresses in MANETs, what they are and are not allowed to do (with reference to the two hop range issue, and whether mobility de facto makes this all the MANET) and the results allowed a wider use of link local addresses, they could be added with no significant changes. But if the most restrictive view of link local addresses prevailed, time would not have been wasted waiting for that. -- Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On Behalf Of Ryuji Wakikawa Sent: 31 August 2009 11:00 To: autoconf@ietf.org Subject: [Autoconf] call for consensus about link local address support *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet. Keep this in mind if you answer this message. Hi all, This is consensus call about the link-local address support in MANET. Please review the following call for consensus and vote your opinion by Sep10th. DT will update the document according to our consensus. thanks, Thomas & ryuji ------------------------------------------------------------------ CALL FOR CONSENSUS Deadline: 2009-09-10 6:00PM PST. Target ID: Design Team Document "IP Addressing Model in Ad Hoc Networks" http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model-01 Issue (cited from the above draft): - Use of Link Local Addresses - while the use of link local addresses on interfaces connecting to a MANET link is not prohibited, the semantics of "link local" in this context is yet to be defined, taking into account the unusual requirements that follow, concerning such addresses. These requirements include for example uniqueness within a scope spanning beyond a single IP hop. Some discussions can be found at the IETF75 AUTOCONF minutes http://www.ietf.org/proceedings/75/minutes/autoconf.txt Please vote your preference between the following two alternatives. If you have another alternative, please propose it and give your reasons why you prefer that alternative. a) The document shall support link-local addresses as required for nodes in a MANET in addition to unique-local and global addresses. b) Support unique-local and global addresses as required for MANET nodes. The document shall not prohibit using link-local addresses, but shall describe the difficulties inhibiting compliance in MANET with the standardized IPv6 properties that characterize the use of link-local addresses. ------------------------------------------------------------------ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From alexandru.petrescu@gmail.com Tue Sep 1 02:21:58 2009 Return-Path: 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 EFFCF28C5F6 for ; Tue, 1 Sep 2009 02:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 k-eG3bpA1p6O for ; Tue, 1 Sep 2009 02:21:58 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 62F3428C5DC for ; Tue, 1 Sep 2009 02:21:54 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n819Lxek021486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Sep 2009 11:21:59 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n819LxrP001378; Tue, 1 Sep 2009 11:21:59 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n819LxWL023651; Tue, 1 Sep 2009 11:21:59 +0200 Message-ID: <4A9CE7B7.2090407@gmail.com> Date: Tue, 01 Sep 2009 11:21:59 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Henning Rogge References: <25c114b90909010151g39a2c869la8b58a75dca4ea8b@mail.gmail.com> <4A9CE4F2.70307@gmail.com> <200909011116.23020.rogge@fgan.de> In-Reply-To: <200909011116.23020.rogge@fgan.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 09:21:59 -0000 Henning Rogge a écrit : > Am Tue September 1 2009 11:10:10 schrieb Alexandru Petrescu: >> Hi Ulrich, >> >> Ulrich Herberg a écrit : >>> Hi Alexandru, >>> >>> I am interested to know about your prototype. How do you assure >>> uniqueness of the LL addresses? >> With DAD. The subnet is stable. >> >>> Are your nodes mobile? (I mean, do they >>> actually move around?) >> Yes, I move them around within a range of cca 50meters and some >> obstacles. They are intended to be mostly static but they can also move >> within the acceptable limits of this particular wireless link-layer. >> >> Comments? > > How do DAD deal with the case of three nodes A-B-C (B can see both A and C, A > and C cannot see each other) when node A and C choose the same link-local IP > for their interface ? I don't have the A-B-C case to deal with. If I had to deal with it I would use a link-layer solution (a bridge), such that DAD messages see all three nodes A, B and C. Comments? Alex From alexandru.petrescu@gmail.com Tue Sep 1 02:23:26 2009 Return-Path: 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 70FE63A6F64 for ; Tue, 1 Sep 2009 02:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.005 X-Spam-Level: X-Spam-Status: No, score=-2.005 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 eRKEA77jynPH for ; Tue, 1 Sep 2009 02:23:25 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 5D6DB3A6F5F for ; Tue, 1 Sep 2009 02:23:25 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n819NZNj022857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Sep 2009 11:23:35 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n819NZmq001926; Tue, 1 Sep 2009 11:23:35 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n819NY22024294; Tue, 1 Sep 2009 11:23:35 +0200 Message-ID: <4A9CE816.6060401@gmail.com> Date: Tue, 01 Sep 2009 11:23:34 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 09:23:26 -0000 Please define "MANET"... Alex Dearlove, Christopher (UK) a écrit : > b. > > Getting into a debate about what link local addresses are and are not > allowed to do in a MANET would delay yet further, and possibly to the > point of failure, the real work that has not started. This was, as I > read it, pretty much the only position that all in the room and > online in Stockholm could agree on. > > If, and preferably after this is agreed and the WG is rechartered to > avoid muddying the waters, someone were to raise an ID discussing > link local addresses in MANETs, what they are and are not allowed to > do (with reference to the two hop range issue, and whether mobility > de facto makes this all the MANET) and the results allowed a wider > use of link local addresses, they could be added with no significant > changes. But if the most restrictive view of link local addresses > prevailed, time would not have been wasted waiting for that. > From Chris.Dearlove@baesystems.com Tue Sep 1 02:23:42 2009 Return-Path: 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 7B3133A696C for ; Tue, 1 Sep 2009 02:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] 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 frwAttZVnmpg for ; Tue, 1 Sep 2009 02:23:41 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 341CF3A6F55 for ; Tue, 1 Sep 2009 02:23:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,311,1249254000"; d="scan'208";a="19854683" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 01 Sep 2009 10:23:53 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id n819Ntl8002699; Tue, 1 Sep 2009 10:23:55 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Sep 2009 10:23:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Sep 2009 10:23:52 +0100 Message-ID: In-Reply-To: <4A9CE7E4.3060709@cea.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] call for consensus about link local address support thread-index: Acoq5cXdY2JGTkoCRPGYTJLnxcDujAAABxtg References: <4A9CE7E4.3060709@cea.fr> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 01 Sep 2009 09:23:53.0553 (UTC) FILETIME=[EC66FC10:01CA2AE5] Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 09:23:42 -0000 RFC 2501 --=20 Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@cea.fr]=20 Sent: 01 September 2009 10:23 To: Dearlove, Christopher (UK) Cc: Ryuji Wakikawa; autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message. Please define "MANET"... Alex Dearlove, Christopher (UK) a =E9crit : > b. >=20 > Getting into a debate about what link local addresses are and > are not allowed to do in a MANET would delay yet further, and > possibly to the point of failure, the real work that has not > started. This was, as I read it, pretty much the only position > that all in the room and online in Stockholm could agree on. >=20 > If, and preferably after this is agreed and the WG is rechartered > to avoid muddying the waters, someone were to raise an ID discussing > link local addresses in MANETs, what they are and are not allowed to > do (with reference to the two hop range issue, and whether mobility > de facto makes this all the MANET) and the results allowed a wider > use of link local addresses, they could be added with no significant > changes. But if the most restrictive view of link local addresses > prevailed, time would not have been wasted waiting for that. >=20 --=20 Alexandru Petrescu CEA LIST Ing=E9nieur Chercheur t=E9l 0169089223 alexandru.petrescu@cea.fr http://www-list.cea.fr ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From ulrich@herberg.name Tue Sep 1 02:27:29 2009 Return-Path: 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 E39F93A6EE1 for ; Tue, 1 Sep 2009 02:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 FlzFDkPavrl8 for ; Tue, 1 Sep 2009 02:27:29 -0700 (PDT) Received: from mail-fx0-f217.google.com (mail-fx0-f217.google.com [209.85.220.217]) by core3.amsl.com (Postfix) with ESMTP id 371743A6F8E for ; Tue, 1 Sep 2009 02:26:52 -0700 (PDT) Received: by fxm17 with SMTP id 17so3364695fxm.37 for ; Tue, 01 Sep 2009 02:26:58 -0700 (PDT) MIME-Version: 1.0 Sender: ulrich@herberg.name Received: by 10.204.153.18 with SMTP id i18mr5378325bkw.123.1251797218494; Tue, 01 Sep 2009 02:26:58 -0700 (PDT) In-Reply-To: <4A9CE7B7.2090407@gmail.com> References: <25c114b90909010151g39a2c869la8b58a75dca4ea8b@mail.gmail.com> <4A9CE4F2.70307@gmail.com> <200909011116.23020.rogge@fgan.de> <4A9CE7B7.2090407@gmail.com> Date: Tue, 1 Sep 2009 11:26:58 +0200 X-Google-Sender-Auth: 7de7925205c09b68 Message-ID: <25c114b90909010226m3e2c40f9ld90b3acd300246c1@mail.gmail.com> From: Ulrich Herberg To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=0015175cd6448a0c60047280c059 Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 09:27:30 -0000 --0015175cd6448a0c60047280c059 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alex, Henning asked exactly the question I wanted to raise as well. On Tue, Sep 1, 2009 at 11:21 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Henning Rogge a =E9crit : > >> Am Tue September 1 2009 11:10:10 schrieb Alexandru Petrescu: >> >> [...] > > I am interested to know about your prototype. How do you assure >>>> uniqueness of the LL addresses? >>>> >>> >>> With DAD. The subnet is stable. >>> >> What subnet? > >>> Are your nodes mobile? (I mean, do they >>>> actually move around?) >>>> >>> Yes, I move them around within a range of cca 50meters and some >>> obstacles. They are intended to be mostly static but they can also mov= e >>> within the acceptable limits of this particular wireless link-layer. >>> >>> Comments? >>> >> >> How do DAD deal with the case of three nodes A-B-C (B can see both A and >> C, A and C cannot see each other) when node A and C choose the same >> link-local IP for their interface ? >> > > I don't have the A-B-C case to deal with. > > If I had to deal with it I would use a link-layer solution (a bridge), su= ch > that DAD messages see all three nodes A, B and C. > > Comments? > This is a very special case that cannot be assumed in general. The case described by Henning is the general case that may (and will in mobile scenarios) happen. We have to deal with that case in MANETs. As the addressing document says: "When more specific assumptions can be made regarding the connectivity to other interfaces on the link, these SHOULD be considered when configuring subnet prefixes." Ulrich --0015175cd6448a0c60047280c059 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alex,

Henning asked exactly the question I wanted to raise as wel= l.

On Tue, Sep 1, 2009 at 11:21 AM, Alexa= ndru Petrescu <alexandru.petrescu@gmail.com> wrote:
Henning Rogge a = =E9crit :

Am Tue September 1 2009 11:10:10 schrieb Alexandru Petrescu:=A0

[...= ]
I am interested to know about your prototype. How do you assure
uniqueness of the LL addresses?

With DAD. =A0The subnet is stable.

What subnet?
=A0

Are your nodes mobile? (I mean, do they
actually move around?)
Yes, I move them around within a range of cca 50meters and some
obstacles. =A0They are intended to be mostly static but they can also move<= br> within the acceptable limits of this particular wireless link-layer.

Comments?

How do DAD deal with the case of three nodes A-B-C (B can see both A and C,= A and C cannot see each other) when node A and C choose the same link-loca= l IP for their interface ?

I don't have the A-B-C case to deal with.

If I had to deal with it I would use a link-layer solution (a bridge), such= that DAD messages see all three nodes A, B and C.

Comments?

This is a very special case that cannot = be assumed in general. The case described by Henning is the general case th= at may (and will in mobile scenarios) happen. We have to deal with that cas= e in MANETs. As the addressing document says:
"When more specific assumptions can be made regarding the connectivity to other interfaces on the link, these SHOULD be considered when configuring subnet prefixes."

Ulrich
=A0
--0015175cd6448a0c60047280c059-- From alexandru.petrescu@gmail.com Tue Sep 1 02:27:32 2009 Return-Path: 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 8684E28C31F for ; Tue, 1 Sep 2009 02:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 Gd+esKCkdttC for ; Tue, 1 Sep 2009 02:27:31 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 6363328C5D9 for ; Tue, 1 Sep 2009 02:27:19 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n819RTOZ026523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Sep 2009 11:27:29 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n819RTXL003222; Tue, 1 Sep 2009 11:27:29 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n819RSBw010800; Tue, 1 Sep 2009 11:27:29 +0200 Message-ID: <4A9CE900.6060007@gmail.com> Date: Tue, 01 Sep 2009 11:27:28 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <4A9CE7E4.3060709@cea.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 09:27:32 -0000 Dearlove, Christopher (UK) a écrit : > RFC 2501 That is so much remote about all we do here that I am highly surprised is given as a reference here. It does not mention A-B-C, IPv6, DAD... nothing. That RFC is irrelevant about what we do in AUTOCONF. Or is as relevant as anything else which has to do with MANET. Alex From rogge@fgan.de Tue Sep 1 02:29:15 2009 Return-Path: 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 89E9B28C5F6 for ; Tue, 1 Sep 2009 02:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.212 X-Spam-Level: X-Spam-Status: No, score=-6.212 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 x5p9vbsHAXTx for ; Tue, 1 Sep 2009 02:29:14 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id AE3253A6EE1 for ; Tue, 1 Sep 2009 02:29:14 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MiPg4-0002oa-Pq; Tue, 01 Sep 2009 11:29:24 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MiPg4-0004Xr-H9; Tue, 01 Sep 2009 11:29:24 +0200 From: Henning Rogge To: Alexandru Petrescu Date: Tue, 1 Sep 2009 11:29:25 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.30-10-generic; KDE/4.2.2; i686; ; ) References: <200909011116.23020.rogge@fgan.de> <4A9CE7B7.2090407@gmail.com> In-Reply-To: <4A9CE7B7.2090407@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1336812.ISjK9FvlgE"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200909011129.25986.rogge@fgan.de> X-Virus-Scanned: yes (ClamAV 0.95.2/9763/Tue Sep 1 09:02:27 2009) by mailguard.fgan.de X-Scan-Signature: 9bea0208ff5bf14e461e230ff4736cfe Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 09:29:15 -0000 --nextPart1336812.ISjK9FvlgE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Tue September 1 2009 11:21:59 schrieb Alexandru Petrescu: > I don't have the A-B-C case to deal with. > > If I had to deal with it I would use a link-layer solution (a bridge), > such that DAD messages see all three nodes A, B and C. Do you use wireless radios for your MANET ? If yes the A-B-C szenario is on= e=20 of the most primitive things you can do with three nodes (and enough distan= ce=20 to prevent direct communication between node A and C). Henning Rogge ************************************************* Diplom Informatiker Henning Rogge =46orschungsgesellschaft f=FCr Angewandte Naturwissenschaften e. V. (FGAN)=20 Neuenahrer Str. 20, 53343 Wachtberg, Germany Tel.: 0049 (0)228 9435-961 =46ax: 0049 (0)228 9435-685 E-Mail: rogge@fgan.de Web: www.fgan.de ************************************************ Sitz der Gesellschaft: Bonn Registergericht: Amtsgericht Bonn VR 2530 Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim Ender=20 (Stellv.) --nextPart1336812.ISjK9FvlgE Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkqc6XUACgkQRIfGfFXsz+A/cACeOfql/4mmbDu6PqmTot5OBcWh jLwAn0Q/eqv/ySLzREupDbCdyWaIsKt7 =2KKr -----END PGP SIGNATURE----- --nextPart1336812.ISjK9FvlgE-- From alexandru.petrescu@gmail.com Tue Sep 1 02:36:01 2009 Return-Path: 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 6F14728C6AD for ; Tue, 1 Sep 2009 02:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.013 X-Spam-Level: X-Spam-Status: No, score=-2.013 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 w0YgBVlA+PCJ for ; Tue, 1 Sep 2009 02:36:00 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 5E65128C6A8 for ; Tue, 1 Sep 2009 02:36:00 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n819a6LG005697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Sep 2009 11:36:06 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n819a5sn005761; Tue, 1 Sep 2009 11:36:05 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n819a5u0014494; Tue, 1 Sep 2009 11:36:05 +0200 Message-ID: <4A9CEB05.1050804@gmail.com> Date: Tue, 01 Sep 2009 11:36:05 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ulrich Herberg References: <25c114b90909010151g39a2c869la8b58a75dca4ea8b@mail.gmail.com> <4A9CE4F2.70307@gmail.com> <200909011116.23020.rogge@fgan.de> <4A9CE7B7.2090407@gmail.com> <25c114b90909010226m3e2c40f9ld90b3acd300246c1@mail.gmail.com> In-Reply-To: <25c114b90909010226m3e2c40f9ld90b3acd300246c1@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] A-B-C general versus special (was: call for consensus about link local address support) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 09:36:01 -0000 Ulrich Herberg a écrit : > Hi Alex, > > Henning asked exactly the question I wanted to raise as well. > > On Tue, Sep 1, 2009 at 11:21 AM, Alexandru Petrescu > > wrote: > > Henning Rogge a écrit : > > Am Tue September 1 2009 11:10:10 schrieb Alexandru Petrescu: > > [...] > > I am interested to know about your prototype. How do you > assure > uniqueness of the LL addresses? > > > With DAD. The subnet is stable. > > > What subnet? 'subnet'... in this particular case I meant the link on which the interfaces self-configure their IPv6 link-local addresses. That link I use is stable. It has no A-B-C. Moreover it is secure. > Are your nodes mobile? (I mean, do they > actually move around?) > > Yes, I move them around within a range of cca 50meters and some > obstacles. They are intended to be mostly static but they > can also move > within the acceptable limits of this particular wireless > link-layer. > > Comments? > > > How do DAD deal with the case of three nodes A-B-C (B can see > both A and C, A and C cannot see each other) when node A and C > choose the same link-local IP for their interface ? > > > I don't have the A-B-C case to deal with. > > If I had to deal with it I would use a link-layer solution (a > bridge), such that DAD messages see all three nodes A, B and C. > > Comments? > > > This is a very special case that cannot be assumed in general. What is special? The fact that I don't use a bridge? The fact that there is no A-B-C problem? I think rather this is the most generic thing which happens the most often. (rather than the A-B-C situation which has to be created specially and artificially). > The case > described by Henning is the general case that may (and will in mobile > scenarios) happen. We have to deal with that case in MANETs. I think the case described by Henning (A-B-C) is a special case which needs special treatment. IT has to be set up specially in order to observe it; it is not obvious. > As the > addressing document says: > "When more specific assumptions can be made regarding the connectivity > to other interfaces on the link, these SHOULD be considered when > configuring subnet prefixes." The link I mentioned above (wrongly a 'subnet' maybe) has no prefix configured on it, other than the fe80::/10 prefix. This is not a specific assumption, but something that works out of the box, just set the link-layer, put the interfaces up and ping. This is the first thing one sees when setting such an 'ad-hoc' network. That's why I consider it general. More people can set this no-A-B-C case than people can set the A-B-C case. Alex From alexandru.petrescu@gmail.com Tue Sep 1 02:39:03 2009 Return-Path: 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 CF59328C69E for ; Tue, 1 Sep 2009 02:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.017 X-Spam-Level: X-Spam-Status: No, score=-2.017 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 4I1DhLoRS7pT for ; Tue, 1 Sep 2009 02:39:03 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id D3BCE28C6B4 for ; Tue, 1 Sep 2009 02:39:02 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n819d9QQ008497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Sep 2009 11:39:09 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n819d9tR006608; Tue, 1 Sep 2009 11:39:09 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n819d8mp015587; Tue, 1 Sep 2009 11:39:09 +0200 Message-ID: <4A9CEBBC.2040303@gmail.com> Date: Tue, 01 Sep 2009 11:39:08 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Henning Rogge References: <200909011116.23020.rogge@fgan.de> <4A9CE7B7.2090407@gmail.com> <200909011129.25986.rogge@fgan.de> In-Reply-To: <200909011129.25986.rogge@fgan.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 09:39:03 -0000 Henning Rogge a écrit : > Am Tue September 1 2009 11:21:59 schrieb Alexandru Petrescu: >> I don't have the A-B-C case to deal with. >> >> If I had to deal with it I would use a link-layer solution (a bridge), >> such that DAD messages see all three nodes A, B and C. > Do you use wireless radios for your MANET ? Yes. > If yes the A-B-C szenario is one > of the most primitive things you can do with three nodes (and enough distance > to prevent direct communication between node A and C). That is a problem. I need at least 100 meters of linear distance to set this A-B-C problem up. However, my setup is on a smaller than 50meter radius scale. I think more people have 50m radius to test with than 100m. If I had 100m to test with and three nodes then the 'B' node would be a bridge solving the A-B-C problem. Comments? Alex From Chris.Dearlove@baesystems.com Tue Sep 1 02:42:17 2009 Return-Path: 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 5BA6728C6D7 for ; Tue, 1 Sep 2009 02:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] 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 huCJoN9aSQbK for ; Tue, 1 Sep 2009 02:42:07 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 6491B28C68C for ; Tue, 1 Sep 2009 02:41:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,311,1249254000"; d="scan'208";a="19861589" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 01 Sep 2009 10:42:11 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id n819gDtt015518; Tue, 1 Sep 2009 10:42:13 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 10:42:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Sep 2009 10:42:07 +0100 Message-ID: In-Reply-To: <4A9CE900.6060007@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] call for consensus about link local address support thread-index: Acoq5m74+eQ7AmZvS/6HQIO1yZNrEQAAU/IA References: <4A9CE7E4.3060709@cea.fr> <4A9CE900.6060007@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 01 Sep 2009 09:42:10.0862 (UTC) FILETIME=[7A730CE0:01CA2AE8] Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 09:42:19 -0000 You didn't ask me to discuss DAD etc., you asked what a MANET was. And RFC 2501 is still the baseline document for the MANET WG. And it explicitly discusses doing routing at L3. You say you solve the A - B - C problem at L2. Fine, many people create MANETs at L2. That is not however what we are doing here, and RFC 2501 is entirely to the point. If you are going to dismiss the A - B - C issue as "solve at L2" you are doing something quite different, and any conclusions you draw without it are entirely beside the point here. In what we are doing here, the A - B - C (or non-transitivity of connectivity) is an inevitable problem and has the consequences for considering link local addresses that have been discussed. --=20 Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Sent: 01 September 2009 10:27 To: Dearlove, Christopher (UK) Cc: Ryuji Wakikawa; autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message. Dearlove, Christopher (UK) a =E9crit : > RFC 2501 That is so much remote about all we do here that I am highly surprised=20 is given as a reference here. It does not mention A-B-C, IPv6, DAD... nothing. That RFC is irrelevant about what we do in AUTOCONF. Or is as relevant as anything else which has to do with MANET. Alex ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From rogge@fgan.de Tue Sep 1 02:43:22 2009 Return-Path: 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 DFAF028C674 for ; Tue, 1 Sep 2009 02:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.216 X-Spam-Level: X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 dNbzGoOkKzoV for ; Tue, 1 Sep 2009 02:43:19 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id C1A783A6C98 for ; Tue, 1 Sep 2009 02:43:18 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MiPth-0003Ht-TM; Tue, 01 Sep 2009 11:43:29 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MiPth-0004hI-KE; Tue, 01 Sep 2009 11:43:29 +0200 From: Henning Rogge To: Alexandru Petrescu Date: Tue, 1 Sep 2009 11:43:25 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.30-10-generic; KDE/4.2.2; i686; ; ) References: <25c114b90909010226m3e2c40f9ld90b3acd300246c1@mail.gmail.com> <4A9CEB05.1050804@gmail.com> In-Reply-To: <4A9CEB05.1050804@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart65887811.sZmZWZZkg0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200909011143.30956.rogge@fgan.de> X-Virus-Scanned: yes (ClamAV 0.95.2/9763/Tue Sep 1 09:02:27 2009) by mailguard.fgan.de X-Scan-Signature: c5b001ed8a32557dab9f13d2bf4e6284 Cc: autoconf@ietf.org Subject: Re: [Autoconf] A-B-C general versus special (was: call for consensus about link local address support) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 09:43:22 -0000 --nextPart65887811.sZmZWZZkg0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Tue September 1 2009 11:36:05 schrieb Alexandru Petrescu: > I think rather this is the most generic thing which happens the most > often. (rather than the A-B-C situation which has to be created > specially and artificially). I totally disagree with you, I think the A-B-C case is THE typical basic bl= ock=20 of a larger mesh network. A node which stands between two other nodes which= =20 cannot see each other. If you have a mesh without this your cannot even create a multihop MANET=20 without multiple interfaces on each node ! Am Tue September 1 2009 11:39:08 schrieb Alexandru Petrescu: > That is a problem. I need at least 100 meters of linear distance to set > this A-B-C problem up. > > However, my setup is on a smaller than 50meter radius scale. > > I think more people have 50m radius to test with than 100m. I think what people use for testing does not matter at all. What matters is= =20 deployment of MANETs and they are typical deployed in scenarios where you n= eed=20 multihop forwarding because some nodes cannot see each other. > If I had 100m to test with and three nodes then the 'B' node would be a > bridge solving the A-B-C problem. You limit your autoconf sollution to networks where every node can see ever= y=20 other node. That's not a MANET in my oppinion. Henning Rogge ************************************************* Diplom Informatiker Henning Rogge =46orschungsgesellschaft f=FCr Angewandte Naturwissenschaften e. V. (FGAN)=20 Neuenahrer Str. 20, 53343 Wachtberg, Germany Tel.: 0049 (0)228 9435-961 =46ax: 0049 (0)228 9435-685 E-Mail: rogge@fgan.de Web: www.fgan.de ************************************************ Sitz der Gesellschaft: Bonn Registergericht: Amtsgericht Bonn VR 2530 Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim Ender=20 (Stellv.) --nextPart65887811.sZmZWZZkg0 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkqc7L4ACgkQRIfGfFXsz+BzVQCgmVWoPswYd08EARxhhCaPf1ID D+4An216c90FUh8vS45M3aNlytvSibpX =Vl6R -----END PGP SIGNATURE----- --nextPart65887811.sZmZWZZkg0-- From ulrich@herberg.name Tue Sep 1 02:44:14 2009 Return-Path: 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 E5BE828C695 for ; Tue, 1 Sep 2009 02:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 HckDUpM8CmZn for ; Tue, 1 Sep 2009 02:44:14 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 9AE8628C68C for ; Tue, 1 Sep 2009 02:44:13 -0700 (PDT) Received: by bwz19 with SMTP id 19so3378747bwz.37 for ; Tue, 01 Sep 2009 02:44:21 -0700 (PDT) MIME-Version: 1.0 Sender: ulrich@herberg.name Received: by 10.204.154.131 with SMTP id o3mr5393492bkw.66.1251798260555; Tue, 01 Sep 2009 02:44:20 -0700 (PDT) In-Reply-To: <4A9CEBBC.2040303@gmail.com> References: <200909011116.23020.rogge@fgan.de> <4A9CE7B7.2090407@gmail.com> <200909011129.25986.rogge@fgan.de> <4A9CEBBC.2040303@gmail.com> Date: Tue, 1 Sep 2009 11:44:20 +0200 X-Google-Sender-Auth: 7b4b2eb1bc238b30 Message-ID: <25c114b90909010244m4579aef8sb44695970dcada29@mail.gmail.com> From: Ulrich Herberg To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=0015175cae66a69ee8047280fe0f Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 09:44:15 -0000 --0015175cae66a69ee8047280fe0f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alex, you are describing your testbed that is limited to 50 meters. Tell me, how would you handle the following case: Every person in Paris has a wireless device (i.e. mobile phone with 802.11). How would you configure such a MANE= T with DAD and link-locals? And I mean configure on L3, not on L2 (which woul= d be outside the scope of AUTOCONF) Ulrich Ulrich On Tue, Sep 1, 2009 at 11:39 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Henning Rogge a =E9crit : > >> Am Tue September 1 2009 11:21:59 schrieb Alexandru Petrescu: >> >>> I don't have the A-B-C case to deal with. >>> >>> If I had to deal with it I would use a link-layer solution (a bridge), >>> such that DAD messages see all three nodes A, B and C. >>> >> Do you use wireless radios for your MANET ? >> > > Yes. > > > If yes the A-B-C szenario is one > >> of the most primitive things you can do with three nodes (and enough >> distance to prevent direct communication between node A and C). >> > > That is a problem. I need at least 100 meters of linear distance to set > this A-B-C problem up. > > However, my setup is on a smaller than 50meter radius scale. > > I think more people have 50m radius to test with than 100m. > > If I had 100m to test with and three nodes then the 'B' node would be a > bridge solving the A-B-C problem. > > Comments? > > Alex > > > --0015175cae66a69ee8047280fe0f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alex,

you are describing your testbed that is limited to 50 meters. = Tell me, how would you handle the following case: Every person in Paris has= a wireless device (i.e. mobile phone with 802.11). How would you configure= such a MANET with DAD and link-locals? And I mean configure on L3, not on = L2 (which would be outside the scope of AUTOCONF)

Ulrich

Ulrich

On Tue, Sep 1, 2= 009 at 11:39 AM, Alexandru Petrescu <alexandru.petrescu@gmail.com> = wrote:
Henning Rogge a = =E9crit :

Am Tue September 1 2009 11:21:59 schrieb Alexandru Petrescu:
I don't have the A-B-C case to deal with.

If I had to deal with it I would use a link-layer solution (a bridge),
such that DAD messages see all three nodes A, B and C.
Do you use wireless radios for your MANET ?

Yes.


> If yes the A-B-C szenario is one
of the most primitive things you can do with three nodes (and enough distan= ce to prevent direct communication between node A and C).

That is a problem. =A0I need at least 100 meters of linear distance to set = this A-B-C problem up.

However, my setup is on a smaller than 50meter radius scale.

I think more people have 50m radius to test with than 100m.

If I had 100m to test with and three nodes then the 'B' node would = be a bridge solving the A-B-C problem.

Comments?

Alex



--0015175cae66a69ee8047280fe0f-- From Chris.Dearlove@baesystems.com Tue Sep 1 02:49:05 2009 Return-Path: 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 6767128C68B for ; Tue, 1 Sep 2009 02:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] 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 rvENpfbpBTpk for ; Tue, 1 Sep 2009 02:49:04 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id B79D928C695 for ; Tue, 1 Sep 2009 02:46:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,311,1249254000"; d="scan'208";a="19863122" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 01 Sep 2009 10:47:02 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id n819l4LS019004; Tue, 1 Sep 2009 10:47:04 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Sep 2009 10:47:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 1 Sep 2009 10:47:00 +0100 Message-ID: In-Reply-To: <4A9CEBBC.2040303@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] call for consensus about link local address support thread-index: Acoq6BgC51OfhVfpToi44rieQPQjGQAAIDIg References: <200909011116.23020.rogge@fgan.de> <4A9CE7B7.2090407@gmail.com><200909011129.25986.rogge@fgan.de> <4A9CEBBC.2040303@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" , "Henning Rogge" X-OriginalArrivalTime: 01 Sep 2009 09:47:02.0212 (UTC) FILETIME=[281B8840:01CA2AE9] Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 09:49:05 -0000 >> If yes the A-B-C szenario is one >> of the most primitive things you can do with three nodes (and enough distance >> to prevent direct communication between node A and C). > That is a problem. I need at least 100 meters of linear distance to set > this A-B-C problem up. > However, my setup is on a smaller than 50meter radius scale. "There are more things in heaven and on earth that are dreamed of in your philosophy." > I think more people have 50m radius to test with than 100m. Actually, our interest is in what people really want in practical situations than in testing. Yes, testing over longer ranges is moree difficult. But as longer ranges are reality, testing has to follow reality. (In fact I'd rather have kilometres than hundreds of metres in many cases.) > If I had 100m to test with and three nodes then the 'B' node would be a > bridge solving the A-B-C problem. You have missed the point of ten years of work in this community (and more before that). ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From alexandru.petrescu@gmail.com Tue Sep 1 02:49:45 2009 Return-Path: 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 4F73A3A6EE1 for ; Tue, 1 Sep 2009 02:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 BAw1UWez0O7R for ; Tue, 1 Sep 2009 02:49:44 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 79D1D3A6A55 for ; Tue, 1 Sep 2009 02:49:42 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n819nocP024653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Sep 2009 11:49:50 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n819nnS6008905; Tue, 1 Sep 2009 11:49:49 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n819nnwt018867; Tue, 1 Sep 2009 11:49:49 +0200 Message-ID: <4A9CEE3D.9080103@gmail.com> Date: Tue, 01 Sep 2009 11:49:49 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ulrich Herberg References: <200909011116.23020.rogge@fgan.de> <4A9CE7B7.2090407@gmail.com> <200909011129.25986.rogge@fgan.de> <4A9CEBBC.2040303@gmail.com> <25c114b90909010244m4579aef8sb44695970dcada29@mail.gmail.com> In-Reply-To: <25c114b90909010244m4579aef8sb44695970dcada29@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 09:49:45 -0000 Ulrich Herberg a écrit : > Alex, > > you are describing your testbed that is limited to 50 meters. Tell me, > how would you handle the following case: Every person in Paris has a > wireless device (i.e. mobile phone with 802.11). How would you configure > such a MANET with DAD and link-locals? And I mean configure on L3, not > on L2 (which would be outside the scope of AUTOCONF) Ulrich, It is obvious that a large network such that you describe (15million devices in a city) need IP routers and wouldn't work solely with IPv6 link-local addresses. Many setups each limited to 50meters could be inter-connected by IP routers. A few by L2 bridges. It is not clear though how large networks does AUTOCONF address. I sense there is a private assumption that the AUTOCONF mechanism should work at the scale of an large network (your Paris question makes think so)... this should be clarified - how large the AUTOCONF network looks like? Alex > > Ulrich > > Ulrich > > On Tue, Sep 1, 2009 at 11:39 AM, Alexandru Petrescu > > wrote: > > Henning Rogge a écrit : > > Am Tue September 1 2009 11:21:59 schrieb Alexandru Petrescu: > > I don't have the A-B-C case to deal with. > > If I had to deal with it I would use a link-layer solution > (a bridge), > such that DAD messages see all three nodes A, B and C. > > Do you use wireless radios for your MANET ? > > > Yes. > > > > If yes the A-B-C szenario is one > > of the most primitive things you can do with three nodes (and > enough distance to prevent direct communication between node A > and C). > > > That is a problem. I need at least 100 meters of linear distance to > set this A-B-C problem up. > > However, my setup is on a smaller than 50meter radius scale. > > I think more people have 50m radius to test with than 100m. > > If I had 100m to test with and three nodes then the 'B' node would > be a bridge solving the A-B-C problem. > > Comments? > > Alex > > > From alexandru.petrescu@gmail.com Tue Sep 1 02:53:30 2009 Return-Path: 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 938423A69FB for ; Tue, 1 Sep 2009 02:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 4PnJ-WDV3sy0 for ; Tue, 1 Sep 2009 02:53:29 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 8983E3A697F for ; Tue, 1 Sep 2009 02:53:29 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n819ratd020586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Sep 2009 11:53:36 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n819raXE009857; Tue, 1 Sep 2009 11:53:36 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n819raTP020101; Tue, 1 Sep 2009 11:53:36 +0200 Message-ID: <4A9CEF1F.8010206@gmail.com> Date: Tue, 01 Sep 2009 11:53:35 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <200909011116.23020.rogge@fgan.de> <4A9CE7B7.2090407@gmail.com><200909011129.25986.rogge@fgan.de> <4A9CEBBC.2040303@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 09:53:30 -0000 Dearlove, Christopher (UK) a écrit : >>> If yes the A-B-C szenario is one >>> of the most primitive things you can do with three nodes (and enough > distance >>> to prevent direct communication between node A and C). > >> That is a problem. I need at least 100 meters of linear distance to > set >> this A-B-C problem up. > >> However, my setup is on a smaller than 50meter radius scale. > > "There are more things in heaven and on earth that are dreamed of in > your philosophy." Call me ignorant while you're at it - won't solve the AUTOCONF issues. >> I think more people have 50m radius to test with than 100m. > > Actually, our interest is in what people really want in practical > situations than in testing. Yes, testing over longer ranges is > moree difficult. But as longer ranges are reality, testing has to > follow reality. (In fact I'd rather have kilometres than hundreds > of metres in many cases.) Hmm... >> If I had 100m to test with and three nodes then the 'B' node would be >> a >> bridge solving the A-B-C problem. > > You have missed the point of ten years of work in this community > (and more before that). I vote for a) and that's it for today. Alex From ulrich@herberg.name Tue Sep 1 02:59:43 2009 Return-Path: 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 70E7A3A6F99 for ; Tue, 1 Sep 2009 02:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 C19c2KOY0m73 for ; Tue, 1 Sep 2009 02:59:42 -0700 (PDT) Received: from mail-fx0-f217.google.com (mail-fx0-f217.google.com [209.85.220.217]) by core3.amsl.com (Postfix) with ESMTP id 0C77F3A6F93 for ; Tue, 1 Sep 2009 02:59:41 -0700 (PDT) Received: by fxm17 with SMTP id 17so3382718fxm.37 for ; Tue, 01 Sep 2009 02:59:48 -0700 (PDT) MIME-Version: 1.0 Sender: ulrich@herberg.name Received: by 10.204.175.83 with SMTP id w19mr2970039bkz.24.1251799188737; Tue, 01 Sep 2009 02:59:48 -0700 (PDT) In-Reply-To: <4A9CEE3D.9080103@gmail.com> References: <200909011116.23020.rogge@fgan.de> <4A9CE7B7.2090407@gmail.com> <200909011129.25986.rogge@fgan.de> <4A9CEBBC.2040303@gmail.com> <25c114b90909010244m4579aef8sb44695970dcada29@mail.gmail.com> <4A9CEE3D.9080103@gmail.com> Date: Tue, 1 Sep 2009 11:59:48 +0200 X-Google-Sender-Auth: 095e3bcaed6a754f Message-ID: <25c114b90909010259r6ae2cc08uba3d18191131c7fc@mail.gmail.com> From: Ulrich Herberg To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=000325557ce2f98e3c04728135f0 Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 09:59:43 -0000 --000325557ce2f98e3c04728135f0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alex, On Tue, Sep 1, 2009 at 11:49 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Ulrich Herberg a =E9crit : > >> you are describing your testbed that is limited to 50 meters. Tell me, h= ow >> would you handle the following case: Every person in Paris has a wireles= s >> device (i.e. mobile phone with 802.11). How would you configure such a M= ANET >> with DAD and link-locals? And I mean configure on L3, not on L2 (which w= ould >> be outside the scope of AUTOCONF) >> > > It is obvious that a large network such that you describe (15million > devices in a city) need IP routers and wouldn't work solely with IPv6 > link-local addresses. > > Many setups each limited to 50meters could be inter-connected by IP > routers. A few by L2 bridges. > You mean a real setting? Or your testbed? As Chris mentioned, testbeds should reflect reality, and I don't think that a testbed contained in a 50m radius reflects any real setting. At least it's not the most general case. The Paris example is something more realistic, even though a solution has t= o cope with that. In an addressing document, we will not talk about the size of the MANET. > > It is not clear though how large networks does AUTOCONF address. > > I sense there is a private assumption that the AUTOCONF mechanism should > work at the scale of an large network (your Paris question makes think > so)... this should be clarified - how large the AUTOCONF network looks li= ke? > We are talking about an addressing document here (not a solution). This document will not say: "your MANET may not exceed 50 meters in diameter and may not have more than 100 nodes". Ulrich > >> On Tue, Sep 1, 2009 at 11:39 AM, Alexandru Petrescu < >> alexandru.petrescu@gmail.com > >> wrote: >> >> Henning Rogge a =E9crit : >> >> Am Tue September 1 2009 11:21:59 schrieb Alexandru Petrescu: >> >> I don't have the A-B-C case to deal with. >> >> If I had to deal with it I would use a link-layer solution >> (a bridge), >> such that DAD messages see all three nodes A, B and C. >> >> Do you use wireless radios for your MANET ? >> >> >> Yes. >> >> >> > If yes the A-B-C szenario is one >> >> of the most primitive things you can do with three nodes (and >> enough distance to prevent direct communication between node A >> and C). >> >> >> That is a problem. I need at least 100 meters of linear distance to >> set this A-B-C problem up. >> >> However, my setup is on a smaller than 50meter radius scale. >> >> I think more people have 50m radius to test with than 100m. >> >> If I had 100m to test with and three nodes then the 'B' node would >> be a bridge solving the A-B-C problem. >> >> Comments? >> >> Alex >> >> >> >> > > > --000325557ce2f98e3c04728135f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alex,

On Tue, Sep 1, 2009 at 11:49 AM, Al= exandru Petrescu <alexandru.petrescu@gmail.com> wrote:
Ulrich Herberg a =E9crit :

you are describing your testbed that is limited to 50 meters. Tell me, how = would you handle the following case: Every person in Paris has a wireless d= evice (i.e. mobile phone with 802.11). How would you configure such a MANET= with DAD and link-locals? And I mean configure on L3, not on L2 (which wou= ld be outside the scope of AUTOCONF)

It is obvious that a large network such that you describe (15million device= s in a city) need IP routers and wouldn't work solely with IPv6 link-lo= cal addresses.

Many setups each limited to 50meters could be inter-connected by IP routers= . =A0A few by L2 bridges.

You mean a real setting?= Or your testbed? As Chris mentioned, testbeds should reflect reality, and = I don't think that a testbed contained in a 50m radius reflects any rea= l setting. At least it's not the most general case. The Paris example i= s something more realistic, even though a solution has to cope with that. I= n an addressing document, we will not talk about the size of the MANET.

=A0

It is not clear though how large networks does AUTOCONF address.

I sense there is a private assumption that the AUTOCONF mechanism should wo= rk at the scale of an large network (your Paris question makes think so)...= this should be clarified - how large the AUTOCONF network looks like?

We are talking about an addressing document here (not= a solution). This document will not say: "your MANET may not exceed 5= 0 meters in diameter and may not have more than 100 nodes".

Ulrich


=A0

On Tue, Sep 1, 2009 at 11:39 AM, Alexandru Petrescu <alexandru.petrescu@gmail.com= <mailto:alexandru.petrescu@gmail.com>> wrote:

=A0 =A0Henning Rogge a =E9crit :

=A0 =A0 =A0 =A0Am Tue September 1 2009 11:21:59 schrieb Alexandru Petrescu= :

=A0 =A0 =A0 =A0 =A0 =A0I don't have the A-B-C case to deal with.

=A0 =A0 =A0 =A0 =A0 =A0If I had to deal with it I would use a link-layer s= olution
=A0 =A0 =A0 =A0 =A0 =A0(a bridge),
=A0 =A0 =A0 =A0 =A0 =A0such that DAD messages see all three nodes A, B and= C.

=A0 =A0 =A0 =A0Do you use wireless radios for your MANET ?


=A0 =A0Yes.


=A0 =A0 > If yes the A-B-C szenario is one

=A0 =A0 =A0 =A0of the most primitive things you can do with three nodes (a= nd
=A0 =A0 =A0 =A0enough distance to prevent direct communication between nod= e A
=A0 =A0 =A0 =A0and C).


=A0 =A0That is a problem. =A0I need at least 100 meters of linear distance= to
=A0 =A0set this A-B-C problem up.

=A0 =A0However, my setup is on a smaller than 50meter radius scale.

=A0 =A0I think more people have 50m radius to test with than 100m.

=A0 =A0If I had 100m to test with and three nodes then the 'B' nod= e would
=A0 =A0be a bridge solving the A-B-C problem.

=A0 =A0Comments?

=A0 =A0Alex







--000325557ce2f98e3c04728135f0-- From Chris.Dearlove@baesystems.com Tue Sep 1 03:21:13 2009 Return-Path: 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 CD3553A6834 for ; Tue, 1 Sep 2009 03:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 KpyPkAfAgKjb for ; Tue, 1 Sep 2009 03:21:12 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id D1C0F3A69AC for ; Tue, 1 Sep 2009 03:21:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,311,1249254000"; d="scan'208,217";a="19875409" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 01 Sep 2009 11:21:24 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id n81ALP69010012; Tue, 1 Sep 2009 11:21:26 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 11:21:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA2AED.F457111F" Date: Tue, 1 Sep 2009 11:21:23 +0100 Message-ID: In-Reply-To: <25c114b90909010259r6ae2cc08uba3d18191131c7fc@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] call for consensus about link local address support thread-index: Acoq6vj/13NpUlC4SQ2TgpnoXFDb7QAAj8+Q References: <200909011116.23020.rogge@fgan.de> <4A9CE7B7.2090407@gmail.com><200909011129.25986.rogge@fgan.de> <4A9CEBBC.2040303@gmail.com><25c114b90909010244m4579aef8sb44695970dcada29@mail.gmail.com><4A9CEE3D.9080103@gmail.com> <25c114b90909010259r6ae2cc08uba3d18191131c7fc@mail.gmail.com> From: "Dearlove, Christopher (UK)" To: "Ulrich Herberg" , "Alexandru Petrescu" X-OriginalArrivalTime: 01 Sep 2009 10:21:23.0535 (UTC) FILETIME=[F4C075F0:01CA2AED] Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 10:21:13 -0000 ------_=_NextPart_001_01CA2AED.F457111F Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I might not go as far as the Paris scenario as a first typical use case. But suppose we have a number of users (tens at least, maybe more) scattered over an area which is hundreds of metres wide, with radios with ranges of order of magnitude 100 metres, and moving about within that area and/or moving such that the area they cover also moves. Movement is at least partly random (i.e. topology varies). --=20 Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 =20 ________________________________ From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On Behal= f Of Ulrich Herberg Sent: 01 September 2009 11:00 To: Alexandru Petrescu Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message. Alex, On Tue, Sep 1, 2009 at 11:49 AM, Alexandru Petrescu wrote: =09Ulrich Herberg a =E9crit :=20 =09=09you are describing your testbed that is limited to 50 meters. Tell me= , how would you handle the following case: Every person in Paris has a wire= less device (i.e. mobile phone with 802.11). How would you configure such a= MANET with DAD and link-locals? And I mean configure on L3, not on L2 (whi= ch would be outside the scope of AUTOCONF) =09=09 =09It is obvious that a large network such that you describe (15million dev= ices in a city) need IP routers and wouldn't work solely with IPv6 link-loc= al addresses. =09 =09Many setups each limited to 50meters could be inter-connected by IP rout= ers. A few by L2 bridges. =09 You mean a real setting? Or your testbed? As Chris mentioned, testbeds shou= ld reflect reality, and I don't think that a testbed contained in a 50m rad= ius reflects any real setting. At least it's not the most general case. The= Paris example is something more realistic, even though a solution has to c= ope with that. In an addressing document, we will not talk about the size o= f the MANET. =20 =09It is not clear though how large networks does AUTOCONF address. =09 =09I sense there is a private assumption that the AUTOCONF mechanism should= work at the scale of an large network (your Paris question makes think so)= ... this should be clarified - how large the AUTOCONF network looks like? =09 We are talking about an addressing document here (not a solution). This doc= ument will not say: "your MANET may not exceed 50 meters in diameter and ma= y not have more than 100 nodes". Ulrich =20 =09=09On Tue, Sep 1, 2009 at 11:39 AM, Alexandru Petrescu > wrote: =09=09 =09=09 Henning Rogge a =E9crit : =09=09 =09=09 Am Tue September 1 2009 11:21:59 schrieb Alexandru Petrescu: =09=09 =09=09 I don't have the A-B-C case to deal with. =09=09 =09=09 If I had to deal with it I would use a link-layer solution =09=09 (a bridge), =09=09 such that DAD messages see all three nodes A, B and C. =09=09 =09=09 Do you use wireless radios for your MANET ? =09=09 =09=09 =09=09 Yes. =09=09 =09=09 =09=09 > If yes the A-B-C szenario is one =09=09 =09=09 of the most primitive things you can do with three nodes (and =09=09 enough distance to prevent direct communication between node A =09=09 and C). =09=09 =09=09 =09=09 That is a problem. I need at least 100 meters of linear distance = to =09=09 set this A-B-C problem up. =09=09 =09=09 However, my setup is on a smaller than 50meter radius scale. =09=09 =09=09 I think more people have 50m radius to test with than 100m. =09=09 =09=09 If I had 100m to test with and three nodes then the 'B' node would =09=09 be a bridge solving the A-B-C problem. =09=09 =09=09 Comments? =09=09 =09=09 Alex =09=09 =09=09 =09=09 =09=09 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** ------_=_NextPart_001_01CA2AED.F457111F Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I might not go as far as the Paris scenario as a= first=20 typical use case.
But suppose we have a number of users (tens at l= east,=20 maybe more)
scattered over an area which is hundreds of metr= es=20 wide, with radios
with ranges of order of magnitude 100 metres, an= d=20 moving about
within that area and/or moving such that the are= a they=20 cover also
moves. Movement is at least partly random (i.e.= =20 topology varies).

--
Christophe= r=20 Dearlove
Technology Leader, Communications Group
Networks, Security a= nd=20 Information Systems Department
BAE Systems Advanced Technology CentreWest=20 Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245= =20 242194  Fax: +44 1245 242124

BAE Systems (Operations)=20 Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aero= space=20 Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wal= es=20 No: 1996687

 

From: autoconf-bounces@ietf.org=20 [mailto:autoconf-bounces@ietf.org] On Behalf Of Ulrich=20 Herberg
Sent: 01 September 2009 11:00
To: Alexandru=20 Petrescu
Cc: autoconf@ietf.org
Subject: Re: [Autoconf] = call=20 for consensus about link local address support

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet.=20
      Keep this in mind if you answer this message.
Alex,

On Tue, Sep 1, 2009 at 11:49 AM, Alexandru Petresc= u <alexandru.petrescu@gmail.com>=20 wrote:
Ulrich=20 Herberg a =E9crit :

you=20 are describing your testbed that is limited to 50 meters. Tell me, how = would=20 you handle the following case: Every person in Paris has a wireless dev= ice=20 (i.e. mobile phone with 802.11). How would you configure such a MANET w= ith=20 DAD and link-locals? And I mean configure on L3, not on L2 (which would= be=20 outside the scope of AUTOCONF)

It is obvious = that a=20 large network such that you describe (15million devices in a city) need I= P=20 routers and wouldn't work solely with IPv6 link-local addresses.

M= any=20 setups each limited to 50meters could be inter-connected by IP routers.= =20  A few by L2 bridges.

You mean a real setting? Or your testbed? As Chris mentioned, test= beds=20 should reflect reality, and I don't think that a testbed contained in a 50m= =20 radius reflects any real setting. At least it's not the most general case. = The=20 Paris example is something more realistic, even though a solution has to co= pe=20 with that. In an addressing document, we will not talk about the size of th= e=20 MANET.

 

It=20 is not clear though how large networks does AUTOCONF address.

I se= nse=20 there is a private assumption that the AUTOCONF mechanism should work at = the=20 scale of an large network (your Paris question makes think so)... this sh= ould=20 be clarified - how large the AUTOCONF network looks like?

We are talking about an addressing document here (not a solution).= This=20 document will not say: "your MANET may not exceed 50 meters in diameter and= may=20 not have more than 100 nodes".

Ulrich


 

On Tue, Sep 1, 2009 at 11:39 AM, Alexandru Petrescu= <alexandru.petrescu@gmail.com <mailto:alexandru.petrescu@gmail.com>> wrote:

=  =20  Henning Rogge a =E9crit :

       Am Tu= e=20 September 1 2009 11:21:59 schrieb Alexandru Petrescu:

  &nb= sp;=20        I don't have the A-B-C case to deal=20 with.

           If I had to deal = with=20 it I would use a link-layer solution
        &nb= sp;=20  (a bridge),
           such that= DAD=20 messages see all three nodes A, B and C.

     =20  Do you use wireless radios for your MANET ?


 =20  Yes.


    > If yes the A-B-C szenario is= =20 one

       of the most primitive things you = can=20 do with three nodes (and
       enough distance = to=20 prevent direct communication between node A
     =20  and C).


   That is a problem.  I need a= t=20 least 100 meters of linear distance to
   set this A-B-C= =20 problem up.

   However, my setup is on a smaller than= =20 50meter radius scale.

   I think more people have 50m= =20 radius to test with than 100m.

   If I had 100m to tes= t=20 with and three nodes then the 'B' node would
   be a bridg= e=20 solving the A-B-C problem.

   Comments?

 = =20  Alex






<= /DIV>

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

------_=_NextPart_001_01CA2AED.F457111F-- From ulrich@herberg.name Tue Sep 1 03:30:06 2009 Return-Path: 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 770A23A6958 for ; Tue, 1 Sep 2009 03:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 TBgAj7jqGU3V for ; Tue, 1 Sep 2009 03:30:05 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 819E73A6942 for ; Tue, 1 Sep 2009 03:30:04 -0700 (PDT) Received: by bwz19 with SMTP id 19so3404094bwz.37 for ; Tue, 01 Sep 2009 03:30:14 -0700 (PDT) MIME-Version: 1.0 Sender: ulrich@herberg.name Received: by 10.204.155.71 with SMTP id r7mr5364925bkw.164.1251801013810; Tue, 01 Sep 2009 03:30:13 -0700 (PDT) In-Reply-To: References: <200909011116.23020.rogge@fgan.de> <4A9CE7B7.2090407@gmail.com> <200909011129.25986.rogge@fgan.de> <4A9CEBBC.2040303@gmail.com> <25c114b90909010244m4579aef8sb44695970dcada29@mail.gmail.com> <4A9CEE3D.9080103@gmail.com> <25c114b90909010259r6ae2cc08uba3d18191131c7fc@mail.gmail.com> Date: Tue, 1 Sep 2009 12:30:13 +0200 X-Google-Sender-Auth: c83e719fb249cd08 Message-ID: <25c114b90909010330q2ed906fdv642cf95d8c52e0b9@mail.gmail.com> From: Ulrich Herberg To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=0015175cba34c1f64e047281a28a Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 10:30:06 -0000 --0015175cba34c1f64e047281a28a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I admit that I chose an extreme example which may not be the first use case (at least not yet). However, even for that extreme example, the addressing document in its current version would be applicable. And in that scenario (even in much smaller scenarios), the mentioned A-B-C scenario would be encountered all the time and could probably not be fixed with bridges, so using link-locals has some severe problems. Ulrich P.S. According to Wikipedia, Paris has 2.2 million inhabitants and the metropolitan area around 11 million ;-) On Tue, Sep 1, 2009 at 12:21 PM, Dearlove, Christopher (UK) < Chris.Dearlove@baesystems.com> wrote: > I might not go as far as the Paris scenario as a first typical use case. > But suppose we have a number of users (tens at least, maybe more) > scattered over an area which is hundreds of metres wide, with radios > with ranges of order of magnitude 100 metres, and moving about > within that area and/or moving such that the area they cover also > moves. Movement is at least partly random (i.e. topology varies). > > -- > Christopher Dearlove > Technology Leader, Communications Group > Networks, Security and Information Systems Department > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 Fax: +44 1245 242124 > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, > Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > ------------------------------ > *From:* autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] *On > Behalf Of *Ulrich Herberg > *Sent:* 01 September 2009 11:00 > *To:* Alexandru Petrescu > *Cc:* autoconf@ietf.org > *Subject:* Re: [Autoconf] call for consensus about link local address > support > > *** WARNING *** > > This message has originated outside your organisation, > either from an external partner or the Global Internet. > Keep this in mind if you answer this message. > > > Alex, > > On Tue, Sep 1, 2009 at 11:49 AM, Alexandru Petrescu < > alexandru.petrescu@gmail.com> wrote: > >> Ulrich Herberg a =E9crit : >> >>> you are describing your testbed that is limited to 50 meters. Tell me, >>> how would you handle the following case: Every person in Paris has a >>> wireless device (i.e. mobile phone with 802.11). How would you configur= e >>> such a MANET with DAD and link-locals? And I mean configure on L3, not = on L2 >>> (which would be outside the scope of AUTOCONF) >>> >> >> It is obvious that a large network such that you describe (15million >> devices in a city) need IP routers and wouldn't work solely with IPv6 >> link-local addresses. >> >> Many setups each limited to 50meters could be inter-connected by IP >> routers. A few by L2 bridges. >> > > You mean a real setting? Or your testbed? As Chris mentioned, testbeds > should reflect reality, and I don't think that a testbed contained in a 5= 0m > radius reflects any real setting. At least it's not the most general case= . > The Paris example is something more realistic, even though a solution has= to > cope with that. In an addressing document, we will not talk about the siz= e > of the MANET. > > > >> >> It is not clear though how large networks does AUTOCONF address. >> >> I sense there is a private assumption that the AUTOCONF mechanism should >> work at the scale of an large network (your Paris question makes think >> so)... this should be clarified - how large the AUTOCONF network looks l= ike? >> > > We are talking about an addressing document here (not a solution). This > document will not say: "your MANET may not exceed 50 meters in diameter a= nd > may not have more than 100 nodes". > > Ulrich > > > > >> >>> On Tue, Sep 1, 2009 at 11:39 AM, Alexandru Petrescu < >>> alexandru.petrescu@gmail.com > >>> wrote: >>> >>> Henning Rogge a =E9crit : >>> >>> Am Tue September 1 2009 11:21:59 schrieb Alexandru Petrescu: >>> >>> I don't have the A-B-C case to deal with. >>> >>> If I had to deal with it I would use a link-layer solution >>> (a bridge), >>> such that DAD messages see all three nodes A, B and C. >>> >>> Do you use wireless radios for your MANET ? >>> >>> >>> Yes. >>> >>> >>> > If yes the A-B-C szenario is one >>> >>> of the most primitive things you can do with three nodes (and >>> enough distance to prevent direct communication between node A >>> and C). >>> >>> >>> That is a problem. I need at least 100 meters of linear distance to >>> set this A-B-C problem up. >>> >>> However, my setup is on a smaller than 50meter radius scale. >>> >>> I think more people have 50m radius to test with than 100m. >>> >>> If I had 100m to test with and three nodes then the 'B' node would >>> be a bridge solving the A-B-C problem. >>> >>> Comments? >>> >>> Alex >>> >>> >>> >>> >> >> >> > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > --0015175cba34c1f64e047281a28a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I admit that I chose an extreme example which may not be the first use case= (at least not yet). However, even for that extreme example, the addressing= document in its current version would be applicable. And in that scenario = (even in much smaller scenarios), the mentioned A-B-C scenario would be enc= ountered all the time and could probably not be fixed with bridges, so usin= g link-locals has some severe problems.

Ulrich

P.S. According to Wikipedia, Paris has 2.2 million inhabi= tants and the metropolitan area around 11 million ;-)

On Tue, Sep 1, 2009 at 12:21 PM, Dearlove, Christopher (UK) <Chris.= Dearlove@baesystems.com> wrote:
I might not go as far as the Paris scenario as a first=20 typical use case.
But suppose we have a number of users (tens at least,=20 maybe more)
scattered over an area which is hundreds of metres=20 wide, with radios
with ranges of order of magnitude 100 metres, and=20 moving about
within that area and/or moving such that the area they=20 cover also
moves. Movement is at least partly random (i.e.=20 topology varies).

--
Christopher=20 Dearlove
Technology Leader, Communications Group
Networks, Security a= nd=20 Information Systems Department
BAE Systems Advanced Technology CentreWest=20 Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245= =20 242194=A0 Fax: +44 1245 242124

BAE Systems (Operations)=20 Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aero= space=20 Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wal= es=20 No: 1996687

=A0

From: autoconf-bounces@ietf.org=20 [mailto:auto= conf-bounces@ietf.org] On Behalf Of Ulrich=20 Herberg
Sent: 01 September 2009 11:00
To: Alexandru=20 Petrescu
Cc: autoconf@ietf.org

Subject: Re: [Autoconf= ] call=20 for consensus about link local address support

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet.=20
      Keep this in mind if you answer this message.
Alex,

On Tue, Sep 1, 2009 at 11:49 AM, Alexandru Petre= scu <alexandru.petrescu@gmail.com>=20 wrote:
Ulrich=20 Herberg a =E9crit :

you=20 are describing your testbed that is limited to 50 meters. Tell me, how = would=20 you handle the following case: Every person in Paris has a wireless dev= ice=20 (i.e. mobile phone with 802.11). How would you configure such a MANET w= ith=20 DAD and link-locals? And I mean configure on L3, not on L2 (which would= be=20 outside the scope of AUTOCONF)

It is obvious = that a=20 large network such that you describe (15million devices in a city) need I= P=20 routers and wouldn't work solely with IPv6 link-local addresses.
<= br>Many=20 setups each limited to 50meters could be inter-connected by IP routers.= =20 =A0A few by L2 bridges.

You mean a real setting? Or your testbed? As Chris mentioned, test= beds=20 should reflect reality, and I don't think that a testbed contained in a= 50m=20 radius reflects any real setting. At least it's not the most general ca= se. The=20 Paris example is something more realistic, even though a solution has to co= pe=20 with that. In an addressing document, we will not talk about the size of th= e=20 MANET.

=A0

It=20 is not clear though how large networks does AUTOCONF address.

I se= nse=20 there is a private assumption that the AUTOCONF mechanism should work at = the=20 scale of an large network (your Paris question makes think so)... this sh= ould=20 be clarified - how large the AUTOCONF network looks like?

We are talking about an addressing document here (not a solution).= This=20 document will not say: "your MANET may not exceed 50 meters in diamete= r and may=20 not have more than 100 nodes".

Ulrich


=A0

On Tue, Sep 1, 2009 at 11:39 AM, Alexandru Petrescu <alexandru.petre= scu@gmail.com <mailto:alexandru.petrescu@gmail.com>> wrote:

=A0=20 =A0Henning Rogge a =E9crit :

=A0 =A0 =A0 =A0Am Tue=20 September 1 2009 11:21:59 schrieb Alexandru Petrescu:

=A0 =A0=20 =A0 =A0 =A0 =A0I don't have the A-B-C case to deal=20 with.

=A0 =A0 =A0 =A0 =A0 =A0If I had to deal with=20 it I would use a link-layer solution
=A0 =A0 =A0 =A0 =A0=20 =A0(a bridge),
=A0 =A0 =A0 =A0 =A0 =A0such that DAD=20 messages see all three nodes A, B and C.

=A0 =A0 =A0=20 =A0Do you use wireless radios for your MANET ?


=A0=20 =A0Yes.


=A0 =A0 > If yes the A-B-C szenario is=20 one

=A0 =A0 =A0 =A0of the most primitive things you can=20 do with three nodes (and
=A0 =A0 =A0 =A0enough distance to=20 prevent direct communication between node A
=A0 =A0 =A0=20 =A0and C).


=A0 =A0That is a problem. =A0I need at=20 least 100 meters of linear distance to
=A0 =A0set this A-B-C=20 problem up.

=A0 =A0However, my setup is on a smaller than=20 50meter radius scale.

=A0 =A0I think more people have 50m=20 radius to test with than 100m.

=A0 =A0If I had 100m to test=20 with and three nodes then the 'B' node would
=A0 =A0be a bri= dge=20 solving the A-B-C problem.

=A0 =A0Comments?

=A0=20 =A0Alex








********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************


--0015175cba34c1f64e047281a28a-- From rogge@fgan.de Tue Sep 1 03:36:08 2009 Return-Path: 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 459653A698C for ; Tue, 1 Sep 2009 03:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.064 X-Spam-Level: X-Spam-Status: No, score=-6.064 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] 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 KmwaxXP2ASOn for ; Tue, 1 Sep 2009 03:36:07 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 6AC0D3A67D9 for ; Tue, 1 Sep 2009 03:36:07 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MiQio-0004uj-MC; Tue, 01 Sep 2009 12:36:18 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MiQio-000531-DM; Tue, 01 Sep 2009 12:36:18 +0200 From: Henning Rogge To: autoconf@ietf.org Date: Tue, 1 Sep 2009 12:36:18 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.30-10-generic; KDE/4.2.2; i686; ; ) References: <25c114b90909010330q2ed906fdv642cf95d8c52e0b9@mail.gmail.com> In-Reply-To: <25c114b90909010330q2ed906fdv642cf95d8c52e0b9@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1737491.jziHGd3tFQ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200909011236.18942.rogge@fgan.de> X-Virus-Scanned: yes (ClamAV 0.95.2/9763/Tue Sep 1 09:02:27 2009) by mailguard.fgan.de X-Scan-Signature: ad1983844cdfc65af3eaa1381589e1d9 Cc: "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 10:36:08 -0000 --nextPart1737491.jziHGd3tFQ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Tue September 1 2009 12:30:13 schrieb Ulrich Herberg: > P.S. According to Wikipedia, Paris has 2.2 million inhabitants and the > metropolitan area around 11 million ;-) A manet with millions of nodes is just a few years away... At=20 =46reifunk/Olsr.org we have tested a network with 1000 nodes and hope we ca= n=20 extend our software to city-meshes with 10000+ nodes. But I don't think=20 100.000 or even a million nodes is impossible, it will just require more=20 applied research. ;) Henning Rogge ************************************************* Diplom Informatiker Henning Rogge =46orschungsgesellschaft f=C3=BCr Angewandte Naturwissenschaften e. V. (FGAN)=20 Neuenahrer Str. 20, 53343 Wachtberg, Germany Tel.: 0049 (0)228 9435-961 =46ax: 0049 (0)228 9435-685 E-Mail: rogge@fgan.de Web: www.fgan.de ************************************************ Sitz der Gesellschaft: Bonn Registergericht: Amtsgericht Bonn VR 2530 Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim Ender=20 (Stellv.) --nextPart1737491.jziHGd3tFQ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkqc+SIACgkQRIfGfFXsz+BAGACgj7xw4KWX5/JMtEIRkS6PO48j nf4An0BnSjXUbT+R1r1cA/yTyQeJExM/ =B5CD -----END PGP SIGNATURE----- --nextPart1737491.jziHGd3tFQ-- From teco@inf-net.nl Tue Sep 1 06:48:14 2009 Return-Path: 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 16D913A6880 for ; Tue, 1 Sep 2009 06:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.19 X-Spam-Level: X-Spam-Status: No, score=0.19 tagged_above=-999 required=5 tests=[AWL=-1.035, BAYES_40=-0.185, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 7K6Q96yirrjP for ; Tue, 1 Sep 2009 06:48:13 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 403763A6FD6 for ; Tue, 1 Sep 2009 06:47:54 -0700 (PDT) Received: (qmail 7053 invoked from network); 1 Sep 2009 15:48:05 +0200 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 1 Sep 2009 15:48:05 +0200 From: "Teco Boot" To: "'Henning Rogge'" , References: <25c114b90909010330q2ed906fdv642cf95d8c52e0b9@mail.gmail.com> <200909011236.18942.rogge@fgan.de> In-Reply-To: <200909011236.18942.rogge@fgan.de> Date: Tue, 1 Sep 2009 15:47:05 +0200 Message-ID: <008901ca2b0a$c358e250$4a0aa6f0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acoq8A4Rzhka36i0S2yd5QYsgFQxBAAGhFsQ Content-Language: nl Cc: "'Dearlove, Christopher \(UK\)'" Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 13:48:14 -0000 For support of millions of nodes, I think using a backbone makes sense. Luckily, this is in place. All we have to do is provide topologically correct addresses and select the direct path to nearby nodes and the path to a border router to nodes that are beyond some limit. Not available today with IETF protocols, but for sure possible and more or less operational already. Teco. |Van: Henning Rogge |Am Tue September 1 2009 12:30:13 schrieb Ulrich Herberg: |> P.S. According to Wikipedia, Paris has 2.2 million inhabitants and the |> metropolitan area around 11 million ;-) |A manet with millions of nodes is just a few years away... At |Freifunk/Olsr.org we have tested a network with 1000 nodes and hope we |can |extend our software to city-meshes with 10000+ nodes. But I don't think |100.000 or even a million nodes is impossible, it will just require more |applied research. ;) | |Henning Rogge From sratliff@cisco.com Tue Sep 1 08:11:03 2009 Return-Path: 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 F24A428C797 for ; Tue, 1 Sep 2009 08:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.354 X-Spam-Level: X-Spam-Status: No, score=-6.354 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 qdgwOgDe+z9C for ; Tue, 1 Sep 2009 08:10:40 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id CD6263A7067 for ; Tue, 1 Sep 2009 08:08:32 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFAGPWnEpAZnme/2dsb2JhbACCJjDCMIhBAS8Ij0oFgj0ICIFOgVyJBQ X-IronPort-AV: E=Sophos;i="4.44,312,1249257600"; d="scan'208,217";a="56314115" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 01 Sep 2009 15:08:20 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n81F8KSq013275; Tue, 1 Sep 2009 11:08:20 -0400 Received: from dhcp-64-102-54-254.cisco.com (dhcp-64-102-54-254.cisco.com [64.102.54.254]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n81F8KJu014123; Tue, 1 Sep 2009 15:08:20 GMT Message-Id: <8D976461-A167-4089-B8D3-25638E331C60@cisco.com> From: Stan Ratliff To: Ulrich Herberg In-Reply-To: <25c114b90909010130h38d3a580pf54fc7be5dba8f24@mail.gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-1-780078911 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 1 Sep 2009 11:08:22 -0400 References: <4A9CD038.1060007@earthlink.net> <25c114b90909010130h38d3a580pf54fc7be5dba8f24@mail.gmail.com> X-Mailer: Apple Mail (2.936) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8874; t=1251817700; x=1252681700; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20Stan=20Ratliff=20 |Subject:=20Re=3A=20[Autoconf]=20call=20for=20consensus=20a bout=20link=20local=20address=20support |Sender:=20 |To:=20Ulrich=20Herberg=20; bh=MOKKj9AJPzuAoZoxbEX/AzRao73OPIvkcsvglccwmME=; b=gvvftkYwZ6u6PRt93EvSAz3UIWr7HYMZrTX9Mmn8A4kpSH2pUjOGviS3Fj sp2vlSLebXrk+5NeqB6gtyF1ccQtj81lt7iOk5dbTHwYg+PPkyBCv0TMBQja 4WO8bWZ8uL; Authentication-Results: rtp-dkim-1; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 15:11:04 -0000 --Apple-Mail-1-780078911 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hello Ryuji, Another vote for option (b). Regards, Stan On Sep 1, 2009, at 4:30 AM, Ulrich Herberg wrote: > Hello Ryuji, > > I agree with Charlie and support (b). In my opinion, there are still > many unresolved issues with link-locals in MANETs and could delay or > even limit solutions. The document should not prohibit link-locals > though (which it does not), it just does not require them. > > Regards, > Ulrich > > On Tue, Sep 1, 2009 at 9:41 AM, Charles E. Perkins > wrote: > > Hello Ryuji, > > I support (b). In fact, I very strongly support it. > > And, if further reasoning is needed, I would supply it in a > different note. Bottom line is, I think that requiring link-local > will drastically limit our solution space and eliminate some > very useful solutions (such as those which have already > been built). > > To be accurate, I think we ought to support unique-local > -INCLUSIVE OR- global addresses. In some situations > (disconnected networks) global address autoconfiguration > may not be possible. > > Regards, > Charlie P. > > > > > Ryuji Wakikawa wrote: > Hi all, > > This is consensus call about the link-local address support in MANET. > Please review the following call for consensus and vote your opinion > by Sep10th. > > DT will update the document according to our consensus. > > thanks, > Thomas & ryuji > > ------------------------------------------------------------------ > CALL FOR CONSENSUS > > Deadline: 2009-09-10 6:00PM PST. > > Target ID: Design Team Document > "IP Addressing Model in Ad Hoc Networks" > http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model-01 > > Issue (cited from the above draft): > - Use of Link Local Addresses - while the use of link local > addresses on > interfaces connecting to a MANET link is not prohibited, the > semantics > of "link local" in this context is yet to be defined, taking into > account the unusual requirements that follow, concerning such > addresses. These requirements include for example uniqueness within a > scope spanning beyond a single IP hop. > > Some discussions can be found at the IETF75 AUTOCONF minutes > http://www.ietf.org/proceedings/75/minutes/autoconf.txt > > Please vote your preference between the following two alternatives. > If you have another alternative, please propose it and give your > reasons why you prefer that alternative. > > a) The document shall support link-local addresses as required > for nodes in a MANET in addition to unique-local and global > addresses. > > b) Support unique-local and global addresses as required for MANET > nodes. The document shall not prohibit using link-local addresses, > but shall describe the difficulties inhibiting compliance in MANET > with the standardized IPv6 properties that characterize the use of > link-local addresses. > ------------------------------------------------------------------ > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf --Apple-Mail-1-780078911 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello = Ryuji, 

Another vote for option = (b).

Regards,
Stan

<= div>On Sep 1, 2009, at 4:30 AM, Ulrich Herberg wrote:

Hello = Ryuji,

I agree with Charlie and support (b). In my opinion, there = are still many unresolved issues with link-locals in MANETs and could = delay or even limit solutions. The document should not prohibit = link-locals though (which it does not), it just does not require = them.

Regards,
Ulrich

On = Tue, Sep 1, 2009 at 9:41 AM, Charles E. Perkins <charles.perkins@earthlink.ne= t> wrote:

Hello Ryuji,

I support (b). =  In fact, I very strongly support it.

And, if further = reasoning is needed, I would supply it in a
different note. =  Bottom line is, I think that requiring link-local
will = drastically limit our solution space and eliminate some
very useful = solutions (such as those which have already
been built).

To = be accurate, I think we ought to support unique-local
-INCLUSIVE OR- = global addresses.  In some situations
(disconnected networks) = global address autoconfiguration
may not be possible.

= Regards,
Charlie P.



=
Ryuji Wakikawa wrote:
Hi all,

This is consensus call = about the link-local address support in MANET.
Please review the = following call for consensus and vote your opinion by Sep10th.

= DT will update the document according to our consensus.

= thanks,
Thomas & ryuji

= ------------------------------------------------------------------
= CALL FOR CONSENSUS

Deadline: 2009-09-10 6:00PM PST.

= Target ID: Design Team Document
"IP Addressing Model in Ad Hoc = Networks"
http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc= -addr-model-01

Issue (cited from the above draft):
- = Use of Link Local Addresses - while the use of link local addresses = on
 interfaces connecting to a MANET link is not prohibited, = the semantics
 of "link local" in this context is yet to be = defined, taking into
 account the unusual requirements that = follow, concerning such
 addresses. These requirements include = for example uniqueness within a
 scope spanning beyond a single = IP hop.

Some discussions can be found at the IETF75 AUTOCONF = minutes
http://www.ietf.org/proceedings/75/minutes/autoconf.txt<= /a>

Please vote your preference between the following two = alternatives.
If you have another alternative, please propose it and = give your
reasons why you prefer that alternative.

a) The = document shall support link-local addresses as required
 for = nodes in a MANET in addition to unique-local and global
=  addresses.

b) Support unique-local and global addresses = as required for MANET
 nodes.  The document shall not = prohibit using link-local addresses,
 but shall describe the = difficulties inhibiting compliance in MANET
 with the = standardized IPv6 properties that characterize the use of
=  link-local addresses.
= ------------------------------------------------------------------
= _______________________________________________
Autoconf mailing = list
Autoconf@ietf.org
https://www.ietf.org/mailman/listinfo/autoconf
=


= _______________________________________________
Autoconf mailing = list
Autoconf@ietf.org
https://www.ietf.org/mailman/listinfo/autoconf
=

= _______________________________________________
Autoconf mailing = list
Autoconf@ietf.org
https://www.iet= f.org/mailman/listinfo/autoconf

= --Apple-Mail-1-780078911-- From Ronald.intVelt@tno.nl Tue Sep 1 16:25:28 2009 Return-Path: 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 5A0F23A6F40 for ; Tue, 1 Sep 2009 16:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[AWL=0.855, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 u8ToBp0uH42L for ; Tue, 1 Sep 2009 16:25:27 -0700 (PDT) Received: from mailoutb.tno.nl (mailoutb.tno.nl [134.221.1.17]) by core3.amsl.com (Postfix) with ESMTP id CD6033A6A67 for ; Tue, 1 Sep 2009 16:25:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,314,1249250400"; d="scan'208";a="5715106" Received: from ms-dt01thalia.tno.nl (HELO ms-dt01thalia.tsn.tno.nl) ([134.221.225.157]) by mailhost1b.tno.nl with ESMTP; 02 Sep 2009 01:25:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Sep 2009 01:25:35 +0200 Message-ID: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] call for consensus about link local address support Thread-Index: AcoqIdK/kwC0YBxEQp+jHQBii6bB3gBNDHsg References: From: "Velt, R. (Ronald) in 't" To: "Ryuji Wakikawa" , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 23:25:28 -0000 Hi Ryuji, all,=20 > This is consensus call about the link-local address support in MANET. > Please review the following call for consensus and vote your=20 > opinion by Sep10th. >=20 > DT will update the document according to our consensus. >=20 > thanks, > Thomas & ryuji >=20 > ------------------------------------------------------------------ > CALL FOR CONSENSUS >=20 > Deadline: 2009-09-10 6:00PM PST. >=20 > Target ID: Design Team Document > "IP Addressing Model in Ad Hoc Networks" > http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model-01 >=20 > Issue (cited from the above draft): > - Use of Link Local Addresses - while the use of link local=20 > addresses on > interfaces connecting to a MANET link is not prohibited,=20 > the semantics > of "link local" in this context is yet to be defined, taking into > account the unusual requirements that follow, concerning such > addresses. These requirements include for example=20 > uniqueness within a > scope spanning beyond a single IP hop. >=20 > Some discussions can be found at the IETF75 AUTOCONF minutes=20 > http://www.ietf.org/proceedings/75/minutes/autoconf.txt >=20 > Please vote your preference between the following two alternatives. > If you have another alternative, please propose it and give=20 > your reasons why you prefer that alternative. >=20 > a) The document shall support link-local addresses as required > for nodes in a MANET in addition to unique-local and global > addresses. >=20 > b) Support unique-local and global addresses as required for MANET > nodes. The document shall not prohibit using link-local addresses, > but shall describe the difficulties inhibiting compliance in MANET > with the standardized IPv6 properties that characterize the use of > link-local addresses. a) is my preference, narrowed down to *IPv6* link-locals. This is about the ad hoc addresssing model. I'm not entirely sure what "shall support" means in this context. However, for the sake of completeness, the document should acknowledge the existence of IPv6 link-local addresses, state compliance (or not) with what existing RFCs mandate w.r.t. link-locals, describe their use in MANET routing and/or data forwarding, as well as mention potential pitfalls associated with their use. If/when the WG moves on to discussing "solution space", it may decide to concentrate on mechanisms for the auto-configuration of global addresses and ULAs. At the Stockholm meeting there already seemed to be concensus on doing so. I am fine with that. Thanks, Ronald in 't Velt This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/disclaimer/email.html From mase@ie.niigata-u.ac.jp Tue Sep 1 17:32:24 2009 Return-Path: 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 CF18B3A6893 for ; Tue, 1 Sep 2009 17:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.282 X-Spam-Level: X-Spam-Status: No, score=0.282 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 QSHRVmDnls5H for ; Tue, 1 Sep 2009 17:32:24 -0700 (PDT) Received: from mxav02.cc.niigata-u.ac.jp (mxav02.cc.niigata-u.ac.jp [133.35.17.130]) by core3.amsl.com (Postfix) with ESMTP id BB7933A6847 for ; Tue, 1 Sep 2009 17:32:23 -0700 (PDT) Received: from mxav02.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8C348454282 for ; Wed, 2 Sep 2009 09:32:04 +0900 (JST) Received: from chamame.ie.niigata-u.ac.jp (chamame.ie.niigata-u.ac.jp [133.35.169.34]) by mxav02.cc.niigata-u.ac.jp (Postfix) with SMTP id 816A1454266 for ; Wed, 2 Sep 2009 09:32:04 +0900 (JST) Received: (qmail 4279 invoked from network); 2 Sep 2009 09:32:04 +0900 Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 2 Sep 2009 09:32:04 +0900 Message-Id: <7.0.0.16.2.20090902093052.06148dd8@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Wed, 02 Sep 2009 09:32:04 +0900 To: Ryuji Wakikawa ,autoconf@ietf.org From: mase In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 00:32:24 -0000 I vote for b. Thanks, Kenichi At 18:59 09/08/31, Ryuji Wakikawa wrote: >Hi all, > >This is consensus call about the link-local address support in MANET. >Please review the following call for consensus and vote your opinion >by Sep10th. > >DT will update the document according to our consensus. > >thanks, >Thomas & ryuji > >------------------------------------------------------------------ >CALL FOR CONSENSUS > >Deadline: 2009-09-10 6:00PM PST. > >Target ID: Design Team Document >"IP Addressing Model in Ad Hoc Networks" >http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model-01 > >Issue (cited from the above draft): >- Use of Link Local Addresses - while the use of link local addresses on > interfaces connecting to a MANET link is not prohibited, the semantics > of "link local" in this context is yet to be defined, taking into > account the unusual requirements that follow, concerning such > addresses. These requirements include for example uniqueness within a > scope spanning beyond a single IP hop. > >Some discussions can be found at the IETF75 AUTOCONF minutes >http://www.ietf.org/proceedings/75/minutes/autoconf.txt > >Please vote your preference between the following two alternatives. >If you have another alternative, please propose it and give your >reasons why you prefer that alternative. > >a) The document shall support link-local addresses as required > for nodes in a MANET in addition to unique-local and global > addresses. > >b) Support unique-local and global addresses as required for MANET > nodes. The document shall not prohibit using link-local addresses, > but shall describe the difficulties inhibiting compliance in MANET > with the standardized IPv6 properties that characterize the use of > link-local addresses. >------------------------------------------------------------------ >_______________________________________________ >Autoconf mailing list >Autoconf@ietf.org >https://www.ietf.org/mailman/listinfo/autoconf > From rogge@fgan.de Wed Sep 2 00:08:15 2009 Return-Path: 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 770AC3A68FD for ; Wed, 2 Sep 2009 00:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.214 X-Spam-Level: X-Spam-Status: No, score=-6.214 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 9nUlcolfC2zu for ; Wed, 2 Sep 2009 00:08:14 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 5E5843A686A for ; Wed, 2 Sep 2009 00:08:14 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MijTT-0004OP-T5; Wed, 02 Sep 2009 08:37:43 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MijTT-0002Q1-KR; Wed, 02 Sep 2009 08:37:43 +0200 From: Henning Rogge To: autoconf@ietf.org Date: Wed, 2 Sep 2009 08:37:43 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.30-10-generic; KDE/4.2.2; i686; ; ) References: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart48152694.V13892Nqrm"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200909020837.43851.rogge@fgan.de> X-Virus-Scanned: yes (ClamAV 0.95.2/9765/Wed Sep 2 07:42:39 2009) by mailguard.fgan.de X-Scan-Signature: 809a703b503da7be30d8e1aebe74084b Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 07:08:15 -0000 --nextPart48152694.V13892Nqrm Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Wed September 2 2009 01:25:35 schrieb Velt, R. (Ronald) in 't: > > a) The document shall support link-local addresses as required > > for nodes in a MANET in addition to unique-local and global > > addresses. > > > > b) Support unique-local and global addresses as required for MANET > > nodes. The document shall not prohibit using link-local addresses, > > but shall describe the difficulties inhibiting compliance in MANET > > with the standardized IPv6 properties that characterize the use of > > link-local addresses. > > a) is my preference, narrowed down to *IPv6* link-locals. > > This is about the ad hoc addresssing model. I'm not entirely sure what > "shall support" means in this context. However, for the sake of > completeness, the document should acknowledge the existence of IPv6 > link-local addresses, state compliance (or not) with what existing RFCs > mandate w.r.t. link-locals, describe their use in MANET routing and/or > data forwarding, as well as mention potential pitfalls associated with > their use. Okay, it seems we have a problem with the wording of a) and b). When I read the options a) and b) I was a little bit unsure what to do with= =20 them. I talked with Ulrich Herbert about it and we decided that a) means th= at=20 ALL autoconf drafts have to support link-local addresses while b) means tha= t=20 link-local support is not mandatory for autoconf sollutions, but may be=20 included in drafts as a feature. The other viewpoint I had for the two options was that a) means link-local= =20 support is considered for documents of the autoconf WG, but b) means that i= t=20 is 'out of scope' of this working group. Can someone confirm we have an issue or that I'm just confused ? I see potential THREE options being discussed: 1) link-local support should be mandatory for autoconf. Every autoconf draf= t=20 working on the problem configuring interfaces must support link-local IPs. 2) link-local support is optional for autoconf. It's within the are of this= =20 WG, but not all autoconf drafts need to support it. Drafts MUST state if th= ey support link-local IPs or not. 3) link-local support is out of scope for this WG. They should not be inclu= ded=20 into autoconf drafts. I thought that a) means 1) and b) means 2), but I'm not sure if parts of th= is=20 group think that b) means 3). Henning Rogge ************************************************* Diplom Informatiker Henning Rogge =46orschungsgesellschaft f=FCr Angewandte Naturwissenschaften e. V. (FGAN)=20 Neuenahrer Str. 20, 53343 Wachtberg, Germany Tel.: 0049 (0)228 9435-961 =46ax: 0049 (0)228 9435-685 E-Mail: rogge@fgan.de Web: www.fgan.de ************************************************ Sitz der Gesellschaft: Bonn Registergericht: Amtsgericht Bonn VR 2530 Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim Ender=20 (Stellv.) --nextPart48152694.V13892Nqrm Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkqeErcACgkQRIfGfFXsz+BKMACcDEVIX2v2VPbnYgFC6Z4thN6O Ni4AoKhWjgbSYFPAt17cRjTAoxMklNXh =RGib -----END PGP SIGNATURE----- --nextPart48152694.V13892Nqrm-- From ulrich@herberg.name Wed Sep 2 00:21:26 2009 Return-Path: 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 B05963A680A for ; Wed, 2 Sep 2009 00:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 2NdrNhFhaa2M for ; Wed, 2 Sep 2009 00:21:25 -0700 (PDT) Received: from mail-fx0-f217.google.com (mail-fx0-f217.google.com [209.85.220.217]) by core3.amsl.com (Postfix) with ESMTP id 4A9093A67FC for ; Wed, 2 Sep 2009 00:21:24 -0700 (PDT) Received: by fxm17 with SMTP id 17so576615fxm.37 for ; Wed, 02 Sep 2009 00:20:12 -0700 (PDT) MIME-Version: 1.0 Sender: ulrich@herberg.name Received: by 10.204.160.90 with SMTP id m26mr6445577bkx.63.1251876011924; Wed, 02 Sep 2009 00:20:11 -0700 (PDT) In-Reply-To: <200909020837.43851.rogge@fgan.de> References: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl> <200909020837.43851.rogge@fgan.de> Date: Wed, 2 Sep 2009 09:20:11 +0200 X-Google-Sender-Auth: 42fe1132bc1ee0dd Message-ID: <25c114b90909020020x355ba523x24f43df7d10440ef@mail.gmail.com> From: Ulrich Herberg To: Henning Rogge Content-Type: multipart/alternative; boundary=0015175cd9fcfe5e540472931836 Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 07:21:26 -0000 --0015175cd9fcfe5e540472931836 Content-Type: text/plain; charset=ISO-8859-1 Hi Ronald, I agree with Henning. When I read your answer, I was not sure whether your arguments are really for vote a). In my opinion, the argument would fit to b) as well. Am Wed September 2 2009 01:25:35 schrieb Velt, R. (Ronald) in 't: > [...] > > > > a) is my preference, narrowed down to *IPv6* link-locals. > > > > This is about the ad hoc addresssing model. I'm not entirely sure what > > "shall support" means in this context. However, for the sake of > > completeness, the document should acknowledge the existence of IPv6 > > link-local addresses, > IMO, the document does not (and will not) deny the existence of IPv6 link locals. It just does not mandate that such an address must be auto-configured by a solution. It does not exclude so either, due to some pitfalls, as you say. > state compliance (or not) with what existing RFCs > > mandate w.r.t. link-locals, describe their use in MANET routing and/or > > data forwarding, as well as mention potential pitfalls associated with > > their use. > Erik Nordmark wrote a -- as I think -- very useful paragraph about the pitfalls of link-locals. That could be included in the document, I suggest. On Wed, Sep 2, 2009 at 8:37 AM, Henning Rogge wrote: > Okay, it seems we have a problem with the wording of a) and b). > > When I read the options a) and b) I was a little bit unsure what to do with > them. I talked with Ulrich Herbert It's Herber*g* :-p > about it and we decided that a) means that > ALL autoconf drafts have to support link-local addresses while b) means > that > link-local support is not mandatory for autoconf sollutions, but may be > included in drafts as a feature. > > The other viewpoint I had for the two options was that a) means link-local > support is considered for documents of the autoconf WG, but b) means that > it > is 'out of scope' of this working group. > > Can someone confirm we have an issue or that I'm just confused ? > I let others (Ryuji?) confirm (or not) this possible wording issue. Ulrich > > > > > I see potential THREE options being discussed: > > 1) link-local support should be mandatory for autoconf. Every autoconf > draft > working on the problem configuring interfaces must support link-local IPs. > > 2) link-local support is optional for autoconf. It's within the are of this > WG, but not all autoconf drafts need to support it. Drafts MUST state if > they > support link-local IPs or not. > > 3) link-local support is out of scope for this WG. They should not be > included > into autoconf drafts. > > > I thought that a) means 1) and b) means 2), but I'm not sure if parts of > this > group think that b) means 3). > > --0015175cd9fcfe5e540472931836 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ronald,

I agree with Henning. When I read your answer, I was not = sure whether your arguments are really for vote a). In my opinion, the argu= ment would fit to b) as well.


Am Wed September 2 2009 01:25:35 schrieb Velt, R. (Ronald) in 't:
[...]
>
> a) is my preference, narrowed down to *IPv6* link-locals.
>
> This is about the ad hoc addresssing model. I'm not entirely sure = what
> "shall support" means in this context. However, for the sake= of
> completeness, the document should acknowledge the existence of IPv6 > link-local addresses,

IMO, the document do= es not (and will not) deny the existence of IPv6 link locals. It just does = not mandate that such an address must be auto-configured by a solution. It = does not exclude so either, due to some pitfalls, as you say.
=A0
state compliance (or not) with what existing RFCs
> mandate w.r.t. link-locals, describe their use in MANET routing and/or=
> data forwarding, as well as mention potential pitfalls associated with=
> their use.

Erik Nordmark wrote a -- as = I think -- very useful paragraph about the pitfalls of link-locals. That co= uld be included in the document, I suggest.

On Wed, Sep = 2, 2009 at 8:37 AM, Henning Rogge <rogge@fgan.de> wrote:
Okay, it seems we have a problem with the wording of a) and b).

When I read the options a) and b) I was a little bit unsure what to do with=
them. I talked with Ulrich Herbert

It's Herber*g*= :-p

=A0
about it and we decided that a) means that
ALL autoconf drafts have to support link-local addresses while b) means tha= t
link-local support is not mandatory for autoconf sollutions, but may be
included in drafts as a feature.

The other viewpoint I had for the two options was that a) means link-local<= br> support is considered for documents of the autoconf WG, but b) means that i= t
is 'out of scope' of this working group.

Can someone confirm we have an issue or that I'm just confused ?

I let others (Ryuji?) confirm (or not) this possible wor= ding issue.

Ulrich
=A0




I see potential THREE options being discussed:

1) link-local support should be mandatory for autoconf. Every autoconf draf= t
working on the problem configuring interfaces must support link-local IPs.<= br>
2) link-local support is optional for autoconf. It's within the are of = this
WG, but not all autoconf drafts need to support it. Drafts MUST state if th= ey
support link-local IPs or not.

3) link-local support is out of scope for this WG. They should not be inclu= ded
into autoconf drafts.


I thought that a) means 1) and b) means 2), but I'm not sure if parts o= f this
group think that b) means 3).

--0015175cd9fcfe5e540472931836-- From ryuji.wakikawa@gmail.com Wed Sep 2 01:07:24 2009 Return-Path: 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 6652B3A6B90 for ; Wed, 2 Sep 2009 01:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 aXpIuVBjykOC for ; Wed, 2 Sep 2009 01:07:23 -0700 (PDT) Received: from mail-pz0-f199.google.com (mail-pz0-f199.google.com [209.85.222.199]) by core3.amsl.com (Postfix) with ESMTP id CC7013A7050 for ; Wed, 2 Sep 2009 01:07:22 -0700 (PDT) Received: by pzk37 with SMTP id 37so622615pzk.17 for ; Wed, 02 Sep 2009 01:06:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=ZFeHKVBsOW1JTKSg/UR0vhnGogMmoOtZGqOcJ7IjC+U=; b=WTK/OyTKhxf5VMdo7+Eq9nrNNC6k2PRv1APQ8zdb/3ViYA8aFasLEjHLbNQFoJgwO7 w7agYgmuw0NUdJDTSU3ZFqy2gN/ywcwut7AyovuONkdcFXoFHEMweZ5g9dWoJoCrbZ0b K9X7IvR8bVHZMRADLBp/U98aqyF1CQj8XXh2U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=Pc1pTxtDnU6XHn074kgA/yfRLf3/4qtsfQlg42yOX+2vw5kx6mon74KLFDS+HxNiJV 4CigiM6P3fyndZGJDa6nSVfPWpljctnJ6UESrxxwxb2/vy+RcWVfF53wVchc78N6xUS0 E687nFqKIx8PV+i/XKhFqOyh9UiJd2C4gNJEI= Received: by 10.115.87.7 with SMTP id p7mr5910088wal.161.1251876936901; Wed, 02 Sep 2009 00:35:36 -0700 (PDT) Received: from ?192.168.25.206? (p3003-ipbfpfx02kyoto.kyoto.ocn.ne.jp [125.207.177.35]) by mx.google.com with ESMTPS id v39sm236914wah.12.2009.09.02.00.35.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Sep 2009 00:35:35 -0700 (PDT) From: Ryuji Wakikawa To: Henning Rogge In-Reply-To: <200909020837.43851.rogge@fgan.de> References: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl> <200909020837.43851.rogge@fgan.de> Message-Id: <63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 2 Sep 2009 16:35:31 +0900 X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 08:07:24 -0000 Hi On 2009/09/02, at 15:37, Henning Rogge wrote: > Am Wed September 2 2009 01:25:35 schrieb Velt, R. (Ronald) in 't: >>> a) The document shall support link-local addresses as required >>> for nodes in a MANET in addition to unique-local and global >>> addresses. >>> >>> b) Support unique-local and global addresses as required for MANET >>> nodes. The document shall not prohibit using link-local addresses, >>> but shall describe the difficulties inhibiting compliance in MANET >>> with the standardized IPv6 properties that characterize the use of >>> link-local addresses. >> >> a) is my preference, narrowed down to *IPv6* link-locals. >> >> This is about the ad hoc addresssing model. I'm not entirely sure =20 >> what >> "shall support" means in this context. However, for the sake of >> completeness, the document should acknowledge the existence of IPv6 >> link-local addresses, state compliance (or not) with what existing =20= >> RFCs >> mandate w.r.t. link-locals, describe their use in MANET routing and/=20= >> or >> data forwarding, as well as mention potential pitfalls associated =20 >> with >> their use. > Okay, it seems we have a problem with the wording of a) and b). > > When I read the options a) and b) I was a little bit unsure what to =20= > do with > them. I talked with Ulrich Herbert about it and we decided that a) =20 > means that > ALL autoconf drafts have to support link-local addresses while b) =20 > means that > link-local support is not mandatory for autoconf sollutions, but may =20= > be > included in drafts as a feature. > > The other viewpoint I had for the two options was that a) means link-=20= > local > support is considered for documents of the autoconf WG, but b) means =20= > that it > is 'out of scope' of this working group. > > Can someone confirm we have an issue or that I'm just confused ? > > > > > I see potential THREE options being discussed: > > 1) link-local support should be mandatory for autoconf. Every =20 > autoconf draft > working on the problem configuring interfaces must support link-=20 > local IPs. > > 2) link-local support is optional for autoconf. It's within the are =20= > of this > WG, but not all autoconf drafts need to support it. Drafts MUST =20 > state if they > support link-local IPs or not. > > 3) link-local support is out of scope for this WG. They should not =20 > be included > into autoconf drafts. This consensus call is only for our single WG item, "IP Addressing =20 Model in Ad Hoc Networks". We seek the consensus whether we will deal with link-local address or =20= not in this work. a) The link-local address is supported for MANET nodes. b) The link-local address is not supported and not defined for MANET =20 nodes in the document. The difficulty and possible problems of the link-local addresses =20= in MANET will be explained in the document. regards, ryuji > > > I thought that a) means 1) and b) means 2), but I'm not sure if =20 > parts of this > group think that b) means 3). > > Henning Rogge > > ************************************************* > Diplom Informatiker Henning Rogge > Forschungsgesellschaft f=FCr > Angewandte Naturwissenschaften e. V. (FGAN) > Neuenahrer Str. 20, 53343 Wachtberg, Germany > Tel.: 0049 (0)228 9435-961 > Fax: 0049 (0)228 9435-685 > E-Mail: rogge@fgan.de > Web: www.fgan.de > ************************************************ > Sitz der Gesellschaft: Bonn > Registergericht: Amtsgericht Bonn VR 2530 > Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim Ender > (Stellv.) > From teco@inf-net.nl Wed Sep 2 02:03:45 2009 Return-Path: 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 E6DB03A690A for ; Wed, 2 Sep 2009 02:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[AWL=0.648, BAYES_00=-2.599] 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 3p+-yuudEXsu for ; Wed, 2 Sep 2009 02:03:44 -0700 (PDT) Received: from CPSMTPM-EML108.kpnxchange.com (Cpsmtpm-eml108.kpnxchange.com [195.121.3.12]) by core3.amsl.com (Postfix) with ESMTP id A46C03A68DE for ; Wed, 2 Sep 2009 02:03:43 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML108.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Wed, 2 Sep 2009 10:49:40 +0200 From: "Teco Boot" To: "'Ryuji Wakikawa'" , "'Henning Rogge'" References: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl> <200909020837.43851.rogge@fgan.de> <63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com> In-Reply-To: <63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com> Date: Wed, 2 Sep 2009 10:49:09 +0200 Message-ID: <006701ca2baa$3c720320$b5560960$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcorpIbRqqSsSz69Ro69V6OvsUbYLQAAwR7w Content-language: nl X-OriginalArrivalTime: 02 Sep 2009 08:49:40.0171 (UTC) FILETIME=[4EE781B0:01CA2BAA] Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 09:03:46 -0000 Even further confused. I still vote for A, as link-locals are required on IPv6 nodes [RFC4291], = for sure for router interfaces [RFC4861]. As Ronald pointed out, the addressing model is just the addressing model and not the requirements document for Autoconf solutions. And I also = felt that we had consensus in Stockholm on including link-locals in the = document (is A), but with clarifying text (as Erik Nordmark provided, and where I suggested some updates). I see 4 options on the table: 1: link-locals are not configured on interfaces in a MANET 2: link-locals are configured on interfaces in a MANET, but not used 3: link-locals are configured on interfaces in a MANET, but used only = where=20 applicable 4: we need an address autoconfiguration mechanism for link-local = addresses in a MANET. I think we end up somewhere between 2 and 3 (A??). Erik his text was = more or less 2, my adjustment "up/downgraded" to 3. I don't understand some of us worked on OSPF-MANET, but vote for B. If B = is 1 (or 2?), I expect some clarifications. There is a lot of stuff around, requiring ND. Any idea how to support = this? Teco. |-----Oorspronkelijk bericht----- |Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] = Namens |Ryuji Wakikawa |Verzonden: woensdag 2 september 2009 9:36 |Aan: Henning Rogge |CC: autoconf@ietf.org |Onderwerp: Re: [Autoconf] call for consensus about link local address |support | |Hi | |On 2009/09/02, at 15:37, Henning Rogge wrote: | |> Am Wed September 2 2009 01:25:35 schrieb Velt, R. (Ronald) in 't: |>>> a) The document shall support link-local addresses as required |>>> for nodes in a MANET in addition to unique-local and global |>>> addresses. |>>> |>>> b) Support unique-local and global addresses as required for MANET |>>> nodes. The document shall not prohibit using link-local = addresses, |>>> but shall describe the difficulties inhibiting compliance in MANET |>>> with the standardized IPv6 properties that characterize the use of |>>> link-local addresses. |>> |>> a) is my preference, narrowed down to *IPv6* link-locals. |>> |>> This is about the ad hoc addresssing model. I'm not entirely sure |>> what |>> "shall support" means in this context. However, for the sake of |>> completeness, the document should acknowledge the existence of IPv6 |>> link-local addresses, state compliance (or not) with what existing |>> RFCs |>> mandate w.r.t. link-locals, describe their use in MANET routing and/ |>> or |>> data forwarding, as well as mention potential pitfalls associated |>> with |>> their use. |> Okay, it seems we have a problem with the wording of a) and b). |> |> When I read the options a) and b) I was a little bit unsure what to |> do with |> them. I talked with Ulrich Herbert about it and we decided that a) |> means that |> ALL autoconf drafts have to support link-local addresses while b) |> means that |> link-local support is not mandatory for autoconf sollutions, but may |> be |> included in drafts as a feature. |> |> The other viewpoint I had for the two options was that a) means link- |> local |> support is considered for documents of the autoconf WG, but b) means |> that it |> is 'out of scope' of this working group. |> |> Can someone confirm we have an issue or that I'm just confused ? |> |> |> |> |> I see potential THREE options being discussed: |> |> 1) link-local support should be mandatory for autoconf. Every |> autoconf draft |> working on the problem configuring interfaces must support link- |> local IPs. |> |> 2) link-local support is optional for autoconf. It's within the are |> of this |> WG, but not all autoconf drafts need to support it. Drafts MUST |> state if they |> support link-local IPs or not. |> |> 3) link-local support is out of scope for this WG. They should not |> be included |> into autoconf drafts. | | |This consensus call is only for our single WG item, "IP Addressing |Model in Ad Hoc Networks". |We seek the consensus whether we will deal with link-local address or |not in this work. | |a) The link-local address is supported for MANET nodes. |b) The link-local address is not supported and not defined for MANET |nodes in the document. | The difficulty and possible problems of the link-local addresses |in MANET will be explained in the document. | | |regards, |ryuji | |> |> |> I thought that a) means 1) and b) means 2), but I'm not sure if |> parts of this |> group think that b) means 3). |> |> Henning Rogge |> |> ************************************************* |> Diplom Informatiker Henning Rogge |> Forschungsgesellschaft f=FCr |> Angewandte Naturwissenschaften e. V. (FGAN) |> Neuenahrer Str. 20, 53343 Wachtberg, Germany |> Tel.: 0049 (0)228 9435-961 |> Fax: 0049 (0)228 9435-685 |> E-Mail: rogge@fgan.de |> Web: www.fgan.de |> ************************************************ |> Sitz der Gesellschaft: Bonn |> Registergericht: Amtsgericht Bonn VR 2530 |> Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim = Ender |> (Stellv.) |> | |_______________________________________________ |Autoconf mailing list |Autoconf@ietf.org |https://www.ietf.org/mailman/listinfo/autoconf From Chris.Dearlove@baesystems.com Wed Sep 2 07:59:31 2009 Return-Path: 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 46A0D3A6BE0 for ; Wed, 2 Sep 2009 07:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] 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 bodqLs56TVry for ; Wed, 2 Sep 2009 07:59:30 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id DFC183A6A64 for ; Wed, 2 Sep 2009 07:56:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,318,1249254000"; d="scan'208";a="20192441" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 02 Sep 2009 15:36:46 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id n82EamVD018749; Wed, 2 Sep 2009 15:36:48 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 15:36:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 2 Sep 2009 15:36:44 +0100 Message-ID: In-Reply-To: <006701ca2baa$3c720320$b5560960$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] call for consensus about link local address support thread-index: AcorpIbRqqSsSz69Ro69V6OvsUbYLQAAwR7wAAv9C7A= References: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl> <200909020837.43851.rogge@fgan.de><63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com> <006701ca2baa$3c720320$b5560960$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Ryuji Wakikawa" , "Henning Rogge" X-OriginalArrivalTime: 02 Sep 2009 14:36:45.0654 (UTC) FILETIME=[CBDC0760:01CA2BDA] Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 14:59:31 -0000 > I still vote for A, as link-locals are required on IPv6 nodes [RFC4291], > for sure for router interfaces [RFC4861]. The suggested compromise in Stockholm was that IPv6 nodes would have link local addresses, but they might not be used, and wouldn't be the intended target of autoconf. > And I also felt > that we had consensus in Stockholm on including link-locals in the document > (is A) This is showing where the A/B distinction may not be clear. The consensus in Stockholm was definitely not for A as I understood it from Ryuji's post. The consensus was, I agree, not to say that "link local addresses are prohibited" but, as I understood it, it was for "we will design an autoconf mechanism that will hand out addresses, those addresses will be global or unique local". (Those are only meant to be rough statements, not precise ones.) > I see 4 options on the table: Yes, it isn't simply A/B. > 1: link-locals are not configured on interfaces in a MANET That I think is not allowed. > 2: link-locals are configured on interfaces in a MANET, but not used > 3: link-locals are configured on interfaces in a MANET, but used only where applicable I'll come back to those. > 4: we need an address autoconfiguration mechanism for link-local addresses in a MANET. That I think is not going to work, because that will bog down the group (in fact I think it will kill it) while the conflicting "whatever addresses you need will be visible two hops away" and "link local addresses should not be seen more than one hop away" requirement and position deadlock. > I think we end up somewhere between 2 and 3 (A??). Agreed, it is somewhere in the 2 to 3 range. But I see that as B, not A, where either we have 2, or we have 3, and "autoconfigured by a mechanism designed in the autoconf group" is considered not applicable for link local addresses. > Erik his text was more or > less 2, my adjustment "up/downgraded" to 3. > I don't understand some of us worked on OSPF-MANET, but vote for B. If B is > 1 (or 2?), I expect some clarifications. I think even 3, subject to the comments I made above (maybe call that 2.5) could be B. I suggest that rather than the A/B thing, someone appropriate sets out what they think the Stockholm consensus was (it will take a few bullet points) and sees who can support it. I think that will actually show more agreement that is currently appearing, and if there is disagreement, will focus it on key points. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From emmanuel.baccelli@gmail.com Wed Sep 2 08:45:16 2009 Return-Path: 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 EEB8028C12A for ; Wed, 2 Sep 2009 08:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 hZ4RSyZU9ghm for ; Wed, 2 Sep 2009 08:45:15 -0700 (PDT) Received: from mail-fx0-f217.google.com (mail-fx0-f217.google.com [209.85.220.217]) by core3.amsl.com (Postfix) with ESMTP id A3DD43A683B for ; Wed, 2 Sep 2009 08:45:14 -0700 (PDT) Received: by fxm17 with SMTP id 17so876910fxm.37 for ; Wed, 02 Sep 2009 08:44:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to :content-type; bh=8Ipwngb23rrahfb+CN3W3NyAfUbJBc+xdVznpS4RMGs=; b=M8/23PUBUsaHVXXH6muf57yqNYGiAhu+duk3e8J31JRm7waDGTB7Z5/27q0m7KYW/4 LCdDebwxl+5qXsxOymelPYYyVb1mEl4C2uPv8rcG7xV/RcxiLgCZjCZIsQ45fivhxMU2 3mxHQkXHMWqpg0XbIDATO+abBSDwo9O7qNeBA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=U+lTYVoJ5Cv0FVBxDipBgQunry7rGmob200Z+vRm9v0Ac0OiTW4PiBHuURcf/MhZuH JF4EmPXkU24Y4akfuuf9aSYp9VHet5yOZIdt//hA7ZBR0bFeGwukwplWIQfvTyHKfZVz FCLVKsA2Jq6LeutkCnEyv0CbnZodDSu0aXlKQ= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.103.126.32 with SMTP id d32mr3643772mun.0.1251905822111; Wed, 02 Sep 2009 08:37:02 -0700 (PDT) In-Reply-To: References: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl> <200909020837.43851.rogge@fgan.de> <63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com> <006701ca2baa$3c720320$b5560960$@nl> From: Emmanuel Baccelli Date: Wed, 2 Sep 2009 17:36:42 +0200 X-Google-Sender-Auth: af4e3ea698105b85 Message-ID: To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=001636499907d1baa504729a09e6 Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 15:45:16 -0000 --001636499907d1baa504729a09e6 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 2, 2009 at 4:36 PM, Dearlove, Christopher (UK) < Chris.Dearlove@baesystems.com> wrote: > > > The suggested compromise in Stockholm was that IPv6 nodes > would have link local addresses, but they might not be used, > and wouldn't be the intended target of autoconf. > > > And I also felt > > that we had consensus in Stockholm on including link-locals in the > document > > (is A) > > This is showing where the A/B distinction may not be clear. > > The consensus in Stockholm was definitely not for A as I > understood it from Ryuji's post. The consensus was, I agree, > not to say that "link local addresses are prohibited" but, as > I understood it, it was for "we will design an autoconf > mechanism that will hand out addresses, those addresses will > be global or unique local". (Those are only meant to be rough > statements, not precise ones.) > I also felt like the Stockholm consensus was more along the lines described above by Chris, with an accompanying, explicit warning about the use of LLs (for which Erik proposed some initial text in an email he sent during this very meeting ;) Anybody else feeling the same? Emmanuel --001636499907d1baa504729a09e6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Sep= 2, 2009 at 4:36 PM, Dearlove, Christopher (UK) <Chris.Dearlove@baesystems.com> wrote:

The suggested compromise in Stockholm was that IPv6 nodes
would have link local addresses, but they might not be used,
and wouldn't be the intended target of autoconf.

> And I also felt
> that we had consensus in Stockholm on including link-locals in the
document
> (is A)

This is showing where the A/B distinction may not be clear.

The consensus in Stockholm was definitely not for A as I
understood it from Ryuji's post. The consensus was, I agree,
not to say that "link local addresses are prohibited" but, as
I understood it, it was for "we will design an autoconf
mechanism that will hand out addresses, those addresses will
be global or unique local". (Those are only meant to be rough
statements, not precise ones.)



I also felt like the Stockholm consensus was more alo= ng the lines described above by Chris, with an accompanying, explicit warni= ng about the use of LLs (for which Erik proposed some initial text in an em= ail he sent during this very meeting ;)=A0

Anybody else feeling the same?

Emmanuel

=A0
--001636499907d1baa504729a09e6-- From sratliff@cisco.com Wed Sep 2 09:24:39 2009 Return-Path: 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 8009228C7C3 for ; Wed, 2 Sep 2009 09:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.376 X-Spam-Level: X-Spam-Status: No, score=-6.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 PaiIRtxesr-G for ; Wed, 2 Sep 2009 09:24:38 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 5D52828C8D9 for ; Wed, 2 Sep 2009 09:24:38 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMM4nkqrR7PE/2dsb2JhbADDOIhBAZBYBYQbgVw X-IronPort-AV: E=Sophos;i="4.44,318,1249257600"; d="scan'208";a="187166036" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 02 Sep 2009 16:23:54 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n82GNsC9022119; Wed, 2 Sep 2009 09:23:54 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n82GNrbv010388; Wed, 2 Sep 2009 16:23:54 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 12:23:53 -0400 Received: from [64.102.54.37] ([64.102.54.37]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 12:23:53 -0400 Message-ID: <4A9E9C19.60808@cisco.com> Date: Wed, 02 Sep 2009 12:23:53 -0400 From: Stan Ratliff User-Agent: Thunderbird 1.5.0.12 (X11/20080131) MIME-Version: 1.0 To: Ryuji Wakikawa References: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl> <200909020837.43851.rogge@fgan.de> <63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com> In-Reply-To: <63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 02 Sep 2009 16:23:53.0169 (UTC) FILETIME=[C2F4FC10:01CA2BE9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4390; t=1251908634; x=1252772634; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20Stan=20Ratliff=20 |Subject:=20Re=3A=20[Autoconf]=20call=20for=20consensus=20a bout=20link=20local=20address=20support |Sender:=20; bh=zaYTcdNKewIhGJ2jQO5h5IgoUYbuYcQvnt7H6ouEG08=; b=TdDYGbiZgNirTiMLSWdqyFb0ZfG/00WZAQFMRO3vffd4Q3Amm4+sIL0yq8 VCR9q5WeAcw9iof/potHSOee7RpWnJ8NDaTFARsFHzzAj67oWgJ5DBmSwV21 6MP600Shgi; Authentication-Results: sj-dkim-4; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 16:24:39 -0000 Ryuji, You confused me with that response. Your last articulation of option (b) is NOT something I'd support, as it appears to totally preclude use of link locals. I'm much more in favor of the initial option (b) text, which is: "Support unique-local and global addresses as required for MANET nodes. The document shall not preclude using link-local addresses, but shall describe the difficulties inhibiting compliance in MANET with the standardizes IPv6 properties that characterize the use of link-local addresses." Regards, Stan Ryuji Wakikawa wrote: > Hi > > On 2009/09/02, at 15:37, Henning Rogge wrote: > >> Am Wed September 2 2009 01:25:35 schrieb Velt, R. (Ronald) in 't: >>>> a) The document shall support link-local addresses as required >>>> for nodes in a MANET in addition to unique-local and global >>>> addresses. >>>> >>>> b) Support unique-local and global addresses as required for MANET >>>> nodes. The document shall not prohibit using link-local addresses, >>>> but shall describe the difficulties inhibiting compliance in MANET >>>> with the standardized IPv6 properties that characterize the use of >>>> link-local addresses. >>> >>> a) is my preference, narrowed down to *IPv6* link-locals. >>> >>> This is about the ad hoc addresssing model. I'm not entirely sure what >>> "shall support" means in this context. However, for the sake of >>> completeness, the document should acknowledge the existence of IPv6 >>> link-local addresses, state compliance (or not) with what existing RFCs >>> mandate w.r.t. link-locals, describe their use in MANET routing and/or >>> data forwarding, as well as mention potential pitfalls associated with >>> their use. >> Okay, it seems we have a problem with the wording of a) and b). >> >> When I read the options a) and b) I was a little bit unsure what to >> do with >> them. I talked with Ulrich Herbert about it and we decided that a) >> means that >> ALL autoconf drafts have to support link-local addresses while b) >> means that >> link-local support is not mandatory for autoconf sollutions, but may be >> included in drafts as a feature. >> >> The other viewpoint I had for the two options was that a) means >> link-local >> support is considered for documents of the autoconf WG, but b) means >> that it >> is 'out of scope' of this working group. >> >> Can someone confirm we have an issue or that I'm just confused ? >> >> >> >> >> I see potential THREE options being discussed: >> >> 1) link-local support should be mandatory for autoconf. Every >> autoconf draft >> working on the problem configuring interfaces must support link-local >> IPs. >> >> 2) link-local support is optional for autoconf. It's within the are >> of this >> WG, but not all autoconf drafts need to support it. Drafts MUST state >> if they >> support link-local IPs or not. >> >> 3) link-local support is out of scope for this WG. They should not be >> included >> into autoconf drafts. > > > This consensus call is only for our single WG item, "IP Addressing > Model in Ad Hoc Networks". > We seek the consensus whether we will deal with link-local address or > not in this work. > > a) The link-local address is supported for MANET nodes. > b) The link-local address is not supported and not defined for MANET > nodes in the document. > The difficulty and possible problems of the link-local addresses > in MANET will be explained in the document. > > > regards, > ryuji > >> >> >> I thought that a) means 1) and b) means 2), but I'm not sure if parts >> of this >> group think that b) means 3). >> >> Henning Rogge >> >> ************************************************* >> Diplom Informatiker Henning Rogge >> Forschungsgesellschaft für >> Angewandte Naturwissenschaften e. V. (FGAN) >> Neuenahrer Str. 20, 53343 Wachtberg, Germany >> Tel.: 0049 (0)228 9435-961 >> Fax: 0049 (0)228 9435-685 >> E-Mail: rogge@fgan.de >> Web: www.fgan.de >> ************************************************ >> Sitz der Gesellschaft: Bonn >> Registergericht: Amtsgericht Bonn VR 2530 >> Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim Ender >> (Stellv.) >> > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From emmanuel.baccelli@gmail.com Wed Sep 2 10:02:49 2009 Return-Path: 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 BA2A33A70CA for ; Wed, 2 Sep 2009 10:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.797 X-Spam-Level: X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 uM0hbRh2fPne for ; Wed, 2 Sep 2009 10:02:49 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 86FE53A67AD for ; Wed, 2 Sep 2009 10:02:48 -0700 (PDT) Received: by bwz19 with SMTP id 19so870309bwz.37 for ; Wed, 02 Sep 2009 10:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to :content-type; bh=D6nocZWGHcWjraFLfEu1VHAkPwYc6JAQ5rw5GhhPZ2k=; b=ofhYECx+VMqq832yQWOdqc4HLsP9bu3FaFUaHmf13CwOhb1SGnDJyRP/pOoDwE9v+I 1l4+uxLWxgedptGMDUjCH8+fVRNu4UpcVPs5+LGGHA05ONKuGKf0CPteXtPHEsXeBUKJ 5N48/EvNygxPLwVR7cJ2OKEt79YQv2dlodjeQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=NLMsp0V2Ec8U5w/E0b7EYVKiSlo0UnDXIwehvGils0cDjrlM70POYeUY87A5AaGxdk gZqcgfQYVAomvxPzI76QcgYYL9cPUzsiwwclplC0bjaNljl1ljiMt9WBN5OP32Df6iRS FxD7ttIQvSzoQFffqDdQLxTwjgi4pMlTiNJIs= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.103.78.35 with SMTP id f35mr3691251mul.89.1251910912110; Wed, 02 Sep 2009 10:01:52 -0700 (PDT) In-Reply-To: References: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl> <200909020837.43851.rogge@fgan.de> <63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com> <006701ca2baa$3c720320$b5560960$@nl> From: Emmanuel Baccelli Date: Wed, 2 Sep 2009 19:01:32 +0200 X-Google-Sender-Auth: 641ed10186036d50 Message-ID: To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=0016e65bcf3034f0d704729b3921 Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 17:02:49 -0000 --0016e65bcf3034f0d704729b3921 Content-Type: text/plain; charset=ISO-8859-1 I am in favor of B by the way (to be a little more explicit than my previous email ;).cheers, Emmanuel On Wed, Sep 2, 2009 at 5:36 PM, Emmanuel Baccelli < Emmanuel.Baccelli@inria.fr> wrote: > > On Wed, Sep 2, 2009 at 4:36 PM, Dearlove, Christopher (UK) < > Chris.Dearlove@baesystems.com> wrote: >> >> >> The suggested compromise in Stockholm was that IPv6 nodes >> would have link local addresses, but they might not be used, >> and wouldn't be the intended target of autoconf. >> >> > And I also felt >> > that we had consensus in Stockholm on including link-locals in the >> document >> > (is A) >> >> This is showing where the A/B distinction may not be clear. >> >> The consensus in Stockholm was definitely not for A as I >> understood it from Ryuji's post. The consensus was, I agree, >> not to say that "link local addresses are prohibited" but, as >> I understood it, it was for "we will design an autoconf >> mechanism that will hand out addresses, those addresses will >> be global or unique local". (Those are only meant to be rough >> statements, not precise ones.) >> > > > > I also felt like the Stockholm consensus was more along the lines described > above by Chris, with an accompanying, explicit warning about the use of LLs > (for which Erik proposed some initial text in an email he sent during this > very meeting ;) > > Anybody else feeling the same? > > Emmanuel > > > --0016e65bcf3034f0d704729b3921 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am in favor of B by the way (to be a little more explicit than my previou= s email ;).
cheers,
Emmanuel



<= div class=3D"gmail_quote">On Wed, Sep 2, 2009 at 5:36 PM, Emmanuel Baccelli= <Emmanu= el.Baccelli@inria.fr> wrote:

On Wed, Sep 2, 2009 at 4:36 PM, Dear= love, Christopher (UK) <Chris.Dearlove@baesystems.com><= /span> wrote:

The suggested compromise in Stockholm was that IPv6 nodes
would have link local addresses, but they might not be used,
and wouldn't be the intended target of autoconf.

> And I also felt
> that we had consensus in Stockholm on including link-locals in the
document
> (is A)

This is showing where the A/B distinction may not be clear.

The consensus in Stockholm was definitely not for A as I
understood it from Ryuji's post. The consensus was, I agree,
not to say that "link local addresses are prohibited" but, as
I understood it, it was for "we will design an autoconf
mechanism that will hand out addresses, those addresses will
be global or unique local". (Those are only meant to be rough
statements, not precise ones.)



I also felt like the Stockholm consensus was mo= re along the lines described above by Chris, with an accompanying, explicit= warning about the use of LLs (for which Erik proposed some initial text in= an email he sent during this very meeting ;)=A0

Anybody else feeling the same?

Emmanuel

=A0

--0016e65bcf3034f0d704729b3921-- From narten@us.ibm.com Wed Sep 2 11:17:59 2009 Return-Path: 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 2022D3A682F for ; Wed, 2 Sep 2009 11:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 E4nx1IQ9UOcW for ; Wed, 2 Sep 2009 11:17:58 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by core3.amsl.com (Postfix) with ESMTP id 83C643A6781 for ; Wed, 2 Sep 2009 11:17:55 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e34.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n82I48um008346 for ; Wed, 2 Sep 2009 12:04:08 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n82I87XQ262440 for ; Wed, 2 Sep 2009 12:08:13 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n82I7r8Z001529 for ; Wed, 2 Sep 2009 12:08:05 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-48-37-171.mts.ibm.com [9.48.37.171]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n82I7nvo001356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Sep 2009 12:07:50 -0600 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.3/8.12.5) with ESMTP id n82I7ibr008763; Wed, 2 Sep 2009 14:07:45 -0400 Message-Id: <200909021807.n82I7ibr008763@cichlid.raleigh.ibm.com> To: "Teco Boot" In-reply-to: <006701ca2baa$3c720320$b5560960$@nl> References: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl> <200909020837.43851.rogge@fgan.de> <63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com> <006701ca2baa$3c720320$b5560960$@nl> Comments: In-reply-to "Teco Boot" message dated "Wed, 02 Sep 2009 10:49:09 +0200." Date: Wed, 02 Sep 2009 14:07:44 -0400 From: Thomas Narten Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 18:17:59 -0000 > I still vote for A, as link-locals are required on IPv6 nodes > [RFC4291], I agree. I've been hesitant to jump into this discussion, but it is a requirement that all IPv6 interfaces have a link-local address. For autoconf to somehow think it doesn't need a LL address or is exempt from having one, makes me scratch my head in confusion. Thomas From Fred.L.Templin@boeing.com Wed Sep 2 11:26:24 2009 Return-Path: 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 9C4C23A67A4 for ; Wed, 2 Sep 2009 11:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.907 X-Spam-Level: X-Spam-Status: No, score=-5.907 tagged_above=-999 required=5 tests=[AWL=0.692, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 QqIbgeP-zjKf for ; Wed, 2 Sep 2009 11:26:23 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id C15263A6781 for ; Wed, 2 Sep 2009 11:26:23 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n82IOq3Q022327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Sep 2009 13:24:53 -0500 (CDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n82IOqdw000028; Wed, 2 Sep 2009 11:24:52 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n82IOpZ2000010; Wed, 2 Sep 2009 11:24:51 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 11:24:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Sep 2009 11:24:49 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10659989A@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <200909021807.n82I7ibr008763@cichlid.raleigh.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] call for consensus about link local address support Thread-Index: Acor+eC+40vqVwkmRH2zheDjBbJbcQAACUSw References: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl><200909020837.43851.rogge@fgan.de><63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com><006701ca2baa$3c720320$b5560960$@nl> <200909021807.n82I7ibr008763@cichlid.raleigh.ibm.com> From: "Templin, Fred L" To: "Thomas Narten" , "Teco Boot" X-OriginalArrivalTime: 02 Sep 2009 18:24:51.0010 (UTC) FILETIME=[A8F7A220:01CA2BFA] Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 18:26:24 -0000 > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Wednesday, September 02, 2009 11:08 AM > To: Teco Boot > Cc: autoconf@ietf.org > Subject: Re: [Autoconf] call for consensus about link local address support >=20 > > I still vote for A, as link-locals are required on IPv6 nodes > > [RFC4291], >=20 > I agree. I've been hesitant to jump into this discussion, but it is a > requirement that all IPv6 interfaces have a link-local address. Yes - all IPv6 interfaces are required to have an IPv6 link-local address. How a MANET interface might *use* an IPv6 link-local address is out of scope, and should not be rolled into a single consensus call item. =20 > For autoconf to somehow think it doesn't need a LL address or is > exempt from having one, makes me scratch my head in confusion. Right. Fred fred.l.templin@boeing.com >=20 > Thomas > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From Ronald.intVelt@tno.nl Wed Sep 2 12:11:16 2009 Return-Path: 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 D344128C454 for ; Wed, 2 Sep 2009 12:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.209 X-Spam-Level: X-Spam-Status: No, score=0.209 tagged_above=-999 required=5 tests=[AWL=0.713, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 r+-tTmbEuwFD for ; Wed, 2 Sep 2009 12:11:16 -0700 (PDT) Received: from mailoutb.tno.nl (mailoutb.tno.nl [134.221.1.17]) by core3.amsl.com (Postfix) with ESMTP id A5B6228C1DA for ; Wed, 2 Sep 2009 12:11:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,319,1249250400"; d="scan'208";a="5726809" Received: from ms-dt01thalia.tno.nl (HELO ms-dt01thalia.tsn.tno.nl) ([134.221.225.157]) by mailhost1b.tno.nl with ESMTP; 02 Sep 2009 21:09:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Sep 2009 21:09:56 +0200 Message-ID: <7877C5C0B5CC894AB26113CF06CF886302A037CF@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] call for consensus about link local address support Thread-Index: Acorn/fwP64rympkTcSMt1fJpUzN8wAX5m0g References: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl> <200909020837.43851.rogge@fgan.de> <63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com> From: "Velt, R. (Ronald) in 't" To: "Ryuji Wakikawa" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 19:11:17 -0000 Hello Ryuji,=20 >This consensus call is only for our single WG item, "IP=20 >Addressing Model in Ad Hoc Networks". >We seek the consensus whether we will deal with link-local=20 >address or not in this work. > >a) The link-local address is supported for MANET nodes. >b) The link-local address is not supported and not defined for=20 >MANET nodes in the document. > The difficulty and possible problems of the link-local=20 >addresses in MANET will be explained in the document. There was no doubt in my mind what the consensus call is about. I merely questioned the meaning of the phrase "shall support" with reference to a document that is an addressing model definition, *not* a protocol specification. Just semantics, I guess. Given the choice between a) and b), my preference is still a). Thanks, Ronald This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/disclaimer/email.html From Ronald.intVelt@tno.nl Wed Sep 2 12:28:33 2009 Return-Path: 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 E738928C93A for ; Wed, 2 Sep 2009 12:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.107 X-Spam-Level: X-Spam-Status: No, score=0.107 tagged_above=-999 required=5 tests=[AWL=0.611, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 YLkB1I0NSgi0 for ; Wed, 2 Sep 2009 12:28:33 -0700 (PDT) Received: from mailouta.tno.nl (mailouta.tno.nl [134.221.1.16]) by core3.amsl.com (Postfix) with ESMTP id AFCE528C938 for ; Wed, 2 Sep 2009 12:28:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,319,1249250400"; d="scan'208";a="24127136" Received: from ms-dt01thalia.tno.nl (HELO ms-dt01thalia.tsn.tno.nl) ([134.221.225.157]) by mailhost1a.tno.nl with ESMTP; 02 Sep 2009 21:27:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Sep 2009 21:27:52 +0200 Message-ID: <7877C5C0B5CC894AB26113CF06CF886302A037D1@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <61DF76BD-1C87-4D6F-A36B-9DC1DD89E558@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Updated IETF 75 meeting minutes Thread-Index: AcoqrWf0lE9WbKaWTXyYLtIBwxqB/wBU7iMg References: <61DF76BD-1C87-4D6F-A36B-9DC1DD89E558@gmail.com> From: "Velt, R. (Ronald) in 't" To: "Ryuji Wakikawa" , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: [Autoconf] Updated IETF 75 meeting minutes X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 19:28:34 -0000 Hi Ryuji, all,=20 >-----Original Message----- >From: autoconf-bounces@ietf.org=20 >[mailto:autoconf-bounces@ietf.org] On Behalf Of Ryuji Wakikawa >Sent: dinsdag 1 september 2009 4:31 >To: autoconf@ietf.org >Subject: [Autoconf] Updated IETF 75 meeting minutes > >Hi > >We revised the meeting minutes and updated it, however the=20 >proceeding of IETF75 has been already fixed. Note that http://www.ietf.org/meeting/cutoff-dates.html#75 says: ... - 2009-08-28 (Friday): Proceedings submission cutoff date by 17:00 PDT (24:00 UTC/GMT), upload using IETF Meeting Materials Management Tool.=20 - 2009-09-16 (Wednesday): Proceedings submission corrections cutoff date by 17:00 PDT (24:00 UTC/GMT), upload using IETF Meeting Materials Management Tool.=20 It appears to me that there is still time to upload the revised minutes as "corrections". Am I wrong? (For the record: I sent my updated version to both WG chairs and my "co-minute-taker" on Wednesday, August 19). Going through the recorded audio was a lot of work. It would be nice to see that effort rewarded by having the revised version adopted as the official minutes of meeting. Thanks, Ronald > >I attach the minutes updated by Ronald. >You will find the detailed discussion of the link-local=20 >address support in the minutes. > >Thanks Ronald for your help. > >ryuji > > This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/disclaimer/email.html From charles.perkins@earthlink.net Wed Sep 2 12:39:12 2009 Return-Path: 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 158EC28C96A for ; Wed, 2 Sep 2009 12:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[AWL=0.130, 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 VPPUOQE74ubT for ; Wed, 2 Sep 2009 12:39:11 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id D675C28C9DD for ; Wed, 2 Sep 2009 12:38:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=C6gYe2U46Bde5l35OcJQO9S2IFQt1dzD7z8mHpwP4uul7B2sEuD2uOJ6HBUSWEC+; 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.52]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Mit9j-0005MI-Dt; Wed, 02 Sep 2009 12:57:59 -0400 Message-ID: <4A9EA40E.1010405@earthlink.net> Date: Wed, 02 Sep 2009 09:57:50 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl> <200909020837.43851.rogge@fgan.de><63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com> <006701ca2baa$3c720320$b5560960$@nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f525e86ec0f355292c8edcdf4a64b478e41350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 19:39:12 -0000 Hello Chris, Dearlove, Christopher (UK) wrote: >> I still vote for A, as link-locals are required on IPv6 nodes >> > [RFC4291], > >> for sure for router interfaces [RFC4861]. >> > > The suggested compromise in Stockholm was that IPv6 nodes > would have link local addresses, but they might not be used, > and wouldn't be the intended target of autoconf. > In an effort to promote further consensus, I would support this statement, but... (see below). > >> And I also felt >> that we had consensus in Stockholm on including link-locals in the >> > document > >> (is A) >> > > This is showing where the A/B distinction may not be clear. > > The consensus in Stockholm was definitely not for A as I > understood it from Ryuji's post. The consensus was, I agree, > not to say that "link local addresses are prohibited" but, as > I understood it, it was for "we will design an autoconf > mechanism that will hand out addresses, those addresses will > be global or unique local". (Those are only meant to be rough > statements, not precise ones.) > I liked that you used "or" between "global" and "unique local". This definitely matches my preference. > >> I see 4 options on the table: >> > > Yes, it isn't simply A/B. > > >> 1: link-locals are not configured on interfaces in a MANET >> > > That I think is not allowed. > Where is it disallowed? What if _every_ MANET interface configures exactly the same link-local address but (see below)... > >> 2: link-locals are configured on interfaces in a MANET, but not used >> that widely-assigned link-local address is "not used" ... or .... >> 3: link-locals are configured on interfaces in a MANET, but used only >> > where > applicable > that widely-assigned link-local address is never "applicable" > I'll come back to those. > > >> 4: we need an address autoconfiguration mechanism for link-local >> > addresses > in a MANET. > > That I think is not going to work, because that will bog down the group > (in fact I think it will kill it) while the conflicting "whatever > addresses > you need will be visible two hops away" and "link local addresses should > not be seen more than one hop away" requirement and position deadlock. > Yes, I agree this is poison, not to mention absolutely unnecessary. > > I suggest that rather than the A/B thing, someone appropriate > sets out what they think the Stockholm consensus was (it will take > a few bullet points) and sees who can support it. I think that > will actually show more agreement that is currently appearing, > and if there is disagreement, will focus it on key points. > Fine with me, except that it opens the door to incessant disagreement on what the consensus was. I'd prefer to see if we could get at least a rough consensus on one of the two choices. I also don't think they are so hard to understand. Regards, Charlie P. From charles.perkins@earthlink.net Wed Sep 2 12:41:40 2009 Return-Path: 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 A610428C1ED for ; Wed, 2 Sep 2009 12:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.858 X-Spam-Level: X-Spam-Status: No, score=-1.858 tagged_above=-999 required=5 tests=[AWL=0.122, 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 xYx5MVvflh4v for ; Wed, 2 Sep 2009 12:41:38 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id D913A28C8E6 for ; Wed, 2 Sep 2009 12:41:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=d6iwdG12l2bdbEc7HHsNJtSHfz6sL9VhDjKTDSZRqIwWF17TcY3+VBDAZqsDO9Ef; 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.52]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MivhS-0008EF-TT; Wed, 02 Sep 2009 15:40:59 -0400 Message-ID: <4A9ECA44.3000507@earthlink.net> Date: Wed, 02 Sep 2009 12:40:52 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Templin, Fred L" References: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl><200909020837.43851.rogge@fgan.de><63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com><006701ca2baa$3c720320$b5560960$@nl> <200909021807.n82I7ibr008763@cichlid.raleigh.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A10659989A@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10659989A@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52b3df7909ad2656c161e6fea218954583350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: Thomas Narten , autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 19:41:40 -0000 Hello Fred, I'll ask you the same question I asked Chris: Templin, Fred L wrote: > > Yes - all IPv6 interfaces are required to have an IPv6 > link-local address. How a MANET interface might *use* > an IPv6 link-local address is out of scope, and should > not be rolled into a single consensus call item. > What if the SAME link-local address were assigned to EVERY manet node in the network, and it was NEVER used? Then we have satisfied the claimed requirement. > > >> For autoconf to somehow think it doesn't need a LL address or is >> exempt from having one, makes me scratch my head in confusion. >> > > Right. > Well, "autoconf" doesn't "think". But I think that we don't need the LL addresses. In fact I am sure of it. The only rationale for requiring them (_in the general case_) is to satisfy the demands of those people who are so insistent that we have to have them. Not that they would necessarily be used for anything at all. Not that the mandate to have them would be enforceable. It's just busy work and yet another roadblock to progress. Of course, as has been stated many many many times in the past, if your design can benefit from LL addresses, there is absolutely no prohibition against their use. But if my design cannot use them, you will still insist that I create them and let them sit in some dark unused corner of protocol requirement hell. Or else some people will scratch their head in puzzlement. Never mind that link-locals are, to say the least, adverse to wireless mobility and are best suited for nodes that are either not wireless or not mobile. Regards, Charlie P. From narten@us.ibm.com Wed Sep 2 14:12:57 2009 Return-Path: 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 E5D8B28C74E for ; Wed, 2 Sep 2009 14:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.349 X-Spam-Level: X-Spam-Status: No, score=-4.349 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_00=-2.599] 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 deMLtJ50MMmz for ; Wed, 2 Sep 2009 14:12:57 -0700 (PDT) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by core3.amsl.com (Postfix) with ESMTP id DBFEE3A6A4B for ; Wed, 2 Sep 2009 14:12:56 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e37.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n82KmpnK021518 for ; Wed, 2 Sep 2009 14:48:51 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n82KnjGH243992 for ; Wed, 2 Sep 2009 14:49:45 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n82KnjaM032300 for ; Wed, 2 Sep 2009 14:49:45 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-48-37-171.mts.ibm.com [9.48.37.171]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n82Knhin032215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Sep 2009 14:49:44 -0600 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.3/8.12.5) with ESMTP id n82Kngca014747; Wed, 2 Sep 2009 16:49:42 -0400 Message-Id: <200909022049.n82Kngca014747@cichlid.raleigh.ibm.com> To: "Charles E. Perkins" In-reply-to: <4A9ECA44.3000507@earthlink.net> References: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl><200909020837.43851.rogge@fgan.de><63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com><006701ca2baa$3c720320$b5560960$@nl> <200909021807.n82I7ibr008763@cichlid.raleigh.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A10659989A@XCH-NW-7V2.nw.nos.boeing.com> <4A9ECA44.3000507@earthlink.net> Comments: In-reply-to "Charles E. Perkins" message dated "Wed, 02 Sep 2009 12:40:52 -0700." Date: Wed, 02 Sep 2009 16:49:42 -0400 From: Thomas Narten Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 21:12:58 -0000 > What if the SAME link-local address were assigned to EVERY > manet node in the network, and it was NEVER used? Why do we worry (and focus?) on these sorts of bizarre and unlikely cases? Is this WG intentionally trying to focus on scenarios that are unsolvable? Reality check for a moment. LL addresses (in IPv6) are generated off of a MAC address. These are highly likely to be unique. And if MAC addresses are not unique, what that means is that you have multiple interface cards that use the same MAC address on the same network. Bad things tend to happen when you try to operate networks with such characteristics, because there are all sorts of assumptions built into various protocols that MAC addresses will be unique. Even if you somehow managed to assign unique addresses in this case, things would still likely not work right because of the duplicate MAC addresses underneath. My point; if you have multiple identical LL addresses on your local network, you probably have BIG problems already, and autoconf is the least of your worries. If the reason folk don't want to use LL is that they might not be unique, can we please instead break this into two problems: 1) assume LL address are unique and go from there, develop some approaches and solutions 2) assume they are not unique and spend another 3 years spinning your wheels on a very hard problem. (And please, make this a separate document and mailing list, so folk interested in option 1 can focus on that.) Thoma From charles.perkins@earthlink.net Wed Sep 2 14:14:36 2009 Return-Path: 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 F15A328C886 for ; Wed, 2 Sep 2009 14:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.865 X-Spam-Level: X-Spam-Status: No, score=-1.865 tagged_above=-999 required=5 tests=[AWL=0.115, 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 hiP-2E5VdA+Z for ; Wed, 2 Sep 2009 14:14:35 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 86FCE28C7C3 for ; Wed, 2 Sep 2009 14:14:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=LFI1AT9OwAeeSnkiKv3VhayK8ceMpHVze5h3/24WWObIuZv1RFemUHCt8S//gd4R; 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.52]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Mix9k-00076J-1D; Wed, 02 Sep 2009 17:14:16 -0400 Message-ID: <4A9EE020.2000807@earthlink.net> Date: Wed, 02 Sep 2009 14:14:08 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Templin, Fred L" References: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl><200909020837.43851.rogge@fgan.de><63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com><006701ca2baa$3c720320$b5560960$@nl> <200909021807.n82I7ibr008763@cichlid.raleigh.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A10659989A@XCH-NW-7V2.nw.nos.boeing.com> <4A9ECA44.3000507@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A1065999AD@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1065999AD@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52937faf3cd88fc2cb64a3c00aa7148bc5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: Thomas Narten , autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 21:14:37 -0000 Hello Fred, Templin, Fred L wrote: > Charlie, > > > >>> Yes - all IPv6 interfaces are required to have an IPv6 >>> link-local address. How a MANET interface might *use* >>> an IPv6 link-local address is out of scope, and should >>> not be rolled into a single consensus call item. >>> >>> >> What if the SAME link-local address were assigned to EVERY >> manet node in the network, and it was NEVER used? >> > > What kind of a question is that? Configure the link-locals > as you would for any other interface and such a scenario > would never arise - use the link-locals between consenting > nodes if you'd like, too. That's all. > Can't do it. Can't guarantee uniqueness across time and space. Can't use DAD for link-locals. So I can't "Configure the link-locals as you would for any other interface". Regards, Charlie P. From hrogge@googlemail.com Wed Sep 2 14:14:47 2009 Return-Path: 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 6939E28C993 for ; Wed, 2 Sep 2009 14:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 3jWVFC9JGJH2 for ; Wed, 2 Sep 2009 14:14:46 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id 3D6BF28C7C3 for ; Wed, 2 Sep 2009 14:14:46 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id e21so1169534fga.13 for ; Wed, 02 Sep 2009 14:14:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=853KU1QhfvWokhEbgbq/jlkTXaaHqbTKvgRusdKwEIY=; b=Bi+4XzZVUR/VsJRX/WA0HqpEclGOiMp91AHA3dP6H0auSMhcHGXN2ccXft80v6QlsS LYdpWW9ZLy6kKr7grWGmyjfcvCDUjrbeVEjicP7m+kAnwoY1X6YUiAraeaTxXNH0tPYv gDez2nAGRcFV+p9GpDvq8boD1863E7Mpekpug= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=PGoyjA7CyzgSXBbDqMgScOMLW8zonfuAwouLeVDhPbHUb48U8RFiL0MIVbjAksPcqB RmTkROqzTC/xdtwt7OawNGqMTlggg8RPge3buoTWijZENyI3kzcGvjH/fLebCZ0AenxM N9/WYujoO8RW65hn5iJr/JrCsuZ8Zhx66CEkA= Received: by 10.86.220.9 with SMTP id s9mr3040827fgg.40.1251926068972; Wed, 02 Sep 2009 14:14:28 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id l19sm239224fgb.3.2009.09.02.14.14.27 (version=SSLv3 cipher=RC4-MD5); Wed, 02 Sep 2009 14:14:28 -0700 (PDT) From: Henning Rogge To: autoconf@ietf.org Date: Wed, 2 Sep 2009 22:38:52 +0200 User-Agent: KMail/1.12.0 (Linux/2.6.30-gentoo-r5; KDE/4.3.0; x86_64; ; ) References: <39C363776A4E8C4A94691D2BD9D1C9A10659989A@XCH-NW-7V2.nw.nos.boeing.com> <4A9ECA44.3000507@earthlink.net> In-Reply-To: <4A9ECA44.3000507@earthlink.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4709240.lsGFK9ZIKG"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200909022239.03713.hrogge@googlemail.com> Cc: Thomas Narten Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 21:14:47 -0000 --nextPart4709240.lsGFK9ZIKG Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am Mittwoch 02 September 2009 21:40:52 schrieb Charles E. Perkins: > Never mind that link-locals are, to say the least, adverse to > wireless mobility and are best suited for nodes that are > either not wireless or not mobile. we might even have a "best of both worlds" approach. If we have a protocol that calculates routing-scope unique addresses for ea= ch=20 interface, we could just use this protocol to calculate routing-scope uniqu= e=20 link-locales. In my understanding of IPv6 link-local addresses must be unique AT LEAST on= =20 the link, so using a routing-scope autoconf for them would be okay. This way we still could using link-local IPs (which will be not forwarded=20 beyond the link), it will be just another approach to get them. At least this would be an optional possibility to use it, if someone does n= ot=20 need link-local IPs and does not care about the "IPv6 must have them", they= =20 can be just droped. Henning Rogge --nextPart4709240.lsGFK9ZIKG Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEABECAAYFAkqe1+cACgkQcenvcwAcHWfkQgCfQbLH+Ibnth69ACVdwK1cCJhW AQYAn09c6WJVnVqw6eXclRr+TJg5uEr8 =m1Bc -----END PGP SIGNATURE----- --nextPart4709240.lsGFK9ZIKG-- From narten@us.ibm.com Wed Sep 2 15:24:25 2009 Return-Path: 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 242F33A6910 for ; Wed, 2 Sep 2009 15:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.155 X-Spam-Level: X-Spam-Status: No, score=-4.155 tagged_above=-999 required=5 tests=[AWL=-1.556, BAYES_00=-2.599] 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 5cjTPyj1RShK for ; Wed, 2 Sep 2009 15:24:24 -0700 (PDT) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by core3.amsl.com (Postfix) with ESMTP id 3755F3A6407 for ; Wed, 2 Sep 2009 15:24:24 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e9.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n82LQnFc023331 for ; Wed, 2 Sep 2009 17:26:49 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n82LSbNG249132 for ; Wed, 2 Sep 2009 17:28:37 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n82LSaeo022126 for ; Wed, 2 Sep 2009 17:28:37 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-48-37-171.mts.ibm.com [9.48.37.171]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n82LSZ4F022054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Sep 2009 17:28:36 -0400 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.3/8.12.5) with ESMTP id n82LSY2P015276; Wed, 2 Sep 2009 17:28:34 -0400 Message-Id: <200909022128.n82LSY2P015276@cichlid.raleigh.ibm.com> To: "Charles E. Perkins" In-reply-to: <4A9EE276.2080905@earthlink.net> References: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl><200909020837.43851.rogge@fgan.de><63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com><006701ca2baa$3c720320$b5560960$@nl> <200909021807.n82I7ibr008763@cichlid.raleigh.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A10659989A@XCH-NW-7V2.nw.nos.boeing.com> <4A9ECA44.3000507@earthlink.net> <200909022049.n82Kngca014747@cichlid.raleigh.ibm.com> <4A9EE276.2080905@earthlink.net> Comments: In-reply-to "Charles E. Perkins" message dated "Wed, 02 Sep 2009 14:24:06 -0700." Date: Wed, 02 Sep 2009 17:28:34 -0400 From: Thomas Narten Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 22:24:25 -0000 > Now this is a great idea. Let's have an autoconf effort for those > who assume unique LL addresses. And let's have a separate autoconf > effort for those who do not. I'll be in the second camp, and we > already have working code. Yep, I hear there is working code all over the place. That's nice. Now why can't we translate that into a useful specification? (My possibly biased answer: because this group can't agree on even the most basic lowest-common denominator underlying assumption about anything. And if you can't agree on any underlying base line, there is little point in trying to develop any solution, since it clearly won't mean the various assumptions people have.) Thomas From charles.perkins@earthlink.net Wed Sep 2 15:58:48 2009 Return-Path: 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 444863A6407 for ; Wed, 2 Sep 2009 15:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[AWL=0.108, 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 dimxUDJ4dG2Q for ; Wed, 2 Sep 2009 15:58:47 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 4F6B028C0E6 for ; Wed, 2 Sep 2009 15:58:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=m9uV1+/JFWBFwMEFyDY61xImXJjYcNGlsvfqyMrlM9pf7oPSPzI155yL2mNO7Vel; 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.52]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MixJK-0002zJ-P3; Wed, 02 Sep 2009 17:24:10 -0400 Message-ID: <4A9EE276.2080905@earthlink.net> Date: Wed, 02 Sep 2009 14:24:06 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Narten References: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl><200909020837.43851.rogge@fgan.de><63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com><006701ca2baa$3c720320$b5560960$@nl> <200909021807.n82I7ibr008763@cichlid.raleigh.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A10659989A@XCH-NW-7V2.nw.nos.boeing.com> <4A9ECA44.3000507@earthlink.net> <200909022049.n82Kngca014747@cichlid.raleigh.ibm.com> In-Reply-To: <200909022049.n82Kngca014747@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5216f034d22db15a9a77633240583b6ab2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 22:58:48 -0000 Hello Thomas, Thomas Narten wrote: >> What if the SAME link-local address were assigned to EVERY >> manet node in the network, and it was NEVER used? >> > > Why do we worry (and focus?) on these sorts of bizarre and unlikely > cases? Is this WG intentionally trying to focus on scenarios that are > unsolvable? > Quite the opposite, I am very sure. I think we ought to focus on scenarios that are solvable. Which does not always include unique link-local. > Reality check for a moment. LL addresses (in IPv6) are generated off > of a MAC address. These are highly likely to be unique. > That argument was deemed not good enough. A huge battle ensued. We mandated DAD for IPv6 nodes. You edited a relevant document, as I remember. Would you like to say that LL addresses are required when MAC addresses are unique? > And if MAC addresses are not unique, what that means is that you have > multiple interface cards that use the same MAC address on the same > network. Or you don't have MAC addresses. > Bad things tend to happen when you try to operate networks > with such characteristics, There are 4 billion nodes out there doing it today. O.K. with me if you want to say they are bad. > because there are all sorts of assumptions > built into various protocols that MAC addresses will be unique. Even > if you somehow managed to assign unique addresses in this case, things > would still likely not work right because of the duplicate MAC > addresses underneath. > This is not true. See above! However, you are really zeroing in on the point -- which is that if you can't already guarantee MAC layer addresses are unique, you are biting off a huge chunk to try to guarantee that LL addresses are unique. UNLESS, that is, you have the luxury of a very very nice broadcast medium. Which we don't. > My point; if you have multiple identical LL addresses on your local > network, you probably have BIG problems already, and autoconf is the > least of your worries. > My point: you don't need to mandate LL addresses in all cases -- which completely then circumvents the problem (BIG or not). > If the reason folk don't want to use LL is that they might not be > unique, can we please instead break this into two problems: > > 1) assume LL address are unique and go from there, develop some > approaches and solutions > For mobile wireless nodes, that is a very restrictive assumption. But I agree that once you make the assumption, you can make solutions. That, unfortunately, don't apply in the problem space of interest. > 2) assume they are not unique and spend another 3 years spinning your > wheels on a very hard problem. (And please, make this a separate > document and mailing list, so folk interested in option 1 can > focus on that.) > Now this is a great idea. Let's have an autoconf effort for those who assume unique LL addresses. And let's have a separate autoconf effort for those who do not. I'll be in the second camp, and we already have working code. Regards, Charlie P. From charles.perkins@earthlink.net Wed Sep 2 17:19:02 2009 Return-Path: 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 73B983A6C80 for ; Wed, 2 Sep 2009 17:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.103, 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 W2tWC8uUtXkn for ; Wed, 2 Sep 2009 17:19:01 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id CD4A43A6B1A for ; Wed, 2 Sep 2009 17:16:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=IYtzcNk/FKdPe/9Ve0yxP0S9YSh806VKVRJUswFOqX7Yi2AbNofOeX6qTfcrH8MZ; 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.52]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MiyCY-0006EX-JP; Wed, 02 Sep 2009 18:21:15 -0400 Message-ID: <4A9EEFD5.4050401@earthlink.net> Date: Wed, 02 Sep 2009 15:21:09 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Narten References: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl><200909020837.43851.rogge@fgan.de><63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com><006701ca2baa$3c720320$b5560960$@nl> <200909021807.n82I7ibr008763@cichlid.raleigh.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A10659989A@XCH-NW-7V2.nw.nos.boeing.com> <4A9ECA44.3000507@earthlink.net> <200909022049.n82Kngca014747@cichlid.raleigh.ibm.com> <4A9EE276.2080905@earthlink.net> <200909022128.n82LSY2P015276@cichlid.raleigh.ibm.com> In-Reply-To: <200909022128.n82LSY2P015276@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f527ead4fe5a3720c47f92ae4ea6f0a2b74350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 00:19:02 -0000 Hello Thomas, Thomas Narten wrote: >> Now this is a great idea. Let's have an autoconf effort for those >> who assume unique LL addresses. And let's have a separate autoconf >> effort for those who do not. I'll be in the second camp, and we >> already have working code. >> > > Yep, I hear there is working code all over the place. That's nice. > > Now why can't we translate that into a useful specification? > We did. It triggered the formation of the working group. Then we needed to make a problem statement. Then some people thought the problem had to do with link-local addresses instead of getting autoconfiguration to work in the scenarios that were the impetus for the people starting the working group. Then a process of years of compromise, discussion, and non-consensus evolved. > (My possibly biased answer: because this group can't agree on even the > most basic lowest-common denominator underlying assumption about > anything. And if you can't agree on any underlying base line, there is > little point in trying to develop any solution, since it clearly won't > mean the various assumptions people have.) > As you point out, there may be two camps: - People who insist on having link-locals, and - People who don't. Maybe they're not compatible. I'm happy to have two different discussions and two different specification efforts. Are you expressing a low opinion of working code and systems? Regards, Charlie P. From ryuji.wakikawa@gmail.com Wed Sep 2 19:34:03 2009 Return-Path: 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 C4F963A6C5D for ; Wed, 2 Sep 2009 19:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 NA46BWlRvF6E for ; Wed, 2 Sep 2009 19:34:02 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by core3.amsl.com (Postfix) with ESMTP id 8AD403A6886 for ; Wed, 2 Sep 2009 19:34:02 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so559128fgg.13 for ; Wed, 02 Sep 2009 19:33:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=kmTa2pLw7zs7bMuUAgk7RZTb+HEkHmtv42KNzqLpQgI=; b=p6GaTejKdtBRd6O93gJTR6hoNIzLQD8evsZXtRNK5vb6N+4fSTH91AS1IQJGbH6z11 t+xY36zPi3FcUXU8N1ZE8CBuAJZuP9B6FFBmSnqfh+dZwysifiLEoxF8DxufWFaLiblO HgiR4LZxcP6yWZT7PlqvpgB7/lSCCBEL15Bdk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=cBpYX9Y4MpkrPlOKzP2CW0ThFYLFtgPWmgncqT77vrnzWREFgmaEnHuCGqLhbpKacc l0ZPVZxnLdgZaTvXPySZO4c9Net4AEspKvIfbVSiOW36c4CwuKqQVL8PNguinLqQ1ZFO uYhOFkntU7KDNeq3HTuhlDgTBfaDS7j4hKKvc= Received: by 10.86.249.22 with SMTP id w22mr3266707fgh.1.1251945217040; Wed, 02 Sep 2009 19:33:37 -0700 (PDT) Received: from ?192.168.25.206? (p3003-ipbfpfx02kyoto.kyoto.ocn.ne.jp [125.207.177.35]) by mx.google.com with ESMTPS id 4sm1257824fgg.17.2009.09.02.19.33.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Sep 2009 19:33:36 -0700 (PDT) From: Ryuji Wakikawa To: "Velt, R. (Ronald) in 't" In-Reply-To: <7877C5C0B5CC894AB26113CF06CF886302A037D1@ms-dt01thalia.tsn.tno.nl> References: <61DF76BD-1C87-4D6F-A36B-9DC1DD89E558@gmail.com> <7877C5C0B5CC894AB26113CF06CF886302A037D1@ms-dt01thalia.tsn.tno.nl> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 3 Sep 2009 11:33:27 +0900 X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Updated IETF 75 meeting minutes X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 02:34:03 -0000 Hi Ronald, I couldn't upload the minutes last time. I tried it again and replace the minutes successfully. I am away from the office on my business trip. My connectivity is not always stable. Now, the latest minutes can be found at the IETF 75th proceeding. thanks, ryuji On 2009/09/03, at 4:27, Velt, R. (Ronald) in 't wrote: > Hi Ryuji, all, > >> -----Original Message----- >> From: autoconf-bounces@ietf.org >> [mailto:autoconf-bounces@ietf.org] On Behalf Of Ryuji Wakikawa >> Sent: dinsdag 1 september 2009 4:31 >> To: autoconf@ietf.org >> Subject: [Autoconf] Updated IETF 75 meeting minutes >> >> Hi >> >> We revised the meeting minutes and updated it, however the >> proceeding of IETF75 has been already fixed. > > Note that http://www.ietf.org/meeting/cutoff-dates.html#75 says: > > ... > - 2009-08-28 (Friday): Proceedings submission cutoff date by 17:00 PDT > (24:00 UTC/GMT), upload using IETF Meeting Materials Management Tool. > - 2009-09-16 (Wednesday): Proceedings submission corrections cutoff > date > by 17:00 PDT (24:00 UTC/GMT), upload using IETF Meeting Materials > Management Tool. > > It appears to me that there is still time to upload the revised > minutes > as "corrections". Am I wrong? (For the record: I sent my updated > version > to both WG chairs and my "co-minute-taker" on Wednesday, August 19). > > Going through the recorded audio was a lot of work. It would be nice > to > see that effort rewarded by having the revised version adopted as the > official minutes of meeting. > > Thanks, > Ronald > > >> >> I attach the minutes updated by Ronald. >> You will find the detailed discussion of the link-local >> address support in the minutes. >> >> Thanks Ronald for your help. >> >> ryuji >> >> > This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html > From Fred.L.Templin@boeing.com Wed Sep 2 21:41:11 2009 Return-Path: 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 985E03A67F7 for ; Wed, 2 Sep 2009 21:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.906 X-Spam-Level: X-Spam-Status: No, score=-5.906 tagged_above=-999 required=5 tests=[AWL=0.693, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 EvoYHOpTSQvC for ; Wed, 2 Sep 2009 21:41:07 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 518013A688C for ; Wed, 2 Sep 2009 21:41:04 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n82KaQFq022448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Sep 2009 13:36:27 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n82KaPTD012087; Wed, 2 Sep 2009 13:36:26 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n82KaMi5011979; Wed, 2 Sep 2009 13:36:25 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 13:36:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Sep 2009 13:36:20 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1065999AD@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <4A9ECA44.3000507@earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] call for consensus about link local address support Thread-Index: AcosBUz59KuTlk+4R6WMOZUmShpcRQABx7lg References: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl><200909020837.43851.rogge@fgan.de><63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com><006701ca2baa$3c720320$b5560960$@nl> <200909021807.n82I7ibr008763@cichlid.raleigh.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A10659989A@XCH-NW-7V2.nw.nos.boeing.com> <4A9ECA44.3000507@earthlink.net> From: "Templin, Fred L" To: "Charles E. Perkins" X-OriginalArrivalTime: 02 Sep 2009 20:36:22.0084 (UTC) FILETIME=[0869F840:01CA2C0D] Cc: Thomas Narten , autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 04:41:12 -0000 Charlie, > -----Original Message----- > From: Charles E. Perkins [mailto:charles.perkins@earthlink.net] > Sent: Wednesday, September 02, 2009 12:41 PM > To: Templin, Fred L > Cc: Thomas Narten; Teco Boot; autoconf@ietf.org > Subject: Re: [Autoconf] call for consensus about link local address support >=20 >=20 > Hello Fred, >=20 > I'll ask you the same question I asked Chris: >=20 > Templin, Fred L wrote: > > > > Yes - all IPv6 interfaces are required to have an IPv6 > > link-local address. How a MANET interface might *use* > > an IPv6 link-local address is out of scope, and should > > not be rolled into a single consensus call item. > > >=20 > What if the SAME link-local address were assigned to EVERY > manet node in the network, and it was NEVER used? What kind of a question is that? Configure the link-locals as you would for any other interface and such a scenario would never arise - use the link-locals between consenting nodes if you'd like, too. That's all. Fred fred.l.templin@boeing.com > Then we have satisfied the claimed requirement. >=20 >=20 >=20 > > > > > >> For autoconf to somehow think it doesn't need a LL address or is > >> exempt from having one, makes me scratch my head in confusion. > >> > > > > Right. > > >=20 >=20 > Well, "autoconf" doesn't "think". But I think that we don't need > the LL addresses. In fact I am sure of it. The only rationale > for requiring them (_in the general case_) is to satisfy the demands > of those people who are so insistent that we have to have them. >=20 > Not that they would necessarily be used for anything at all. >=20 > Not that the mandate to have them would be enforceable. >=20 > It's just busy work and yet another roadblock to progress. >=20 > Of course, as has been stated many many many times in > the past, if your design can benefit from LL addresses, there > is absolutely no prohibition against their use. >=20 > But if my design cannot use them, you will still insist > that I create them and let them sit in some dark unused > corner of protocol requirement hell. >=20 > Or else some people will scratch their head in puzzlement. >=20 > Never mind that link-locals are, to say the least, adverse to > wireless mobility and are best suited for nodes that are > either not wireless or not mobile. >=20 > Regards, > Charlie P. From Chris.Dearlove@baesystems.com Thu Sep 3 02:11:58 2009 Return-Path: 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 0772A3A6935 for ; Thu, 3 Sep 2009 02:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] 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 n1GDbaux2VyA for ; Thu, 3 Sep 2009 02:11:57 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 791F53A67AB for ; Thu, 3 Sep 2009 02:11:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,324,1249254000"; d="scan'208";a="20315528" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 03 Sep 2009 10:10:53 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id n839AtIZ011754; Thu, 3 Sep 2009 10:10:55 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 10:10:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 3 Sep 2009 10:10:51 +0100 Message-ID: In-Reply-To: <4A9EA40E.1010405@earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] call for consensus about link local address support thread-index: Acor7og85Vd9yGc+R0SJqHoZu8a94gAhp21Q References: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl> <200909020837.43851.rogge@fgan.de><63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com> <006701ca2baa$3c720320$b5560960$@nl> <4A9EA40E.1010405@earthlink.net> From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" X-OriginalArrivalTime: 03 Sep 2009 09:10:52.0592 (UTC) FILETIME=[6FBD4B00:01CA2C76] Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 09:11:58 -0000 > I liked that you used "or" between "global" and "unique local". This > definitely matches my preference. I have no idea whether people thought they were supporting exclusive or inclusive or. It wasn't something I thought about, and don't have a view on. >>> 1: link-locals are not configured on interfaces in a MANET >> >> That I think is not allowed. > > Where is it disallowed? As I recall, someone (the minutes will probably indicate who, they are pretty extensive) quoted from the IPv6 RFC (I should have noted that this is an IPv6 comment only) that said (roughly) that an interface must have a link local address. > What if _every_ MANET interface configures exactly > the same link-local address but (see below)... > that widely-assigned link-local address is "not used" ... or .... > that widely-assigned link-local address is never "applicable" The "all the same" part I have no idea about. The "never used" option (which one of your two I don't know) was suggested in Stockholm. > Fine with me, except that it opens the door to incessant > disagreement on what the consensus was. I think incessant disagreement is endemic here. > I'd prefer to see if we could get at least a rough consensus > on one of the two choices. I also don't think they are so > hard to understand. I think the key point is that A/B as worded aren't doing that job. I was suggesting (but might be wrong) that it would be easier to achieve consensus starting from one statement that, if necessary, was tweaked, rather than start from two statements that polarise. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Thu Sep 3 02:49:05 2009 Return-Path: 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 786223A69D5 for ; Thu, 3 Sep 2009 02:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] 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 A4N3ZLGrL8va for ; Thu, 3 Sep 2009 02:49:04 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 268C03A694C for ; Thu, 3 Sep 2009 02:49:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,324,1249254000"; d="scan'208";a="20326811" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 03 Sep 2009 10:45:27 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id n839jTxt004750; Thu, 3 Sep 2009 10:45:29 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Sep 2009 10:45:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 3 Sep 2009 10:45:26 +0100 Message-ID: In-Reply-To: <7877C5C0B5CC894AB26113CF06CF886302A037D1@ms-dt01thalia.tsn.tno.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Updated IETF 75 meeting minutes thread-index: AcoqrWf0lE9WbKaWTXyYLtIBwxqB/wBU7iMgAB55RkA= References: <61DF76BD-1C87-4D6F-A36B-9DC1DD89E558@gmail.com> <7877C5C0B5CC894AB26113CF06CF886302A037D1@ms-dt01thalia.tsn.tno.nl> From: "Dearlove, Christopher (UK)" To: "Velt, R. (Ronald) in 't" , "Ryuji Wakikawa" , X-OriginalArrivalTime: 03 Sep 2009 09:45:27.0504 (UTC) FILETIME=[447BBD00:01CA2C7B] Cc: Thomas Heide Clausen Subject: Re: [Autoconf] Updated IETF 75 meeting minutes X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 09:49:05 -0000 Agreed. Ronald did a great job. I'd disagree with him in just one way, I'd make one further change as I think the minutes should (if they record a minute taker at all) reflect both names equally, not Ronald as an add-on. -- Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On Behalf Of Velt, R. (Ronald) in 't Sent: 02 September 2009 20:28 To: Ryuji Wakikawa; autoconf@ietf.org Subject: Re: [Autoconf] Updated IETF 75 meeting minutes *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet. Keep this in mind if you answer this message. Hi Ryuji, all, >-----Original Message----- >From: autoconf-bounces@ietf.org >[mailto:autoconf-bounces@ietf.org] On Behalf Of Ryuji Wakikawa >Sent: dinsdag 1 september 2009 4:31 >To: autoconf@ietf.org >Subject: [Autoconf] Updated IETF 75 meeting minutes > >Hi > >We revised the meeting minutes and updated it, however the >proceeding of IETF75 has been already fixed. Note that http://www.ietf.org/meeting/cutoff-dates.html#75 says: ... - 2009-08-28 (Friday): Proceedings submission cutoff date by 17:00 PDT (24:00 UTC/GMT), upload using IETF Meeting Materials Management Tool. - 2009-09-16 (Wednesday): Proceedings submission corrections cutoff date by 17:00 PDT (24:00 UTC/GMT), upload using IETF Meeting Materials Management Tool. It appears to me that there is still time to upload the revised minutes as "corrections". Am I wrong? (For the record: I sent my updated version to both WG chairs and my "co-minute-taker" on Wednesday, August 19). Going through the recorded audio was a lot of work. It would be nice to see that effort rewarded by having the revised version adopted as the official minutes of meeting. Thanks, Ronald > >I attach the minutes updated by Ronald. >You will find the detailed discussion of the link-local >address support in the minutes. > >Thanks Ronald for your help. > >ryuji > > This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Thu Sep 3 02:56:29 2009 Return-Path: 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 63E7A3A6974 for ; Thu, 3 Sep 2009 02:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] 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 DElzxvT5u+lK for ; Thu, 3 Sep 2009 02:56:28 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 061B628C128 for ; Thu, 3 Sep 2009 02:56:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,324,1249254000"; d="scan'208";a="20329535" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 03 Sep 2009 10:54:29 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id n839sVbQ011246; Thu, 3 Sep 2009 10:54:31 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Sep 2009 10:54:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 3 Sep 2009 10:54:28 +0100 Message-ID: In-Reply-To: <200909022049.n82Kngca014747@cichlid.raleigh.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] call for consensus about link local address support thread-index: AcosEjGUEWNOFPDxR+qP+qU0YtqobgAaS0cw References: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl><200909020837.43851.rogge@fgan.de><63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com><006701ca2baa$3c720320$b5560960$@nl><200909021807.n82I7ibr008763@cichlid.raleigh.ibm.com><39C363776A4E8C4A94691D2BD9D1C9A10659989A@XCH-NW-7V2.nw.nos.boeing.com><4A9ECA44.3000507@earthlink.net> <200909022049.n82Kngca014747@cichlid.raleigh.ibm.com> From: "Dearlove, Christopher (UK)" To: "Thomas Narten" , "Charles E. Perkins" X-OriginalArrivalTime: 03 Sep 2009 09:54:29.0589 (UTC) FILETIME=[87975850:01CA2C7C] Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 09:56:29 -0000 I believe - Yes, you can generate LL addresses as Thomas indicates. That satisfies some requirements. - However those are not the routable address needed, as they are local. - The autoconf work is to generate those addresses, to be used by MANET routing protocols, and then by applications. - We also need those other addresses for even link symmetry checking if there is a prohibition on link local addresses being seen non-locally, as the physics is non-transitive, and that's not changing. - Trying to argue about two-hop (or, with mobility, MANET wide) visibility of link local addresses is doomed to spin wheels - in my estimation until the WG dies. -- Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On Behalf Of Thomas Narten Sent: 02 September 2009 21:50 To: Charles E. Perkins Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet. Keep this in mind if you answer this message. > What if the SAME link-local address were assigned to EVERY > manet node in the network, and it was NEVER used? Why do we worry (and focus?) on these sorts of bizarre and unlikely cases? Is this WG intentionally trying to focus on scenarios that are unsolvable? Reality check for a moment. LL addresses (in IPv6) are generated off of a MAC address. These are highly likely to be unique. And if MAC addresses are not unique, what that means is that you have multiple interface cards that use the same MAC address on the same network. Bad things tend to happen when you try to operate networks with such characteristics, because there are all sorts of assumptions built into various protocols that MAC addresses will be unique. Even if you somehow managed to assign unique addresses in this case, things would still likely not work right because of the duplicate MAC addresses underneath. My point; if you have multiple identical LL addresses on your local network, you probably have BIG problems already, and autoconf is the least of your worries. If the reason folk don't want to use LL is that they might not be unique, can we please instead break this into two problems: 1) assume LL address are unique and go from there, develop some approaches and solutions 2) assume they are not unique and spend another 3 years spinning your wheels on a very hard problem. (And please, make this a separate document and mailing list, so folk interested in option 1 can focus on that.) Thoma _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From alexandru.petrescu@gmail.com Thu Sep 3 03:09:58 2009 Return-Path: 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 4365A3A6928 for ; Thu, 3 Sep 2009 03:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 I4ZQKHi+k3V0 for ; Thu, 3 Sep 2009 03:09:57 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 364483A691B for ; Thu, 3 Sep 2009 03:09:56 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n83A6xBF030619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Sep 2009 12:06:59 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n83A6wid029572; Thu, 3 Sep 2009 12:06:59 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n83A6vfI023683; Thu, 3 Sep 2009 12:06:58 +0200 Message-ID: <4A9F9541.2080903@gmail.com> Date: Thu, 03 Sep 2009 12:06:57 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl><200909020837.43851.rogge@fgan.de><63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com><006701ca2baa$3c720320$b5560960$@nl><200909021807.n82I7ibr008763@cichlid.raleigh.ibm.com><39C363776A4E8C4A94691D2BD9D1C9A10659989A@XCH-NW-7V2.nw.nos.boeing.com><4A9ECA44.3000507@earthlink.net> <200909022049.n82Kngca014747@cichlid.raleigh.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Thomas Narten , autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 10:09:58 -0000 Dearlove, Christopher (UK) a écrit : > I believe > - Yes, you can generate LL addresses as Thomas indicates. > That satisfies some requirements. > - However those are not the routable address needed, as they > are local. Yes, but they should be used as src/dst fields in messages exchanging routing information data (if the routing protocol exchanges messages like OSPF does). They [link-local addresses] can also be used as src/dst fields in AUTOCONF messages which allocate new unique global or unique-local addresses. For example - an AUREQ (address uniqueness request) with link-local src/dst which is sent and re-sent across a "MANET" to request if a certain global address exists already. Alex > - The autoconf work is to generate those addresses, to be used > by MANET routing protocols, and then by applications. > - We also need those other addresses for even link symmetry > checking if there is a prohibition on link local addresses > being seen non-locally, as the physics is non-transitive, > and that's not changing. > - Trying to argue about two-hop (or, with mobility, MANET > wide) visibility of link local addresses is doomed to spin > wheels - in my estimation until the WG dies. > From Chris.Dearlove@baesystems.com Thu Sep 3 03:30:55 2009 Return-Path: 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 6030B3A6976 for ; Thu, 3 Sep 2009 03:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] 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 dZQGeU6XUhOB for ; Thu, 3 Sep 2009 03:30:54 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 0558B3A688B for ; Thu, 3 Sep 2009 03:30:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,324,1249254000"; d="scan'208";a="20341821" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 03 Sep 2009 11:29:21 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id n83ATMIe005346; Thu, 3 Sep 2009 11:29:23 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Sep 2009 11:29:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Sep 2009 11:29:19 +0100 Message-ID: In-Reply-To: <4A9F9541.2080903@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] call for consensus about link local address support thread-index: AcosflHNf0vO9qPkSS6KtkrFTNQ+CAAAW5Pw References: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl><200909020837.43851.rogge@fgan.de><63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com><006701ca2baa$3c720320$b5560960$@nl><200909021807.n82I7ibr008763@cichlid.raleigh.ibm.com><39C363776A4E8C4A94691D2BD9D1C9A10659989A@XCH-NW-7V2.nw.nos.boeing.com><4A9ECA44.3000507@earthlink.net> <200909022049.n82Kngca014747@cichlid.raleigh.ibm.com> <4A9F9541.2080903@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 03 Sep 2009 10:29:20.0819 (UTC) FILETIME=[660FB830:01CA2C81] Cc: Thomas Narten , autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 10:30:55 -0000 You are assuming that you are allowed to distribute a link local address across an entire MANET. People do that, and it can work. But other people aren't happy with that being permitted by the definition of link local, as it will mean that router A with no connection to router B will receive router B's link local address (via at least router C). That happens even just for router C transmitting router A's address to establish that it has a symmetric link to router A, due to the physical nature of wireless broadcast. If we say this (non-local link local addresses) is what we are doing, that will not (in my and other people's estimation) get a consensus of any sort in a useful timescale. So my view is that, for pragmatic reasons at least, let's not do that, and concentrate on autoconfiguration of addresses that can definitely be used non-locally, and which we also need for other purposes. --=20 Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Sent: 03 September 2009 11:07 To: Dearlove, Christopher (UK) Cc: Thomas Narten; Charles E. Perkins; autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message. Dearlove, Christopher (UK) a =E9crit : > I believe > - Yes, you can generate LL addresses as Thomas indicates. > That satisfies some requirements. > - However those are not the routable address needed, as they > are local. Yes, but they should be used as src/dst fields in messages exchanging=20 routing information data (if the routing protocol exchanges messages=20 like OSPF does). They [link-local addresses] can also be used as src/dst fields in=20 AUTOCONF messages which allocate new unique global or unique-local=20 addresses. For example - an AUREQ (address uniqueness request) with link-local=20 src/dst which is sent and re-sent across a "MANET" to request if a=20 certain global address exists already. Alex > - The autoconf work is to generate those addresses, to be used > by MANET routing protocols, and then by applications. > - We also need those other addresses for even link symmetry > checking if there is a prohibition on link local addresses > being seen non-locally, as the physics is non-transitive, > and that's not changing. > - Trying to argue about two-hop (or, with mobility, MANET > wide) visibility of link local addresses is doomed to spin > wheels - in my estimation until the WG dies. >=20 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From alexandru.petrescu@gmail.com Thu Sep 3 05:11:58 2009 Return-Path: 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 474373A682B for ; Thu, 3 Sep 2009 05:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.038 X-Spam-Level: X-Spam-Status: No, score=-2.038 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 GjIgVufkm1yn for ; Thu, 3 Sep 2009 05:11:57 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 9D2703A68F8 for ; Thu, 3 Sep 2009 05:11:54 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n83BCqx4022526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Sep 2009 13:12:52 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n83BCqR4007838; Thu, 3 Sep 2009 13:12:52 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n83BCppE031813; Thu, 3 Sep 2009 13:12:52 +0200 Message-ID: <4A9FA4B3.6010003@gmail.com> Date: Thu, 03 Sep 2009 13:12:51 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl><200909020837.43851.rogge@fgan.de><63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com><006701ca2baa$3c720320$b5560960$@nl><200909021807.n82I7ibr008763@cichlid.raleigh.ibm.com><39C363776A4E8C4A94691D2BD9D1C9A10659989A@XCH-NW-7V2.nw.nos.boeing.com><4A9ECA44.3000507@earthlink.net> <200909022049.n82Kngca014747@cichlid.raleigh.ibm.com> <4A9F9541.2080903@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Thomas Narten , autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 12:11:58 -0000 Dearlove, Christopher (UK) a écrit : > You are assuming that you are allowed to distribute a link local > address across an entire MANET. No, I am not assuming a link-local address distributed across an entire "MANET", but across a link. A message with a src link-local address received by a "MANET" node can be re-constructed and re-sent using its own link-local address, by that node, if needed to go to another link. In this way, messages with src/dst link-local addresses are not forwarded outside of a link, but are re-constructed. > People do that, and it can work. But other people aren't happy with > that being permitted by the definition of link local, I agree a message with a link-local address in src/dst field not to be forwarded outside of a link. The message can be re-constructed to respect this rule. > as it will mean that router A with no connection to router B will > receive router B's link local address (via at least router C). Not if the src address is re-written (or the message re-constructed). These are special control messages (not application flows) used for AUTOCONFing global or unique-local addresses. > That happens even just for router C transmitting router A's address > to establish that it has a symmetric link to router A, due to the > physical nature of wireless broadcast. > > If we say this (non-local link local addresses) is what we are doing, > that will not (in my and other people's estimation) get a consensus > of any sort in a useful timescale. So my view is that, for pragmatic > reasons at least, let's not do that, and concentrate on > autoconfiguration of addresses that can definitely be used > non-locally, and which we also need for other purposes. The first steps of any autoconfiguration mechanism must put something in the src/dst fields. What do you think will be there? I believe link-local addresses in there. And/or link-scoped multicast addresses. And/or Link-Local Multicast Group for MANET Routers (RFC5498). Alex From Fred.L.Templin@boeing.com Thu Sep 3 08:28:40 2009 Return-Path: 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 0177F28C368 for ; Thu, 3 Sep 2009 08:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.924 X-Spam-Level: X-Spam-Status: No, score=-5.924 tagged_above=-999 required=5 tests=[AWL=0.675, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 QkVZNo70n9sF for ; Thu, 3 Sep 2009 08:28:39 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 94F203A6DAE for ; Thu, 3 Sep 2009 08:28:11 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n83FQsCB004765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 3 Sep 2009 10:26:55 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n83FQsTA008618 for ; Thu, 3 Sep 2009 10:26:54 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n83FQpBI008495 for ; Thu, 3 Sep 2009 10:26:54 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 08:26:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Sep 2009 08:26:52 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A106599CC8@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <4A9EE020.2000807@earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] call for consensus about link local address support Thread-Index: AcosElYjaCCrVC34SvWbb+7xZNhyqwAmA+4Q References: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl><200909020837.43851.rogge@fgan.de><63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com><006701ca2baa$3c720320$b5560960$@nl> <200909021807.n82I7ibr008763@cichlid.raleigh.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A10659989A@XCH-NW-7V2.nw.nos.boeing.com> <4A9ECA44.3000507@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A1065999AD@XCH-NW-7V2.nw.nos.boeing.com> <4A9EE020.2000807@earthlink.net> From: "Templin, Fred L" To: X-OriginalArrivalTime: 03 Sep 2009 15:26:53.0400 (UTC) FILETIME=[F7076580:01CA2CAA] Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 15:28:40 -0000 Charlie, > -----Original Message----- > From: Charles E. Perkins [mailto:charles.perkins@earthlink.net] > Sent: Wednesday, September 02, 2009 2:14 PM > To: Templin, Fred L > Cc: Thomas Narten; Teco Boot; autoconf@ietf.org > Subject: Re: [Autoconf] call for consensus about link local address support >=20 >=20 > Hello Fred, >=20 > Templin, Fred L wrote: > > Charlie, > > > > > > > >>> Yes - all IPv6 interfaces are required to have an IPv6 > >>> link-local address. How a MANET interface might *use* > >>> an IPv6 link-local address is out of scope, and should > >>> not be rolled into a single consensus call item. > >>> > >>> > >> What if the SAME link-local address were assigned to EVERY > >> manet node in the network, and it was NEVER used? > >> > > > > What kind of a question is that? Configure the link-locals > > as you would for any other interface and such a scenario > > would never arise - use the link-locals between consenting > > nodes if you'd like, too. That's all. > > >=20 > Can't do it. Can't guarantee uniqueness across time and space. > Can't use DAD for link-locals. Who said anything about uniqueness? And, it seems like a rather myopic viewpoint to assert that anything having to do with a MANET would be "guaranteed". =20 > So I can't "Configure the link-locals as you would for any other interface". Sure you can; the specs tell how. Fred fred.l.templin@boeing.com > Regards, > Charlie P. >=20 >=20 >=20 >=20 From charles.perkins@earthlink.net Thu Sep 3 09:48:26 2009 Return-Path: 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 9478128C2E1 for ; Thu, 3 Sep 2009 09:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.882 X-Spam-Level: X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[AWL=0.098, 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 k7u6PvxkQDc2 for ; Thu, 3 Sep 2009 09:48:26 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id DF4CF28C1FC for ; Thu, 3 Sep 2009 09:48:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=UvWCoJ4j63tHA+cKH07Tb1y/8dfnBOnSm/2N+6UmGnh+r/wo5K/xLyDmaJrPIFhn; 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.52]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MjFTd-0006LG-N0; Thu, 03 Sep 2009 12:48:01 -0400 Message-ID: <4A9FF33C.7050409@earthlink.net> Date: Thu, 03 Sep 2009 09:47:56 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl> <200909020837.43851.rogge@fgan.de><63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com> <006701ca2baa$3c720320$b5560960$@nl> <4A9EA40E.1010405@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52bfbbf3cd0c947f28b52f8d6d994a82af350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 16:48:26 -0000 Hello Chris, Dearlove, Christopher (UK) wrote: >> I liked that you used "or" between "global" and "unique local". This >> definitely matches my preference. >> > > I have no idea whether people thought they were supporting exclusive > or inclusive or. It wasn't something I thought about, and don't have > a view on. > > It's not about "exclusive" vs. "inclusive" OR. I was commenting that OR is better than AND as a connective between "global" and "unique local". The reason is that we can't have "global" for standalone MANETs. So "AND" would be an immediate showstopper. Given "OR", I'm quite sure we would insist on "inclusive OR". Exclusive would be silly :-), although not unfathomable. Regards, Charlie P. From teco@inf-net.nl Thu Sep 3 10:32:42 2009 Return-Path: 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 9F6A928C39D for ; Thu, 3 Sep 2009 10:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[AWL=-0.368, BAYES_20=-0.74] 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 VulZsLbBzhFp for ; Thu, 3 Sep 2009 10:32:40 -0700 (PDT) Received: from CPSMTPM-EML110.kpnxchange.com (cpsmtpm-eml110.kpnxchange.com [195.121.3.14]) by core3.amsl.com (Postfix) with ESMTP id 89EF428C38B for ; Thu, 3 Sep 2009 10:32:40 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML110.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Thu, 3 Sep 2009 19:31:26 +0200 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" References: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl><200909020837.43851.rogge@fgan.de><63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com><006701ca2baa$3c720320$b5560960$@nl><200909021807.n82I7ibr008763@cichlid.raleigh.ibm.com><39C363776A4E8C4A94691D2BD9D1C9A10659989A@XCH-NW-7V2.nw.nos.boeing.com><4A9ECA44.3000507@earthlink.net> <200909022049.n82Kngca014747@cichlid.raleigh.ibm.com> In-Reply-To: Date: Thu, 3 Sep 2009 19:30:56 +0200 Message-ID: <001201ca2cbc$4b4a3a30$e1deae90$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcosEjGUEWNOFPDxR+qP+qU0YtqobgAaS0cwABAcODA= Content-Language: nl X-OriginalArrivalTime: 03 Sep 2009 17:31:26.0342 (UTC) FILETIME=[5D3FDA60:01CA2CBC] Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 17:32:42 -0000 |Van: Dearlove, Christopher (UK) |I believe ..... |- We also need those other addresses for even link symmetry | checking if there is a prohibition on link local addresses | being seen non-locally, as the physics is non-transitive, | and that's not changing. Not sure on this. When LLs have unique IfId's, there is no need for other addresses. Or when unique RouterId's are used. Teco. From charles.perkins@earthlink.net Thu Sep 3 11:14:25 2009 Return-Path: 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 21BCB3A6828 for ; Thu, 3 Sep 2009 11:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[AWL=0.093, 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 gjplOtMy0NJ3 for ; Thu, 3 Sep 2009 11:14:24 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 3D2463A6825 for ; Thu, 3 Sep 2009 11:14:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=C6EdhLmkD3MUEyUMRq+UzZKQYxY2ze+Lg7UuRSBtnNoDyp+OJ0Y+SkyIcQHkWn6G; 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.52]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MjGUr-0006uE-NZ; Thu, 03 Sep 2009 13:53:21 -0400 Message-ID: <4AA0028C.4030505@earthlink.net> Date: Thu, 03 Sep 2009 10:53:16 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Templin, Fred L" References: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl><200909020837.43851.rogge@fgan.de><63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com><006701ca2baa$3c720320$b5560960$@nl> <200909021807.n82I7ibr008763@cichlid.raleigh.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A10659989A@XCH-NW-7V2.nw.nos.boeing.com> <4A9ECA44.3000507@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A1065999AD@XCH-NW-7V2.nw.nos.boeing.com> <4A9EE020.2000807@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A106599CC8@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A106599CC8@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5274163008016f269c58e588b303c1c8cf350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 18:14:25 -0000 Hello Fred, Templin, Fred L wrote: > >> Can't do it. Can't guarantee uniqueness across time and space. >> Can't use DAD for link-locals. >> > > Who said anything about uniqueness? And, it seems like > a rather myopic viewpoint to assert that anything > having to do with a MANET would be "guaranteed". > Well, O.K., if link-locals don't have to be unique, then I am surprised. Maybe you didn't mean that. Are you sure you don't want unique link-locals? > > >> So I can't "Configure the link-locals as you would for any other >> > interface". > > Sure you can; the specs tell how. > > I must have missed that. Or else you are thinking about something different than I am. Maybe a concrete example will help. Here are four nodes at time T_0: A --------- B --------- C --------- D The dashed lines indicate neighborliness at time T_0. Assume all bidirectional links. At time T_1, a second later, the neighborhoods are as follows: A --------- C --------- B --------- D Please explain how you identify the links upon which your assignment of link-local addresses are valid, and indicate a compatible assignment of link local addresses, and indicate which specs provide you with the protocol mechanism for carrying out the proposed assignment. How many links are there in your model of this network? Do you think your link definition is the only one that should be considered valid for work in [autoconf]? Narten's answer was "unique MAC-layer addresses". Do you agree with that? Do you think we should restrict work in [autoconf] to be applicable only to such networks in which that restriction is valid? Do you have any intuition about the scalability of the system resulting from your definitions? What if you discovered that your definitions resulted in a system that was three orders of magnitude less scalable than an alternative that did not impose a requirement for assigning unique link-local addresses? -- or, a system that, effectively, didn't even define any broadcast-oriented links at all? Regards, Charlie P. From thomas@thomasclausen.org Wed Sep 9 07:56:47 2009 Return-Path: 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 0D1CC3A68CD for ; Wed, 9 Sep 2009 07:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 QYUS4CosckgT for ; Wed, 9 Sep 2009 07:56:45 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 9D7FA3A6848 for ; Wed, 9 Sep 2009 07:56:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 8C84932317A2 for ; Wed, 9 Sep 2009 07:57:18 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.112.166] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 024F232317AF for ; Wed, 9 Sep 2009 07:57:16 -0700 (PDT) Message-Id: From: Thomas Heide Clausen To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-3--676871889 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 9 Sep 2009 16:57:14 +0200 References: <20090909143800.E2CD928C13E@core3.amsl.com> X-Mailer: Apple Mail (2.936) Subject: [Autoconf] Fwd: Nomcom 2009-10: Important Reminder: Call for Nominations, Local Office hours, Nominee Questionnaires available X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 14:56:47 -0000 --Apple-Mail-3--676871889 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit All, The NomCom needs your input. Thomas Begin forwarded message: > From: Mary Barnes > Date: September 9, 2009 4:37:59 PM CEDT > To: IETF Announcement list > Cc: ietf@ietf.org > Subject: Nomcom 2009-10: Important Reminder: Call for Nominations, > Local Office hours, Nominee Questionnaires available > > Hi all, > > This is a 2nd reminder of the Call for Nominations that is > underway. We > *really* need more nominations in order to properly execute the task > of > selecting candidates for the open positions. At this time, the > number of > nominations for all the positions is about 1/2 of what is necessary > for > the Nomcom to do a conscientious job of evaluating the nominees and > we are > over 2/3 of the way through the nominations period. Nomcom cannot do > their > job without this important input from the community. > > So, please consider making nominations for the open positions - it > takes > just a few minutes of your time - the details are below. Right now, > we > just need the names/email addresses for the nominees - we'll be > soliciting > feedback later. Also, consider that over 1/2 the nominees are not > able to > accept the nominations for a variety of reasons - e.g., lack of > funding, > lack of sponsor support, etc. Thus, please consider nominating more > than > one individual for each of the positions. > > As well as the reminder for the call for nominations, this email also > serves as a reminder for: > 2) Local Office Hours > 3) Questionnaires available for nominees > > Best Regards, > Mary Barnes > nomcom-chair@ietf.org > mary.h.barnes@gmail.com > mary.barnes@nortel.com > > > = > = > = > ====================================================================== > > 1) Call for Nominations > ------------------------ > The nomination period ends in less than 2 weeks on Sept. 18th, 2009. > We > appreciate the folks that have taken the time to make nominations thus > far. But, we do need more nominations. Please use the online tool to > nominate - it's fast, easy and secure: > https://wiki.tools.ietf.org/group/nomcom/09/nominate > > Details on the open positions, as well as other details and options > for > making nominations are available on the Nomcom homepage: > https://wiki.tools.ietf.org/group/nomcom/09/ > > Please consider that the sooner you make the nominations, the more > time > your nominee(s) will have to complete the necessary questionnaire > (item 3 > below). As well, please consider nominating more than one person > for a > particular position. You will have the opportunity to provide > additional > feedback later and it's important to consider that not all nominees > will > be able to accept the nomination. > > > 2) Local office hours > ----------------------- > > In order facilitate additional feedback, the Nomcom has decided to > make > themselves available for office areas at various geographic > locations for > 3 weeks in September, starting on the 8th. > > Below please find the list of locations where Nomcom members will be > available for these f2f meetings . Unless dates are identified > below, the > Nomcom member is generally available for part of the day during the > weeks > of Sept 8-11, Sept 14-18 and Sept 21-25. Also, languages other than > English in which the Nomcom member is fluent are identfied. > > Please contact a Nomcom member in a specific geographic location to > arrange a convenient meeting time and place. Most Nomcom members are > flexible as to meeting locations - i.e., we can travel to your office, > meet at our offices or somewhere in between. > > As a reminder folks can always contact any Nomcom member to provide > feedback at anytime - i.e., you don't need to participate in these f2f > sessions to provide feedback. > > > Belgium: > Dimitri Papadimitriou - dimitri.papadimitriou@alcatel-lucent.be > (Sept > 21-25) (Languages: French) > > Boston, Mass, USA: > Stephen Kent - kent@bbn.com (Sept 16-18) > > Boulder, CO, USA: > Wassim Haddad - wmhaddad@gmail.com (Sept 14-18) > > Dallas/Ft. Worth, TX, USA: > Mary Barnes - mary.h.barnes@gmail.com > Lucy Yong - lucyyong@huawei.com (Languages: Chinese) > > Helsinki, Finland: > Simo Veikkolainen - simo.veikkolainen@nokia.com (Languages: > Finnish) > > > Ithaca, NY, USA: > Scott Brim - scott.brim@gmail.com > > Montevideo, Uruguay: > Roque Gagliano - roque@lacnic.net (Sept 14-18, 21-25) (Languages: > Spanish, Portuguese) > > Montreal, Quebec, Canada > Wassim Haddad - wmhaddad@gmail.com (Sept 8-11) > -- Can also be available in Ottawa if folks are interested > > Paris, France: > Dimitri Papadimitriou - dimitri.papadimitriou@alcatel-lucent.be > (Sept 15-18) (Languages: French) > > San Diego, CA, USA: > Randall Gellens - rg+ietf@qualcomm.com > Dave Crocker - dcrocker@bbiw.net (Sept 16-18) > > Silicon Valley/SF Bay, CA, USA: > Dave Crocker - dcrocker@bbiw.net (Sept 8-11, Sept 14-15, Sept > 21-25) > Dorothy Gellert - Dorothy.gellert@gmail.com > > 3) Questionnaires available for nominees: > > For folks that have been notified that they have been nominated for > any > of the positions, the questionnaires are now available on the Nomcom09 > tools website: > https://wiki.tools.ietf.org/group/nomcom/09/iab-questionnaire > https://wiki.tools.ietf.org/group/nomcom/09/iaoc-questionnaire > https://wiki.tools.ietf.org/group/nomcom/09/iesg-questionnaire > > If you have any questions, please let me know. I will be contacting > everyone individually, as well as sending reminders. > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail-3--676871889 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable All,

The = NomCom needs your = input.

Thomas


Begin = forwarded message:

From: = Mary Barnes <mary.barnes@nortel.com>
Date: September 9, 2009 4:37:59 PM = CEDT
To: IETF Announcement list <ietf-announce@ietf.org>
Subject: = Nomcom 2009-10: Important Reminder: Call for Nominations, = Local  Office hours, = Nominee Questionnaires available 

Hi = all,

This is a 2nd reminder of the Call for Nominations that is = underway.  We
*really* need more nominations in order to = properly execute the task of
selecting candidates for the open = positions. At this time, the number of
nominations for all the = positions is about 1/2 of what is necessary for
the Nomcom to do a = conscientious job of evaluating the nominees and we are
over 2/3 of = the way through the nominations period. Nomcom cannot do their
job = without this important input from the community.

So, please = consider making nominations for the open positions - it takes
just a = few minutes of your time - the details are below.  Right now, = we
just need the names/email addresses for the nominees - we'll be = soliciting
feedback later. Also, consider that over 1/2 the nominees = are not able to
accept the nominations for a variety of reasons - = e.g., lack of funding,
lack of sponsor support, etc. Thus, please = consider nominating more than
one individual for each of the = positions.  

As well as the reminder for the call for = nominations, this email also
serves as a reminder for:
2) Local = Office Hours
3) Questionnaires available for nominees

Best = Regards,
Mary Barnes
nomcom-chair@ietf.org
mary.h.= barnes@gmail.com
mary.barnes@nortel.com


=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

1) Call for = Nominations
------------------------
The nomination period ends in = less than 2 weeks on Sept. 18th, 2009. We
appreciate the folks that = have taken the time to make nominations thus
far. But, we do need = more nominations. Please use the online tool to
nominate - it's fast, = easy and = secure:
https://wiki.tools.ietf.org/group/nomcom/09/nominate

Det= ails on the open positions, as well as other details and options = for
making nominations are available on the Nomcom = homepage:
https://wiki.tools.ietf.org/group/nomcom/09/

Please = consider that the sooner you make the nominations, the more time
your = nominee(s) will have to complete the necessary questionnaire (item = 3
below).  As well, please consider nominating more than one = person for a
particular position. You will have the opportunity to = provide additional
feedback later and it's important to consider that = not all nominees will
be able to accept the nomination. =


2) Local office hours
-----------------------

In = order facilitate additional feedback, the Nomcom has decided to = make
themselves available for office areas at various geographic = locations for
3 weeks in September, starting on the 8th. =

Below please find the list of locations where Nomcom members = will be
available for these f2f meetings . Unless dates are = identified below, the
Nomcom member is generally available for part = of the day during the weeks
of Sept 8-11, Sept 14-18 and Sept 21-25. = Also, languages other than
English in which the Nomcom member is = fluent are identfied.  

Please contact a Nomcom member in a = specific geographic location to
arrange a convenient meeting time and = place. Most Nomcom members are
flexible as to meeting locations - = i.e., we can travel to your office,
meet at our offices or somewhere = in between.  

As a reminder folks can always contact any = Nomcom member to provide
feedback at anytime - i.e., you don't need = to participate in these f2f
sessions to provide feedback. =


Belgium:
    Dimitri Papadimitriou = - dimitri.papadimitriou@alcatel-lucent.be (Sept
21-25) (Languages: = French)

Boston, Mass, USA:  
=     Stephen Kent - kent@bbn.com  (Sept 16-18) =

Boulder, CO, USA:
    Wassim Haddad - = wmhaddad@gmail.com (Sept 14-18)

Dallas/Ft. Worth, TX, USA: =  
    Mary Barnes  - = mary.h.barnes@gmail.com
    Lucy Yong - = lucyyong@huawei.com  (Languages: Chinese)

Helsinki, = Finland:
     Simo Veikkolainen - = simo.veikkolainen@nokia.com (Languages: Finnish)


Ithaca, NY, = USA:
     Scott Brim - = scott.brim@gmail.com

Montevideo, Uruguay:
=      Roque Gagliano - roque@lacnic.net (Sept = 14-18, 21-25) (Languages:
Spanish, Portuguese)

Montreal, = Quebec, Canada
    Wassim Haddad - = wmhaddad@gmail.com (Sept 8-11)
    -- Can also = be available in Ottawa if folks are interested

Paris, France: =
     Dimitri Papadimitriou - = dimitri.papadimitriou@alcatel-lucent.be
(Sept 15-18) =  (Languages: French)

San Diego, CA, USA:
=      Randall Gellens - rg+ietf@qualcomm.com =   
     Dave Crocker - = dcrocker@bbiw.net  (Sept 16-18)

Silicon Valley/SF Bay, =  CA, USA:
     Dave Crocker - = dcrocker@bbiw.net  (Sept 8-11, Sept 14-15, Sept
21-25) =   
     Dorothy Gellert - = Dorothy.gellert@gmail.com

3) Questionnaires available for = nominees:

For folks that have been notified that they have been = nominated for any
of the positions, the questionnaires are now = available on the Nomcom09
tools = website:
https://wiki.tools.ietf.org/group/nomcom/09/iab-questionnaire<= br>https://wiki.tools.ietf.org/group/nomcom/09/iaoc-questionnaire
https= ://wiki.tools.ietf.org/group/nomcom/09/iesg-questionnaire

If you = have any questions, please let me know. I will be contacting
everyone = individually, as well as sending reminders. =


_______________________________________________
IETF-Announ= ce mailing = list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ie= tf-announce

= --Apple-Mail-3--676871889-- From charles.perkins@earthlink.net Mon Sep 21 11:36:16 2009 Return-Path: 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 1E2C93A6914 for ; Mon, 21 Sep 2009 11:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.981 X-Spam-Level: X-Spam-Status: No, score=-0.981 tagged_above=-999 required=5 tests=[AWL=-0.860, BAYES_20=-0.74, 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 jrmvO-b+yT+9 for ; Mon, 21 Sep 2009 11:36:15 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 2EB1A3A67F2 for ; Mon, 21 Sep 2009 11:36:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Kqj+iXRfbN8c1bdNb4w//uzrTlEkjZ5hPJyjB9qzMQnWjCXOVlTlRxALGI7XYpYI; 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.12]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MpnlE-0000Kh-VN; Mon, 21 Sep 2009 14:37:17 -0400 Message-ID: <4AB7C7DC.4000403@earthlink.net> Date: Mon, 21 Sep 2009 11:37:16 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: autoconf@ietf.org References: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl><200909020837.43851.rogge@fgan.de><63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com><006701ca2baa$3c720320$b5560960$@nl> <200909021807.n82I7ibr008763@cichlid.raleigh.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A10659989A@XCH-NW-7V2.nw.nos.boeing.com> <4A9ECA44.3000507@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A1065999AD@XCH-NW-7V2.nw.nos.boeing.com> <4A9EE020.2000807@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A106599CC8@XCH-NW-7V2.nw.nos.boeing.com> <4AA0028C.4030505@earthlink.net> In-Reply-To: <4AA0028C.4030505@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f526515649a1c0f249bb4dbd64599292dd8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 18:36:16 -0000 Hello folks, I asked some very pertinent questions to this list a few weeks ago. Up until now, no one who has been clamoring for mandatory inclusion of link-local addresses in [autoconf] design documents has answered my questions about a very simple network. Four nodes! I can tell you_exactly_ how it _can_ work if we don't MANDATE link-locals, and my solution is scalable. I think the matter is important enough to deserve a response -- especially given the amount of time (measured in _years_!) demanded by the link-local proponents for previous discussions of the abstract concepts. Do any link-local proponents have any answers? Please see my example network and my questions, re-posted below. Regards, Charlie P. PS. Again, for the nth time, I am not against link locals. I am against mandating their use, and I am against requiring all solutions to resolve the issues surrounding the assignment of link-local addresses. Charles E. Perkins wrote: > > Hello Fred, > > Templin, Fred L wrote: >> >>> Can't do it. Can't guarantee uniqueness across time and space. >>> Can't use DAD for link-locals. >>> >> >> Who said anything about uniqueness? And, it seems like >> a rather myopic viewpoint to assert that anything >> having to do with a MANET would be "guaranteed". >> > > Well, O.K., if link-locals don't have to be unique, then I am > surprised. Maybe you didn't mean that. Are you sure you don't > want unique link-locals? > >> >> >>> So I can't "Configure the link-locals as you would for any other >>> >> interface". >> >> Sure you can; the specs tell how. >> >> > > I must have missed that. Or else you are thinking about > something different than I am. > > Maybe a concrete example will help. > > Here are four nodes at time T_0: > > A --------- B --------- C --------- D > > The dashed lines indicate neighborliness at time T_0. > Assume all bidirectional links. > > At time T_1, a second later, the neighborhoods > are as follows: > > A --------- C --------- B --------- D > > Please explain how you identify the links upon which > your assignment of link-local addresses are valid, and > indicate a compatible assignment of link local addresses, > and indicate which specs provide you with the protocol > mechanism for carrying out the proposed assignment. > How many links are there in your model of this network? > > Do you think your link definition is the only one that should > be considered valid for work in [autoconf]? > > Narten's answer was "unique MAC-layer addresses". > Do you agree with that? Do you think we should restrict > work in [autoconf] to be applicable only to such networks > in which that restriction is valid? > > Do you have any intuition about the scalability of the > system resulting from your definitions? > > What if you discovered that your definitions resulted in a > system that was three orders of magnitude less scalable than > an alternative that did not impose a requirement for assigning > unique link-local addresses? -- or, a system that, effectively, > didn't even define any broadcast-oriented links at all? > > Regards, > Charlie P. > > From Fred.L.Templin@boeing.com Mon Sep 21 12:14:15 2009 Return-Path: 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 E1FDC3A690E for ; Mon, 21 Sep 2009 12:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.087 X-Spam-Level: X-Spam-Status: No, score=-5.087 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] 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 YOzLzK1W+tuo for ; Mon, 21 Sep 2009 12:14:15 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 051AB3A6831 for ; Mon, 21 Sep 2009 12:14:14 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n8LJFE5o027421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Sep 2009 12:15:14 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n8LJFDU6018346; Mon, 21 Sep 2009 12:15:13 -0700 (PDT) Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n8LJFDsO018331 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 21 Sep 2009 12:15:13 -0700 (PDT) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Mon, 21 Sep 2009 12:15:13 -0700 From: "Templin, Fred L" To: "Charles E. Perkins" , "autoconf@ietf.org" Date: Mon, 21 Sep 2009 12:15:12 -0700 Thread-Topic: [Autoconf] call for consensus about link local address support Thread-Index: Aco66oxIwQt8KTfwTP6V6vIWq7vbfgAAu66w Message-ID: <12F4112206976147A34FEC0277597CCF27A4093D54@XCH-NW-15V.nw.nos.boeing.com> References: <7877C5C0B5CC894 AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl><200909020837.43851.rogg e@fgan.de><63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com><006701ca2baa$3c7 20320$b5560960$@nl> <200909021807.n82I7ibr008763@cichlid.raleigh.ibm.com> < 39C363776A4E8C4A94691D2BD9D1C9A10659989A@XCH-NW-7V2.nw.nos.boeing.com> <4A9 ECA44.3000507@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A1065999AD@XCH- NW-7V2.nw.nos.boeing.com> <4A9EE020.2000807@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A106599CC8@XCH-NW-7V2.nw.nos.boeing.com> <4AA0028C.4030505@earthlink.net> <4AB7C7DC.4000403@earthlink.net> In-Reply-To: <4AB7C7DC.4000403@earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 19:14:16 -0000 Charlie, If you are talking about me, your questions were unanswerable because you made incorrect first assumptions about my meaning and then vectored off from there. Fred fred.l.templin@boeing.com > -----Original Message----- > From: Charles E. Perkins [mailto:charles.perkins@earthlink.net] > Sent: Monday, September 21, 2009 11:37 AM > To: autoconf@ietf.org > Cc: Templin, Fred L > Subject: Re: [Autoconf] call for consensus about link local address suppo= rt >=20 >=20 > Hello folks, >=20 > I asked some very pertinent questions to this list a few > weeks ago. >=20 > Up until now, no one who has been clamoring for mandatory > inclusion of link-local addresses in [autoconf] design documents > has answered my questions about a very simple network. > Four nodes! >=20 > I can tell you_exactly_ how it _can_ work if we don't > MANDATE link-locals, and my solution is scalable. >=20 > I think the matter is important enough to deserve a > response -- especially given the amount of time (measured > in _years_!) demanded by the link-local proponents for > previous discussions of the abstract concepts. >=20 > Do any link-local proponents have any answers? > Please see my example network and my questions, > re-posted below. >=20 > Regards, > Charlie P. >=20 > PS. Again, for the nth time, I am not against link locals. > I am against mandating their use, and I am against > requiring all solutions to resolve the issues surrounding > the assignment of link-local addresses. >=20 >=20 > Charles E. Perkins wrote: > > > > Hello Fred, > > > > Templin, Fred L wrote: > >> > >>> Can't do it. Can't guarantee uniqueness across time and space. > >>> Can't use DAD for link-locals. > >>> > >> > >> Who said anything about uniqueness? And, it seems like > >> a rather myopic viewpoint to assert that anything > >> having to do with a MANET would be "guaranteed". > >> > > > > Well, O.K., if link-locals don't have to be unique, then I am > > surprised. Maybe you didn't mean that. Are you sure you don't > > want unique link-locals? > > > >> > >> > >>> So I can't "Configure the link-locals as you would for any other > >>> > >> interface". > >> > >> Sure you can; the specs tell how. > >> > >> > > > > I must have missed that. Or else you are thinking about > > something different than I am. > > > > Maybe a concrete example will help. > > > > Here are four nodes at time T_0: > > > > A --------- B --------- C --------- D > > > > The dashed lines indicate neighborliness at time T_0. > > Assume all bidirectional links. > > > > At time T_1, a second later, the neighborhoods > > are as follows: > > > > A --------- C --------- B --------- D > > > > Please explain how you identify the links upon which > > your assignment of link-local addresses are valid, and > > indicate a compatible assignment of link local addresses, > > and indicate which specs provide you with the protocol > > mechanism for carrying out the proposed assignment. > > How many links are there in your model of this network? > > > > Do you think your link definition is the only one that should > > be considered valid for work in [autoconf]? > > > > Narten's answer was "unique MAC-layer addresses". > > Do you agree with that? Do you think we should restrict > > work in [autoconf] to be applicable only to such networks > > in which that restriction is valid? > > > > Do you have any intuition about the scalability of the > > system resulting from your definitions? > > > > What if you discovered that your definitions resulted in a > > system that was three orders of magnitude less scalable than > > an alternative that did not impose a requirement for assigning > > unique link-local addresses? -- or, a system that, effectively, > > didn't even define any broadcast-oriented links at all? > > > > Regards, > > Charlie P. > > > > From charles.perkins@earthlink.net Mon Sep 21 12:26:32 2009 Return-Path: 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 C36863A6839 for ; Mon, 21 Sep 2009 12:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[AWL=0.099, 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 uO4GuvYo4FxU for ; Mon, 21 Sep 2009 12:26:32 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id D35FD3A6984 for ; Mon, 21 Sep 2009 12:26:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Qs56NZr/p8dZOYi0eb4FMmaqR+teGf3OihjZjdYXc3LKaHlDZ9D/QPZ4R42/a57w; 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.12]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MpoXt-0003ku-IV; Mon, 21 Sep 2009 15:27:33 -0400 Message-ID: <4AB7D3A4.4010600@earthlink.net> Date: Mon, 21 Sep 2009 12:27:32 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Templin, Fred L" References: <7877C5C0B5CC894 AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl><200909020837.43851.rogg e@fgan.de><63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com><006701ca2baa$3c7 20320$b5560960$@nl> <200909021807.n82I7ibr008763@cichlid.raleigh.ibm.com> < 39C363776A4E8C4A94691D2BD9D1C9A10659989A@XCH-NW-7V2.nw.nos.boeing.com> <4A9 ECA44.3000507@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A1065999AD@XCH- NW-7V2.nw.nos.boeing.com> <4A9EE020.2000807@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A106599CC8@XCH-NW-7V2.nw.nos.boeing.com> <4AA0028C.4030505@earthlink.net> <4AB7C7DC.4000403@earthlink.net> <12F4112206976147A34FEC0277597CCF27A4093D54@XCH-NW-15V.nw.nos.boeing.com> In-Reply-To: <12F4112206976147A34FEC0277597CCF27A4093D54@XCH-NW-15V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52b4346eceea9507b1e6e0b1c3bc579de5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 19:26:32 -0000 Hello Fred, I'd appreciate it if you could point out where I went wrong. Plus, my example network does not in any way depend on my assumptions about your meanings. I'm happy to resume the discussion! And I really prefer to not be misled by wrong ideas about what you meant. Regards, Charlie P. Templin, Fred L wrote: > Charlie, > > If you are talking about me, your questions were unanswerable > because you made incorrect first assumptions about my meaning > and then vectored off from there. > > Fred > fred.l.templin@boeing.com > > >> -----Original Message----- >> From: Charles E. Perkins [mailto:charles.perkins@earthlink.net] >> Sent: Monday, September 21, 2009 11:37 AM >> To: autoconf@ietf.org >> Cc: Templin, Fred L >> Subject: Re: [Autoconf] call for consensus about link local address support >> >> >> Hello folks, >> >> I asked some very pertinent questions to this list a few >> weeks ago. >> >> Up until now, no one who has been clamoring for mandatory >> inclusion of link-local addresses in [autoconf] design documents >> has answered my questions about a very simple network. >> Four nodes! >> >> I can tell you_exactly_ how it _can_ work if we don't >> MANDATE link-locals, and my solution is scalable. >> >> I think the matter is important enough to deserve a >> response -- especially given the amount of time (measured >> in _years_!) demanded by the link-local proponents for >> previous discussions of the abstract concepts. >> >> Do any link-local proponents have any answers? >> Please see my example network and my questions, >> re-posted below. >> >> Regards, >> Charlie P. >> >> PS. Again, for the nth time, I am not against link locals. >> I am against mandating their use, and I am against >> requiring all solutions to resolve the issues surrounding >> the assignment of link-local addresses. >> >> >> Charles E. Perkins wrote: >> >>> Hello Fred, >>> >>> Templin, Fred L wrote: >>> >>>>> Can't do it. Can't guarantee uniqueness across time and space. >>>>> Can't use DAD for link-locals. >>>>> >>>>> >>>> Who said anything about uniqueness? And, it seems like >>>> a rather myopic viewpoint to assert that anything >>>> having to do with a MANET would be "guaranteed". >>>> >>>> >>> Well, O.K., if link-locals don't have to be unique, then I am >>> surprised. Maybe you didn't mean that. Are you sure you don't >>> want unique link-locals? >>> >>> >>>> >>>>> So I can't "Configure the link-locals as you would for any other >>>>> >>>>> >>>> interface". >>>> >>>> Sure you can; the specs tell how. >>>> >>>> >>>> >>> I must have missed that. Or else you are thinking about >>> something different than I am. >>> >>> Maybe a concrete example will help. >>> >>> Here are four nodes at time T_0: >>> >>> A --------- B --------- C --------- D >>> >>> The dashed lines indicate neighborliness at time T_0. >>> Assume all bidirectional links. >>> >>> At time T_1, a second later, the neighborhoods >>> are as follows: >>> >>> A --------- C --------- B --------- D >>> >>> Please explain how you identify the links upon which >>> your assignment of link-local addresses are valid, and >>> indicate a compatible assignment of link local addresses, >>> and indicate which specs provide you with the protocol >>> mechanism for carrying out the proposed assignment. >>> How many links are there in your model of this network? >>> >>> Do you think your link definition is the only one that should >>> be considered valid for work in [autoconf]? >>> >>> Narten's answer was "unique MAC-layer addresses". >>> Do you agree with that? Do you think we should restrict >>> work in [autoconf] to be applicable only to such networks >>> in which that restriction is valid? >>> >>> Do you have any intuition about the scalability of the >>> system resulting from your definitions? >>> >>> What if you discovered that your definitions resulted in a >>> system that was three orders of magnitude less scalable than >>> an alternative that did not impose a requirement for assigning >>> unique link-local addresses? -- or, a system that, effectively, >>> didn't even define any broadcast-oriented links at all? >>> >>> Regards, >>> Charlie P. >>> >>> >>> > > > > From Fred.L.Templin@boeing.com Mon Sep 21 12:42:36 2009 Return-Path: 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 14ED13A6AFC for ; Mon, 21 Sep 2009 12:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.012 X-Spam-Level: X-Spam-Status: No, score=-6.012 tagged_above=-999 required=5 tests=[AWL=0.587, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 LNDqE73YhjQ3 for ; Mon, 21 Sep 2009 12:42:32 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 817BE3A6AF8 for ; Mon, 21 Sep 2009 12:42:30 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n8LJhSZi022537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 21 Sep 2009 14:43:29 -0500 (CDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n8LJhSa1014053; Mon, 21 Sep 2009 12:43:28 -0700 (PDT) Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n8LJhSoG014043 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 21 Sep 2009 12:43:28 -0700 (PDT) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Mon, 21 Sep 2009 12:43:27 -0700 From: "Templin, Fred L" To: "Charles E. Perkins" Date: Mon, 21 Sep 2009 12:43:25 -0700 Thread-Topic: [Autoconf] call for consensus about link local address support Thread-Index: Aco68ZKN1tGQ2al8TtuMsutSd4LKXgAAeGfw Message-ID: <12F4112206976147A34FEC0277597CCF27A4093D76@XCH-NW-15V.nw.nos.boeing.com> References: <7877C5C0B5CC894 AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl><200909020837.43851.rog g e@fgan.de><63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com><006701ca2baa$3 c7 20320$b5560960$@nl> <200909021807.n82I7ibr008763@cichlid.raleigh.ibm.com > < 39C363776A4E8C4A94691D2BD9D1C9A10659989A@XCH-NW-7V2.nw.nos.boeing.com> <4A9 ECA44.3000507@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A1065999AD @XCH- NW-7V2.nw.nos.boeing.com> <4A9EE020.2000807@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A106599CC8@XCH-NW-7V2.nw.nos.boeing.com> <4AA0028C.4030505@earthlink.net> <4AB7C7DC.4000403@earthlink.net> <12F4112206976147A34FEC0277597CCF27A4093D54@XCH-NW-15V.nw.nos.boeing.com> <4AB7D3A4.4010600@earthlink.net> In-Reply-To: <4AB7D3A4.4010600@earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.0.0.1181-5.600.1016-16888.004 x-tm-as-result: No--81.398400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 19:42:36 -0000 Charlie, > -----Original Message----- > From: Charles E. Perkins [mailto:charles.perkins@earthlink.net] > Sent: Monday, September 21, 2009 12:28 PM > To: Templin, Fred L > Cc: autoconf@ietf.org > Subject: Re: [Autoconf] call for consensus about link local address suppo= rt >=20 >=20 > Hello Fred, >=20 > I'd appreciate it if you could point out > where I went wrong. I'm sorry, but I'm not going to get drawn into an on-list interrogation. > Plus, my example network does not > in any way depend on my assumptions > about your meanings. On this point, we disagree. Fred fred.l.templin@boeing.com=20 > I'm happy to resume the discussion! > And I really prefer to not be misled > by wrong ideas about what you meant. >=20 > Regards, > Charlie P. >=20 >=20 > Templin, Fred L wrote: > > Charlie, > > > > If you are talking about me, your questions were unanswerable > > because you made incorrect first assumptions about my meaning > > and then vectored off from there. > > > > Fred > > fred.l.templin@boeing.com > > > > > >> -----Original Message----- > >> From: Charles E. Perkins [mailto:charles.perkins@earthlink.net] > >> Sent: Monday, September 21, 2009 11:37 AM > >> To: autoconf@ietf.org > >> Cc: Templin, Fred L > >> Subject: Re: [Autoconf] call for consensus about link local address su= pport > >> > >> > >> Hello folks, > >> > >> I asked some very pertinent questions to this list a few > >> weeks ago. > >> > >> Up until now, no one who has been clamoring for mandatory > >> inclusion of link-local addresses in [autoconf] design documents > >> has answered my questions about a very simple network. > >> Four nodes! > >> > >> I can tell you_exactly_ how it _can_ work if we don't > >> MANDATE link-locals, and my solution is scalable. > >> > >> I think the matter is important enough to deserve a > >> response -- especially given the amount of time (measured > >> in _years_!) demanded by the link-local proponents for > >> previous discussions of the abstract concepts. > >> > >> Do any link-local proponents have any answers? > >> Please see my example network and my questions, > >> re-posted below. > >> > >> Regards, > >> Charlie P. > >> > >> PS. Again, for the nth time, I am not against link locals. > >> I am against mandating their use, and I am against > >> requiring all solutions to resolve the issues surrounding > >> the assignment of link-local addresses. > >> > >> > >> Charles E. Perkins wrote: > >> > >>> Hello Fred, > >>> > >>> Templin, Fred L wrote: > >>> > >>>>> Can't do it. Can't guarantee uniqueness across time and space. > >>>>> Can't use DAD for link-locals. > >>>>> > >>>>> > >>>> Who said anything about uniqueness? And, it seems like > >>>> a rather myopic viewpoint to assert that anything > >>>> having to do with a MANET would be "guaranteed". > >>>> > >>>> > >>> Well, O.K., if link-locals don't have to be unique, then I am > >>> surprised. Maybe you didn't mean that. Are you sure you don't > >>> want unique link-locals? > >>> > >>> > >>>> > >>>>> So I can't "Configure the link-locals as you would for any other > >>>>> > >>>>> > >>>> interface". > >>>> > >>>> Sure you can; the specs tell how. > >>>> > >>>> > >>>> > >>> I must have missed that. Or else you are thinking about > >>> something different than I am. > >>> > >>> Maybe a concrete example will help. > >>> > >>> Here are four nodes at time T_0: > >>> > >>> A --------- B --------- C --------- D > >>> > >>> The dashed lines indicate neighborliness at time T_0. > >>> Assume all bidirectional links. > >>> > >>> At time T_1, a second later, the neighborhoods > >>> are as follows: > >>> > >>> A --------- C --------- B --------- D > >>> > >>> Please explain how you identify the links upon which > >>> your assignment of link-local addresses are valid, and > >>> indicate a compatible assignment of link local addresses, > >>> and indicate which specs provide you with the protocol > >>> mechanism for carrying out the proposed assignment. > >>> How many links are there in your model of this network? > >>> > >>> Do you think your link definition is the only one that should > >>> be considered valid for work in [autoconf]? > >>> > >>> Narten's answer was "unique MAC-layer addresses". > >>> Do you agree with that? Do you think we should restrict > >>> work in [autoconf] to be applicable only to such networks > >>> in which that restriction is valid? > >>> > >>> Do you have any intuition about the scalability of the > >>> system resulting from your definitions? > >>> > >>> What if you discovered that your definitions resulted in a > >>> system that was three orders of magnitude less scalable than > >>> an alternative that did not impose a requirement for assigning > >>> unique link-local addresses? -- or, a system that, effectively, > >>> didn't even define any broadcast-oriented links at all? > >>> > >>> Regards, > >>> Charlie P. > >>> > >>> > >>> > > > > > > > > From charles.perkins@earthlink.net Mon Sep 21 14:04:54 2009 Return-Path: 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 94D543A69A8 for ; Mon, 21 Sep 2009 14:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.884 X-Spam-Level: X-Spam-Status: No, score=-1.884 tagged_above=-999 required=5 tests=[AWL=0.096, 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 f6dcawe7wjRJ for ; Mon, 21 Sep 2009 14:04:53 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id C73B03A68CD for ; Mon, 21 Sep 2009 14:04:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=cynvLqz9fqp8sDYFrLYxEmLQySkkkgTP+W1FPStUJQHQrKvOm0BPHFwEM7VSegpe; 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.12]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Mpq53-0001KC-QK; Mon, 21 Sep 2009 17:05:53 -0400 Message-ID: <4AB7EAB0.20805@earthlink.net> Date: Mon, 21 Sep 2009 14:05:52 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Templin, Fred L" References: <7877C5C0B5CC894 AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl><200909020837.43851.rog g e@fgan.de><63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com><006701ca2baa$3 c7 20320$b5560960$@nl> <200909021807.n82I7ibr008763@cichlid.raleigh.ibm.com > < 39C363776A4E8C4A94691D2BD9D1C9A10659989A@XCH-NW-7V2.nw.nos.boeing.com> <4A9 ECA44.3000507@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A1065999AD @XCH- NW-7V2.nw.nos.boeing.com> <4A9EE020.2000807@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A106599CC8@XCH-NW-7V2.nw.nos.boeing.com> <4AA0028C.4030505@earthlink.net> <4AB7C7DC.4000403@earthlink.net> <12F4112206976147A34FEC0277597CCF27A4093D54@XCH-NW-15V.nw.nos.boeing.com> <4AB7D3A4.4010600@earthlink.net> <12F4112206976147A34FEC0277597CCF27A4093D76@XCH-NW-15V.nw.nos.boeing.com> In-Reply-To: <12F4112206976147A34FEC0277597CCF27A4093D76@XCH-NW-15V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f529132522920de6192566d551b6278a1e6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 21:04:54 -0000 Hello Fred, Templin, Fred L wrote: > >> I'd appreciate it if you could point out >> where I went wrong. >> > > I'm sorry, but I'm not going to get drawn into > an on-list interrogation. > I'd be happy to carry on privately if you prefer. I can't remember such a conversation where I was told that I have wrong assumptions, but that no one would even tell me which assumptions are wrong (at least in the engineering realm). > >> Plus, my example network does not >> in any way depend on my assumptions >> about your meanings. >> > > On this point, we disagree. > > How in the heck can different engineering perspectives be resolved if the proponents won't converse? My questions were very reasonable, I thought. If link-local proponents (a) insist that all networks must have link-local addresses (b) won't answer a question about how it can be done with four nodes, and (c) do not desire to tackle the issues online, I am amazed that we would wait four years for the outcome. Regards, Charlie P. From Fred.L.Templin@boeing.com Mon Sep 21 17:05:33 2009 Return-Path: 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 A4C623A68DD for ; Mon, 21 Sep 2009 17:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.02 X-Spam-Level: X-Spam-Status: No, score=-6.02 tagged_above=-999 required=5 tests=[AWL=0.579, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 lPo2G65Pkb3t for ; Mon, 21 Sep 2009 17:05:32 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id C94733A63C9 for ; Mon, 21 Sep 2009 17:05:32 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n8M06WN9016405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 21 Sep 2009 19:06:32 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n8M06Whm014428; Mon, 21 Sep 2009 19:06:32 -0500 (CDT) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n8M06VPC014425 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 21 Sep 2009 19:06:31 -0500 (CDT) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Mon, 21 Sep 2009 17:06:31 -0700 From: "Templin, Fred L" To: "Charles E. Perkins" Date: Mon, 21 Sep 2009 17:06:28 -0700 Thread-Topic: [Autoconf] call for consensus about link local address support Thread-Index: Aco6/1Hzur3DDqDeSOC9BAbX9dGtRgAF4KrA Message-ID: <12F4112206976147A34FEC0277597CCF27A4093E94@XCH-NW-15V.nw.nos.boeing.com> References: <7877C5C0B5CC894 AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl><200909020837.43851.ro g g e@fgan.de><63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com><006701ca2baa $3 c7 20320$b5560960$@nl> <200909021807.n82I7ibr008763@cichlid.raleigh.ibm. com > < 39C363776A4E8C4A94691D2BD9D1C9A10659989A@XCH-NW-7V2.nw.nos.boeing.c om> <4A9 ECA44.3000507@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A1065 999AD @XCH- NW-7V2.nw.nos.boeing.com> <4A9EE020.2000807@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A106599CC8@XCH-NW-7V2.nw.nos.boeing.com> <4AA0028C.4030505@earthlink.net> <4AB7C7DC.4000403@earthlink.net> <12F4112206976147A34FEC0277597CCF27A4093D54@XCH-NW-15V.nw.nos.boeing.com> <4AB7D3A4.4010600@earthlink.net> <12F4112206976147A34FEC0277597CCF27A4093D76@XCH-NW-15V.nw.nos.boeing.com> <4AB7EAB0.20805@earthlink.net> In-Reply-To: <4AB7EAB0.20805@earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 00:05:33 -0000 Charlie, There are myriad unspoken assumptions in your messages wrapped around nodes moving, definitions of "link", *guaranteed* uniqueness, etc. that are way outside of the scope of what I have been thinking. But, the way I have been thinking for link-local configuration is EUI-64 - in particular, when the L2 address can be statelessly derived from the L3 address there should be no need to maintain a coherent neighbor cache. Again, I am thinking only about link-local *configuration*; what happens after the link-local is configured is out of scope for what I have been meaning to convey. Fred fred.l.templin@boeing.com > -----Original Message----- > From: Charles E. Perkins [mailto:charles.perkins@earthlink.net] > Sent: Monday, September 21, 2009 2:06 PM > To: Templin, Fred L > Cc: autoconf@ietf.org > Subject: Re: [Autoconf] call for consensus about link local address suppo= rt >=20 >=20 > Hello Fred, >=20 > Templin, Fred L wrote: > > > >> I'd appreciate it if you could point out > >> where I went wrong. > >> > > > > I'm sorry, but I'm not going to get drawn into > > an on-list interrogation. > > >=20 > I'd be happy to carry on privately if you prefer. > I can't remember such a conversation where I was > told that I have wrong assumptions, but that no one > would even tell me which assumptions are wrong > (at least in the engineering realm). >=20 > > > >> Plus, my example network does not > >> in any way depend on my assumptions > >> about your meanings. > >> > > > > On this point, we disagree. > > > > >=20 > How in the heck can different engineering perspectives > be resolved if the proponents won't converse? > My questions were very reasonable, I thought. >=20 > If link-local proponents (a) insist that all networks must > have link-local addresses (b) won't answer a question > about how it can be done with four nodes, and (c) > do not desire to tackle the issues online, I am amazed > that we would wait four years for the outcome. >=20 > Regards, > Charlie P. From charles.perkins@earthlink.net Mon Sep 21 22:15:12 2009 Return-Path: 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 EB3C63A6831 for ; Mon, 21 Sep 2009 22:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] 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 J7hU4nfsQhV3 for ; Mon, 21 Sep 2009 22:15:11 -0700 (PDT) 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 E63D83A6861 for ; Mon, 21 Sep 2009 22:15:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=QfZIO2ylz9pEKPcNSWhO2qwvjtU8soRn/EoUjwytEsqlGS8d0t4/C1urT9XIQZsd; 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 [99.51.74.16] (helo=[192.168.1.102]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MpxjZ-0008JA-JL; Tue, 22 Sep 2009 01:16:13 -0400 Message-ID: <4AB85D9C.5040707@earthlink.net> Date: Mon, 21 Sep 2009 22:16:12 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Templin, Fred L" References: <7877C5C0B5CC894 AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl><200909020837.43851.ro g g e@fgan.de><63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com><006701ca2baa $3 c7 20320$b5560960$@nl> <200909021807.n82I7ibr008763@cichlid.raleigh.ibm. com > < 39C363776A4E8C4A94691D2BD9D1C9A10659989A@XCH-NW-7V2.nw.nos.boeing.c om> <4A9 ECA44.3000507@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A1065 999AD @XCH- NW-7V2.nw.nos.boeing.com> <4A9EE020.2000807@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A106599CC8@XCH-NW-7V2.nw.nos.boeing.com> <4AA0028C.4030505@earthlink.net> <4AB7C7DC.4000403@earthlink.net> <12F4112206976147A34FEC0277597CCF27A4093D54@XCH-NW-15V.nw.nos.boeing.com> <4AB7D3A4.4010600@earthlink.net> <12F4112206976147A34FEC0277597CCF27A4093D76@XCH-NW-15V.nw.nos.boeing.com> <4AB7EAB0.20805@earthlink.net> <12F4112206976147A34FEC0277597CCF27A4093E94@XCH-NW-15V.nw.nos.boeing.com> In-Reply-To: <12F4112206976147A34FEC0277597CCF27A4093E94@XCH-NW-15V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f523db020df984dfb8336edc3e345d6c4ae350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 05:15:12 -0000 Hello Fred, Thanks for the honor of your reply. Turns out we may not be very far apart after all. Of course I have no objection whatsoever to carrying out the indicated link-local address formation for EUI-64 derived addresses. I'm very happy if there is a statement somewhere that nodes should do this when they have been configured with known-unique such addresses. I also agree with you that the neighbor cache would not need additional maintenance in that case. Furthermore, I also think that the *use* of such configured addresses does not have to be in scope for the [autoconf] discussion. The point of my example was almost precisely that I do _NOT_ have assumptions about the definitions of "link", and I had wanted to draw out your assumptions for further inspection. I do _NOT_ have other unspoken assumptions, except for the one assumption that I think we ought to be having honest discussions about what can, cannot, should, and, should not be assumed. If you find in any of my messages the unspoken assumptions, you should point them out to me. Otherwise I really insist on not fitting that description. If anyone else wants to take a crack at my four-node example, and suggest their solution, I'd still like to see it. Regards, Charlie P. Templin, Fred L wrote: > Charlie, > > There are myriad unspoken assumptions in your messages wrapped > around nodes moving, definitions of "link", *guaranteed* > uniqueness, etc. that are way outside of the scope of what > I have been thinking. But, the way I have been thinking for > link-local configuration is EUI-64 - in particular, when the > L2 address can be statelessly derived from the L3 address > there should be no need to maintain a coherent neighbor cache. > > Again, I am thinking only about link-local *configuration*; > what happens after the link-local is configured is out of > scope for what I have been meaning to convey. > > Fred > fred.l.templin@boeing.com > > >> -----Original Message----- >> From: Charles E. Perkins [mailto:charles.perkins@earthlink.net] >> Sent: Monday, September 21, 2009 2:06 PM >> To: Templin, Fred L >> Cc: autoconf@ietf.org >> Subject: Re: [Autoconf] call for consensus about link local address support >> >> >> Hello Fred, >> >> Templin, Fred L wrote: >> >>>> I'd appreciate it if you could point out >>>> where I went wrong. >>>> >>>> >>> I'm sorry, but I'm not going to get drawn into >>> an on-list interrogation. >>> >>> >> I'd be happy to carry on privately if you prefer. >> I can't remember such a conversation where I was >> told that I have wrong assumptions, but that no one >> would even tell me which assumptions are wrong >> (at least in the engineering realm). >> >> >>>> Plus, my example network does not >>>> in any way depend on my assumptions >>>> about your meanings. >>>> >>>> >>> On this point, we disagree. >>> >>> >>> >> How in the heck can different engineering perspectives >> be resolved if the proponents won't converse? >> My questions were very reasonable, I thought. >> >> If link-local proponents (a) insist that all networks must >> have link-local addresses (b) won't answer a question >> about how it can be done with four nodes, and (c) >> do not desire to tackle the issues online, I am amazed >> that we would wait four years for the outcome. >> >> Regards, >> Charlie P. >> > > > > From teco@inf-net.nl Tue Sep 22 01:31:36 2009 Return-Path: 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 477E53A67A5 for ; Tue, 22 Sep 2009 01:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.421 X-Spam-Level: * X-Spam-Status: No, score=1.421 tagged_above=-999 required=5 tests=[AWL=-0.326, BAYES_05=-1.11, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MISSING_SUBJECT=1.762, RCVD_IN_DNSWL_LOW=-1] 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 FzOdgABVxqgn for ; Tue, 22 Sep 2009 01:31:35 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 018023A68B1 for ; Tue, 22 Sep 2009 01:31:34 -0700 (PDT) Received: (qmail 6093 invoked by uid 48); 22 Sep 2009 10:32:33 +0200 Received: from 62.140.137.8 (SquirrelMail authenticated user teco@inf-net.nl) by webmail.inf-net.nl with HTTP; Tue, 22 Sep 2009 10:32:33 +0200 (CEST) Message-ID: <50591.62.140.137.8.1253608353.squirrel@webmail.inf-net.nl> Date: Tue, 22 Sep 2009 10:32:33 +0200 (CEST) From: teco@inf-net.nl To: charles.perkins@earthlink.net, autoconf@ietf.org User-Agent: SquirrelMail/1.4.11 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [Autoconf] (no subject) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 08:31:36 -0000 Hi Charlie, |PS. Again, for the nth time, I am not against link locals. | I am against mandating their use, and I am against | requiring all solutions to resolve the issues surrounding | the assignment of link-local addresses. I think this is completely in line with my "adjusted" text for the addressing model document. So why not include this, and go to the next steps? We have two more open issues. |Here are four nodes at time T_0: | | A --------- B --------- C --------- D | |The dashed lines indicate neighborliness at time T_0. |Assume all bidirectional links. | |At time T_1, a second later, the neighborhoods |are as follows: | | A --------- C --------- B --------- D | |Please explain how you identify the links upon which |your assignment of link-local addresses are valid, Link-locals are on-link by definition, and are not forwarded. LL_A is not seen of C-B and B-D, although if it was, it is valid. | and |indicate a compatible assignment of link local addresses, EUI-64 is one mechanism, especially useful when there is a globally unique MAC address available. Any unique MAC address on the box will do. Another practical approach is using random interface-id and accept an almost zero chance on a duplicate. One may come up with a multi-hop DAD. |and indicate which specs provide you with the protocol |mechanism for carrying out the proposed assignment. BRDP is just an example. |How many links are there in your model of this network? No limit. |Do you think your link definition is the only one that should |be considered valid for work in [autoconf]? I don't think there is a need to pay so much attention on link definition. We just need to specify what is intended. For example, it is clear that with link metrics we assign a metric to a link between two nodes ("edge" in relation theory). And the RFC5498 link-local is one hop away. I think sub-IP MANETs are out-of-scope for [Autoconf], as current autoconf mechanisms can be used. |Narten's answer was "unique MAC-layer addresses". |Do you agree with that? Fully agreed. But I don't think Narten excludes other unique / almost unique interface-ids. | Do you think we should restrict |work in [autoconf] to be applicable only to such networks |in which that restriction is valid? I think [autoconf] should focus on IPv6, and work on a mechanism that is independent of a MANET routing protocol. Also, the mechanism shall stay in line with current IETF standards as much as possible. This implies "link-locals are always there" and used by for example RA and OSPF-MANET. I don't see a reason why DYMO won't send messages with link-locals. And there is some progress on NHDP / OLSR for support of link-locals. |Do you have any intuition about the scalability of the |system resulting from your definitions? With 48-bit MAC addresses, IEEE has address space of 46^2-1. With random, we have 62^2-1. Even with large or huge MANETs, the chance on duplicates is almost zero. |What if you discovered that your definitions resulted in a |system that was three orders of magnitude less scalable than |an alternative that did not impose a requirement for assigning |unique link-local addresses? -- or, a system that, effectively, |didn't even define any broadcast-oriented links at all? BRDP provides a mechanism that connects all MANETs on this globe via the Internet without any problems. Do you need three orders of magnitude more? Teco. From henning.rogge@fkie.fraunhofer.de Tue Sep 22 03:56:00 2009 Return-Path: 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 215FB3A68D1 for ; Tue, 22 Sep 2009 03:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.359 X-Spam-Level: X-Spam-Status: No, score=-4.359 tagged_above=-999 required=5 tests=[AWL=-0.710, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 HU1eTwG-RXms for ; Tue, 22 Sep 2009 03:55:59 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id D7B213A6A0D for ; Tue, 22 Sep 2009 03:55:58 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Mq33M-0001CG-OG for autoconf@ietf.org; Tue, 22 Sep 2009 12:57:00 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Mq33M-0005Eb-Dj for autoconf@ietf.org; Tue, 22 Sep 2009 12:57:00 +0200 From: Henning Rogge To: autoconf@ietf.org Date: Tue, 22 Sep 2009 12:56:55 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.30-10-generic; KDE/4.2.2; i686; ; ) References: <50591.62.140.137.8.1253608353.squirrel@webmail.inf-net.nl> In-Reply-To: <50591.62.140.137.8.1253608353.squirrel@webmail.inf-net.nl> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3771659.914MJPvWLz"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200909221257.00721.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/9821/Tue Sep 22 01:48:15 2009) by mailguard.fgan.de X-Scan-Signature: d06c92ca4406a5c9a6ad4030b633b206 Subject: Re: [Autoconf] (no subject) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 10:56:00 -0000 --nextPart3771659.914MJPvWLz Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Tue September 22 2009 10:32:33 schrieb teco@inf-net.nl: > With 48-bit MAC addresses, IEEE has address space of 46^2-1. > With random, we have 62^2-1. Even with large or huge MANETs, > the chance on duplicates is almost zero. This depends on the quality of the random number generator. Especially duri= ng=20 initialization it's difficult for embedded devices without a unique seed to= =20 get good random numbers. Think a manet after a power outage in a city. Most devices boot during the= =20 same time (when power is back again). Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart3771659.914MJPvWLz Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEUEABECAAYFAkq4rXcACgkQRIfGfFXsz+CRKwCfQ8570RYTmeT+ksNzShR8V6Yv cOAAmNpRTzq7KTFFi/XhDASMWAgmDuU= =x9o8 -----END PGP SIGNATURE----- --nextPart3771659.914MJPvWLz-- From ulrich@herberg.name Tue Sep 22 04:38:13 2009 Return-Path: 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 7F1683A69C7 for ; Tue, 22 Sep 2009 04:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 S01Y3XeYPv51 for ; Tue, 22 Sep 2009 04:38:12 -0700 (PDT) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id 3540F3A69AB for ; Tue, 22 Sep 2009 04:38:11 -0700 (PDT) Received: by bwz6 with SMTP id 6so2550636bwz.37 for ; Tue, 22 Sep 2009 04:39:12 -0700 (PDT) MIME-Version: 1.0 Sender: ulrich@herberg.name Received: by 10.204.160.73 with SMTP id m9mr735708bkx.214.1253619551852; Tue, 22 Sep 2009 04:39:11 -0700 (PDT) In-Reply-To: <200909221257.00721.henning.rogge@fkie.fraunhofer.de> References: <50591.62.140.137.8.1253608353.squirrel@webmail.inf-net.nl> <200909221257.00721.henning.rogge@fkie.fraunhofer.de> Date: Tue, 22 Sep 2009 13:39:11 +0200 X-Google-Sender-Auth: 8f8e17a2f5330266 Message-ID: <25c114b90909220439o595ae314v849c0b010749439@mail.gmail.com> From: Ulrich Herberg To: Henning Rogge Content-Type: multipart/alternative; boundary=0015175d04bc125ca60474290cb1 Cc: autoconf@ietf.org Subject: Re: [Autoconf] (no subject) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 11:38:13 -0000 --0015175d04bc125ca60474290cb1 Content-Type: text/plain; charset=ISO-8859-1 Hi, On Tue, Sep 22, 2009 at 12:56 PM, Henning Rogge < henning.rogge@fkie.fraunhofer.de> wrote: > Am Tue September 22 2009 10:32:33 schrieb teco@inf-net.nl: > > With 48-bit MAC addresses, IEEE has address space of 46^2-1. > > With random, we have 62^2-1. Even with large or huge MANETs, > > the chance on duplicates is almost zero. > > This depends on the quality of the random number generator. Especially > during > initialization it's difficult for embedded devices without a unique seed to > get good random numbers. > > Think a manet after a power outage in a city. Most devices boot during the > same time (when power is back again). > I agree with Henning. It is not good enough to assume unique MAC addresses or good random number generators. I think that this is the reason why DAD is required in RFC4862. In such a case mentioned by Henning, devices could indeed use the same seed for the random number generator and create the same addresses. Coming back to Charlie's mail, I think he mentioned two important facts: -- The proposed addressing model in the draft works in all cases; no-one so far did show that it would break things. -- Requiring link-models have some severe problems, as mentioned in the text by Erik that will be integrated in the next revision of the draft. No-one of the proponents of link-locals has answered how to circumvent these problems (e.g. how to assure uniqueness at all time over several hops in a mobile scenario). Repeating Charlie, the draft does NOT prohibit the use of link-locals. It simply does not _require_ such an address. Ulrich --0015175d04bc125ca60474290cb1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

On Tue, Sep 22, 2009 at 12:56 PM, Hen= ning Rogge <henning.rogge@fkie.fraunhofer.de> wrote:
Am Tue September 22 2009 10:32:33 schrieb teco@inf-net.nl:
> With 48-bit MAC addresses, IEEE has address space of= 46^2-1.
> With random, we have 62^2-1. Even with large or huge MANETs,
> the chance on duplicates is almost zero.
= =A0
This depends on the quality of the random number generator. Especiall= y during
initialization it's difficult for embedded devices without a unique see= d to
get good random numbers.

Think a manet after a power outage in a city. Most devices boot during the<= br> same time (when power is back again).

I agree with= Henning. It is not good enough to assume unique MAC addresses or good rand= om number generators. I think that this is the reason why DAD is required i= n RFC4862. In such a case mentioned by Henning, devices could indeed use th= e same seed for the random number generator and create the same addresses. =

Coming back to Charlie's mail, I think he mentioned two important f= acts:
=A0=A0 -- The proposed addressing model in the draft works in all = cases; no-one so far did show that it would break things.
=A0=A0 -- Requ= iring link-models have some severe problems, as mentioned in the text by Er= ik that will be integrated in the next revision of the draft. No-one of the= proponents of link-locals has answered how to circumvent these problems (e= .g. how to assure uniqueness at all time over several hops in a mobile scen= ario). Repeating Charlie, the draft does NOT prohibit the use of link-local= s. It simply does not _require_ such an address.

Ulrich
--0015175d04bc125ca60474290cb1-- From hrogge@googlemail.com Tue Sep 22 04:41:59 2009 Return-Path: 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 DA5E93A6881 for ; Tue, 22 Sep 2009 04:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 OKu2fKPFNAF3 for ; Tue, 22 Sep 2009 04:41:56 -0700 (PDT) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 6D00E3A6939 for ; Tue, 22 Sep 2009 04:41:56 -0700 (PDT) Received: by ewy28 with SMTP id 28so1163667ewy.42 for ; Tue, 22 Sep 2009 04:42:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2M+dpqfXpfJd2V5FGXLWg8ci1h7+j+da3DmJDgOmSFA=; b=EZ5eN8jgPm4z0U62fScrncSMiNCBYzWzXVyJjhtcRxd/lFqrW7SdJWY7whlXuNfNEo O9vN5hN/p/kIAL4jMpsARG5I4DdImtZXrg/XELST5/P9TFshs76vvdQK4CzZsXHL3Yt6 piy1qqrabpQn7vXpN8IGVw1O7jxwt538pv7ns= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ABCR5P6x3XGTcp81/vz0zjHvXgrmHPK7KzeZVrLqIaL3cQL1KRNvKbR+73lGOIiWI4 wz5nfel/v6wY6Suhjd9dQ3PatkNAHf5cGCtNwvT74kTNy/yTRa6WAswxCxICqLfhhtM5 3L/fjleWikm//6fbblCR5uK1to5aDEYGvNt+A= MIME-Version: 1.0 Received: by 10.216.36.9 with SMTP id v9mr216877wea.21.1253619776797; Tue, 22 Sep 2009 04:42:56 -0700 (PDT) In-Reply-To: <25c114b90909220439o595ae314v849c0b010749439@mail.gmail.com> References: <50591.62.140.137.8.1253608353.squirrel@webmail.inf-net.nl> <200909221257.00721.henning.rogge@fkie.fraunhofer.de> <25c114b90909220439o595ae314v849c0b010749439@mail.gmail.com> Date: Tue, 22 Sep 2009 13:42:56 +0200 Message-ID: <87eacd830909220442p69e15de9ie3dcce2b0fbf7d53@mail.gmail.com> From: Henning Rogge To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: autoconf@ietf.org Subject: Re: [Autoconf] (no subject) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 11:41:59 -0000 On Tue, Sep 22, 2009 at 13:39, Ulrich Herberg wrote: > Hi, > > On Tue, Sep 22, 2009 at 12:56 PM, Henning Rogge > wrote: >> >> Am Tue September 22 2009 10:32:33 schrieb teco@inf-net.nl: >> > With 48-bit MAC addresses, IEEE has address space of 46^2-1. >> > With random, we have 62^2-1. Even with large or huge MANETs, >> > the chance on duplicates is almost zero. > > >> >> This depends on the quality of the random number generator. Especially >> during >> initialization it's difficult for embedded devices without a unique seed >> to >> get good random numbers. >> >> Think a manet after a power outage in a city. Most devices boot during t= he >> same time (when power is back again). > > I agree with Henning. It is not good enough to assume unique MAC addresse= s > or good random number generators. I think that this is the reason why DAD= is > required in RFC4862. In such a case mentioned by Henning, devices could > indeed use the same seed for the random number generator and create the s= ame > addresses. Unique MAC addresses are good enough... random number generator is not. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 From charles.perkins@earthlink.net Tue Sep 22 10:38:48 2009 Return-Path: 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 717BD3A68A1 for ; Tue, 22 Sep 2009 10:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[AWL=0.093, 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 tFiYM6lXmDSe for ; Tue, 22 Sep 2009 10:38:47 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 22DDF3A67B6 for ; Tue, 22 Sep 2009 10:38:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=VXlISN0rUdFS8n1TQvKoq1RADteI2FnBo0ENCdShv9NnsJ44yttzJQr7PwPwwe5G; 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.158]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Mq9LC-00044Z-Ri; Tue, 22 Sep 2009 13:39:50 -0400 Message-ID: <4AB90BE5.5010506@earthlink.net> Date: Tue, 22 Sep 2009 10:39:49 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: teco@inf-net.nl References: <50591.62.140.137.8.1253608353.squirrel@webmail.inf-net.nl> In-Reply-To: <50591.62.140.137.8.1253608353.squirrel@webmail.inf-net.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52b8153f43b6595112256a5f70714a4086350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] (no subject) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 17:38:48 -0000 Hello Teco, Thanks for your explanations. teco@inf-net.nl wrote: > Hi Charlie, > > |PS. Again, for the nth time, I am not against link locals. > | I am against mandating their use, and I am against > | requiring all solutions to resolve the issues surrounding > | the assignment of link-local addresses. > > I think this is completely in line with my "adjusted" text for the > addressing model document. > So why not include this, and go to the next steps? We have two more open > issues. > I'm not the right person to answer this question :-) > > |Here are four nodes at time T_0: > | > | A --------- B --------- C --------- D > | > |The dashed lines indicate neighborliness at time T_0. > |Assume all bidirectional links. > | > |At time T_1, a second later, the neighborhoods > |are as follows: > | > | A --------- C --------- B --------- D > | > |Please explain how you identify the links upon which > |your assignment of link-local addresses are valid, > > Link-locals are on-link by definition, and are not forwarded. > LL_A is not seen of C-B and B-D, Check. > although if it was, it is valid. > I am skeptical about this UNLESS you are already assuming some scheme like EUI-64 derived link-local addresses, as you mention shortly below. > > | and > |indicate a compatible assignment of link local addresses, > > EUI-64 is one mechanism, especially useful when there is a globally > unique MAC address available. Any unique MAC address on the box > will do. > Another practical approach is using random interface-id and accept > an almost zero chance on a duplicate. In the past, some random number generators have been "bad", to use the technical nomenclature. Perhaps you would like to make it illegal by international law to enable user-selectable MAC addresses. > One may come up with a > multi-hop DAD. > Indeed. This is, in fact, my favored approach -- and I don't restrict it to ensuring uniqueness only for link-local addresses. > > |and indicate which specs provide you with the protocol > |mechanism for carrying out the proposed assignment. > > BRDP is just an example. > Time to re-read that. > > |How many links are there in your model of this network? > > No limit. > I don't see how, given the connectivity as indicated in the stick figures. Can you say more? > > |Do you think your link definition is the only one that should > |be considered valid for work in [autoconf]? > > I don't think there is a need to pay so much attention > on link definition. We just need to specify what is > intended. For example, it is clear that with link metrics > we assign a metric to a link between two nodes ("edge" > in relation theory). And the RFC5498 link-local is > one hop away. > > I think sub-IP MANETs are out-of-scope for [Autoconf], > as current autoconf mechanisms can be used. > I was almost agreeing with you, but... what _are_ the "current" autoconf mechanisms? Do you mean the current IPv6 autoconfiguration mechanisms? > > |Narten's answer was "unique MAC-layer addresses". > |Do you agree with that? > > Fully agreed. > But I don't think Narten excludes other unique / almost > unique interface-ids. > Does this mean that your proposed mechanisms are applicable only when there are such interface-ids available? > > | Do you think we should restrict > |work in [autoconf] to be applicable only to such networks > |in which that restriction is valid? > > I think [autoconf] should focus on IPv6, and work on a > mechanism that is independent of a MANET routing protocol. > I don't think anyone is disputing this. > Also, the mechanism shall stay in line with current IETF standards > as much as possible. Check. > This implies "link-locals are always there" and > used by for example RA and OSPF-MANET. I don't agree that the implication is necessary. However, I would agree that it is quite compatible with residence in the universe where MAC addresses are already known to be unique or astronomically randomized. > I don't see a reason why > DYMO won't send messages with link-locals. That one I can answer. It's because link-locals (almost by definition) do not contain any information useful for the purposes of DYMO (i.e., creating routes to destination IP addresses). > And there is some > progress on NHDP / OLSR for support of link-locals. > I've already given up on registering further objections to NHDP. We love big packets, yes we do. Silly to complain when we are already assuming big layer-2 headers... we do, don't we? > > |Do you have any intuition about the scalability of the > |system resulting from your definitions? > > With 48-bit MAC addresses, IEEE has address space of 46^2-1. > With random, we have 62^2-1. Even with large or huge MANETs, > the chance on duplicates is almost zero. > Putting aside the birthday paradox, this still only pertains to residence in the nice universe of nodes that conform to your expectations of either randomness or uniqueness. > > BRDP provides a mechanism that connects all MANETs on this > globe via the Internet without any problems. Do you need three > orders of magnitude more? > Is there any appendix describing the solution to world hunger? More seriously, extraordinary claims demand extraordinary proof and invite extraordinary skepticism. Put another way, I need to study BRDP to discover what must be a large difference in the way we mutually view MANETs. Regards, Charlie P. From ulrich@herberg.name Tue Sep 22 11:09:19 2009 Return-Path: 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 0BAEF3A68D3 for ; Tue, 22 Sep 2009 11:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 MlLfRJoqVKcL for ; Tue, 22 Sep 2009 11:09:18 -0700 (PDT) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by core3.amsl.com (Postfix) with ESMTP id E6A523A6852 for ; Tue, 22 Sep 2009 11:09:17 -0700 (PDT) Received: by fxm27 with SMTP id 27so983939fxm.42 for ; Tue, 22 Sep 2009 11:10:17 -0700 (PDT) MIME-Version: 1.0 Sender: ulrich@herberg.name Received: by 10.204.11.18 with SMTP id r18mr1083825bkr.15.1253643017084; Tue, 22 Sep 2009 11:10:17 -0700 (PDT) In-Reply-To: <87eacd830909220442p69e15de9ie3dcce2b0fbf7d53@mail.gmail.com> References: <50591.62.140.137.8.1253608353.squirrel@webmail.inf-net.nl> <200909221257.00721.henning.rogge@fkie.fraunhofer.de> <25c114b90909220439o595ae314v849c0b010749439@mail.gmail.com> <87eacd830909220442p69e15de9ie3dcce2b0fbf7d53@mail.gmail.com> Date: Tue, 22 Sep 2009 20:10:17 +0200 X-Google-Sender-Auth: a9c7b63dca87e16a Message-ID: <25c114b90909221110j1fa9f5d5m2eb41ed0f69dc857@mail.gmail.com> From: Ulrich Herberg To: Henning Rogge Content-Type: multipart/alternative; boundary=00032555a15ab5618c04742e823c Cc: autoconf@ietf.org Subject: Re: [Autoconf] (no subject) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 18:09:19 -0000 --00032555a15ab5618c04742e823c Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 22, 2009 at 1:42 PM, Henning Rogge wrote: > [...] > > > > I agree with Henning. It is not good enough to assume unique MAC > addresses > > or good random number generators. I think that this is the reason why DAD > is > > required in RFC4862. In such a case mentioned by Henning, devices could > > indeed use the same seed for the random number generator and create the > same > > addresses. > Unique MAC addresses are good enough...[...] > Yes, *if* they are unique. But this cannot always be asumed. Ulrich > > --00032555a15ab5618c04742e823c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Sep 22, 2009 at 1:42 PM, Henning= Rogge <hrogg= e@googlemail.com> wrote:
[...]
>
> I agree with Henning. It is not good enough to assume unique MAC addre= sses
> or good random number generators. I think that this is the reason why = DAD is
> required in RFC4862. In such a case mentioned by Henning, devices coul= d
> indeed use the same seed for the random number generator and create th= e same
> addresses.
Unique MAC addresses are good enough...[...]
=A0=
Yes, *if* they are unique. But this cannot always be asumed.
=
Ulrich
=A0
--00032555a15ab5618c04742e823c-- From teco@inf-net.nl Tue Sep 22 14:56:35 2009 Return-Path: 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 C78E83A6B01 for ; Tue, 22 Sep 2009 14:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.177 X-Spam-Level: * X-Spam-Status: No, score=1.177 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] 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 k67guBhwxIfM for ; Tue, 22 Sep 2009 14:56:35 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 924923A6AE7 for ; Tue, 22 Sep 2009 14:56:34 -0700 (PDT) Received: (qmail 20367 invoked by uid 48); 22 Sep 2009 23:57:37 +0200 Received: from 62.140.137.37 (SquirrelMail authenticated user teco@inf-net.nl) by webmail.inf-net.nl with HTTP; Tue, 22 Sep 2009 23:57:36 +0200 (CEST) Message-ID: <45311.62.140.137.37.1253656656.squirrel@webmail.inf-net.nl> Date: Tue, 22 Sep 2009 23:57:36 +0200 (CEST) From: teco@inf-net.nl To: autoconf@ietf.org User-Agent: SquirrelMail/1.4.11 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 21:56:35 -0000 (copy to mail-list) Ulrich, Why should we work on a protocol that protects against invalid usage? L2 won't work anyway. And we only help the misusing nodes. Let's forget this useless effort. Teco. On Tue, Sep 22, 2009 at 1:42 PM, Henning Rogge wrote: [...] > > I agree with Henning. It is not good enough to assume unique MAC addresses > or good random number generators. I think that this is the reason why DAD is > required in RFC4862. In such a case mentioned by Henning, devices could > indeed use the same seed for the random number generator and create the same > addresses. Unique MAC addresses are good enough...[...] Yes, *if* they are unique. But this cannot always be asumed. Ulrich From teco@inf-net.nl Tue Sep 22 14:57:11 2009 Return-Path: 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 5E1763A68E6 for ; Tue, 22 Sep 2009 14:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.161 X-Spam-Level: * X-Spam-Status: No, score=1.161 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] 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 s9P1sUbz01YZ for ; Tue, 22 Sep 2009 14:57:10 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 3100B3A67A1 for ; Tue, 22 Sep 2009 14:57:10 -0700 (PDT) Received: (qmail 20840 invoked by uid 48); 22 Sep 2009 23:58:11 +0200 Received: from 62.140.137.37 (SquirrelMail authenticated user teco@inf-net.nl) by webmail.inf-net.nl with HTTP; Tue, 22 Sep 2009 23:58:11 +0200 (CEST) Message-ID: <46104.62.140.137.37.1253656691.squirrel@webmail.inf-net.nl> Date: Tue, 22 Sep 2009 23:58:11 +0200 (CEST) From: teco@inf-net.nl To: autoconf@ietf.org User-Agent: SquirrelMail/1.4.11 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 21:57:11 -0000 (copy to mail-list) Hi Charlie, |> EUI-64 is one mechanism, especially useful when there is a globally |> unique MAC address available. Any unique MAC address on the box |> will do. |> Another practical approach is using random interface-id and accept |> an almost zero chance on a duplicate. | |In the past, some random number generators have been "bad", |to use the technical nomenclature. Perhaps you would like to |make it illegal by international law to enable user-selectable MAC |addresses. I'll repeat my opinion: I think DAD is optional. It helps for misbehaving nodes (or manual configuration). Wellbehaving nodes have the overhead. And thus I think it is useless. And harmful, because the risk of a DoS attack. And yes, random means random. |> I don't see a reason why |> DYMO won't send messages with link-locals. | |That one I can answer. It's because link-locals (almost by definition) |do not contain any information useful for the purposes of DYMO |(i.e., creating routes to destination IP addresses). ??? The source IP address of a DYMO message has little to do with routes to be created. It is needed for 1-hop connectivity only. So link-locals work well for DYMO :-) But for sure, the created routes are ULA or global (or new type "ManetLocal"). Regards, Teco. From alexandru.petrescu@gmail.com Wed Sep 23 10:26:52 2009 Return-Path: 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 76DAE3A688D for ; Wed, 23 Sep 2009 10:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.309 X-Spam-Level: X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[AWL=-0.660, BAYES_50=0.001, HELO_EQ_FR=0.35] 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 qwKwKFuFAS1L for ; Wed, 23 Sep 2009 10:26:51 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 217153A659A for ; Wed, 23 Sep 2009 10:26:49 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id EE620D4820B; Wed, 23 Sep 2009 19:27:51 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 86455D481C7; Wed, 23 Sep 2009 19:27:48 +0200 (CEST) Message-ID: <4ABA5A8F.4020800@gmail.com> Date: Wed, 23 Sep 2009 19:27:43 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" References: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl><200909020837.43851.rogge@fgan.de><63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com><006701ca2baa$3c720320$b5560960$@nl> <200909021807.n82I7ibr008763@cichlid.raleigh.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A10659989A@XCH-NW-7V2.nw.nos.boeing.com> <4A9ECA44.3000507@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A1065999AD@XCH-NW-7V2.nw.nos.boeing.com> <4A9EE020.2000807@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A106599CC8@XCH-NW-7V2.nw.nos.boeing.com> <4AA0028C.4030505@earthlink.net> In-Reply-To: <4AA0028C.4030505@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090922-0, 22/09/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] identifying links for CP's 4 node example X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 17:26:52 -0000 Charles, sorry for late reply. Charles E. Perkins a écrit : [...] > I asked some very pertinent questions to this list a few > weeks ago. > > Up until now, no one who has been clamoring for mandatory > inclusion of link-local addresses in [autoconf] design documents > has answered my questions about a very simple network. > Four nodes! [...] > I think the matter is important enough to deserve a > response -- especially given the amount of time (measured > in _years_!) demanded by the link-local proponents for > previous discussions of the abstract concepts. > > Do any link-local proponents have any answers? > Please see my example network and my questions, > re-posted below. > > Regards, > Charlie P. > > PS. Again, for the nth time, I am not against link locals. > I am against mandating their use, and I am against > requiring all solutions to resolve the issues surrounding > the assignment of link-local addresses. > Maybe a concrete example will help. > > Here are four nodes at time T_0: > > A --------- B --------- C --------- D > > The dashed lines indicate neighborliness at time T_0. > Assume all bidirectional links. > > At time T_1, a second later, the neighborhoods > are as follows: > > A --------- C --------- B --------- D > > Please explain how you identify the links upon which > your assignment of link-local addresses are valid, and > indicate a compatible assignment of link local addresses, I assume in your sketch that C and B each has two interfaces, and that a single segment is 50m long and that the link-layer technology is wifi. How to identify the links? Each link (a segment) is a different SSID. This is a field in each 802.11 header of each packet. The link-local address assignment is like this: A(fe80::MAC_FFFE1)---(fe80::MAC_FFFE2)C(fe80::MAC_FFFE3)-... ...---(fe80::MAC_FFFE4)B(fe80::MAC_FFE5)---(fe80::MAC_FFE6)D The notation fe80::MAC_FFFEx means the IPv6 link link-local address derived from the MAC address of that interface and having FFFE in the middle somewhere, as per rfc2464. > and indicate which specs provide you with the protocol > mechanism for carrying out the proposed assignment. RFC2464 is sufficient for self-forming the link-local addresses. > How many links are there in your model of this network? Three links - as many as segments. > Do you think your link definition is the only one that should > be considered valid for work in [autoconf]? The above (mine?) link definition is ok for the purpose of my prototype. This is straightforward and should not be forbidden. As for the change in topology from A-B-C-D to A-C-B-D from T_0 to T_1 - your challenge should dissected in the separate steps: A-B-C-D T_0 A- -B-C-D T_1 A -B- -C-D T_2 A -C- -B- -D T_3 A-C- -B- -D T_4 A-C-B- -D T_5 A-C-B-D T_6 At T_1 A and B realize they can no longer talk to each other. They do so with NUD. At T_2 B and C realize can't reach each other. Also NUD. At T_3 C and D realize can't reach each other. Also NUD. At T_4 A and C realize they can talk to each other. By using periodic NAs, RSs, RAs. At T_5 B and C can talk, they discover that also with NA. Finally, at T_6 B and D talk (also discover that with NA). Of course, until now A can not send a packet with a dst address D, because only link-local addresses are used above. In order to achieve A-to-D communnication, a mechanism for global address (or ULA) and subnet prefix assignment should be used. This can be achieved as follows: -on each interface of each node pre-configure a unique /64 subnet prefix. -designate A and D to send Router Advertisements with prefixes that should be interpreted as to install in the receivers' routing tables (an extended "intepretation" of RFC4191 "more specific routes"). -designate B and C to also send such extended RAs but _only_ if there isn't already somebody else sending such an extended RA on that link, or if a new NA is heard from a neighbor it hasn't seen before. This should be done carefully such as to avoid loops. So, what do you think Charlie? And of course - what do the others think? > Narten's answer was "unique MAC-layer addresses". > Do you agree with that? I agree unique MAC-layer addresses are helping forming unique IPv6 link-local addresses. > Do you think we should restrict > work in [autoconf] to be applicable only to such networks > in which that restriction is valid? Of course, I don't agree restricting work. I don't agree forbidding link-local addresses either. > Do you have any intuition about the scalability of the > system resulting from your definitions? Hmm... tough question. I believe the method I presented above should scale well provided (1) all nodes are pre-configured with prefixes unique and (2) MAC addresses are unique. But I have of course some doubts. But whereas you're very specific A-B-C-D to A-C-B-D you don't say how would you like it to scale: would it always be rectilinear scaling (max 2 interfaces per node)? Something else? > What if you discovered that your definitions resulted in a > system that was three orders of magnitude less scalable than > an alternative that did not impose a requirement for assigning > unique link-local addresses? -- or, a system that, effectively, > didn't even define any broadcast-oriented links at all? This is speculation from your part. You are asking to compare against something that you don't say what is. (no offence pointing at 'you' - it is more or less intended response to previous comments :-) Yours, Alex From alexandru.petrescu@gmail.com Wed Sep 23 10:42:05 2009 Return-Path: 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 1F4083A6814 for ; Wed, 23 Sep 2009 10:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.351 X-Spam-Level: X-Spam-Status: No, score=-0.351 tagged_above=-999 required=5 tests=[AWL=-0.516, BAYES_40=-0.185, HELO_EQ_FR=0.35] 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 aUvdmDglSlU4 for ; Wed, 23 Sep 2009 10:42:03 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 9AB053A688D for ; Wed, 23 Sep 2009 10:42:02 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 0EA95D4819A; Wed, 23 Sep 2009 19:43:04 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id DD807D48091; Wed, 23 Sep 2009 19:43:01 +0200 (CEST) Message-ID: <4ABA5E20.8090608@gmail.com> Date: Wed, 23 Sep 2009 19:42:56 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu References: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl><200909020837.43851.rogge@fgan.de><63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com><006701ca2baa$3c720320$b5560960$@nl> <200909021807.n82I7ibr008763@cichlid.raleigh.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A10659989A@XCH-NW-7V2.nw.nos.boeing.com> <4A9ECA44.3000507@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A1065999AD@XCH-NW-7V2.nw.nos.boeing.com> <4A9EE020.2000807@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A106599CC8@XCH-NW-7V2.nw.nos.boeing.com> <4AA0028C.4030505@earthlink.net> <4ABA5A8F.4020800@gmail.com> In-Reply-To: <4ABA5A8F.4020800@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090922-0, 22/09/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] dynamically assigning prefixes on links for CP's 4 node example X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 17:42:05 -0000 Alexandru Petrescu a écrit : >> Here are four nodes at time T_0: >> >> A --------- B --------- C --------- D >> >> The dashed lines indicate neighborliness at time T_0. >> Assume all bidirectional links. >> >> At time T_1, a second later, the neighborhoods >> are as follows: >> >> A --------- C --------- B --------- D >> [...] Then I said: > Of course, until now A can not send a packet with a dst address D, > because only link-local addresses are used above. In order to achieve > A-to-D communnication, a mechanism for global address (or ULA) and > subnet prefix assignment should be used. > > This can be achieved as follows: > -on each interface of each node pre-configure a unique /64 subnet > prefix. And of course, people are interested in more than simply pre-configuring /64 unique prefixes on each node. This can be achieved as follows: -designate A to be a DHCPv6 server having a pool of such prefixes to use with a technique called "prefix delegation" RFC number here. -designate B, C and D to request a prefix each time they think their neighbors on one interface has changed. -designate B, C and D to RA that prefix on the other interface (on the interface different from the one where it received the prefix). If there's only one interface then don't advertise on the "other" interface because it doesn't exist. -Designate B and C to become DHCP Relays once they have received a prefix (following a change in the neighbor state). In this sense - what do you think? Alex > -designate A and D to send Router Advertisements with prefixes that > should be interpreted as to install in the receivers' routing tables > (an extended "intepretation" of RFC4191 "more specific routes"). > -designate B and C to also send such extended RAs but _only_ if there > isn't already somebody else sending such an extended RA on that link, > or if a new NA is heard from a neighbor it hasn't seen before. > > This should be done carefully such as to avoid loops. > > So, what do you think Charlie? And of course - what do the others think? > >> Narten's answer was "unique MAC-layer addresses". >> Do you agree with that? > > I agree unique MAC-layer addresses are helping forming unique IPv6 > link-local addresses. > >> Do you think we should restrict >> work in [autoconf] to be applicable only to such networks >> in which that restriction is valid? > > Of course, I don't agree restricting work. I don't agree forbidding > link-local addresses either. > >> Do you have any intuition about the scalability of the >> system resulting from your definitions? > > Hmm... tough question. I believe the method I presented above should > scale well provided (1) all nodes are pre-configured with prefixes > unique and (2) MAC addresses are unique. But I have of course some doubts. > > But whereas you're very specific A-B-C-D to A-C-B-D you don't say how > would you like it to scale: would it always be rectilinear scaling (max > 2 interfaces per node)? Something else? > >> What if you discovered that your definitions resulted in a >> system that was three orders of magnitude less scalable than >> an alternative that did not impose a requirement for assigning >> unique link-local addresses? -- or, a system that, effectively, >> didn't even define any broadcast-oriented links at all? > > This is speculation from your part. You are asking to compare against > something that you don't say what is. > > (no offence pointing at 'you' - it is more or less intended response to > previous comments :-) > > Yours, > > Alex > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From alexandru.petrescu@gmail.com Wed Sep 23 10:49:48 2009 Return-Path: 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 9EF073A6845 for ; Wed, 23 Sep 2009 10:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.221 X-Spam-Level: X-Spam-Status: No, score=-0.221 tagged_above=-999 required=5 tests=[AWL=-0.572, BAYES_50=0.001, HELO_EQ_FR=0.35] 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 ssDqr9kDoAm7 for ; Wed, 23 Sep 2009 10:49:44 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id E6D473A67BD for ; Wed, 23 Sep 2009 10:49:42 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 44AACD480D9; Wed, 23 Sep 2009 19:50:44 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 22468D480D7; Wed, 23 Sep 2009 19:50:42 +0200 (CEST) Message-ID: <4ABA5FEC.5070405@gmail.com> Date: Wed, 23 Sep 2009 19:50:36 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu References: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl><200909020837.43851.rogge@fgan.de><63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com><006701ca2baa$3c720320$b5560960$@nl> <200909021807.n82I7ibr008763@cichlid.raleigh.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A10659989A@XCH-NW-7V2.nw.nos.boeing.com> <4A9ECA44.3000507@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A1065999AD@XCH-NW-7V2.nw.nos.boeing.com> <4A9EE020.2000807@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A106599CC8@XCH-NW-7V2.nw.nos.boeing.com> <4AA0028C.4030505@earthlink.net> <4ABA5A8F.4020800@gmail.com> <4ABA5E20.8090608@gmail.com> In-Reply-To: <4ABA5E20.8090608@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090922-0, 22/09/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] dynamically assigning prefixes on links for CP's 4 node example X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 17:49:48 -0000 Alexandru Petrescu a écrit : > Alexandru Petrescu a écrit : >>> Here are four nodes at time T_0: >>> >>> A --------- B --------- C --------- D >>> >>> The dashed lines indicate neighborliness at time T_0. >>> Assume all bidirectional links. >>> >>> At time T_1, a second later, the neighborhoods >>> are as follows: >>> >>> A --------- C --------- B --------- D >>> > [...] > > Then I said: >> Of course, until now A can not send a packet with a dst address D, >> because only link-local addresses are used above. In order to achieve >> A-to-D communnication, a mechanism for global address (or ULA) and >> subnet prefix assignment should be used. >> >> This can be achieved as follows: >> -on each interface of each node pre-configure a unique /64 subnet >> prefix. > > And of course, people are interested in more than simply pre-configuring > /64 unique prefixes on each node. This can be achieved as follows: > > -designate A to be a DHCPv6 server having a pool of such prefixes to use > with a technique called "prefix delegation" RFC number here. And of course, it may be possible that it is not liked that a single designated machine (A) acts as a DHCPv6 server and the others not. IF this is the case then modify the behaviour as follows: -all nodes are tentative DHCP Servers. Each is pre-configured with a unique _pool_ of prefixes (meaning A has p1, p2 and B has p3, p4). -add a new field in RA which says "I want to act as a DHCP server". -any node can become an "acting" or "elected" DHCP Serverprovided it has not already received an RA saying somebody else is a tentative DHCP Server. This should be done carefully such as to avoid a situation where nobody becomes a DHCP Server because everybody else wants to. And of course, it may replied that pre-configuring pools of prefixes is not enough self-configuration... Alex > -designate B, C and D to request a prefix each time they think their > neighbors on one interface has changed. > -designate B, C and D to RA that prefix on the other interface (on the > interface different from the one where it received the prefix). If > there's only one interface then don't advertise on the "other" > interface because it doesn't exist. > -Designate B and C to become DHCP Relays once they have received a > prefix (following a change in the neighbor state). > > In this sense - what do you think? > > Alex > > > >> -designate A and D to send Router Advertisements with prefixes that >> should be interpreted as to install in the receivers' routing tables >> (an extended "intepretation" of RFC4191 "more specific routes"). >> -designate B and C to also send such extended RAs but _only_ if there >> isn't already somebody else sending such an extended RA on that link, >> or if a new NA is heard from a neighbor it hasn't seen before. >> >> This should be done carefully such as to avoid loops. >> >> So, what do you think Charlie? And of course - what do the others think? >> >>> Narten's answer was "unique MAC-layer addresses". >>> Do you agree with that? >> >> I agree unique MAC-layer addresses are helping forming unique IPv6 >> link-local addresses. >> >>> Do you think we should restrict >>> work in [autoconf] to be applicable only to such networks >>> in which that restriction is valid? >> >> Of course, I don't agree restricting work. I don't agree forbidding >> link-local addresses either. >> >>> Do you have any intuition about the scalability of the >>> system resulting from your definitions? >> >> Hmm... tough question. I believe the method I presented above should >> scale well provided (1) all nodes are pre-configured with prefixes >> unique and (2) MAC addresses are unique. But I have of course some >> doubts. >> >> But whereas you're very specific A-B-C-D to A-C-B-D you don't say how >> would you like it to scale: would it always be rectilinear scaling >> (max 2 interfaces per node)? Something else? >> >>> What if you discovered that your definitions resulted in a >>> system that was three orders of magnitude less scalable than >>> an alternative that did not impose a requirement for assigning >>> unique link-local addresses? -- or, a system that, effectively, >>> didn't even define any broadcast-oriented links at all? >> >> This is speculation from your part. You are asking to compare against >> something that you don't say what is. >> >> (no offence pointing at 'you' - it is more or less intended response to >> previous comments :-) >> >> Yours, >> >> Alex >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >> > > From charles.perkins@earthlink.net Wed Sep 23 11:06:49 2009 Return-Path: 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 9BA893A686C for ; Wed, 23 Sep 2009 11:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.963 X-Spam-Level: X-Spam-Status: No, score=-0.963 tagged_above=-999 required=5 tests=[AWL=-0.842, BAYES_20=-0.74, 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 IT6EiIaVz+-p for ; Wed, 23 Sep 2009 11:06:48 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 65FFC3A681E for ; Wed, 23 Sep 2009 11:06:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=q7G8yFVtsc9g3EWaj6908uYlFxtQ1zEtvVVYDdrgWZMj/2U8Y34wMhGuRFnmh65k; 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.147]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MqWFu-0007Y1-93; Wed, 23 Sep 2009 14:07:54 -0400 Message-ID: <4ABA63F6.4030908@earthlink.net> Date: Wed, 23 Sep 2009 11:07:50 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu References: <7877C5C0B5CC894AB26113CF06CF886301238D6A@ms-dt01thalia.tsn.tno.nl><200909020837.43851.rogge@fgan.de><63626659-7239-46FA-BE48-9EA7B57B4979@gmail.com><006701ca2baa$3c720320$b5560960$@nl> <200909021807.n82I7ibr008763@cichlid.raleigh.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A10659989A@XCH-NW-7V2.nw.nos.boeing.com> <4A9ECA44.3000507@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A1065999AD@XCH-NW-7V2.nw.nos.boeing.com> <4A9EE020.2000807@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A106599CC8@XCH-NW-7V2.nw.nos.boeing.com> <4AA0028C.4030505@earthlink.net> <4ABA5A8F.4020800@gmail.com> In-Reply-To: <4ABA5A8F.4020800@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52e22133047a78a939a2c44e704a4d8468350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] identifying links for CP's 4 node example X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 18:06:49 -0000 Hello Alex, Alexandru Petrescu wrote: >> >> Here are four nodes at time T_0: >> >> A --------- B --------- C --------- D >> >> The dashed lines indicate neighborliness at time T_0. >> Assume all bidirectional links. >> >> At time T_1, a second later, the neighborhoods >> are as follows: >> >> A --------- C --------- B --------- D >> >> Please explain how you identify the links upon which >> your assignment of link-local addresses are valid, and >> indicate a compatible assignment of link local addresses, > > I assume in your sketch that C and B each has two interfaces, and that > a single segment is 50m long and that the link-layer technology is wifi. The way I think of it, C and B have a single network interface. Each segment is only meant to signify a relatively reliable signal path. A packet transmitted by C would be detectable by both A and B (almost) simultaneously, if we disregard propagation delays. Link-layer technology isn't specified, but WiFi would give good intuition. > > How to identify the links? Each link (a segment) is a different SSID. > This is a field in each 802.11 header of each packet. Do you mean to specialize your solution to situations where the SSID can be used to identify intended recipients? > > The link-local address assignment is like this: > > A(fe80::MAC_FFFE1)---(fe80::MAC_FFFE2)C(fe80::MAC_FFFE3)-... > ...---(fe80::MAC_FFFE4)B(fe80::MAC_FFE5)---(fe80::MAC_FFE6)D > > The notation fe80::MAC_FFFEx means the IPv6 link link-local address > derived from the MAC address of that interface and having FFFE in the > middle somewhere, as per rfc2464. Check. > >> and indicate which specs provide you with the protocol >> mechanism for carrying out the proposed assignment. > > RFC2464 is sufficient for self-forming the link-local addresses. Check. > >> How many links are there in your model of this network? > > Three links - as many as segments. Check. > >> Do you think your link definition is the only one that should >> be considered valid for work in [autoconf]? > > The above (mine?) link definition is ok for the purpose of my > prototype. This is straightforward and should not be forbidden. I'm quite sure no one would forbid such a model of link establishment. That would be wrong. > > As for the change in topology from A-B-C-D to A-C-B-D from T_0 to T_1 > - your challenge should dissected in the separate steps: > > A-B-C-D T_0 > A- -B-C-D T_1 > A -B- -C-D T_2 > A -C- -B- -D T_3 > A-C- -B- -D T_4 > A-C-B- -D T_5 > A-C-B-D T_6 > > At T_1 A and B realize they can no longer talk to each other. They > do so with NUD. > > At T_2 B and C realize can't reach each other. Also NUD. > > At T_3 C and D realize can't reach each other. Also NUD. > > At T_4 A and C realize they can talk to each other. By using periodic > NAs, RSs, RAs. > > At T_5 B and C can talk, they discover that also with NA. > > Finally, at T_6 B and D talk (also discover that with NA). The timeouts for these operations are not compatible with the expected rate or motion. If the internodal distances are 50 meters, then the transition time between the illustrated two network configurations would not likely be as low as 1 second. Then you might have enough time for occasionally correct operation -- but I'm sure there would be failures anyway. If the transition happens in 1 second, your RAs need to arrive perhaps as often as 100ms apart. If there were 20 nodes instead of 4, your advertisement period might be as low as 5ms. You would have a massive problem with collisions of advertisements unless you synchronize and stagger the RAs. The synchronization problem by itself will cause you to age prematurely. You can't rely on NUD. For example, it requires active signaling: > Receipt of other Neighbor Discovery messages such as Router > Advertisements and Neighbor Advertisement with the Solicited flag set > to zero MUST NOT be treated as a reachability confirmation. So if you want to overlay active confirmations on top of the passive one-way path verifications, you will compound the problems mentioned above that are due to frequent transmissions of RAs. Basically, even for four nodes, I think you are hosed, and for 20 nodes, it borders on insanity. We have been able to show operation of AODV for thousands of nodes. Still needs improvements! But, if we were MANDATED to run RAs and NUD, it would be absolutely and irretrievably unattainable. > > Of course, until now A can not send a packet with a dst address D, > because only link-local addresses are used above. In order to achieve > A-to-D communnication, a mechanism for global address (or ULA) and > subnet prefix assignment should be used. Check. > > This can be achieved as follows: > -on each interface of each node pre-configure a unique /64 subnet > prefix. I'd say one per node. > -designate A and D to send Router Advertisements with prefixes that > should be interpreted as to install in the receivers' routing tables > (an extended "intepretation" of RFC4191 "more specific routes"). > -designate B and C to also send such extended RAs but _only_ if there > isn't already somebody else sending such an extended RA on that link, > or if a new NA is heard from a neighbor it hasn't seen before. In the initial configuration, when does B learn that it can communicate directly with C? As long as C is happy with D and B is happy with A, they might never learn about each other. > >> Narten's answer was "unique MAC-layer addresses". >> Do you agree with that? > > I agree unique MAC-layer addresses are helping forming unique IPv6 > link-local addresses. This has never been at issue, but of course I do agree with you. > >> Do you think we should restrict >> work in [autoconf] to be applicable only to such networks >> in which that restriction is valid? > > Of course, I don't agree restricting work. I don't agree forbidding > link-local addresses either. I don't remember anyone forbidding link-local addresses. > >> Do you have any intuition about the scalability of the >> system resulting from your definitions? > > Hmm... tough question. I believe the method I presented above should > scale well provided (1) all nodes are pre-configured with prefixes > unique and (2) MAC addresses are unique. But I have of course some > doubts. > > But whereas you're very specific A-B-C-D to A-C-B-D you don't say how > would you like it to scale: would it always be rectilinear scaling > (max 2 interfaces per node)? Something else? I'm not sure what rectilinear scaling would be, but I would not expect most networks to necessarily conform to any rectilinear layouts. The other networks are, however, much harder to draw with ASCII stick figures. > >> What if you discovered that your definitions resulted in a >> system that was three orders of magnitude less scalable than >> an alternative that did not impose a requirement for assigning >> unique link-local addresses? -- or, a system that, effectively, >> didn't even define any broadcast-oriented links at all? > > This is speculation from your part. You are asking to compare against > something that you don't say what is. I'm thinking about AODV-style networks with hundreds or thousands of nodes. > > (no offence pointing at 'you' - it is more or less intended response to > previous comments :-) Absolutely no offense taken, and thanks for the time you spent to make the reply. Regards, Charlie P. From charles.perkins@earthlink.net Wed Sep 23 13:42:23 2009 Return-Path: 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 D800F3A6848 for ; Wed, 23 Sep 2009 13:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.868 X-Spam-Level: X-Spam-Status: No, score=-1.868 tagged_above=-999 required=5 tests=[AWL=0.112, 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 eK0cz6tTq1Ct for ; Wed, 23 Sep 2009 13:42:22 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id DC8B23A6819 for ; Wed, 23 Sep 2009 13:42:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=NLmIS7gq9uNdFuhfdaB7PWKOVeaPhGKk/IkPP3KDX1Qw99IhvRp5VtT2M35Sn3G1; 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.147]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MqYgS-0008Ck-8B; Wed, 23 Sep 2009 16:43:28 -0400 Message-ID: <4ABA886E.3070304@earthlink.net> Date: Wed, 23 Sep 2009 13:43:26 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: teco@inf-net.nl References: <50591.62.140.137.8.1253608353.squirrel@webmail.inf-net.nl> In-Reply-To: <50591.62.140.137.8.1253608353.squirrel@webmail.inf-net.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52a303d3f9dca4a552705c96b9786c04ad350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: [Autoconf] BDRP vs. world hunger X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 20:42:24 -0000 Hello Teco, teco@inf-net.nl wrote: > ... > |indicate a compatible assignment of link local addresses, > > EUI-64 is one mechanism, especially useful when there is a globally > unique MAC address available. Any unique MAC address on the box > will do. > Another practical approach is using random interface-id and accept > an almost zero chance on a duplicate. One may come up with a > multi-hop DAD. > > > |and indicate which specs provide you with the protocol > |mechanism for carrying out the proposed assignment. > > BRDP is just an example. > > > > BRDP is, if you'll pardon my simplification, a souped-up version of Router Advertisement. So, it isn't designed at all for autonomous MANETs. It is not clear from what you said how BRDP can begin to solve the problem that I outlined whereby four nodes cooperate to form a highly mobile network. If I was challenged to make a solution to the problem using BRDP, I would do so by nominating a distinguished node to define a routing tree for the network. On average, the pathlengths would be reasonable, and the node beaconing BRDP messages would be the root of the tree. Disregard for now the difficulty that BRDP is only specified for networks connected to the Internet. This model of operation is workable, but it suffers from the obvious problems of robustness (what if the root wanders away) and selection of the distinguished node (what if there are multiple contenders). But this is all speculation -- you may not even desire to offer BRDP as a solution which might be applicable in the general case. > |What if you discovered that your definitions resulted in a > |system that was three orders of magnitude less scalable than > |an alternative that did not impose a requirement for assigning > |unique link-local addresses? -- or, a system that, effectively, > |didn't even define any broadcast-oriented links at all? > > BRDP provides a mechanism that connects all MANETs on this > globe via the Internet without any problems. Do you need three > orders of magnitude more? > Clearly, BRDP does _not_ connect all MANETs on the globe, if some are disconnected. Plus, it is not a property of BRDP that connects a multiplicity of MANETs. It is a property of the Internet, which would be the same whether BRDP or any other gateway protocol were to be put into service. Regards, Charlie P. From teco@inf-net.nl Thu Sep 24 02:12:37 2009 Return-Path: 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 ADACE3A67E6 for ; Thu, 24 Sep 2009 02:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.057 X-Spam-Level: * X-Spam-Status: No, score=1.057 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_40=-0.185, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] 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 zwxDwrUlRDV1 for ; Thu, 24 Sep 2009 02:12:36 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 6AC443A67B5 for ; Thu, 24 Sep 2009 02:12:35 -0700 (PDT) Received: (qmail 31947 invoked by uid 48); 24 Sep 2009 11:13:40 +0200 Received: from 62.140.137.28 (SquirrelMail authenticated user teco@inf-net.nl) by webmail.inf-net.nl with HTTP; Thu, 24 Sep 2009 11:13:40 +0200 (CEST) Message-ID: <17436.62.140.137.28.1253783620.squirrel@webmail.inf-net.nl> Date: Thu, 24 Sep 2009 11:13:40 +0200 (CEST) From: teco@inf-net.nl To: charles.perkins@earthlink.net User-Agent: SquirrelMail/1.4.11 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: autoconf@ietf.org Subject: [Autoconf] BDRP vs. world hunger X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 09:12:37 -0000 Hi Charlie, I think we people can produce enough food for solving world hunger. Maybe there are some L8 (political layer) problems to solve. Let's not tackle this in [Autoconf]. |BRDP is, if you'll pardon my simplification, a souped-up version |of Router Advertisement. So, it isn't designed at all for autonomous |MANETs. BRDP is on top of RA, that is correct. It could be updated to run on top of PacketBB messages, but now it is independent of any MANET protocol. Did you check 5.3. Support for Autonomous MANETs ? It is a bit out of context for BRDP. As I see it, assigning globals is the tough part. |It is not clear from what you said how BRDP can begin to solve the |problem that I outlined whereby four nodes cooperate to form a highly |mobile network. I assume unique Interface-IDs. I do not reject any proposal for DAD, although I do prefer IDs that are unique by nature. This because no overhead and no DoS vulnerability. I say DAD is optional. If one comes up with a multi-hop 62-bit Duplicate ID Detection, it could be used for interface-IDs with any address type. It was less than 3 weeks ago that I saw a complete operational network down due to DAD. A misbehaving DHCP server responded on ARP probes from another DHCP server. I hate DAD. For good reasons. (I also dislike DHCP servers without non-volatile memory, that rely on DAD for not reassigning the same addresses over and over) |If I was challenged to make a solution to the problem using BRDP, |I would do so by nominating a distinguished node to define a routing |tree for the network. On average, the pathlengths would be |reasonable, and the node beaconing BRDP messages would |be the root of the tree. Disregard for now the difficulty that |BRDP is only specified for networks connected to the Internet. This facility was included in the parent of BRDP. It would help using less ULA prefixes and help address list compression, as nodes would have a common prefix. An alternative is listen to already existing ULA prefixes. |This model of operation is workable, but it suffers from the obvious |problems of robustness (what if the root wanders away) and selection |of the distinguished node (what if there are multiple contenders). |But this is all speculation -- you may not even desire to offer BRDP |as a solution which might be applicable in the general case. I set BRDP temporally on hold, as it is solution space. And I check ROLL every now and then. I'll line up with their solution one day. |Clearly, BRDP does _not_ connect all MANETs on the globe, |if some are disconnected. The claim was on scalability of the proposed mechanism. This claim is very true. It is not in my hands connecting all MANETs to the Internet. | Plus, it is not a property of BRDP that |connects a multiplicity of MANETs. It is a property of the Internet, |which would be the same whether BRDP or any other gateway |protocol were to be put into service. I don't think BRDP is a gateway protocol. I left out the routing part of earlier versions of the mechanism (Tree Discovery). I clearly state that the MANET protocol shall provide reachability. Of course it is easy to recreate the path to the gateway, as there is a DAG. And some are working on this, see ROLL for details. The difficulty is selecting the path to the gateway that does not block packets due to ingress filters. Therefore I suggest BRDP based routing (again, this is not a routing protocol). I replace the default gateway with a mechanism that packets with unknown destination are forwarded to the BR that "owns" the source address prefix. In fact, BRDP with BRDP based routing would upgrade DYMO to a protocol that works well connecting DYMO MANETs to the Internet. And with scoping RREQs, the size of DYMO MANETs would be unlimited. How nice :-) Regards, Teco From teco@inf-net.nl Thu Sep 24 02:33:26 2009 Return-Path: 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 9B0C93A68C7 for ; Thu, 24 Sep 2009 02:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.129 X-Spam-Level: * X-Spam-Status: No, score=1.129 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] 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 ryRDN9czeNAr for ; Thu, 24 Sep 2009 02:33:26 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 7665D3A694D for ; Thu, 24 Sep 2009 02:33:24 -0700 (PDT) Received: (qmail 18566 invoked by uid 48); 24 Sep 2009 11:34:31 +0200 Received: from 62.140.137.28 (SquirrelMail authenticated user teco@inf-net.nl) by webmail.inf-net.nl with HTTP; Thu, 24 Sep 2009 11:34:30 +0200 (CEST) Message-ID: <40297.62.140.137.28.1253784870.squirrel@webmail.inf-net.nl> Date: Thu, 24 Sep 2009 11:34:30 +0200 (CEST) From: teco@inf-net.nl To: charles.perkins@earthlink.net User-Agent: SquirrelMail/1.4.11 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 09:33:26 -0000 Hi Charlie, |> And yes, random means random. |> | |No problem there, but the question is whether or not |random is _achievable_. The answer is: it depends. In my MANETs, I do not need the random or I have random. I have some security requirements also. Any idea how to implement a secure protocol on boxes that are not able to come up with a random number? What if we define that we need a duplicate detection mechnism, for those who need it? I accept it should be turned on by default, if a node is not sure on uniqueness. My boxes would have it turned off, or run a passive mode. |> |> I don't see a reason why |> |> DYMO won't send messages with link-locals. |If they are unique (and exist), they work great. If they do not |exist, they don't work well for DYMO. If they aren't unique, |they do not work well for DYMO. I was never favorable |to restricting DYMO so that it would only be applicable in |situations admitting the configuration of unique link-local |addresses. It is defined link-locals must exist on IPv6 interfaces (RFC4291): >> All interfaces are required to have at least one Link-Local unicast >> address (see Section 2.8 for additional required addresses). The uniqueness requirement applies on any address, isn't it? Please explain why fulfilling this requirement for non-link-locals is left out in this discussion. Regards, Teco From emmanuel.baccelli@gmail.com Thu Sep 24 04:38:15 2009 Return-Path: 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 3878F3A687D for ; Thu, 24 Sep 2009 04:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.142 X-Spam-Level: X-Spam-Status: No, score=-1.142 tagged_above=-999 required=5 tests=[AWL=-0.655, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 4v6W+E8USk5R for ; Thu, 24 Sep 2009 04:38:14 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by core3.amsl.com (Postfix) with ESMTP id 628593A6781 for ; Thu, 24 Sep 2009 04:38:14 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c5so553806anc.4 for ; Thu, 24 Sep 2009 04:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=Qi0MTeAfHvVKpjBlZaQ1BD8qyRp1uHhqHeArCjByBLE=; b=ePlklUcialYEsYlYICNCr03D1EscXVCPp0q5JMnvq3ygJVzBZT35Oi3RW9ZX2cfwc4 IVizjjhIc6RQ0uWV/WoE4lh/B+8nH31i9Wi26LvXs6R+nKSAkjGZzWL+7+D29MJyKPWt kWUqpWmjCydG/gLzs1MQbfJJL2CLI1sNDuCKY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; b=bT+l0QvEErVh5qW5hP8dvQQnObuBBZLLUCwScV5z9/1soCDSf7Iw5PICcWxjpHWcI6 arbT58NBbeeHEOA/FIiP/gonW4TmAPEBdOMM8MxF5CJKbIzs+kXbMP5MuplqCsG7aBHS XrpIMp8bUHGFm6cirJXKJXrsRC2e/oOyYmzOk= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.100.24.37 with SMTP id 37mr4099358anx.45.1253792359148; Thu, 24 Sep 2009 04:39:19 -0700 (PDT) From: Emmanuel Baccelli Date: Thu, 24 Sep 2009 13:38:59 +0200 X-Google-Sender-Auth: 6496c0e74e72dfbb Message-ID: To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=0016e646916a306f220474514800 Subject: [Autoconf] updated MANET addressing model draft X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 11:38:15 -0000 --0016e646916a306f220474514800 Content-Type: text/plain; charset=ISO-8859-1 Hi all, an updated version of the MANET addressing model draft has just been published. It integrates comments received during and after the last IETF meeting, including some advisory text about IPv6 Link Local addresses, heavily inspired from Erik Nordmark's initial proposal on this topic. http://www.ietf.org/id/draft-baccelli-autoconf-adhoc-addr-model-02.txt Please review it thouroughly, and give us some feedback. Regards, Emmanuel --0016e646916a306f220474514800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all= ,

an updated version of the MANET addressing model draft has j= ust been published. It integrates comments received during and after the la= st IETF meeting, including some advisory text about IPv6 Link Local address= es, heavily inspired from Erik Nordmark's initial proposal on this topi= c.

http://www.ietf.= org/id/draft-baccelli-autoconf-adhoc-addr-model-02.txt

Please review it thouroughly, and give us some fe= edback.

Regards,

Emmanuel
 --0016e646916a306f220474514800-- From charles.perkins@earthlink.net Thu Sep 24 09:25:45 2009 Return-Path: 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 309483A68DD for ; Thu, 24 Sep 2009 09:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.871 X-Spam-Level: X-Spam-Status: No, score=-1.871 tagged_above=-999 required=5 tests=[AWL=0.109, 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 yno+mUi70JSn for ; Thu, 24 Sep 2009 09:25:44 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 55EAE3A67A8 for ; Thu, 24 Sep 2009 09:25:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=YUYBBhiJCyLhslFYpNnUWpOKks7sAbEYvYTJvzCSuWRLPcJQwovkuGQY5DbMItPE; 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.14]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Mqr9g-0000l3-JU; Thu, 24 Sep 2009 12:26:52 -0400 Message-ID: <4ABB9DCC.5040302@earthlink.net> Date: Thu, 24 Sep 2009 09:26:52 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: teco@inf-net.nl References: <40297.62.140.137.28.1253784870.squirrel@webmail.inf-net.nl> In-Reply-To: <40297.62.140.137.28.1253784870.squirrel@webmail.inf-net.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f522fcb6e86b9eed17399dd865c86287a81350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] call for consensus about link local address support X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 16:25:45 -0000 Hello Teco, Comments inline... teco@inf-net.nl wrote: > Hi Charlie, > > |> And yes, random means random. > |> > | > |No problem there, but the question is whether or not > |random is _achievable_. > ... > Any idea how to implement a secure protocol on boxes that are not able to > come up with a random number? > Preconfigure a shared key, 65,536 bits long, not visible to the user. That'll work for a few years. > What if we define that we need a duplicate detection mechnism, for those > who need it? I accept it should be turned on by default, if a node is not > sure on uniqueness. > This is a matter we don't have to resolve right now. I'd prefer that DAD be configurable also. > |> |> I don't see a reason why > |> |> DYMO won't send messages with link-locals. > > |If they are unique (and exist), they work great. If they do not > |exist, they don't work well for DYMO. If they aren't unique, > |they do not work well for DYMO. I was never favorable > |to restricting DYMO so that it would only be applicable in > |situations admitting the configuration of unique link-local > |addresses. > > It is defined link-locals must exist on IPv6 interfaces (RFC4291): > Well then, let's define a global constant that nodes can use as a LL address on their IPv6 interface on the condition that the address will never appear as source or destination IP address in a packet. I think it is more sensible to update RFC 4291. We're talking about enabling solutions here, not professing a religion. >>> All interfaces are required to have at least one Link-Local unicast >>> address (see Section 2.8 for additional required addresses). >>> > > The uniqueness requirement applies on any address, isn't it? > Please explain why fulfilling this requirement for non-link-locals is left > out in this discussion. > Who has time to talk about anything but link-locals? I think we should charter a new working group that plays discussions about link-locals 24 hours a day, 7 days a week. Regards, Charlie P. From charles.perkins@earthlink.net Thu Sep 24 10:02:28 2009 Return-Path: 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 BF9F23A6AAA for ; Thu, 24 Sep 2009 10:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.13 X-Spam-Level: X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[AWL=-0.639, BAYES_05=-1.11, 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 81agoAWf3TKE for ; Thu, 24 Sep 2009 10:02:28 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id D31A83A6A8C for ; Thu, 24 Sep 2009 10:02:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ZAxiwM/m9BWPyDP10oXTWHSElhsKvDpvuBZcf6FI99/LVMsq6JVwhd4DrIqI3X8q; 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.14]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MqrjE-0006eF-8w; Thu, 24 Sep 2009 13:03:36 -0400 Message-ID: <4ABBA667.40009@earthlink.net> Date: Thu, 24 Sep 2009 10:03:35 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: teco@inf-net.nl References: <17436.62.140.137.28.1253783620.squirrel@webmail.inf-net.nl> In-Reply-To: <17436.62.140.137.28.1253783620.squirrel@webmail.inf-net.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52435a5e43645fafb59db1d386256f0dcc350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] BDRP vs. world hunger X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 17:02:28 -0000 Hello Teco, Comments inline below... teco@inf-net.nl wrote: > Hi Charlie, > > I think we people can produce enough food for solving world hunger. > Maybe there are some L8 (political layer) problems to solve. Let's not > tackle this in [Autoconf]. > There seem to be big problems with the content providers, and especially reliable delivery between the application endpoints due to extremely lossy channel conditions over an expensive transmission medium. > > |BRDP is, if you'll pardon my simplification, a souped-up version > |of Router Advertisement. So, it isn't designed at all for autonomous > |MANETs. > > BRDP is on top of RA, that is correct. It could be updated to run on top of > PacketBB messages, but now it is independent of any MANET protocol. > > Did you check 5.3. Support for Autonomous MANETs ? > It is a bit out of context for BRDP. As I see it, assigning globals is the > tough part. > You have to admit, that section 5.3 does not indicate the solution to the four-node problem. > > |It is not clear from what you said how BRDP can begin to solve the > |problem that I outlined whereby four nodes cooperate to form a highly > |mobile network. > > I assume unique Interface-IDs. Enough said! Unique interface-IDs do, in fact, enable a trivial solution for globally unique link-locals. There is no need to say anything else. However, the point of the discussion has been that we should enable solutions where this assumption isn't automatically valid. And, the flip side of that coin, that we should not require solutions to provide link-local addresses when such addresses are not already trivially configurable. > > > |Clearly, BRDP does _not_ connect all MANETs on the globe, > |if some are disconnected. > > The claim was on scalability of the proposed mechanism. This claim is very > true. It is not in my hands connecting all MANETs to the Internet. > But, previously, you said: > > BRDP provides a mechanism that connects all MANETs on this > globe via the Internet without any problems. I am disputing that claim. > In fact, BRDP with BRDP based routing would upgrade DYMO to a protocol > that works well connecting DYMO MANETs to the Internet. And with scoping > RREQs, the size of DYMO MANETs would be unlimited. How nice :-) > > What's a "scoping RREQ"? Are we wandering back into the realm of extraordinary claims? Why wouldn't any other gateway protocol produce the same effect? Regards, Charlie P. From teco@inf-net.nl Thu Sep 24 14:18:00 2009 Return-Path: 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 2C92D3A6925 for ; Thu, 24 Sep 2009 14:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.125 X-Spam-Level: * X-Spam-Status: No, score=1.125 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] 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 fjp3lst7MN40 for ; Thu, 24 Sep 2009 14:17:59 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 8CDD43A68C5 for ; Thu, 24 Sep 2009 14:17:57 -0700 (PDT) Received: (qmail 16651 invoked by uid 48); 24 Sep 2009 23:19:04 +0200 Received: from 62.140.137.8 (SquirrelMail authenticated user teco@inf-net.nl) by webmail.inf-net.nl with HTTP; Thu, 24 Sep 2009 23:19:04 +0200 (CEST) Message-ID: <54170.62.140.137.8.1253827144.squirrel@webmail.inf-net.nl> Date: Thu, 24 Sep 2009 23:19:04 +0200 (CEST) From: teco@inf-net.nl To: charles.perkins@earthlink.net User-Agent: SquirrelMail/1.4.11 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: autoconf@ietf.org Subject: Re: [Autoconf] BDRP vs. world hunger X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 21:18:00 -0000 Hi Charlie, |> Did you check 5.3. Support for Autonomous MANETs ? |> It is a bit out of context for BRDP. As I see it, assigning globals is |the |> tough part. |> | |You have to admit, that section 5.3 does not indicate the solution to |the four-node problem. I don't see the four-node problem as a problem. If your boxes has a problem because they cannot generate an (almost) unique address, you may define a solution. Such a mechanism could work for all address types of interest. > I assume unique Interface-IDs. |However, the point of the discussion has been that we should |enable solutions where this assumption isn't automatically |valid. Do we agree on having unique Interface-IDs, by nature (EUI-64), pseudo-random (good enough) or inferieur with duplicate detection (try & error)? I really want to know why this DAD discussion is related to link-locals and not to other address types. Regards, Teco From charles.perkins@earthlink.net Thu Sep 24 14:38:29 2009 Return-Path: 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 E434C3A68A1 for ; Thu, 24 Sep 2009 14:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599] 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 XBaLRU-UsnMD for ; Thu, 24 Sep 2009 14:38:27 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id B5ED93A68C1 for ; Thu, 24 Sep 2009 14:38:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=o9SXr+IhhL7mfHNVx5BOaQ9o2o9e7CMFkpKdADgtUS8ebvdO1/AwrVl/p1z0N7Rv; 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 [99.51.74.16] (helo=[192.168.1.102]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Mqw2H-0001DE-JV; Thu, 24 Sep 2009 17:39:33 -0400 Message-ID: <4ABBE714.2010903@earthlink.net> Date: Thu, 24 Sep 2009 14:39:32 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: teco@inf-net.nl References: <54170.62.140.137.8.1253827144.squirrel@webmail.inf-net.nl> In-Reply-To: <54170.62.140.137.8.1253827144.squirrel@webmail.inf-net.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5293ed6a6874b666a4817f3229642517ad350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] BDRP vs. world hunger X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 21:38:30 -0000 Hello Teco, teco@inf-net.nl wrote: > |You have to admit, that section 5.3 does not indicate the solution to > |the four-node problem. > > I don't see the four-node problem as a problem. > If your boxes has a problem because they cannot generate > an (almost) unique address, you may define a solution. > Such a mechanism could work for all address types of interest. > Then in your universe all nodes have unique interface identifications, So much the better! All you need from autoconfiguration is to learn the routing prefix. Then you are done. If the four nodes do not have the unique interface IDs, then you do not provide a solution for them. But solutions have been devised for that case. They do not need link-locals. In point of fact, you don't need link-locals, even when you do have unique interface IDs, except insofar as they have been mandated by IPv6 specification. I think the main point is that we want to avoid making the universal mandate, not at all that we would try to make the universal prohibition. I hope by now you agree with this. > > >> I assume unique Interface-IDs. >> > > |However, the point of the discussion has been that we should > |enable solutions where this assumption isn't automatically > |valid. > > Do we agree on having unique Interface-IDs, Not always. > by nature (EUI-64), > Not always. > pseudo-random (good enough) Not always. > or inferieur Inferior by what metric? What if there are cost goals that must be met? What if they just don't happen to be IEEE interfaces? > with duplicate detection (try & > error)? > These are not necessarily tied together. > > I really want to know why this DAD discussion is related to link-locals > and not to other address types. > What DAD discussion? Can we distinguish between (i) some discussion about duplicate addresses and (ii) DAD? I think we ought, generally speaking, to try to avoid (ii) at this point in the discussion. Regards, Charlie P. From emmanuel.baccelli@gmail.com Tue Sep 29 08:41:36 2009 Return-Path: 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 93D583A6822 for ; Tue, 29 Sep 2009 08:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 6b0PBzLPWIHM for ; Tue, 29 Sep 2009 08:41:35 -0700 (PDT) Received: from mail-yw0-f202.google.com (mail-yw0-f202.google.com [209.85.211.202]) by core3.amsl.com (Postfix) with ESMTP id CF29F3A67B2 for ; Tue, 29 Sep 2009 08:41:34 -0700 (PDT) Received: by ywh40 with SMTP id 40so5698393ywh.32 for ; Tue, 29 Sep 2009 08:42:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to :content-type; bh=rY2uhuBKe2AIhuJI9G/9tsPtKkAdjEzwMxC1wWInKRc=; b=s86q8lUuJRwkcKzx63PUZltw6s6n9lPPNEXZWByt0lkP0J/0KhOmzouqBtdurtX/Q9 xngeQxeywf97ZjZNr5yPt5Z+glSSIIaOXtZo7iMGRRTjTOzBxYulPAjqV5uZ+HIZv0Q6 HUT+1hO6fmDmtkNkNMmTqekwLp9svRq0VW3qk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=nRKrHjtPq56Fi551VrCq/VaiQxUMVkxhQINfNP0K2IxtHNoeJk/3YUKhcEeRdFTdIR obftPgYVpaVZST1FZiILl6V3V3Ob0MzIZP56aXUhfFKl0NmIkiRFjCNudStNNR9nr1EO wExKabS/LlNbtYTkKjtaEBdXeoFfYfJLZzyBg= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.90.10.1 with SMTP id 1mr3747305agj.62.1254238972132; Tue, 29 Sep 2009 08:42:52 -0700 (PDT) In-Reply-To: References: From: Emmanuel Baccelli Date: Tue, 29 Sep 2009 17:42:32 +0200 X-Google-Sender-Auth: 4f29e395d475aeb5 Message-ID: To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=00163628351665bde10474b9440e Subject: Re: [Autoconf] updated MANET addressing model draft X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 15:41:36 -0000 --00163628351665bde10474b9440e Content-Type: text/plain; charset=ISO-8859-1 Hi all, Please do let us know your feedback on the updated doc http://www.ietf.org/id/draft-baccelli-autoconf-adhoc-addr-model-02.txt Silence may be interpreted as violent agreement with its content ;) Let's move on quickly with this, while we still have time before Hiroshima! Cheers, Emmanuel On Thu, Sep 24, 2009 at 1:38 PM, Emmanuel Baccelli < Emmanuel.Baccelli@inria.fr> wrote: > Hi all, > an updated version of the MANET addressing model draft has just been > published. It integrates comments received during and after the last IETF > meeting, including some advisory text about IPv6 Link Local addresses, > heavily inspired from Erik Nordmark's initial proposal on this topic. > > http://www.ietf.org/id/draft-baccelli-autoconf-adhoc-addr-model-02.txt > > Please review it thouroughly, and give us some feedback. > > Regards, > > Emmanuel > --00163628351665bde10474b9440e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

Please do let us know your feedback on the updated doc http://www.ietf.org/id/draft-baccelli-autoconf-a= dhoc-addr-model-02.txt

Silence may be interpreted as violent agreement with its content ;)
=
Let's move on quickly with this, while we still have time before Hi= roshima!

Cheers,

Emmanuel



On Thu, Sep 24, 2009 at 1:38 PM, Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr&= gt; wrote:
Hi all,

an updated ver= sion of the MANET addressing model draft has just been published. It integr= ates comments received during and after the last IETF meeting, including so= me advisory text about IPv6 Link Local addresses, heavily inspired from Eri= k Nordmark's initial proposal on this topic.
Please review it thouroughly, and give us some fe= edback.

Regards,

Emmanuel

--00163628351665bde10474b9440e-- From teco@inf-net.nl Wed Sep 30 05:18:09 2009 Return-Path: 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 115483A6953 for ; Wed, 30 Sep 2009 05:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[AWL=-0.679, BAYES_50=0.001] 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 ClcIz98QtGHW for ; Wed, 30 Sep 2009 05:18:08 -0700 (PDT) Received: from CPSMTPM-EML101.kpnxchange.com (cpsmtpm-eml101.kpnxchange.com [195.121.3.5]) by core3.amsl.com (Postfix) with ESMTP id 860B13A6821 for ; Wed, 30 Sep 2009 05:18:06 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML101.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Wed, 30 Sep 2009 14:19:28 +0200 From: "Teco Boot" To: "'Emmanuel Baccelli'" , References: In-Reply-To: Date: Wed, 30 Sep 2009 14:19:28 +0200 Message-ID: <002f01ca41c8$418c0340$c4a409c0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpBG4x2+goTKbFQTSmNW/wk548epgAo8sGg Content-Language: nl X-OriginalArrivalTime: 30 Sep 2009 12:19:28.0649 (UTC) FILETIME=[41C9CF90:01CA41C8] Subject: Re: [Autoconf] updated MANET addressing model draft X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 12:18:09 -0000 Hi Emmanuel, Here some (not retired :-) comments. > 4. IP Subnet Prefix Configuration > > If the link to which an interface connects enables no assumptions of > connectivity to other interfaces, the only addresses which can be > assumed "on link", are the address(es) of that interface itself. > Note that while IPv6 link-local addresses are assumed to be "on > link", the utility of IPv6 link-local addresses is limited as > specified in Section 6.2. I posted earlier that adding the link-local topic is not needed. I suggested the text could be changed in: If the link to which an interface connects enables no assumptions of connectivity to other interfaces, the only addresses which can be assumed reachable, are the address(es) of that interface itself. This circumvents the "on-link" discussion, which we can continue forever. We better don't. On 6.2 IPv6 Model: I am fine with: > Note that while an IPv6 link-local address is assigned to each > interface as per [RFC4291], in general link-local addresses are of > limited utility on links with undetermined connectivity, as neighbors > may be constantly moving in and out of reachability. The known > limitations are: > Therefore MANET autoconfiguration solutions will primarily focus on > configuring IP addresses that are not IPv6 link-local. But I think the left out "known limitations" shall be verified for correctness and not being "opinions". > o Even if tested for local uniqueness at one moment using Duplicate > Address Detection [RFC4862], a duplicate link-local address might > appear as a neighbor the next moment and DAD would not detect > that. This is very true for all unicast address types. Link-local is no exception at all!!! To rephrase Charlie P. his comment on my recent posting: >I think we ought, generally speaking, to try to avoid (ii) at this point >in the discussion. (ii is DAD) > o 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. I remember the RouterID topic was discussed shortly some time ago (IETF ??). The opinion was that we shall stay away from this topic. Also, I do not agree. Link-locals can perfectly be used as RouterID, as long as the Interface-ID is unique. And this can be ensured in many cases, if not all. One approach of Autoconf could be making sure Interface-IDs are unique. Then, these can be used for whatever unicast Address type. We have to deal with globals one day. The sooner the better. > o Routers cannot forward any packets with link-local source or > destination addresses to other links (as per [RFC4291]) while most > of the time, routers need to be able to forward packets to/from > different links. This is very true. True in every IPv6 network. I don't see a reason to repeat this here. Or I miss something. Maybe the intended limitation was providing reachability on links with "RFC4861 asymmetric reachability". When IPv6 routers do not forward packets with link-local source or destination, nodes on such a link may have or may not have connectivity using link-locals. The MANET protocol would not "repair" this. With MANET-local or globals, there is no such limitation in connectivity. On the other hand, some protocols or applications require that packets are not forwarded, even on the same link. Then, link-locals can be utilized. MANET routing protocols are a perfect example for this. Suggested text: Routers cannot forward any packets with link-local source or destination addresses to other links (as per [RFC4291]). In general, routers do not forward such packets. This would limit connectivity between MANET nodes. For this reason, link-local addresses shall be used only for protocols that require one-hop limited delivery of packets. The complete text added in 6.2 would be: Note that while an IPv6 link-local address is assigned to each interface as per [RFC4291], in general link-local addresses are of limited utility on links with undetermined connectivity, as neighbors may be constantly moving in and out of reachability. Routers cannot forward any packets with link-local source or destination addresses to other links (as per [RFC4291]). In general, routers do not forward such packets. This would limit connectivity between MANET nodes. For this reason, link-local addresses shall be used only for protocols that require one-hop limited delivery of packets. MANET autoconfiguration solutions will primarily focus on configuring IP addresses that are not IPv6 link-local. I hope everybody can agree on this text. Regards, Teco Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens Emmanuel Baccelli Verzonden: dinsdag 29 september 2009 17:43 Aan: autoconf@ietf.org Onderwerp: Re: [Autoconf] updated MANET addressing model draft Hi all, Please do let us know your feedback on the updated doc http://www.ietf.org/id/draft-baccelli-autoconf-adhoc-addr-model-02.txt Silence may be interpreted as violent agreement with its content ;) Let's move on quickly with this, while we still have time before Hiroshima! Cheers, Emmanuel On Thu, Sep 24, 2009 at 1:38 PM, Emmanuel Baccelli wrote: Hi all, an updated version of the MANET addressing model draft has just been published. It integrates comments received during and after the last IETF meeting, including some advisory text about IPv6 Link Local addresses, heavily inspired from Erik Nordmark's initial proposal on this topic. http://www.ietf.org/id/draft-baccelli-autoconf-adhoc-addr-model-02.txt Please review it thouroughly, and give us some feedback. Regards, Emmanuel From teco@inf-net.nl Wed Sep 30 05:48:28 2009 Return-Path: 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 542BC3A6A50 for ; Wed, 30 Sep 2009 05:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.196 X-Spam-Level: X-Spam-Status: No, score=-1.196 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_05=-1.11] 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 to1AM2XHuERE for ; Wed, 30 Sep 2009 05:48:27 -0700 (PDT) Received: from CPSMTPM-EML101.kpnxchange.com (cpsmtpm-eml101.kpnxchange.com [195.121.3.5]) by core3.amsl.com (Postfix) with ESMTP id E6EDF3A659C for ; Wed, 30 Sep 2009 05:48:26 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML101.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Wed, 30 Sep 2009 14:49:48 +0200 From: "Teco Boot" To: "'Charles E. Perkins'" References: <54170.62.140.137.8.1253827144.squirrel@webmail.inf-net.nl> <4ABBE714.2010903@earthlink.net> In-Reply-To: <4ABBE714.2010903@earthlink.net> Date: Wed, 30 Sep 2009 14:49:48 +0200 Message-ID: <003001ca41cc$7e74fb50$7b5ef1f0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aco9X4cGv4laf4y+Rxm3CwGk9hMiZAEaNdzg Content-Language: nl X-OriginalArrivalTime: 30 Sep 2009 12:49:48.0754 (UTC) FILETIME=[7EA7CB20:01CA41CC] Cc: autoconf@ietf.org Subject: Re: [Autoconf] BDRP vs. world hunger X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 12:48:28 -0000 Hi Charlie, |-----Oorspronkelijk bericht----- |Van: Charles E. Perkins [mailto:charles.perkins@earthlink.net] |Verzonden: donderdag 24 september 2009 23:40 |Aan: teco@inf-net.nl |CC: autoconf@ietf.org |Onderwerp: Re: BDRP vs. world hunger | | |Hello Teco, | |teco@inf-net.nl wrote: |> |You have to admit, that section 5.3 does not indicate the solution to |> |the four-node problem. |> |> I don't see the four-node problem as a problem. |> If your boxes has a problem because they cannot generate |> an (almost) unique address, you may define a solution. |> Such a mechanism could work for all address types of interest. |> | |Then in your universe all nodes have unique interface |identifications, So much the better! All you need from |autoconfiguration is to learn the routing prefix. Then |you are done. | |If the four nodes do not have the unique interface IDs, |then you do not provide a solution for them. But |solutions have been devised for that case. They do |not need link-locals. In point of fact, you don't need |link-locals, even when you do have unique interface IDs, |except insofar as they have been mandated by IPv6 |specification. | |I think the main point is that we want to avoid making |the universal mandate, not at all that we would try to |make the universal prohibition. I hope by now you |agree with this. Agreed. Let us focus on [Autoconf] chartered items. This includes global addresses. You stated correctly, one way dealing with it is unique interface identifications and learn the routing prefix. There is more, such as address selection and routing packets to the correct border router. But first things first. Can you be specific on "provided solutions"? Then I can check these for unique interface IDs and / or providing globals. I said many times I stop pushing BRDP if an equivalent is out there. |> |> |>> I assume unique Interface-IDs. |>> |> |> |However, the point of the discussion has been that we should |> |enable solutions where this assumption isn't automatically |> |valid. |> |> Do we agree on having unique Interface-IDs, |Not always. |> by nature (EUI-64), |> |Not always. |> pseudo-random (good enough) |Not always. |> or inferieur | |Inferior by what metric? What if there are |cost goals that must be met? What if they |just don't happen to be IEEE interfaces? (sorry for using Dutch word) "inferior" was for uniqueness. I thought the context was quite clear. On cost goals: this is extremely important for me. For me, the costs of unneeded overhead is unacceptable expensive. A good seed for pseudo random is in my case for free or very low cost. Also, in my case there are IEEE interfaces in the box. The global unique identifiers can be used for all interfaces for that box. I asked couple of times for clarifications on mechanisms for avoiding duplicates. No answers yet. We could say we postpone, as it is solution space. But we have to include something in the MANET addressing model. It is about using unique Interface IDs or not. Regards, Teco. | | |> with duplicate detection (try & |> error)? |> | |These are not necessarily tied together. | |> |> I really want to know why this DAD discussion is related to link- |locals |> and not to other address types. |> | |What DAD discussion? | |Can we distinguish between (i) some discussion about |duplicate addresses and (ii) DAD? | |I think we ought, generally speaking, to try to avoid (ii) at this point |in the discussion. | |Regards, |Charlie P. From teco@inf-net.nl Wed Sep 30 05:53:29 2009 Return-Path: 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 257F33A695D for ; Wed, 30 Sep 2009 05:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[AWL=0.663, BAYES_00=-2.599] 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 BMNykRkQjHwy for ; Wed, 30 Sep 2009 05:53:28 -0700 (PDT) Received: from CPSMTPM-EML109.kpnxchange.com (Cpsmtpm-eml109.kpnxchange.com [195.121.3.13]) by core3.amsl.com (Postfix) with ESMTP id 1F8B43A6951 for ; Wed, 30 Sep 2009 05:53:27 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML109.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Wed, 30 Sep 2009 14:54:50 +0200 From: "Teco Boot" To: "'Emmanuel Baccelli'" , References: In-Reply-To: Date: Wed, 30 Sep 2009 14:54:49 +0200 Message-ID: <003101ca41cd$31e7dae0$95b790a0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpBG4x2+goTKbFQTSmNW/wk548epgAsRYmA Content-Language: nl X-OriginalArrivalTime: 30 Sep 2009 12:54:50.0408 (UTC) FILETIME=[32748A80:01CA41CD] Subject: Re: [Autoconf] updated MANET addressing model draft X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 12:53:29 -0000 Hi Emmanuel, Another oldie: Appendix A. Open Issues > Global Uniqueness Requirements - it remains to be determined whether > or not the scope of AUTOCONF includes applications other than > routing protocols running on the router, which may communicate > with outside the routing domain and which for that, require > globally unique addresses. > Out of our charter: >Ad hoc nodes may also need to >configure globally routable addresses, in order to communicate with >devices on the Internet. For me it is clear that configuring globally routable addresses is in scope. I think I just repeat others here. Regards, Teco. Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens Emmanuel Baccelli Verzonden: dinsdag 29 september 2009 17:43 Aan: autoconf@ietf.org Onderwerp: Re: [Autoconf] updated MANET addressing model draft Hi all, Please do let us know your feedback on the updated doc http://www.ietf.org/id/draft-baccelli-autoconf-adhoc-addr-model-02.txt Silence may be interpreted as violent agreement with its content ;) Let's move on quickly with this, while we still have time before Hiroshima! Cheers, Emmanuel On Thu, Sep 24, 2009 at 1:38 PM, Emmanuel Baccelli wrote: Hi all, an updated version of the MANET addressing model draft has just been published. It integrates comments received during and after the last IETF meeting, including some advisory text about IPv6 Link Local addresses, heavily inspired from Erik Nordmark's initial proposal on this topic. http://www.ietf.org/id/draft-baccelli-autoconf-adhoc-addr-model-02.txt Please review it thouroughly, and give us some feedback. Regards, Emmanuel