From ryuji.wakikawa@gmail.com Tue Oct 6 12:12: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 881C028C21A for ; Tue, 6 Oct 2009 12:12:18 -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 zIM37bxWZnyp for ; Tue, 6 Oct 2009 12:12:17 -0700 (PDT) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 94E6C28C0F0 for ; Tue, 6 Oct 2009 12:12:15 -0700 (PDT) Received: by ewy10 with SMTP id 10so4553830ewy.9 for ; Tue, 06 Oct 2009 12:13:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=YdJtPxcmCcT97cGvyNWSnTHdDYIDNVCxPCFY2WoAsRY=; b=Ypj6rjQgCTNgOALxX0o38tFVdbgUjw5/qYMpV0aiXyr1KDyFmPfjARInGFtvV0uduh 1aSrrp1c2q8ZtfIpPwBg+SYlc43IA+abrUhrvLmXrMBjHZjNxncm2Uui360yLLjgfcwo 2zLzHJWNd5v26jnbXcZCnaYo3HY5Fg+YFAFKY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; b=MlG3AUjPjlXftPJApcT2eWVRBKjk8xTk/xssi9/rbXMdKLCo4KZCoUaKd6fdj8a9ly 0mlxArxym1X6mu3joQ4azi6Oo7Nl5v3N0A85AZ2MwrVJl8PRyNxXbA5nzHoLWIYylbXo JZTuuBG9cpuzc5v0kGSVG+QtVlbw93KBELU2I= MIME-Version: 1.0 Received: by 10.216.73.135 with SMTP id v7mr386598wed.66.1254856431141; Tue, 06 Oct 2009 12:13:51 -0700 (PDT) In-Reply-To: <20091006011144.BBE063A6A4E@core3.amsl.com> References: <20091006011144.BBE063A6A4E@core3.amsl.com> Date: Tue, 6 Oct 2009 12:13:51 -0700 Message-ID: <84840efa0910061213h569699cdpfa14732248619d6d@mail.gmail.com> From: Ryuji Wakikawa To: autoconf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Autoconf] Fwd: AUTOCONF - Requested session has been scheduled for IETF 76 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ryuji@sfc.wide.ad.jp List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 19:12:18 -0000 FYI, we will have a meeting in IETF76. thanks ryuji ---------- Forwarded message ---------- From: IETF Secretariat Date: 2009/10/5 Subject: AUTOCONF - Requested session has been scheduled for IETF 76 To: ryuji.wakikawa@gmail.com Cc: T.Clausen@computer.org, rdroms@cisco.com, jari.arkko@piuha.net, session-request@ietf.org Dear Ryuji Wakikawa, The sessions that you have requested have been scheduled. Below is the scheduled session information followed by the information of sessions that you have requested. AUTOCONF Session 1 (2 hours) Monday, Afternoon Session III 1740-1940 Room Name: Acacia 1 ---------------------------------------------- From thomas@thomasclausen.org Thu Oct 8 23:15: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 0AA4A3A68E3 for ; Thu, 8 Oct 2009 23:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 r9Mcv99nxjFM for ; Thu, 8 Oct 2009 23:15:23 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 738C03A681E for ; Thu, 8 Oct 2009 23:15:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 86B18322DE39; Thu, 8 Oct 2009 23:17:07 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.133.2] (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 08F1E322D188; Thu, 8 Oct 2009 23:17:05 -0700 (PDT) Message-Id: <587654C4-E358-48A5-8C24-DFDB786E9793@thomasclausen.org> From: Thomas Heide Clausen To: Emmanuel Baccelli , Mark Townsley In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-6--263566664 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 9 Oct 2009 08:17:03 +0200 References: X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org 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: Fri, 09 Oct 2009 06:15:25 -0000 --Apple-Mail-6--263566664 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Emmanuel, Mark, all, On Sep 29, 2009, at 5:42 PM, Emmanuel Baccelli wrote: > 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 ;) Uhh, that's a threat. I wouldn't want to be taken as being silently agreeing (or disagreeing) with anything. Speaking without any hats (specifically, I do not speak as chair in this email), and simply as someone building MANETs, hereby my comments to this document. Overall: ======= I think that the document is in a decent shape and reflects the WG discussions and the issues that have been brought up thus far. I would therefore be supportive (as WG participant) of accepting this document as WG document. Also, I have some detailed comments, which I would be happy to see addressed (but whose address would not be a prerequisite for my support of this document as WG document). Details: ======== o The title of the document contains "Ad Hoc Networks", but nowhere does it say "Ad Hoc Networks" inside the document. This is rather odd. I would suggest that it be said somewhere (e.g. in the applicability statement or introduction?) that: + an "Ad Hoc Network" is a typical example of a network with "undetermined connectivity"; where + MANET routing protocols have as their raison d'etre to "determine network-wide connectivity"; but that to do so + MANET protocols require the interfaces to be configured with IP addresses The latter of these is already said in the Introduction. I would suggest that saying the two others would make it clear what this document is about. Note that the second point above is critical in that the goal is not to "hide" (or "fake out", in Townsley- terminology) the undetermined connectivity properties, but rather that there are routing protocols in existence in the IETF that are conceived explicitly to handle these properties. o The introduction is a little murky with respect to links/topology/ assumptions/ configurations. In my world-view: + the network topology *is* -- is an undisputed fact. + we may know something about this, or we may not. I.e. given a network, we may make use this knowledge to make assumptions about the properties of that network. + those assumptions we use to *reflect* the topology in the network *configuration*. So I would suggest that the second paragraph of the introduction be revisited with this in mind. As it is, it appears a little roundabout, that the network topology is "designed" by the configuration (I realize that this to some extend also is true, but I do not think that this is the message in this paragraph?) o Section 3: + should we say in paragraph 1 that we're concerned with IP routers and their IP interfaces, to stamp out any ambiguity on L2 "routing"? + should we say "between interfaces" rather than "to other interfaces on the link" in the second paragraph, to not be caught in the "what is a link" issue again? o Section 4: + First paragraph top of page 4, use "described in section 6.2" rather than "specified in section 6.2" + Insert "direct" between "As" and "communication" in penultimate paragraph. + Alsp penultimate paragraph, any way to get rid of "on that link"? I was playing around with "between which L2 communication is enabled" as an alternative. It avoids the issue that Thaler brought up of "IP Link" and "Data Link". + Previous bullet applies in the ultimate paragraph of section 4 as well. o Section 4 + 5, both: + I suggest replacing "This translates in the following policy" by "This translate into the following principle" -- in part because "principle" is the term used for referencing these later + The "principles", I would make into bullet-points in order to make them stand out and be easy to see among the text. o Section 5: + First paragraph last sentence after the comma, suggest: "....., to uniqueness within, at least, the routing domain". o Section 6.1: + Penultimate bullet, suggest replacing the comma before and by a semicolon + Ultimate bullet, suggest replacing "A subnet" by "Any subnet" o Section 6.2: + Same considerations as in 6.1 for the first two bullet points. + First paragraph after the two first bulletpoints, suggest: "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: connectivity to neighbors may be constantly changing. The known limitations are:" Reason: the original text talk about "mobility" ("moving in and out of reachability"), which is rather specific to one given type of interface. Logially, what matters is that being a neighbor at one given time does not guarantee that one is neighbor in the future, nor that such a change is detectable (to trigger reconfiguration). + First bullet point in last block of bullets, suggest (for the same reasons as above): "Even if tested for local uniqueness at one given time and using Duplicate Address Detection (DAD) [RFC4862], a duplicate link-local address might appear as a neighbor at any time thereafter. Without an explicit event that would trigger DAD, such duplication would go undetected". + Ultimate paragraph in 6.2 reads more like a "problem statement". Suggest rephrasing to conclude that LLs are difficult to use in a coherent way under the conditions that this document present, and suggest that therefore non-LLs are encouraged [in part, because as this is not a WG document yet, it doesn't really reflect any official WG position on the matter...yet]. I'll conclude by expressing satisfaction that what is described in this document is compatible with the way I build MANETs -- or rather, that the configuration of the MANETs, which I am aware of, conforms to the principles laid out in this document. Cheers, Thomas > 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 > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf --Apple-Mail-6--263566664 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Emmanuel, Mark, = all,

On Sep 29, 2009, at 5:42 PM, Emmanuel = Baccelli wrote:

Hi all,

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

Silence may be interpreted as violent = agreement with its content ;)

Uhh, = that's a threat. I wouldn't want to be taken as being silently agreeing = (or disagreeing) with = anything.


Speaking without any = hats (specifically, I do not speak as chair in this email), and simply = as someone building MANETs, hereby my comments to this = document.

Overall:
=3D=3D=3D=3D=3D=3D=3D=

I think that the document is in a = decent shape and reflects the WG discussions
and the = issues that have been brought up thus far. I would therefore = be
= supportive (as WG participant) of accepting this document as WG = document.

Also, I have some detailed = comments, which I would be happy to see addressed
(but = whose address would not be a prerequisite for my support of this = document as
WG = document).

Details:
=3D=3D=3D=3D=3D=3D=3D= =3D

o The title of the document = contains "Ad Hoc Networks", but nowhere does it say
= "Ad Hoc Networks" inside the document. This is rather odd. I = would suggest that
it be said somewhere = (e.g. in the applicability statement or introduction?) = that: 
= + = an "Ad Hoc Network" is a typical example of a network = with 
= "undetermined connectivity"; = where

+ MANET = routing protocols have as their raison d'etre to = "determine
network-wide = connectivity"; but that to do so

= + = MANET protocols require the interfaces to be configured with IP = addresses

The latter of these is = already said in the Introduction. I would suggest that = saying
= the two others would make it clear what this = document is about. Note that the second
= point above is critical in that the goal is not to "hide" (or = "fake out", in Townsley-
terminology) the = undetermined connectivity properties, but rather that there are = routing 
protocols in existence in = the IETF that are conceived explicitly to handle = these 
= properties.

o The introduction is a little = murky with respect to links/topology/assumptions/
= configurations. In my world-view:

= + = the network topology *is* -- is an undisputed = fact.
=
+ we may = know something about this, or we may not. I.e. given a network, = we
= may make use this knowledge to make assumptions about the = properties of
that = network.

+ those = assumptions we use to *reflect* the topology in the = network 
= *configuration*.

= So I would suggest that the second paragraph of the introduction = be revisited with 
this in mind. As it is, = it appears a little roundabout, that the network topology = is 
"designed" by the = configuration (I realize that this to some extend also is true, = but
= I do not think that this is the message in this = paragraph?)

o Section = 3:

+ should we = say in paragraph 1 that we're concerned with IP routers and = their
= IP interfaces, to stamp out any ambiguity on L2 = "routing"?

+ should we = say "between interfaces" rather than "to other interfaces on the = link"
= in the second paragraph, to not be caught in the = "what is a link" issue again?

o Section = 4:
=
+ First = paragraph top of page 4, use "described in section 6.2" rather = than 
"specified in = section 6.2"

+ Insert = "direct" between "As" and "communication" in penultimate = paragraph.

+ Alsp = penultimate paragraph, any way to get rid of "on that link"? I = was 
playing around = with "between which L2 communication is enabled" as an
= alternative. It avoids the issue that Thaler brought up of "IP = Link" and 
"Data = Link".

+ Previous = bullet applies in the ultimate paragraph of section 4 as = well.

o Section 4 + 5, = both:

+ I suggest = replacing "This translates in the following policy" by
= "This translate into the following principle" -- in part because = "principle"
is the term used = for referencing these later

= + = The "principles", I would make into bullet-points in order to = make them stand
out and be easy = to see among the text.

o Section = 5:

+ First = paragraph last sentence after the comma, = suggest:

"....., = to uniqueness within, at least, the routing = domain".


o Section = 6.1:

+ = Penultimate bullet, suggest replacing the comma before and by a = semicolon
= + = Ultimate bullet, suggest replacing "A subnet" by "Any = subnet"

o Section = 6.2:

+ Same = considerations as in 6.1 for the first two bullet = points.

+ First = paragraph after the two first bulletpoints, = suggest:

   = "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: connectivity
   =  to neighbors may be constantly changing.  The = known
=     limitations = are:"

Reason: the = original text talk about "mobility" ("moving in and out = of
= reachability"), which is rather specific to one given = type of interface. 
Logially, what = matters is that being a neighbor at one given time 
= does not guarantee that one is neighbor in the future, nor that = such
= a change is detectable (to trigger = reconfiguration).

+ First = bullet point in last block of bullets, suggest (for the same reasons = as 
= above):

   = "Even if tested for local uniqueness at one given time = and using 
=   =  Duplicate Address Detection (DAD) [RFC4862], a = duplicate 
=  link-local address might appear as a neighbor at any = time thereafter.
=  Without an explicit event that would trigger DAD, such = duplication
=  would go undetected".

= + = Ultimate paragraph in 6.2 reads more like a "problem = statement". 
Suggest = rephrasing to conclude that LLs are difficult to use in a = coherent
way under the = conditions that this document present, and suggest = that 
therefore non-LLs = are encouraged [in part, because as this is not a = WG 
document yet, it = doesn't really reflect any official WG position on = the 
= matter...yet].

I'll conclude by = expressing satisfaction that what is described in this document is = compatible with the way I build MANETs -- or rather, that the = configuration of the MANETs, which I am aware of, conforms to the = principles laid out in this = document.

Cheers,

Thomas=

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&= gt; 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.
Please review it = thouroughly, and give us some = feedback.

Regards,

Emmanuel
 =

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

= --Apple-Mail-6--263566664-- From emmanuel.baccelli@gmail.com Fri Oct 9 02:37: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 36A333A67EF for ; Fri, 9 Oct 2009 02:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.516 X-Spam-Level: X-Spam-Status: No, score=-0.516 tagged_above=-999 required=5 tests=[AWL=-1.140, BAYES_50=0.001, 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 GPmH4BIw7r8Z for ; Fri, 9 Oct 2009 02:37:01 -0700 (PDT) Received: from mail-gx0-f212.google.com (mail-gx0-f212.google.com [209.85.217.212]) by core3.amsl.com (Postfix) with ESMTP id 483443A672F for ; Fri, 9 Oct 2009 02:37:01 -0700 (PDT) Received: by gxk4 with SMTP id 4so7776269gxk.8 for ; Fri, 09 Oct 2009 02:38:42 -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=247dL5Cp1gkIM1/nllQekNg4aIbnwIluf9qmLLDVBbY=; b=H86KsNvs7Huvz0XYc5x+CB4Cm7Ih0SuLCCJis6UPvGmam5i0tJPIpHMLHnz7kO+/5/ zuad+UtqzrytVKnNyQEkpQDKumujX+voWyRR1YEWuH9EdwDYpj+l3iczoDJto1sxIDgV eXPy7e0sf4ukXO8Pk2Pfy0Hl8dB0VRasHrClY= 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=pyq49CZcGS+2ws+MwqTKtvd5andQbkMjAGMngfYxv2wL14x3F7QjiLIUIO9v6fHv+Y rKiXkZJkEHGJ5HrN91dO/6JNA8AZY/DhW+HpaXxz6wM2arQh8TgansamFyhnjE3G4BAf c3MFY3lioYqoEGbFXFraMixjrzEa5PMDcx4SI= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.91.102.6 with SMTP id e6mr1324123agm.99.1255081122169; Fri, 09 Oct 2009 02:38:42 -0700 (PDT) In-Reply-To: <002f01ca41c8$418c0340$c4a409c0$@nl> References: <002f01ca41c8$418c0340$c4a409c0$@nl> From: Emmanuel Baccelli Date: Fri, 9 Oct 2009 11:38:22 +0200 X-Google-Sender-Auth: 9f1675173ecfba18 Message-ID: To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=0016e645b7a073822404757d58de 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: Fri, 09 Oct 2009 09:37:03 -0000 --0016e645b7a073822404757d58de Content-Type: text/plain; charset=ISO-8859-1 Hi Teco, thanks for your feedback. Comments inline: On Wed, Sep 30, 2009 at 2:19 PM, Teco Boot wrote: > 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 disagree. The last months have shown that there is quite a lot to say about Link-Locals, and such considerations are summarized later on in the document, so it seems natural to me to reference it at this point. > 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. > > > OK. > > 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!!! > > I guess you are right, the point is not clearly expressed here. I think Thomas expressed it better in his last email: it's about not having any discrete on/off link event that would trigger DAD in our context, which is an issue with regards to traditional use of Link Locals. So how about saying: "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, without it being an explicit event that would trigger DAD again. Such duplication would thus go undetected." > 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. > > > I agree. I also think the goal of autoconf is to have unique interface IDs within the routing domain at least (as stated in section 6). > > > 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. > > > I personally agree with mentionning the fact that "the use of Link Locals limits the connectivity between routers" in our context. It's an elegant way of saying things ;) Now it may be OK in some special case to use a Link Local address, even if they suffer from these limitations. One trivial example is: for testing purposes, when a human operator is right next to the router, why not use a LL to communicate with the router? But for a more general applicability, including all the routing protocols we have to accomodate, LLs are not suitable -- I see we agree on that. And that's why the conclusion is: AUTOCONF should focus on configuring other types of addresses. Now let's move on! Cheers Emmanuel > > 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 > > > --0016e645b7a073822404757d58de Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Teco,

thanks for your feedback. Comments inline:


On Wed, Sep 30, 2009 at 2:19 PM, T= eco Boot <teco@inf-= net.nl> wrote:
Hi Emmanuel,

Here some (not retired :-) comments.


> 4. =A0IP Subnet Prefix Configuration
>
> =A0 If the link to which an interface connects enables no assumptions = of
> =A0 connectivity to other interfaces, the only addresses which can be<= br> > =A0 assumed "on link", are the address(es) of that interface= itself.
> =A0 Note that while IPv6 link-local addresses are assumed to be "= on
> =A0 link", the utility of IPv6 link-local addresses is limited as=
> =A0 specified in Section 6.2.

I posted earlier that adding the link-local topic is not needed.


I disagree. The last months have s= hown that there is quite a lot to say about Link-Locals, and such considera= tions are summarized later on in the document, so it seems natural to me to= reference it at this point.


=A0
I suggested the text could be changed in:

=A0 If the link to which an interface connects enables no assumptions of =A0 connectivity to other interfaces, the only addresses which can be
=A0 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.
=A0

On 6.2 IPv6 Model:

I am fine with:
> =A0 Note that while an IPv6 link-local address is assigned to each
> =A0 interface as per [RFC4291], in general link-local addresses are of=
> =A0 limited utility on links with undetermined connectivity, as neighb= ors
> =A0 may be constantly moving in and out of reachability. =A0The known<= br> > =A0 limitations are:
=A0<skip>
> =A0 Therefore MANET autoconfiguration solutions will primarily focus o= n
> =A0 configuring IP addresses that are not IPv6 link-local.



OK.
=A0

But I think the left out "known limitations" shall be verified fo= r
correctness and not being "opinions".

> =A0 o =A0Even if tested for local uniqueness at one moment using Dupli= cate
> =A0 =A0 =A0Address Detection [RFC4862], a duplicate link-local address= might
> =A0 =A0 =A0appear as a neighbor the next moment and DAD would not dete= ct
> =A0 =A0 =A0that.

This is very true for all unicast address types. Link-local is no exception=
at all!!!


I guess you are right, the point is no= t clearly expressed here. I think Thomas expressed it better in his last em= ail: it's about not having any discrete on/off link event that would tr= igger DAD in our context, which is an issue with regards to=A0traditional u= se of Link Locals. So how about saying:


"Even if tested for local uniquenes= s at one moment using Duplicate=A0Address Detection [RFC4862], a duplicate = link-local address might=A0appear as a neighbor the next moment,=A0without = it being an explicit event that would trigger DAD again. Such duplication w= ould thus go undetected."


=A0
To rephrase Charlie P. his comment on my recent posting:
>I think we ought, generally speaking, to try to avoid (ii) at this poin= t
>in the discussion.
(ii is DAD)


> =A0 o =A0There is no mechanism to ensure that IPv6 link-local addresse= s are
> =A0 =A0 =A0unique across multiple links, hence they can not be used to=
> =A0 =A0 =A0reliably 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.<= br>


I agree. I also think the goal of auto= conf is to have unique interface IDs within the routing domain at least (as= stated in section 6).

=A0

> =A0 o =A0Routers cannot forward any packets with link-local source or<= br> > =A0 =A0 =A0destination addresses to other links (as per [RFC4291]) whi= le most
> =A0 =A0 =A0of the time, routers need to be able to forward packets to/= from
> =A0 =A0 =A0different links.

This is very true. True in every IPv6 network. I don't see a reason to<= br> 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 forwa= rd 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 limi= tation 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:

=A0Routers cannot forward any packets with link-local source or
=A0destination addresses to other links (as per [RFC4291]). In general, =A0routers do not forward such packets. This would limit connectivity
=A0between MANET nodes. For this reason, link-local addresses shall be
=A0used only for protocols that require one-hop limited delivery of packet= s.


The complete text added in 6.2 would be:

=A0 Note that while an IPv6 link-local address is assigned to each
=A0 interface as per [RFC4291], in general link-local addresses are of
=A0 limited utility on links with undetermined connectivity, as neighbors<= br> =A0 may be constantly moving in and out of reachability.

=A0 Routers cannot forward any packets with link-local source or
=A0 destination addresses to other links (as per [RFC4291]). In general, =A0 routers do not forward such packets. This would limit connectivity
=A0 between MANET nodes. For this reason, link-local addresses shall be =A0 used only for protocols that require one-hop limited delivery of packe= ts.

=A0 MANET autoconfiguration solutions will primarily focus on
=A0 configuring IP addresses that are not IPv6 link-local.

I hope everybody can agree on this text.




I personally agree with= mentionning the fact that "the use of Link Locals limits the connecti= vity between routers" in our context. It's an elegant way of sayin= g things ;) Now it may be OK in some special case to use a Link Local addre= ss, even if they suffer from these limitations. One trivial example is: for= testing purposes, when a human operator is right next to the router, why n= ot use a LL to communicate with the router? But for a more general applicab= ility, including all the routing protocols we have to accomodate, LLs are n= ot suitable -- I see we agree on that. And that's why the conclusion is= : AUTOCONF should focus on configuring other=A0types=A0of=A0addresses. Now = let's move on!

Cheers
Emmanuel

=A0<= /div>

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-ad= hoc-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 Hirosh= ima!

Cheers,

Emmanuel


On Thu, Sep 24, 2009 at 1:38 PM, Emmanuel Baccelli
<Emmanuel.Baccelli@inria.f= r> 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-ad= hoc-addr-model-02.txt

Please review it thouroughly, and give us some feedback.

Regards,

Emmanuel



--0016e645b7a073822404757d58de-- From emmanuel.baccelli@gmail.com Fri Oct 9 02:52:44 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 55FB128C0E3 for ; Fri, 9 Oct 2009 02:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.721 X-Spam-Level: X-Spam-Status: No, score=-1.721 tagged_above=-999 required=5 tests=[AWL=0.255, 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 CwbktUePYzzZ for ; Fri, 9 Oct 2009 02:52:42 -0700 (PDT) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 713A93A67AA for ; Fri, 9 Oct 2009 02:52:42 -0700 (PDT) Received: by yxe30 with SMTP id 30so9458653yxe.29 for ; Fri, 09 Oct 2009 02:54:26 -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=Bdu8MioMzN8HT7ZLEHukTW1ryhV0xZQ6aM2enNVcsPQ=; b=etn8cNCznxCfTrMg8vrWkeNDYmEWaG6V790aK0xT4rIpEbEPZgLAtRLjpx8J2DcD/j t0xboUy1luZRelqKPbbxsu45p8AS13GLEmV8Yka8+FYLF3cMAJRTuPtZFR+1EPnvJ/u0 PfZ7/m9BDFq5vPX3jvN5uIxHM5lco1RohOk+o= 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=uvdyjC4Xw64tUh8AY3SVR4gUUF6e0/MCVMSZjKrIUDeR0Xk+IjIMGs34igt+wfNT0P DHCEp/pdrWKFGnQ7gNgSKq8Z9BrXeUuUf4h86SED8FmS3BEWYB8UDAe/flCuzij2nccZ a6Y0dXsoLE2WaCOJWgPlTDYrAyueYSMv9jHp8= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.91.28.9 with SMTP id f9mr1293515agj.89.1255082066171; Fri, 09 Oct 2009 02:54:26 -0700 (PDT) In-Reply-To: <587654C4-E358-48A5-8C24-DFDB786E9793@thomasclausen.org> References: <587654C4-E358-48A5-8C24-DFDB786E9793@thomasclausen.org> From: Emmanuel Baccelli Date: Fri, 9 Oct 2009 11:54:06 +0200 X-Google-Sender-Auth: 72891fa986a74d40 Message-ID: To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=001485f8975eb7d7f604757d90b5 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: Fri, 09 Oct 2009 09:52:44 -0000 --001485f8975eb7d7f604757d90b5 Content-Type: text/plain; charset=ISO-8859-1 Hi Thomas, thanks for the detailed comments. See inline: On Fri, Oct 9, 2009 at 8:17 AM, Thomas Heide Clausen < thomas@thomasclausen.org> wrote: > Emmanuel, Mark, all, > On Sep 29, 2009, at 5:42 PM, Emmanuel Baccelli wrote: > > 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 ;) > > > Uhh, that's a threat. I wouldn't want to be taken as being silently > agreeing (or disagreeing) with anything. > > > I'm happy my ultimatum worked. I may use it again ;) > Speaking without any hats (specifically, I do not speak as chair in this > email), and simply as someone building MANETs, hereby my comments to this > document. > > Overall: > ======= > > I think that the document is in a decent shape and reflects the WG > discussions > and the issues that have been brought up thus far. I would therefore be > supportive (as WG participant) of accepting this document as WG document. > > Great. > Also, I have some detailed comments, which I would be happy to see > addressed > (but whose address would not be a prerequisite for my support of this > document as > WG document). > > Details: > ======== > > o The title of the document contains "Ad Hoc Networks", but nowhere does > it say > "Ad Hoc Networks" inside the document. This is rather odd. I would suggest > that > it be said somewhere (e.g. in the applicability statement or > introduction?) that: > + an "Ad Hoc Network" is a typical example of a network with > "undetermined connectivity"; where > > + MANET routing protocols have as their raison d'etre to "determine > network-wide connectivity"; but that to do so > > + MANET protocols require the interfaces to be configured with IP > addresses > > The latter of these is already said in the Introduction. I would suggest > that saying > the two others would make it clear what this document is about. Note that > the second > point above is critical in that the goal is not to "hide" (or "fake out", > in Townsley- > terminology) the undetermined connectivity properties, but rather that > there are routing > protocols in existence in the IETF that are conceived explicitly to > handle these > properties. > Agreed. It makes sense to mention this explicitely at this point. > > o The introduction is a little murky with respect to > links/topology/assumptions/ > configurations. In my world-view: > > + the network topology *is* -- is an undisputed fact. > + we may know something about this, or we may not. I.e. given a network, > we > may make use this knowledge to make assumptions about the properties of > that network. > > + those assumptions we use to *reflect* the topology in the network > *configuration*. > > So I would suggest that the second paragraph of the introduction be > revisited with > this in mind. As it is, it appears a little roundabout, that the network > topology is > "designed" by the configuration (I realize that this to some extend also > is true, but > I do not think that this is the message in this paragraph?) > > OK. We will revise this paragraph. I think there is indeed a way to make this point clearer. > o Section 3: > > + should we say in paragraph 1 that we're concerned with IP routers and > their > IP interfaces, to stamp out any ambiguity on L2 "routing"? > > + should we say "between interfaces" rather than "to other interfaces on > the link" > in the second paragraph, to not be caught in the "what is a link" issue > again? > > OK. Sounds good to me. > o Section 4: > + First paragraph top of page 4, use "described in section 6.2" rather > than > "specified in section 6.2" > > + Insert "direct" between "As" and "communication" in penultimate > paragraph. > > + Alsp penultimate paragraph, any way to get rid of "on that link"? I was > playing around with "between which L2 communication is enabled" as an > alternative. It avoids the issue that Thaler brought up of "IP Link" and > "Data Link". > > + Previous bullet applies in the ultimate paragraph of section 4 as well. > Doable too. I also think it is important to be clear that we are talking about L2 connectivity here. > > o Section 4 + 5, both: > > + I suggest replacing "This translates in the following policy" by > "This translate into the following principle" -- in part because > "principle" > is the term used for referencing these later > > + The "principles", I would make into bullet-points in order to make them > stand > out and be easy to see among the text. > > OK. > o Section 5: > > + First paragraph last sentence after the comma, suggest: > > "....., to uniqueness within, at least, the routing domain". > > > > o Section 6.1: > > + Penultimate bullet, suggest replacing the comma before and by a > semicolon > + Ultimate bullet, suggest replacing "A subnet" by "Any subnet" > > o Section 6.2: > > + Same considerations as in 6.1 for the first two bullet points. > > + First paragraph after the two first bulletpoints, suggest: > > "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: connectivity > to neighbors may be constantly changing. The known > limitations are:" > > Reason: the original text talk about "mobility" ("moving in and out of > reachability"), which is rather specific to one given type of interface. > Logially, what matters is that being a neighbor at one given time > does not guarantee that one is neighbor in the future, nor that such > a change is detectable (to trigger reconfiguration). > > + First bullet point in last block of bullets, suggest (for the same > reasons as > above): > > "Even if tested for local uniqueness at one given time and using > Duplicate Address Detection (DAD) [RFC4862], a duplicate > link-local address might appear as a neighbor at any time thereafter. > Without an explicit event that would trigger DAD, such duplication > would go undetected". > > Agreed. See my email to Teco about this. I think you pinpoint right. We have to mention the lack on on/off events which is the main difference here. > + Ultimate paragraph in 6.2 reads more like a "problem statement". > Suggest rephrasing to conclude that LLs are difficult to use in a > coherent > way under the conditions that this document present, and suggest that > therefore non-LLs are encouraged [in part, because as this is not a WG > document yet, it doesn't really reflect any official WG position on the > matter...yet]. > > Right. I guess the "will" in this paragraph is probably a little too violent. It should be a "should" ;) or replaced by a "recommendation" at this point. > I'll conclude by expressing satisfaction that what is described in this > document is compatible with the way I build MANETs -- or rather, that the > configuration of the MANETs, which I am aware of, conforms to the principles > laid out in this document. > OK! Regards, Emmanuel --001485f8975eb7d7f604757d90b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Thomas,

thanks for the detailed comments. See inline:=


On Fri, Oct 9, 2009 at 8:17 A= M, Thomas Heide Clausen <thomas@thomasclausen.org> wrote:
Emmanue= l, Mark, all,

On Sep 29, 200= 9, at 5:42 PM, Emmanuel Baccelli wrote:

Hi all,

Please do let us know your fee= dback 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 ;)

Uhh, that's a threat. I wouldn&= #39;t want to be taken as being silently agreeing (or disagreeing) with any= thing.




I'm happy my ultimatum worked. I may use it again = ;)

=A0
Speaking with= out any hats (specifically, I do not speak as chair in this email), and sim= ply as someone building MANETs, hereby my comments to this document.

Overall:
=3D=3D=3D=3D=3D=3D=3D

=
I think that the documen= t is in a decent shape and reflects the WG discussions
and the issues that have been brought up thus= far. I would therefore be
supportive (as WG participant)= of accepting this document as WG document.




Great= .=A0



=A0
Also, I have some detailed comments= , which I would be happy to see addressed
(but whose address would not b= e a prerequisite for my support of this document as
WG document).

Details= :
=3D=3D=3D=3D=3D=3D=3D=3D

o The title of t= he document contains "Ad Hoc Networks", but nowhere does it say
"Ad Hoc Networks&quo= t; inside the document. This is rather odd. I would suggest that
it be said somewhere (e.g. in= the applicability statement or introduction?) that:=A0
= + an "Ad Hoc Network&q= uot; is a typical example of a network with=A0
"undetermined=A0connect= ivity"; where

+ MANET routing protocols = have as their raison d'etre to "determine
network-wide connectivity&qu= ot;; but that to do so

+ MANET protocols requ= ire the interfaces to be configured with IP addresses

The latter of = these is already said in the Introduction. I would suggest that saying
the two others would make it= clear what this document is about. Note that the second
point above is critical in th= at the goal is not to "hide" (or "fake out", in Townsle= y-
terminology)=A0the un= determined connectivity=A0properties, but rather that there are routing=A0<= /div>
protocols in existence in the= IETF that are conceived=A0explicitly to handle these=A0
properties.


Agreed. It makes sense to mention this e= xplicitely at this point.

=A0

o The= introduction is a little murky with respect to links/topology/assumptions/=
configurations. In my world-v= iew:

+ the network topology *is* -- is an und= isputed fact.
+ we may know = something about this, or we may not. I.e. given a network, we
may make use this knowledge to make = assumptions about the properties of
that network.

=
+ those assumptions we use to *reflect* the topology in the= network=A0
*configuration*.
<= br>
So I would suggest t= hat the second paragraph of the introduction be revisited with=A0
this in mind. As it is, it appears= a little roundabout, that the network topology is=A0
"designed" by the c= onfiguration (I realize that this to some extend also is true, but
I do not think that this is the = message in this paragraph?)




OK. We will revise this paragraph. I think there is in= deed a way to make this point clearer.

=A0
o Section 3:

+ should we say in paragraph 1 that we're co= ncerned with IP routers and their
IP interfaces, to stamp out any ambiguity on L2 "routing&qu= ot;?

+ should we say "between interfaces" r= ather than "to other interfaces on the link"
in the second paragraph, to not be caught i= n the "what is a link" issue again?



OK. Sounds good to me.

=A0
o Secti= on 4:
+ = First paragraph top of page 4, use "described in section 6.2" rat= her than=A0
"specified in section 6= .2"

= + Insert "direct" between = "As" and "communication" in penultimate paragraph.

+ Alsp penultimate paragraph, any way to get rid= of "on that link"? I was=A0
playing around with "between which L2 communication is= enabled" as an
alternative. It avoids the i= ssue that Thaler brought up of "IP Link" and=A0
"Data Link".

+ Previous bullet applies in the ultimate paragraph of section 4 = as well.



Doable too. I also think it is important to be clear th= at we are talking about L2 connectivity here.

=A0<= /div>

o Sec= tion 4 + 5, both:

= + I suggest replacing "= ;This translates in the following policy" by
"This translate into th= e following principle" -- in part because "principle"
<= div> is the term used for referenc= ing these later

+ The "principles", I would make into = bullet-points in order to make them stand
out and be easy to see among the text.



OK.

=A0
o Section 5:

+ Fir= st paragraph last sentence after the comma, suggest:

".....,= to uniqueness within, at least, the routing domain".


=A0

o Section 6.1:

= + Penultimate bullet, suggest= replacing the comma before and by a semicolon
+ Ultimate bullet, suggest replacing "A sub= net" by "Any subnet"

o Section 6.2:

+ Same= considerations as in 6.1 for the first two bullet points.

+ First paragraph after the two first bulletpoin= ts, suggest:

=A0=A0 "Note that while an IPv6 link-local= address is assigned to each
=A0=A0 =A0interface as per [= RFC4291], in general link-local addresses are of
=A0=A0 =A0limited utility on links with und= etermined connectivity: connectivity
=A0=A0 =A0to=A0neighbors=A0m= ay be constantly changing. =A0The known
=A0=A0 =A0limitations are:"

= Reason: the original text talk ab= out "mobility" ("moving in and out of
reachability"), which i= s rather specific to one given type of interface.=A0
Logially, what matters is that being a neigh= bor at one given time=A0
does not guarantee that one = is neighbor in the future, nor that such
a change is detectable (to trigger reconfiguration).

+ First bullet point in last block of bullets, s= uggest (for the same reasons as=A0
above):

=A0=A0 "Even if tested for local uniqueness at one given time and using=A0
=A0 =A0Duplicate=A0Address Detection (DAD) [RFC4862], a dup= licate=A0
=A0link-local address migh= t=A0appear as a neighbor at any time thereafter.
=A0Without an explicit event that would trigger= DAD, such duplication
=A0would go undetected&quo= t;.



Agreed. See my email to Teco about this. I think you p= inpoint right. We have to mention the lack on on/off events which is the ma= in difference here.


=A0
+ = Ultimate paragraph in 6.2 reads more like a "problem statement".= =A0
Suggest rephrasing to conclu= de that LLs are difficult to use in a coherent
way under the conditions that this document present= , and suggest that=A0
therefore non-LLs are encour= aged [in part, because as this is not a WG=A0
document yet, it doesn't really reflect any offi= cial WG position on the=A0
matter...yet].

Right. I gu= ess the "will" in this paragraph is probably a little too violent= . It should be a "should" ;) or replaced by a "recommendatio= n" at this point.


=A0
I'l= l conclude by expressing satisfaction that what is described in this docume= nt is compatible with the way I build MANETs -- or rather, that the configu= ration of the MANETs, which I am aware of, conforms to the principles laid = out in this document.


OK!=

Regards,

Emmanuel
<= div>
--001485f8975eb7d7f604757d90b5-- From teco@inf-net.nl Fri Oct 9 03:15:44 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 1D1AB3A67B8 for ; Fri, 9 Oct 2009 03:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.669 X-Spam-Level: X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[AWL=-0.670, 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 HRCsm4QGGKys for ; Fri, 9 Oct 2009 03:15:42 -0700 (PDT) Received: from CPSMTPM-EML108.kpnxchange.com (Cpsmtpm-eml108.kpnxchange.com [195.121.3.12]) by core3.amsl.com (Postfix) with ESMTP id 2F02E3A679F for ; Fri, 9 Oct 2009 03:15:41 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML108.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Fri, 9 Oct 2009 12:17:25 +0200 From: "Teco Boot" To: "'Emmanuel Baccelli'" , References: <002f01ca41c8$418c0340$c4a409c0$@nl> In-Reply-To: Date: Fri, 9 Oct 2009 12:17:20 +0200 Message-ID: <00d801ca48c9$af8ed400$0eac7c00$@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: AcpIxFA23tsmODvhTvWSu2sikXjIcQAANmwQ Content-Language: nl X-OriginalArrivalTime: 09 Oct 2009 10:17:25.0118 (UTC) FILETIME=[B25769E0:01CA48C9] 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: Fri, 09 Oct 2009 10:15:44 -0000 Hi Emmanuel, I'll tag my comments, for better readability. Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens Emmanuel Baccelli Verzonden: vrijdag 9 oktober 2009 11:38 Aan: autoconf@ietf.org Onderwerp: Re: [Autoconf] updated MANET addressing model draft Hi Teco, thanks for your feedback. Comments inline: On Wed, Sep 30, 2009 at 2:19 PM, Teco Boot wrote: Hi Emmanuel, Here some (not retired :-) comments. > 4. =A0IP Subnet Prefix Configuration > > =A0 If the link to which an interface connects enables no assumptions = of > =A0 connectivity to other interfaces, the only addresses which can be > =A0 assumed "on link", are the address(es) of that interface itself. > =A0 Note that while IPv6 link-local addresses are assumed to be "on > =A0 link", the utility of IPv6 link-local addresses is limited as > =A0 specified in Section 6.2. I posted earlier that adding the link-local topic is not needed. I disagree. The last months have shown that there is quite a lot to say about Link-Locals, and such considerations are summarized later on in = the document, so it seems natural to me to reference it at this point. Please explain why LLs have to do with IP Subnet Prefix Configuration. I suggested the text could be changed in: =A0 If the link to which an interface connects enables no assumptions of =A0 connectivity to other interfaces, the only addresses which can be =A0 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. =A0 On 6.2 IPv6 Model: I am fine with: > =A0 Note that while an IPv6 link-local address is assigned to each > =A0 interface as per [RFC4291], in general link-local addresses are of > =A0 limited utility on links with undetermined connectivity, as = neighbors > =A0 may be constantly moving in and out of reachability. =A0The known > =A0 limitations are: =A0 > =A0 Therefore MANET autoconfiguration solutions will primarily focus = on > =A0 configuring IP addresses that are not IPv6 link-local. OK. =A0 But I think the left out "known limitations" shall be verified for correctness and not being "opinions". > =A0 o =A0Even if tested for local uniqueness at one moment using = Duplicate > =A0 =A0 =A0Address Detection [RFC4862], a duplicate link-local address = might > =A0 =A0 =A0appear as a neighbor the next moment and DAD would not = detect > =A0 =A0 =A0that. This is very true for all unicast address types. Link-local is no = exception at all!!! I guess you are right, the point is not clearly expressed here. I think Thomas expressed it better in his last email: it's about not having any discrete on/off link event that would trigger DAD in our context, which = is an issue with regards to=A0traditional use of Link Locals.=20 Again, this is applicable to all types of addresses. So how about saying: "Even if tested for local uniqueness at one moment using = Duplicate=A0Address Detection [RFC4862], a duplicate link-local address might=A0appear as a neighbor the next moment,=A0without it being an explicit event that = would trigger DAD again. Such duplication would thus go undetected." Again, this is applicable to all types of addresses. =A0 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) > =A0 o =A0There is no mechanism to ensure that IPv6 link-local = addresses are > =A0 =A0 =A0unique across multiple links, hence they can not be used to > =A0 =A0 =A0reliably 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. I agree. I also think the goal of autoconf is to have unique interface = IDs within the routing domain at least (as stated in section 6). We could have found some common ground here.=20 This would be a break-through:-)=20 Is this something to include in the document, section 6.2? Discuss / get consensus @ next IETF? By the way, the goal having unique interface IDs is nothing new. It is related by a long list of proposals, inspired by 8+8/GSE. =A0 > =A0 o =A0Routers cannot forward any packets with link-local source or > =A0 =A0 =A0destination addresses to other links (as per [RFC4291]) = while most > =A0 =A0 =A0of the time, routers need to be able to forward packets = to/from > =A0 =A0 =A0different 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: =A0Routers cannot forward any packets with link-local source or =A0destination addresses to other links (as per [RFC4291]). In general, =A0routers do not forward such packets. This would limit connectivity =A0between MANET nodes. For this reason, link-local addresses shall be =A0used only for protocols that require one-hop limited delivery of = packets. The complete text added in 6.2 would be: =A0 Note that while an IPv6 link-local address is assigned to each =A0 interface as per [RFC4291], in general link-local addresses are of =A0 limited utility on links with undetermined connectivity, as = neighbors =A0 may be constantly moving in and out of reachability. =A0 Routers cannot forward any packets with link-local source or =A0 destination addresses to other links (as per [RFC4291]). In general, =A0 routers do not forward such packets. This would limit connectivity =A0 between MANET nodes. For this reason, link-local addresses shall be =A0 used only for protocols that require one-hop limited delivery of = packets. =A0 MANET autoconfiguration solutions will primarily focus on =A0 configuring IP addresses that are not IPv6 link-local. I hope everybody can agree on this text. I personally agree with mentionning the fact that "the use of Link = Locals limits the connectivity between routers" in our context. It's an elegant = way of saying things ;) Now it may be OK in some special case to use a Link Local address, even if they suffer from these limitations. One trivial example is: for testing purposes, when a human operator is right next to = the router, why not use a LL to communicate with the router? But for a more general applicability, including all the routing protocols we have to accomodate, LLs are not suitable -- I see we agree on that. And that's = why the conclusion is: AUTOCONF should focus on configuring other=A0types=A0of=A0addresses. Now let's move on! We can speed up by not arguing on why we focus on configuring other = types of addresses. Please stay away from a need for routing protocols on not using LLs. We definitely need the non-LLs for user applications. No one disputes = this. I read the posting from Thomas C., especially on this one: >>> MANET protocols require the interfaces to be=20 >>> configured with IP addresses I can't understand why we focus so much on the MANET routing protocols. The MANETs I am working with have real users. For them, it is totally Irrelevant what the MANET protocol IP addresses are. As long as = applications work fine, also in the MANET, they are fine. There is a problem here, I cannot connect the MANETs to The Internet=20 dynamically with IETF protocols available today. I could use NAPT,=20 but we IETF really want to kick this out. We need a solution for connecting our MANETs to the Internet. Regards, Teco =20 Cheers Emmanuel =A0 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 emmanuel.baccelli@gmail.com Fri Oct 9 04:05:04 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 3914A28C0ED for ; Fri, 9 Oct 2009 04:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.741 X-Spam-Level: X-Spam-Status: No, score=-1.741 tagged_above=-999 required=5 tests=[AWL=0.235, 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 cx-HYEWt6JQJ for ; Fri, 9 Oct 2009 04:05:02 -0700 (PDT) Received: from mail-gx0-f212.google.com (mail-gx0-f212.google.com [209.85.217.212]) by core3.amsl.com (Postfix) with ESMTP id 092603A682A for ; Fri, 9 Oct 2009 04:05:01 -0700 (PDT) Received: by gxk4 with SMTP id 4so7822110gxk.8 for ; Fri, 09 Oct 2009 04:06:43 -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=FZLOvL/KPxVsQ9L7Ie+uKTyBiBwDYOkfa8kBMwpdx/Y=; b=CCOAmS2PXR7y48z4hqh+/jtY/80i+uAnK+7Eo9nPmE8f8TKWqjDS5K/E6RMyOeovM9 Aibf8vBoxqTFW2ECDCTfyT8jkNNy88QA8o48aOOwqv7YYDJVl5/hh1IljRxxK9XatWBF NnxotXq8bqp8qYS4dzB4ooiECe/O+x2O8xZks= 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=KVPuCiVAk3o3hnhnyqSPXvdB1UVderuWKyxbcjdawhH1H9rQJyrv69kNzto7je3KCT n9xav/OPcCOj8zVd0yN4xZ4NpkSMvbcNomzn1L1Rv4DWs+wl1KJR3ioO/n3igcPBlxpO nenMPhQMSQVjbWBrFCqCRR3haKKel8f4wzzbk= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.91.28.2 with SMTP id f2mr1393728agj.16.1255086402214; Fri, 09 Oct 2009 04:06:42 -0700 (PDT) In-Reply-To: <00d801ca48c9$af8ed400$0eac7c00$@nl> References: <002f01ca41c8$418c0340$c4a409c0$@nl> <00d801ca48c9$af8ed400$0eac7c00$@nl> From: Emmanuel Baccelli Date: Fri, 9 Oct 2009 13:06:22 +0200 X-Google-Sender-Auth: 2189e115972d4d78 Message-ID: To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=001485f5ea782a9b2404757e930f 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: Fri, 09 Oct 2009 11:05:04 -0000 --001485f5ea782a9b2404757e930f Content-Type: text/plain; charset=ISO-8859-1 Hi Teco, inline: On Fri, Oct 9, 2009 at 12:17 PM, Teco Boot wrote: > Hi Emmanuel, > > I'll tag my comments, for better readability. > > > > Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens > Emmanuel Baccelli > Verzonden: vrijdag 9 oktober 2009 11:38 > Aan: autoconf@ietf.org > Onderwerp: Re: [Autoconf] updated MANET addressing model draft > > Hi Teco, > > thanks for your feedback. Comments inline: > > On Wed, Sep 30, 2009 at 2:19 PM, Teco Boot wrote: > 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 disagree. The last months have shown that there is quite a lot to say > about Link-Locals, and such considerations are summarized later on in the > document, so it seems natural to me to reference it at this point. > > > Please explain why LLs have to do with IP Subnet Prefix Configuration. > > > EB: Can I answer with a cryptic fe80:: ? > > 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. > > > OK. > > > 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!!! > > I guess you are right, the point is not clearly expressed here. I think > Thomas expressed it better in his last email: it's about not having any > discrete on/off link event that would trigger DAD in our context, which is > an issue with regards to traditional use of Link Locals. > > > Again, this is applicable to all types of addresses. > > > EB: I disagree: link local addresses are supposed to be managed with DAD (RFC4862) which deals with link local signalling only and that relies on on/off link events. So we have an issue with link-locals. For other types of addresses, different signalling is at work, that is not limited to the link, and that can work without on/off link events. > > So how about saying: > > "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, without it being an explicit event that would > trigger DAD again. Such duplication would thus go undetected." > > > Again, this is applicable to all types of addresses. > > > > 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. > > > I agree. I also think the goal of autoconf is to have unique interface IDs > within the routing domain at least (as stated in section 6). > > > We could have found some common ground here. > This would be a break-through:-) > > Is this something to include in the document, section 6.2? > Discuss / get consensus @ next IETF? > > By the way, the goal having unique interface IDs is nothing new. > It is related by a long list of proposals, inspired by 8+8/GSE. > > > EB: The document already says that the interfaces addresses should be unique within the routing domain at least so that's fine as it is. I guess we've been violently agreeing all this time then ;) > > > 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. > > > > I personally agree with mentionning the fact that "the use of Link Locals > limits the connectivity between routers" in our context. It's an elegant > way > of saying things ;) Now it may be OK in some special case to use a Link > Local address, even if they suffer from these limitations. One trivial > example is: for testing purposes, when a human operator is right next to > the > router, why not use a LL to communicate with the router? But for a more > general applicability, including all the routing protocols we have to > accomodate, LLs are not suitable -- I see we agree on that. And that's why > the conclusion is: AUTOCONF should focus on configuring > other types of addresses. Now let's move on! > > > > We can speed up by not arguing on why we focus on configuring other types > of addresses. > Please stay away from a need for routing protocols on not using LLs. > We definitely need the non-LLs for user applications. No one disputes this. > > I read the posting from Thomas C., especially on this one: > >>> MANET protocols require the interfaces to be > >>> configured with IP addresses > > I can't understand why we focus so much on the MANET routing protocols. > The MANETs I am working with have real users. For them, it is totally > Irrelevant what the MANET protocol IP addresses are. As long as > applications > work fine, also in the MANET, they are fine. > There is a problem here, I cannot connect the MANETs to The Internet > dynamically with IETF protocols available today. I could use NAPT, > but we IETF really want to kick this out. > We need a solution for connecting our MANETs to the Internet. > > EB: We agree on this goal ;) For this we need routing protocols which work on MANETs. This document describes a model that works for ALL the current IETF protocols that work on MANETs, so everything's fine. Regards Emmanuel --001485f5ea782a9b2404757e930f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Teco,

inline:
=

On Fri, Oct 9, 2009 at 12:17 P= M, Teco Boot <teco@= inf-net.nl> wrote:
Hi Emmanuel,

I'll tag my comments, for better readability.



Van: autoconf-bounces@ietf.org= [mailto:autoconf-bounces@= ietf.org] Namens
Emmanuel Baccelli
Verzonden: vrijdag 9 oktober 2009 11:38
Aan: autoconf@ietf.o= rg
Onderwerp: Re: [Autoconf] updated MANET addressing model draft

Hi Teco,

thanks for your feedback. Comments inline:

On Wed, Sep 30, 2009 at 2:19 PM, Teco Boot <teco@inf-net.nl> wrote:
Hi Emmanuel,

Here some (not retired :-) comments.


> 4. =A0IP Subnet Prefix Configuration
>
> =A0 If the link to which an interface connects enables no assumptions = of
> =A0 connectivity to other interfaces, the only addresses which can be<= br> > =A0 assumed "on link", are the address(es) of that interface= itself.
> =A0 Note that while IPv6 link-local addresses are assumed to be "= on
> =A0 link", the utility of IPv6 link-local addresses is limited as=
> =A0 specified in Section 6.2.

I posted earlier that adding the link-local topic is not needed.


I disagree. The last months have shown that there is quite a lot to say
about Link-Locals, and such considerations are summarized later on in the document, so it seems natural to me to reference it at this point.

<Teco>
Please explain why LLs have to do with IP Subnet Prefix Configuration.
</Teco>


EB: Can I answer with a cryptic=A0fe80:: ?

=A0

I suggested the text could be changed in:

=A0 If the link to which an interface connects enables no assumptions of =A0 connectivity to other interfaces, the only addresses which can be
=A0 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.
=A0

On 6.2 IPv6 Model:

I am fine with:
> =A0 Note that while an IPv6 link-local address is assigned to each
> =A0 interface as per [RFC4291], in general link-local addresses are of=
> =A0 limited utility on links with undetermined connectivity, as neighb= ors
> =A0 may be constantly moving in and out of reachability. =A0The known<= br> > =A0 limitations are:
=A0<skip>
> =A0 Therefore MANET autoconfiguration solutions will primarily focus o= n
> =A0 configuring IP addresses that are not IPv6 link-local.


OK.
=A0

But I think the left out "known limitations" shall be verified fo= r
correctness and not being "opinions".

> =A0 o =A0Even if tested for local uniqueness at one moment using Dupli= cate
> =A0 =A0 =A0Address Detection [RFC4862], a duplicate link-local address= might
> =A0 =A0 =A0appear as a neighbor the next moment and DAD would not dete= ct
> =A0 =A0 =A0that.

This is very true for all unicast address types. Link-local is no exception=
at all!!!

I guess you are right, the point is not clearly expressed here. I think
Thomas expressed it better in his last email: it's about not having any=
discrete on/off link event that would trigger DAD in our context, which is<= br> an issue with regards to=A0traditional use of Link Locals.

<Teco>
Again, this is applicable to all types of addresses.
</Teco>



EB:=A0I disagree: link local addresses are supposed to be managed with=A0D= AD=A0(RFC4862) which deals with link local signalling only and that relies = on on/off link events. So we have an issue with link-locals. For other type= s of addresses, different=A0signalling is at work, that is not limited to the link, and= that can work without on/off link events.


=A0

So how about saying:

"Even if tested for local uniqueness at one moment using Duplicate=A0A= ddress
Detection [RFC4862], a duplicate link-local address might=A0appear as a
neighbor the next moment,=A0without it being an explicit event that would trigger DAD again. Such duplication would thus go undetected."

<Teco>
Again, this is applicable to all types of addresses.
</Teco>

=A0
To rephrase Charlie P. his comment on my recent posting:
>I think we ought, generally speaking, to try to avoid (ii) at this poin= t
>in the discussion.
(ii is DAD)


> =A0 o =A0There is no mechanism to ensure that IPv6 link-local addresse= s are
> =A0 =A0 =A0unique across multiple links, hence they can not be used to=
> =A0 =A0 =A0reliably 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.<= br>

I agree. I also think the goal of autoconf is to have unique interface IDs<= br> within the routing domain at least (as stated in section 6).

<Teco>
We could have found some common ground here.
This would be a break-through:-)

Is this something to include in the document, section 6.2?
Discuss / get consensus @ next IETF?

By the way, the goal having unique interface IDs is nothing new.
It is related by a long list of proposals, inspired by 8+8/GSE.
</Teco>=A0


EB:=A0The document already says that the interfaces addresses shoul= d be unique within the routing domain at least so that's fine as it is.= I guess we've been violently agreeing all this time then ;)

=A0

> =A0 o =A0Routers cannot forward any packets with link-local source or<= br> > =A0 =A0 =A0destination addresses to other links (as per [RFC4291]) whi= le most
> =A0 =A0 =A0of the time, routers need to be able to forward packets to/= from
> =A0 =A0 =A0different links.

This is very true. True in every IPv6 network. I don't see a reason to<= br> 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 forwa= rd 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 limi= tation 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:

=A0Routers cannot forward any packets with link-local source or
=A0destination addresses to other links (as per [RFC4291]). In general,
=A0routers do not forward such packets. This would limit connectivity
=A0between MANET nodes. For this reason, link-local addresses shall be
=A0used only for protocols that require one-hop limited delivery of packets= .


The complete text added in 6.2 would be:

=A0 Note that while an IPv6 link-local address is assigned to each
=A0 interface as per [RFC4291], in general link-local addresses are of
=A0 limited utility on links with undetermined connectivity, as neighbors =A0 may be constantly moving in and out of reachability.

=A0 Routers cannot forward any packets with link-local source or
=A0 destination addresses to other links (as per [RFC4291]). In general, =A0 routers do not forward such packets. This would limit connectivity
=A0 between MANET nodes. For this reason, link-local addresses shall be
=A0 used only for protocols that require one-hop limited delivery of packet= s.

=A0 MANET autoconfiguration solutions will primarily focus on
=A0 configuring IP addresses that are not IPv6 link-local.

I hope everybody can agree on this text.



I personally agree with mentionning the fact that "the use of Link Loc= als
limits the connectivity between routers" in our context. It's an e= legant way
of saying things ;) Now it may be OK in some special case to use a Link
Local address, even if they suffer from these limitations. One trivial
example is: for testing purposes, when a human operator is right next to th= e
router, why not use a LL to communicate with the router? But for a more
general applicability, including all the routing protocols we have to
accomodate, LLs are not suitable -- I see we agree on that. And that's = why
the conclusion is: AUTOCONF should focus on configuring
other=A0types=A0of=A0addresses. Now let's move on!

<Teco>

We can speed up by not arguing on why we focus on configuring other types of addresses.
Please stay away from a need for routing protocols on not using LLs.
We definitely need the non-LLs for user applications. No one disputes this.=

I read the posting from Thomas C., especially on this one:
>>> =A0MANET protocols require the interfaces to= be
>>> =A0configured with IP addresses

I can't understand why we focus so much on the MANET routing prot= ocols.
The MANETs I am working with have real users. For them, it is totally
Irrelevant what the MANET protocol IP addresses are. As long as application= s
work fine, also in the MANET, they are fine.
There is a problem here, I cannot connect the MANETs to The Internet
dynamically with IETF protocols available today. I could use NAPT,
but we IETF really want to kick this out.
We need a solution for connecting our MANETs to the Internet.


EB:=A0We agree on this goal ;) For thi= s we need routing protocols which work on MANETs. This document describes a= model that works for ALL the current IETF protocols that work on MANETs, s= o everything's fine.


Regards
Emmanuel
--001485f5ea782a9b2404757e930f-- From teco@inf-net.nl Fri Oct 9 04:57: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 D0C9528C0DB for ; Fri, 9 Oct 2009 04:57: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.662, 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 VsgKj8A5fDs1 for ; Fri, 9 Oct 2009 04:57:06 -0700 (PDT) Received: from CPSMTPM-EML107.kpnxchange.com (Cpsmtpm-eml107.kpnxchange.com [195.121.3.11]) by core3.amsl.com (Postfix) with ESMTP id 513C83A6891 for ; Fri, 9 Oct 2009 04:57:04 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML107.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Fri, 9 Oct 2009 13:58:47 +0200 From: "Teco Boot" To: "'Emmanuel Baccelli'" , References: <002f01ca41c8$418c0340$c4a409c0$@nl> <00d801ca48c9$af8ed400$0eac7c00$@nl> In-Reply-To: Date: Fri, 9 Oct 2009 13:58:42 +0200 Message-ID: <00f601ca48d7$d8fcb8d0$8af62a70$@nl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F7_01CA48E8.9C8588D0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpI0J7p9FZ79f3sRhGNK8ZqTXq34QABBDwA Content-Language: nl X-OriginalArrivalTime: 09 Oct 2009 11:58:47.0676 (UTC) FILETIME=[DBD41BC0:01CA48D7] 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: Fri, 09 Oct 2009 11:57:19 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00F7_01CA48E8.9C8588D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit BOLD ITALIC Calibri J Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens Emmanuel Baccelli Verzonden: vrijdag 9 oktober 2009 13:06 Aan: autoconf@ietf.org Onderwerp: Re: [Autoconf] updated MANET addressing model draft Hi Teco, inline: On Fri, Oct 9, 2009 at 12:17 PM, Teco Boot wrote: Hi Emmanuel, I'll tag my comments, for better readability. Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens Emmanuel Baccelli Verzonden: vrijdag 9 oktober 2009 11:38 Aan: autoconf@ietf.org Onderwerp: Re: [Autoconf] updated MANET addressing model draft Hi Teco, thanks for your feedback. Comments inline: On Wed, Sep 30, 2009 at 2:19 PM, Teco Boot wrote: 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 disagree. The last months have shown that there is quite a lot to say about Link-Locals, and such considerations are summarized later on in the document, so it seems natural to me to reference it at this point. Please explain why LLs have to do with IP Subnet Prefix Configuration. EB: Can I answer with a cryptic fe80:: ? TB: Then we are done! Hard coded and no problem at all. 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. OK. 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!!! I guess you are right, the point is not clearly expressed here. I think Thomas expressed it better in his last email: it's about not having any discrete on/off link event that would trigger DAD in our context, which is an issue with regards to traditional use of Link Locals. Again, this is applicable to all types of addresses. EB: I disagree: link local addresses are supposed to be managed with DAD (RFC4862) which deals with link local signalling only and that relies on on/off link events. So we have an issue with link-locals. For other types of addresses, different signalling is at work, that is not limited to the link, and that can work without on/off link events. TB: All addresses are support to be managed with DAD. LLs are no special case. However, some implementations use DAD only for LLs and as a result, they assume the InterfaceID is unique so DAD for other addresses with same, assumed unique, InterfaceID is bypassed (this mechanism is broken). Even if true, and we remove the DAD for LLs, or simply ignore it, because it would not work in all cases in our MANET, then we have the full problem for making sure all types of addresses are unique. I might miss something, but for now I assume I'm a messenger of bad news. No one said we have an easy job L. So how about saying: "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, without it being an explicit event that would trigger DAD again. Such duplication would thus go undetected." Again, this is applicable to all types of addresses. 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. I agree. I also think the goal of autoconf is to have unique interface IDs within the routing domain at least (as stated in section 6). We could have found some common ground here. This would be a break-through:-) Is this something to include in the document, section 6.2? Discuss / get consensus @ next IETF? By the way, the goal having unique interface IDs is nothing new. It is related by a long list of proposals, inspired by 8+8/GSE. EB: The document already says that the interfaces addresses should be unique within the routing domain at least so that's fine as it is. I guess we've been violently agreeing all this time then ;) TB: InterfaceIDs not equals IP addresses. What do you mean with interface addresses? Are there other types of IP addresses? Link layer addresses? IP addresses can be identifiers and / or locators. We must be very careful using right terminology. Once more, there is something called anycast. IP addresses doesn't need to be unique in all cases. For those who don't know, this raised in MANET ML and is of scope for Autoconf. > 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. I personally agree with mentionning the fact that "the use of Link Locals limits the connectivity between routers" in our context. It's an elegant way of saying things ;) Now it may be OK in some special case to use a Link Local address, even if they suffer from these limitations. One trivial example is: for testing purposes, when a human operator is right next to the router, why not use a LL to communicate with the router? But for a more general applicability, including all the routing protocols we have to accomodate, LLs are not suitable -- I see we agree on that. And that's why the conclusion is: AUTOCONF should focus on configuring other types of addresses. Now let's move on! We can speed up by not arguing on why we focus on configuring other types of addresses. Please stay away from a need for routing protocols on not using LLs. We definitely need the non-LLs for user applications. No one disputes this. I read the posting from Thomas C., especially on this one: >>> MANET protocols require the interfaces to be >>> configured with IP addresses I can't understand why we focus so much on the MANET routing protocols. The MANETs I am working with have real users. For them, it is totally Irrelevant what the MANET protocol IP addresses are. As long as applications work fine, also in the MANET, they are fine. There is a problem here, I cannot connect the MANETs to The Internet dynamically with IETF protocols available today. I could use NAPT, but we IETF really want to kick this out. We need a solution for connecting our MANETs to the Internet. EB: We agree on this goal ;) For this we need routing protocols which work on MANETs. This document describes a model that works for ALL the current IETF protocols that work on MANETs, so everything's fine. TB: I think the MANET protocols are a bit out of scope for Autoconf. It is all about the other thing, getting addresses and being reachable. The model in the document requires an update on all OSPF-MANET documents, including that from yourself (or the STD track OSPF one). This is unimportant and getting boring. Please do not say it works for all protocols. It is broken already. Regards, Teco ------=_NextPart_000_00F7_01CA48E8.9C8588D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

BOLD ITALIC Calibri J

 

Van:<= /b> autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens = Emmanuel Baccelli
Verzonden: vrijdag 9 oktober 2009 13:06
Aan: autoconf@ietf.org
Onderwerp: Re: [Autoconf] updated MANET addressing model = draft

 

Hi = Teco,

 

inline:

 

On Fri, Oct 9, 2009 at 12:17 PM, Teco Boot <teco@inf-net.nl> = wrote:

Hi Emmanuel,

I'll tag my comments, for better readability.




Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens
Emmanuel Baccelli

Verzonden: vrijdag 9 oktober 2009 = 11:38

Aan: autoconf@ietf.org
Onderwerp: Re: [Autoconf] updated MANET addressing model = draft

Hi Teco,

thanks for your feedback. Comments inline:

On Wed, Sep 30, 2009 at 2:19 PM, Teco Boot <teco@inf-net.nl> wrote:
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 disagree. The last months have shown that there is quite a lot to = say
about Link-Locals, and such considerations are summarized later on in = the
document, so it seems natural to me to reference it at this = point.

<Teco>
Please explain why LLs have to do with IP Subnet Prefix = Configuration.
</Teco>

 

 

EB: Can I answer with a cryptic fe80:: ?

TB: Then we are done! Hard coded and no problem at all. =

 

 


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:
 <skip>
>   Therefore MANET autoconfiguration solutions will primarily = focus on
>   configuring IP addresses that are not IPv6 link-local.


OK.
 

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!!!

I guess you are right, the point is not clearly expressed here. I = think
Thomas expressed it better in his last email: it's about not having = any
discrete on/off link event that would trigger DAD in our context, which = is
an issue with regards to traditional use of Link = Locals.

<Teco>
Again, this is applicable to all types of addresses.
</Teco>

 

 

 

EB: I disagree: link local addresses are = supposed to be managed with DAD (RFC4862) which deals with link local = signalling only and that relies on on/off link events. So we have an issue with link-locals. For other types of addresses, different signalling is at work, that is not limited to the link, and that can work without = on/off link events.

TB: All addresses are support to be managed with DAD. LLs = are no special case.

However, some implementations use DAD only for LLs and as = a result, they assume the InterfaceID is unique so DAD for other addresses = with same, assumed unique, InterfaceID is bypassed (this mechanism is broken). =

Even if true, and we remove the DAD for LLs, or simply = ignore it, because it would not work in all cases in our MANET, then we have = the full problem for making sure all types of addresses are = unique.

I might miss something, but for now I assume I’m a messenger of bad news.

No one said we have an easy job = L.

 

 


So how about saying:

"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, without it being an explicit event that = would
trigger DAD again. Such duplication would thus go = undetected."

<Teco>
Again, this is applicable to all types of addresses.
</Teco>


 
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.


I agree. I also think the goal of autoconf is to have unique interface = IDs
within the routing domain at least (as stated in section = 6).

<Teco>
We could have found some common ground here.
This would be a break-through:-)

Is this something to include in the document, section 6.2?
Discuss / get consensus @ next IETF?

By the way, the goal having unique interface IDs is nothing new.
It is related by a long list of proposals, inspired by 8+8/GSE.
</Teco> 

 

 

EB: The document already says that the = interfaces addresses should be unique within the routing domain at least so that's = fine as it is. I guess we've been violently agreeing all this time then = ;)

TB: InterfaceIDs not equals IP addresses. =

What do you mean with interface addresses? Are there = other types of IP addresses? Link layer addresses?

IP addresses can be identifiers and / or locators. We = must be very careful using right terminology.

Once more, there is something called anycast. IP = addresses doesn’t need to be unique in all cases. For those who don’t know, this = raised in MANET ML and is of scope for Autoconf.

 

 


>   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.



I personally agree with mentionning the fact that "the use of Link = Locals
limits the connectivity between routers" in our context. It's an = elegant way
of saying things ;) Now it may be OK in some special case to use a = Link
Local address, even if they suffer from these limitations. One = trivial
example is: for testing purposes, when a human operator is right next to = the
router, why not use a LL to communicate with the router? But for a = more
general applicability, including all the routing protocols we have = to
accomodate, LLs are not suitable -- I see we agree on that. And that's = why
the conclusion is: AUTOCONF should focus on configuring
other types of addresses. Now let's move = on!

<Teco>

We can speed up by not arguing on why we focus on configuring other = types
of addresses.
Please stay away from a need for routing protocols on not using LLs.
We definitely need the non-LLs for user applications. No one disputes = this.

I read the posting from Thomas C., especially on this = one:

>>> =  MANET protocols require the interfaces to be
>>>  configured with IP addresses

I can't understand = why we focus so much on the MANET routing protocols.
The MANETs I am working with have real users. For them, it is = totally
Irrelevant what the MANET protocol IP addresses are. As long as = applications
work fine, also in the MANET, they are fine.
There is a problem here, I cannot connect the MANETs to The Internet
dynamically with IETF protocols available today. I could use NAPT,
but we IETF really want to kick this out.
We need a solution for connecting our MANETs to the = Internet.

 

EB: We agree on this goal ;) For this we need = routing protocols which work on MANETs. This document describes a model that = works for ALL the current IETF protocols that work on MANETs, so everything's = fine.

 

TB: I think the MANET protocols are a bit out of scope = for Autoconf. It is all about the other thing, getting addresses and being reachable.

 

The model in the document requires an update on all = OSPF-MANET documents, including that from yourself (or the STD track OSPF = one).

This is unimportant and getting boring. Please do not say = it works for all protocols. It is broken = already.

 

Regards, Teco

 

 

------=_NextPart_000_00F7_01CA48E8.9C8588D0-- From Fred.L.Templin@boeing.com Fri Oct 9 09:06: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 C8E5428C143 for ; Fri, 9 Oct 2009 09:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.021 X-Spam-Level: X-Spam-Status: No, score=-6.021 tagged_above=-999 required=5 tests=[AWL=0.577, 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 qPdVEpPt622k for ; Fri, 9 Oct 2009 09:06:47 -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 E0FA428C112 for ; Fri, 9 Oct 2009 09:06:47 -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 n99G8RSH001579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Oct 2009 09:08:30 -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 n99G8RjV015446; Fri, 9 Oct 2009 09:08:27 -0700 (PDT) Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n99G8QPs015434 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 9 Oct 2009 09:08:27 -0700 (PDT) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Fri, 9 Oct 2009 09:08:26 -0700 From: "Templin, Fred L" To: Emmanuel Baccelli , "autoconf@ietf.org" Date: Fri, 9 Oct 2009 09:08:26 -0700 Thread-Topic: [Autoconf] updated MANET addressing model draft Thread-Index: Aco9C6uYd95UsHj0RAewcXFMbtpd1QL7eSFg Message-ID: <12F4112206976147A34FEC0277597CCF27A416478C@XCH-NW-15V.nw.nos.boeing.com> References: In-Reply-To: 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-16936.002 x-tm-as-result: No--48.805600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_12F4112206976147A34FEC0277597CCF27A416478CXCHNW15Vnwnos_" MIME-Version: 1.0 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: Fri, 09 Oct 2009 16:06:48 -0000 --_000_12F4112206976147A34FEC0277597CCF27A416478CXCHNW15Vnwnos_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Emmanuel, Section 6.1 of your draft should say the same thing about IPv4 link-local addresses [RFC3927] as was said about IPv6 link-local addresses in Section 6.2. The only difference being that when (or rather if) an IPv4 interface configures a routable address the link-local one is typically deprecated. Fred fred.l.templin@boeing.com ________________________________ From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On Behal= f Of Emmanuel Baccelli Sent: Thursday, September 24, 2009 4:39 AM To: autoconf@ietf.org Subject: [Autoconf] updated MANET addressing model draft Hi all, an updated version of the MANET addressing model draft has just been publis= hed. It integrates comments received during and after the last IETF meeting= , including some advisory text about IPv6 Link Local addresses, heavily ins= pired 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 --_000_12F4112206976147A34FEC0277597CCF27A416478CXCHNW15Vnwnos_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Emmanuel,

 

Section 6.1 of your draft should say t= he same thing about IPv4 link-local

addresses [RFC3927] as was said about = IPv6 link-local addresses in

Section 6.2. The only difference being that when (or rather if) an IPv4

interface configures a routable addres= s the link-local one is typically

deprecated.

 

Fred

fred.l.templin@boeing.com

 

From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On Behalf Of Emmanuel Baccelli
Sent: Thursday, September 24= , 2009 4:39 AM
To: autoconf@ietf.org
Subject: [Autoconf] updated = MANET addressing model draft

 

Hi all,

 

an updated versi= on 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.

Please review it thouroughly, and give us some feedback.

 

Regards,<= /font>

 

Emmanuel<= /font>

--_000_12F4112206976147A34FEC0277597CCF27A416478CXCHNW15Vnwnos_-- From alexandru.petrescu@gmail.com Fri Oct 9 10:31:46 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 3DC0528C16C for ; Fri, 9 Oct 2009 10:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, FS_SINGLE_LETTER_J=0.672, 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 AMZ5PvGZeIA1 for ; Fri, 9 Oct 2009 10:31:44 -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 32F6F28C0EE for ; Fri, 9 Oct 2009 10:31:44 -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 n99HXQj3005967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Oct 2009 19:33:26 +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 n99HXPOQ015419; Fri, 9 Oct 2009 19:33:26 +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 n99HXPJc007655; Fri, 9 Oct 2009 19:33:25 +0200 Message-ID: <4ACF73E5.6030600@gmail.com> Date: Fri, 09 Oct 2009 19:33:25 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Teco Boot References: <002f01ca41c8$418c0340$c4a409c0$@nl> <00d801ca48c9$af8ed400$0eac7c00$@nl> <00f601ca48d7$d8fcb8d0$8af62a70$@nl> In-Reply-To: <00f601ca48d7$d8fcb8d0$8af62a70$@nl> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, 'Emmanuel Baccelli' Subject: Re: [Autoconf] Bold Italic Calibri J font (was: 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: Fri, 09 Oct 2009 17:31:46 -0000 Teco Boot a écrit : > */BOLD ITALIC Calibri /**/J/**/ /* As a side note: how about using a more traditional way of citing like: Mike said on 13th of Aug: Paul said on 15th of Aug: >> Bit 1 should be 0. > > No, bit 0 should be 1. The tools to achieve this ">" indentation and quotation are widely available on software mailers for users ranging from hardcore elm/mailx-ers to lazy thunderbird/eudora/outlook-ers. You seem to be using outlook 2007, so to achieve this ">" effect do this: Tools->Options->Emailoptions->"During answering a message" (the 2nd scrolling menu of the window) select item "Prefix each line of the original message" (the last item in that menu). The quotes are translated from my French reader, I hope you get it. Alex > > > > *Van:* autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] > *Namens *Emmanuel Baccelli *Verzonden:* vrijdag 9 oktober 2009 13:06 > *Aan:* autoconf@ietf.org *Onderwerp:* Re: [Autoconf] updated MANET > addressing model draft > > > > Hi Teco, > > > > inline: > > > > On Fri, Oct 9, 2009 at 12:17 PM, Teco Boot > wrote: > > Hi Emmanuel, > > I'll tag my comments, for better readability. > > > > > Van: autoconf-bounces@ietf.org > [mailto:autoconf-bounces@ietf.org ] > Namens Emmanuel Baccelli > > Verzonden: vrijdag 9 oktober 2009 11:38 > > Aan: autoconf@ietf.org Onderwerp: Re: > [Autoconf] updated MANET addressing model draft > > Hi Teco, > > thanks for your feedback. Comments inline: > > On Wed, Sep 30, 2009 at 2:19 PM, Teco Boot > wrote: 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 disagree. The last months have shown that there is quite a lot to > say about Link-Locals, and such considerations are summarized later > on in the document, so it seems natural to me to reference it at this > point. > > Please explain why LLs have to do with IP Subnet Prefix > Configuration. > > > > > > EB: Can I answer with a cryptic fe80:: ? > > */TB: Then we are done! Hard coded and no problem at all. /* > > > > > > > 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. > > > OK. > > > 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!!! > > I guess you are right, the point is not clearly expressed here. I > think Thomas expressed it better in his last email: it's about not > having any discrete on/off link event that would trigger DAD in our > context, which is an issue with regards to traditional use of Link > Locals. > > Again, this is applicable to all types of addresses. > > > > > > > > EB: I disagree: link local addresses are supposed to be managed with > DAD (RFC4862) which deals with link local signalling only and that > relies on on/off link events. So we have an issue with link-locals. > For other types of addresses, different signalling is at work, that > is not limited to the link, and that can work without on/off link > events. > > */TB: All addresses are support to be managed with DAD. LLs are no > special case./* > > */However, some implementations use DAD only for LLs and as a result, > they assume the InterfaceID is unique so DAD for other addresses > with same, assumed unique, InterfaceID is bypassed (this mechanism is > broken). /* > > */Even if true, and we remove the DAD for LLs, or simply ignore it, > because it would not work in all cases in our MANET, then we have the > full problem for making sure all types of addresses are unique./* > > */I might miss something, but for now I assume I’m a messenger of bad > news./* > > */No one said we have an easy job /**/L/**/./* > > > > > > > So how about saying: > > "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, without it being an explicit > event that would trigger DAD again. Such duplication would thus go > undetected." > > Again, this is applicable to all types of addresses. > > > > 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. > > > I agree. I also think the goal of autoconf is to have unique > interface IDs within the routing domain at least (as stated in > section 6). > > We could have found some common ground here. This would be a > break-through:-) > > Is this something to include in the document, section 6.2? Discuss / > get consensus @ next IETF? > > By the way, the goal having unique interface IDs is nothing new. It > is related by a long list of proposals, inspired by 8+8/GSE. > > > > > > > EB: The document already says that the interfaces addresses should be > unique within the routing domain at least so that's fine as it is. I > guess we've been violently agreeing all this time then ;) > > */TB: InterfaceIDs not equals IP addresses. /* > > */What do you mean with interface addresses? Are there other types of > IP addresses? Link layer addresses?/* > > */IP addresses can be identifiers and / or locators. We must be very > careful using right terminology./* > > */Once more, there is something called anycast. IP addresses doesn’t > need to be unique in all cases. For those who don’t know, this > raised in MANET ML and is of scope for Autoconf./* > > > > > > >> 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. > > > > I personally agree with mentionning the fact that "the use of Link > Locals limits the connectivity between routers" in our context. It's > an elegant way of saying things ;) Now it may be OK in some special > case to use a Link Local address, even if they suffer from these > limitations. One trivial example is: for testing purposes, when a > human operator is right next to the router, why not use a LL to > communicate with the router? But for a more general applicability, > including all the routing protocols we have to accomodate, LLs are > not suitable -- I see we agree on that. And that's why the conclusion > is: AUTOCONF should focus on configuring other types of addresses. > Now let's move on! > > > > We can speed up by not arguing on why we focus on configuring other > types of addresses. Please stay away from a need for routing > protocols on not using LLs. We definitely need the non-LLs for user > applications. No one disputes this. > > I read the posting from Thomas C., especially on this one: > >>>> MANET protocols require the interfaces to be configured with IP >>>> addresses > > I can't understand why we focus so much on the MANET routing > protocols. The MANETs I am working with have real users. For them, it > is totally Irrelevant what the MANET protocol IP addresses are. As > long as applications work fine, also in the MANET, they are fine. > There is a problem here, I cannot connect the MANETs to The Internet > dynamically with IETF protocols available today. I could use NAPT, > but we IETF really want to kick this out. We need a solution for > connecting our MANETs to the Internet. > > > > EB: We agree on this goal ;) For this we need routing protocols which > work on MANETs. This document describes a model that works for ALL > the current IETF protocols that work on MANETs, so everything's fine. > > > > > */TB: I think the MANET protocols are a bit out of scope for > Autoconf. It is all about the other thing, getting addresses and > being reachable./* > > */ /* > > */The model in the document requires an update on all OSPF-MANET > documents, including that from yourself (or the STD track OSPF > one)./* > > */This is unimportant and getting boring. Please do not say it works > for all protocols. It is broken already./* > > */ /* > > */Regards, Teco/* > > > > > > > ------------------------------------------------------------------------ > > > _______________________________________________ Autoconf mailing list > Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From charles.perkins@earthlink.net Fri Oct 9 11:32: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 96C4928C188 for ; Fri, 9 Oct 2009 11:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.733 X-Spam-Level: X-Spam-Status: No, score=-1.733 tagged_above=-999 required=5 tests=[AWL=0.247, 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 13h07o1PrKl5 for ; Fri, 9 Oct 2009 11:32:54 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id CDA253A6827 for ; Fri, 9 Oct 2009 11:32:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Qzjoz1fgivAgICgcThdHjns9TLpyFpuHB8fbjkbCJyrRwBW8AYa6d8Mvqe61YJii; 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.139]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MwKIS-0005Ve-P8; Fri, 09 Oct 2009 14:34:32 -0400 Message-ID: <4ACF8238.5020503@earthlink.net> Date: Fri, 09 Oct 2009 11:34:32 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Emmanuel Baccelli References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52f05a6474f850efa969960b53e5b770be350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org 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: Fri, 09 Oct 2009 18:32:55 -0000 Hello Emmanuel, I think it is a good draft. I generally agree with Thomas's comments for editorial improvement. I still find the word "translates" unclear, and would make the following changes: > This translates in the > following policy: > --> This suggests the following policy: [two occurrences] [BTW: "translates in" is not good idiomatic English anyway] and > The > following describes a practical translation for these > principles, respectively for IPv4 and IPv6. > > --> The following describes guidelines that follow from these principles, respectively for IPv4 and IPv6. Regards, Charlie P. Emmanuel Baccelli wrote: > 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 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From root@core3.amsl.com Mon Oct 19 13:00:04 2009 Return-Path: X-Original-To: autoconf@ietf.org Delivered-To: autoconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8375C3A696C; Mon, 19 Oct 2009 13:00:03 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091019200004.8375C3A696C@core3.amsl.com> Date: Mon, 19 Oct 2009 13:00:03 -0700 (PDT) Cc: autoconf@ietf.org Subject: [Autoconf] I-D Action:draft-ietf-autoconf-adhoc-addr-model-00.txt 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, 19 Oct 2009 20:00:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Ad-Hoc Network Autoconfiguration Working Group of the IETF. Title : IP Addressing Model in Ad Hoc Networks Author(s) : E. Baccelli, M. Townsley Filename : draft-ietf-autoconf-adhoc-addr-model-00.txt Pages : 7 Date : 2009-10-19 This document describes a model for configuring IP addresses and subnet prefixes on the interfaces of routers which connect to links with undetermined connectivity properties. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-autoconf-adhoc-addr-model-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-autoconf-adhoc-addr-model-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-19124913.I-D@ietf.org> --NextPart-- From emmanuel.baccelli@gmail.com Tue Oct 20 08:15:20 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 717BA3A67BD for ; Tue, 20 Oct 2009 08:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[AWL=0.658, 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 W1oticVZC9hg for ; Tue, 20 Oct 2009 08:15:19 -0700 (PDT) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 9BAC43A67FB for ; Tue, 20 Oct 2009 08:15:19 -0700 (PDT) Received: by ywh13 with SMTP id 13so7781205ywh.29 for ; Tue, 20 Oct 2009 08:15:24 -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=3y4wmlwiyaiQRGkPidyBtn4uMmqbf933Zq5U5qYzRXs=; b=bkkmqGqOrCTuPK6bfgLO2dXUR2mYG6WbKvyfr3OCknqPo6zf/AYSIpFDCEyDXt8ZFi wG96FV5ahV65d/6LmCrDVv6YUS8afNGfd10BCfcLcfPTIp6MzGI9XFo8Bn7RbEveNh1n HIKfxaVnTRMNTOOf8psXUPXNf/u+met6c1GeA= 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=tChRb+0sjZbCTwCxCSQP/Gmmtu60vL6ZJw619WO6ybd0BoyobcM2MbJemUbJtkBoSX cH4Yp36lxrsF++F/9J/gchMxd/vzfbgidZRwAYvhXXH7IVKwhZ9qnDUJIipQK0jcF/16 nkJCYV8BaaA57bdppwkDPC9vLFdUHaAOo3gok= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.91.27.6 with SMTP id e6mr6630503agj.27.1256051724099; Tue, 20 Oct 2009 08:15:24 -0700 (PDT) From: Emmanuel Baccelli Date: Tue, 20 Oct 2009 17:15:03 +0200 X-Google-Sender-Auth: 63bdcbfbfa4cb2ab Message-ID: To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=001485f912a8d5a1fa04765f54ec Subject: [Autoconf] IP Addressing Model for Ad Hoc Networks 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, 20 Oct 2009 15:15:20 -0000 --001485f912a8d5a1fa04765f54ec Content-Type: text/plain; charset=ISO-8859-1 Hi autoconfers, a new version of the addressing model draft is out since yesterday. http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model-00 Please send to the list any comments you may have about it. Regards, Emmanuel --001485f912a8d5a1fa04765f54ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi autoconfers,

a new version of the addressing model dr= aft is out since yesterday.

Please send to the list any comments you may have about= it.

Regards,

Emmanuel


--001485f912a8d5a1fa04765f54ec-- From charles.perkins@earthlink.net Tue Oct 20 10:19: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 A778D3A68AC for ; Tue, 20 Oct 2009 10:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[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 H+vOKg9v5kW1 for ; Tue, 20 Oct 2009 10:19:25 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id D22B33A6861 for ; Tue, 20 Oct 2009 10:19:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=IHfXNgNHptnJPq9FHZiCILA/orj/0pqX5r/ZXcmW/RKK6qmZaSl/L5wEuJe+ULh6; 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.153]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1N0IMr-0001Uu-Pl; Tue, 20 Oct 2009 13:19:29 -0400 Message-ID: <4ADDF121.301@earthlink.net> Date: Tue, 20 Oct 2009 10:19:29 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Emmanuel Baccelli References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5212cdd4187016925a96cef0d4e9e2c9f5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] IP Addressing Model for Ad Hoc Networks 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, 20 Oct 2009 17:19:25 -0000 Hello Emmanuel, The draft looks good to me. I thought of a possible structural improvement to the document, but it would not be worth any further delay to the document. However, the Security Considerations is not really appropriate: > This document does currently not describe any security > considerations. > First of all, that can't be a suitable sentence because it would be tautologically true for any document that just deleted all relevant security discussion. So I think something else is needed. Second, it's likely that there ARE relevant security considerations. For instance, any security protocols would be affected that had to do with securing any subnet range of addresses all at once, or multicast security, or security based on static links, or security for anycast addresses. These are just possibilities that came to mind upon a few moments reflection. Maybe a more serious discussion would bring to light additional points for inclusion in the Security Considerations section. Regards, Charlie P. Emmanuel Baccelli wrote: > Hi autoconfers, > > a new version of the addressing model draft is out since yesterday. > http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model-00 > > Please send to the list any comments you may have about it. > > Regards, > > Emmanuel > > > ------------------------------------------------------------------------ > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From alexandru.petrescu@gmail.com Tue Oct 20 12:22:07 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 8AC883A6830 for ; Tue, 20 Oct 2009 12:22:07 -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 23Ff5cT9RRs7 for ; Tue, 20 Oct 2009 12:22:06 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 986A33A681E for ; Tue, 20 Oct 2009 12:22:06 -0700 (PDT) Received: by fxm18 with SMTP id 18so6812679fxm.37 for ; Tue, 20 Oct 2009 12:22:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=D0dih0Ui5piGrXEgaO6TkJ4vrXnm+pvBtfhScBTK+To=; b=cB9ShvP1XJ7rEMoeCd4GZdC5sYehP0qTjC6xE7/6DEXFkcpJSqMw+V0LCWOjus8nD2 8qMdfKQcZg5PboZx0asbyii3G6lkOrJAsAq102gv9gnsVnTXQXv7L31R2Hfl91Vhsp1y HNNZm17k7QQ6prQBIW8i/8FAwr77vdlaDIyqE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=SCwCh206KeQdg2NTWNkroMJNwqqpgHbxrSiKn0erP5rPnLsz4YnpRD1t8zJYaG4ZHT Q64tht8BhOZdYXl6t/O/rGSLOndDa9kFfXERt/xtdjCMbMov0JQSdqcje1cBb5wmGxjY 4AfFP5Gw2VIbTo78cG2nLPPyRbfg++yRcOOJo= MIME-Version: 1.0 Received: by 10.223.143.73 with SMTP id t9mr1260658fau.89.1256066529421; Tue, 20 Oct 2009 12:22:09 -0700 (PDT) Date: Tue, 20 Oct 2009 21:22:09 +0200 Message-ID: <840fa9b60910201222y40c68aacyd7afa30a264156a7@mail.gmail.com> From: Alexandru Petrescu To: autoconf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Autoconf] IP Addressing Model for Ad Hoc Networks 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, 20 Oct 2009 19:22:07 -0000 Hi Emmanuel, Well - thank you for this new draft. However - shouldn't we agree in the WG before the document becomes a WG item (draft-ietf-autoconf)? It is strange to see the document submitted as WG item all of a sudden. What is going on? Alex E. Baccelli wrote recently: > Hi autoconfers, > > a new version of the addressing model draft is out since yesterday. > http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model-00 > > Please send to the list any comments you may have about it. > > Regards, > > Emmanuel > From emmanuel.baccelli@gmail.com Tue Oct 20 14:36: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 345733A67E5 for ; Tue, 20 Oct 2009 14:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.483 X-Spam-Level: X-Spam-Status: No, score=-1.483 tagged_above=-999 required=5 tests=[AWL=0.493, 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 H2TZRypbQKSk for ; Tue, 20 Oct 2009 14:36:36 -0700 (PDT) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 50B623A67B1 for ; Tue, 20 Oct 2009 14:36:36 -0700 (PDT) Received: by ywh13 with SMTP id 13so8293373ywh.29 for ; Tue, 20 Oct 2009 14:36:40 -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=h+3r9NvhVCZiI4y5zl9w58suLLdDEn1dFJfkU4psyxg=; b=vztHy4ydr1JJInBr5FpfC1UJXMrVaeE9B2TdhZhNvJogNAHOZHqY5kqfz2LEMxJhAA V0V4dzSDwVFwgghfoYrDQJsUb4pRwaDGT8RPVEYES00AT+1XqjVF0sZaltoXYgg6cAQT iswGGacTSRufaWQjr4Y2rkFFZMxx7McD2Yz/U= 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=ghgEkj/tGQ+SrG1mh/KCLOA5B2oWCmDvEyHR8J2Z1ckMJneWGXEDZWuEjeTwiiqjjc oQJK2QwjLI/CquBsCX8k2x+DYAa0j2uSewG0pBj+pRWzBTgnsqucnSXShS2zvoRtr0DZ aZVVfY4iguGCmJyKj2yDYeRzUxDkXQd8ZG/Xg= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.91.28.2 with SMTP id f2mr7475973agj.16.1256074600135; Tue, 20 Oct 2009 14:36:40 -0700 (PDT) In-Reply-To: <840fa9b60910201222y40c68aacyd7afa30a264156a7@mail.gmail.com> References: <840fa9b60910201222y40c68aacyd7afa30a264156a7@mail.gmail.com> From: Emmanuel Baccelli Date: Tue, 20 Oct 2009 23:36:20 +0200 X-Google-Sender-Auth: f6d5a32219362500 Message-ID: To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=001485f5ea785a3e99047664a888 Subject: Re: [Autoconf] IP Addressing Model for Ad Hoc Networks 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, 20 Oct 2009 21:36:37 -0000 --001485f5ea785a3e99047664a888 Content-Type: text/plain; charset=ISO-8859-1 Hi Alex, Thanks for your feedback. Can you be more explicit about what is in the draft, that you disagree with, if anything? Regards, Emmanuel On Tue, Oct 20, 2009 at 9:22 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Hi Emmanuel, > > Well - thank you for this new draft. > > However - shouldn't we agree in the WG before the document becomes a > WG item (draft-ietf-autoconf)? > > It is strange to see the document submitted as WG item all of a > sudden. What is going on? > > Alex > > E. Baccelli wrote recently: > > Hi autoconfers, > > > > a new version of the addressing model draft is out since yesterday. > > http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model-00 > > > > Please send to the list any comments you may have about it. > > > > Regards, > > > > Emmanuel > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > --001485f5ea785a3e99047664a888 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alex,

Thanks for your feedback. Can you be more expli= cit about what is in the draft, that you disagree with, if anything?
<= div>
Regards,

Emmanuel


On Tue, Oct 20, 2009 at 9:22 PM, Alexand= ru Petrescu <alexandru.petrescu@gmail.com> wrote:
Hi Emmanuel,

Well - thank you for this new draft.

However - shouldn't we agree in the WG before the document becomes a WG item (draft-ietf-autoconf)?

It is strange to see the document submitted as WG item all of a
sudden. =A0What is going on?

Alex

E. Baccelli wrote recently:
> Hi autoconfers,
>
> a new version of the addressing model draft is out since yesterday. > http://tools.ietf.org/html/draft-ietf-autoconf-a= dhoc-addr-model-00
>
> Please send to the list any comments you may have about it.
>
> Regards,
>
> Emmanuel
>
_______________________________________________
Autoconf mailing list
Autoconf@ietf.org
https://www.ietf.org/mailman/listinfo/autoconf

--001485f5ea785a3e99047664a888-- From emmanuel.baccelli@gmail.com Tue Oct 20 14:39: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 8AF6E3A6960 for ; Tue, 20 Oct 2009 14:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.581 X-Spam-Level: X-Spam-Status: No, score=-1.581 tagged_above=-999 required=5 tests=[AWL=0.395, 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 OsLFAavo25LW for ; Tue, 20 Oct 2009 14:39:16 -0700 (PDT) Received: from mail-yx0-f174.google.com (mail-yx0-f174.google.com [209.85.210.174]) by core3.amsl.com (Postfix) with ESMTP id 743CC3A6954 for ; Tue, 20 Oct 2009 14:39:16 -0700 (PDT) Received: by yxe4 with SMTP id 4so4736210yxe.32 for ; Tue, 20 Oct 2009 14: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:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to :content-type; bh=UFqB9C+R2bc5k3eLNy50tdGtkAcaHOm9UhBrQTC7YFc=; b=t7LL+2xugyTNsPbakyya0OvxZGDgDy5MKasUcrBl0P2LYHJxoUUb5zeS0VPxfQ9Ooa tRiicPlXlFS0H8uU+bbMAR3P4XPFU/PsLuWPGP2v2mTM6RXUTLfurjmEcFPJ7RCBoFL0 3/VdSgl3h2OOhvDcOY3o64Df55j5h3c84HOPY= 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=PS+nlJA/lFmW3xkpPS+VWVbP7wi58528TyT1vDXq6JcA7Gr3ZJC/YVef6O28105leq jqTrGQdbxhCHLZRXItVxhxYtMxj0KwVGSRybd6d2eAr59Keq6h+3iXBh8Z4ssBlOIlcg qCRn6tF7arq8Tw5L9q+vISQMLN2orVsjEYK4Y= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.91.143.18 with SMTP id v18mr7497537agn.71.1256074759204; Tue, 20 Oct 2009 14:39:19 -0700 (PDT) In-Reply-To: <4ADDF121.301@earthlink.net> References: <4ADDF121.301@earthlink.net> From: Emmanuel Baccelli Date: Tue, 20 Oct 2009 23:38:59 +0200 X-Google-Sender-Auth: 7cb0f2a8122c5d73 Message-ID: To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=0016e643559ad581c1047664b1a7 Subject: Re: [Autoconf] IP Addressing Model for Ad Hoc Networks 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, 20 Oct 2009 21:39:18 -0000 --0016e643559ad581c1047664b1a7 Content-Type: text/plain; charset=ISO-8859-1 Hi Charlie, On Tue, Oct 20, 2009 at 7:19 PM, Charles E. Perkins < charles.perkins@earthlink.net> wrote: > > Hello Emmanuel, > > The draft looks good to me. I thought of a possible > structural improvement to the document, but it would > not be worth any further delay to the document. > > OK, sounds good. > However, the Security Considerations is not > really appropriate: > >> This document does currently not describe any security >> considerations. >> >> > > First of all, that can't be a suitable sentence because > it would be tautologically true for any document that > just deleted all relevant security discussion. > > So I think something else is needed. > > Second, it's likely that there ARE relevant > security considerations. For instance, any security > protocols would be affected that had to do with > securing any subnet range of addresses all at once, > or multicast security, or security based on static links, > or security for anycast addresses. > > These are just possibilities that came to mind upon > a few moments reflection. Maybe a more serious > discussion would bring to light additional points > for inclusion in the Security Considerations section. > > I totally agree with you. We need to work on this section at this point. It was not the focus until now, but the time has come, indeed ;) Emmanuel Regards, > Charlie P. > > > Emmanuel Baccelli wrote: > >> Hi autoconfers, >> >> a new version of the addressing model draft is out since yesterday. >> http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model-00 >> >> Please send to the list any comments you may have about it. >> >> Regards, >> >> Emmanuel >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >> >> > > --0016e643559ad581c1047664b1a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Charlie,


On Tue, Oct 20, 2009 at = 7:19 PM, Charles E. Perkins <charles.perkins@earthlink.net> wrote:=

Hello Emmanuel,

The draft looks good to me. =A0I thought of a possible
structural improvement to the document, but it would
not be worth any further delay to the document.




OK, soun= ds good.



=A0
However, the Security Considerations is not
really appropriate:
=A0 This document does currently not describe any security
=A0 considerations.
=A0

First of all, that can't be a suitable sentence because
it would be tautologically true for any document that
just deleted all relevant security discussion.

So I think something else is needed.

Second, it's likely that there ARE relevant
security considerations. =A0For instance, any security
protocols would be affected that had to do with
securing any subnet range of addresses all at once,
or multicast security, or security based on static links,
or security for anycast addresses.

These are just possibilities that came to mind upon
a few moments reflection. =A0Maybe a more serious
discussion would bring to light additional points
for inclusion in the Security Considerations section.




I totall= y agree with you. We need to work on this section at this point. It was not= the focus until now, but the time has come, indeed ;)

Emmanuel
=A0




Regards,
Charlie P.


Emmanuel Baccelli wrote:
Hi autoconfers,

a new version of the addressing model draft is out since yesterday.
http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-= addr-model-00

Please send to the list any comments you may have about it.

Regards,

Emmanuel


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


--0016e643559ad581c1047664b1a7-- From townsley@cisco.com Wed Oct 21 02:28: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 9336F3A6936 for ; Wed, 21 Oct 2009 02:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.044 X-Spam-Level: X-Spam-Status: No, score=-6.044 tagged_above=-999 required=5 tests=[AWL=0.555, 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 8cch3BF-oZzv for ; Wed, 21 Oct 2009 02:28:41 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 9C7CD3A687F for ; Wed, 21 Oct 2009 02:28:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=townsley@cisco.com; l=2594; q=dns/txt; s=sjiport06001; t=1256117330; x=1257326930; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Mark=20Townsley=20|Subject: =20IPv4=20link-locals|Date:=20Wed,=2021=20Oct=202009=2011 :28:32=20+0200|Message-ID:=20<4ADED440.2080403@cisco.com> |To:=20"Templin,=20Fred=20L"=20,=20autoconf@ietf.org|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit; bh=o/OtbWRb2mN6tUMQTVtIRjaHBn5mDrad1Pai3ci6OEk=; b=ArDZs58caw5nifeL6GV6MFEeO02nDtPmx00yZepcmtMyj5UIJ5qGAVJs yi7uj2CMfL5kQLGg2G57C4I4H12Pbe8yUSCjeaYsX0DJWGm1jeyLdLAZg JgfL0nhYxc2YayhThIeD9DcOT8bAk66XgIyOrrvQXZX3+XF3H7igU6WoH 8=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgFAARx3kqrR7Ht/2dsb2JhbACBUb8xmGWEMQSBXA X-IronPort-AV: E=Sophos;i="4.44,595,1249257600"; d="scan'208";a="414207684" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 21 Oct 2009 09:28:50 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9L9So5d025440; Wed, 21 Oct 2009 09:28:50 GMT Received: from Townsley-MacBook.local (dhcp-10-55-95-84.cisco.com [10.55.95.84]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id n9L9SnX19674; Wed, 21 Oct 2009 02:28:49 -0700 (PDT) Message-ID: <4ADED440.2080403@cisco.com> Date: Wed, 21 Oct 2009 11:28:32 +0200 From: Mark Townsley User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Templin, Fred L" , autoconf@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Autoconf] IPv4 link-locals 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, 21 Oct 2009 09:28:42 -0000 Fred wrote: > Emmanuel, > > Section 6.1 of your draft should say the same thing about IPv4 link-local > addresses [RFC3927] as was said about IPv6 link-local addresses in > Section 6.2. The only difference being that when (or rather if) an IPv4 > interface configures a routable address the link-local one is typically > deprecated. > > Fred Fred, this is the text that ended up in -00: Note that the use of IPv4 link-local addresses [RFC3927] in this context should be discouraged for most applications, as the limitations outlined in Section 6.2 for IPv6 link-local addresses also concern IPv4 link-local addresses. These limitations are further exacerbated by the smaller pool of IPv4 link-local addresses to choose from and thus increased reliance on DAD. However, I think that we need to say a little more here to your point. Also, I think that while it is reasonable to discourage link-local usage in IPv6 (as hopefully we are more able to readily autoconfigure a ULA or Global Ipv6 address) the situation in IPv4 is a bit different as obtaining a unique Global or Private IPv4 address may be quite a bit more difficult. Therefore, usage of IPv4 link-locals may be necessary in some cases (I'm thinking of mdns-based service discovery, for example). So, I'd like to propose something like this: "The use of IPv4 link-local addresses [RFC3927] is discouraged for most applications. The limitations outlined in Section 6.2 for IPv6 link-local addresses also concern IPv4 link-local addresses, and are further exacerbated by the smaller pool of IPv4 link-local addresses to choose from and thus increased reliance on DAD. However, given the increased difficulty of obtaining a Global or Private [RFC1918] IPv4 address, use of IPv4 link-locals may be the only readily available option in some circumstances. Applications running in an ad-hoc environment must be well-aware that link-connectivity is constantly in flux, and if link-locals are used, ensure that this is not a detrimental factor to proper operation. An application that may be able to use IPv4 link-locals effectively is one that consists of a stateless request-response action and no more. An application that may not operate with IPv4 link-locals effectively is one that relies on nodes to have a consistent or long-lived IPv4 address (e.g., connection-oriented communication bound to the IP address). In the event an interface obtains a non-link-local IPv4 address, the link-local IPv4 address should be deprecated." - Mark From alexandru.petrescu@gmail.com Wed Oct 21 03:08:38 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 2F6C73A6889 for ; Wed, 21 Oct 2009 03:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.200, 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 cMsS3CI4vm8L for ; Wed, 21 Oct 2009 03:08:37 -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 390503A67DF for ; Wed, 21 Oct 2009 03:08:37 -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 n9LA8iro001286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Oct 2009 12:08:44 +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 n9LA8ir0028075; Wed, 21 Oct 2009 12:08:44 +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 n9LA8gX0015144; Wed, 21 Oct 2009 12:08:44 +0200 Message-ID: <4ADEDDA9.1030209@gmail.com> Date: Wed, 21 Oct 2009 12:08:41 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Emmanuel Baccelli References: <840fa9b60910201222y40c68aacyd7afa30a264156a7@mail.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] IP Addressing Model for Ad Hoc Networks 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, 21 Oct 2009 10:08:38 -0000 Emmanuel Baccelli a écrit : > Hi Alex, > > Thanks for your feedback. Can you be more explicit about what is in the > draft, that you disagree with, if anything? I said, did you ask this WG before submitting a WG item? Alex (sorry for being too direct) > > Regards, > > Emmanuel > > > On Tue, Oct 20, 2009 at 9:22 PM, Alexandru Petrescu > > wrote: > > Hi Emmanuel, > > Well - thank you for this new draft. > > However - shouldn't we agree in the WG before the document becomes a > WG item (draft-ietf-autoconf)? > > It is strange to see the document submitted as WG item all of a > sudden. What is going on? > > Alex > > E. Baccelli wrote recently: > > Hi autoconfers, > > > > a new version of the addressing model draft is out since yesterday. > > http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model-00 > > > > Please send to the list any comments you may have about it. > > > > Regards, > > > > Emmanuel > > > _______________________________________________ > 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 ietf@thomasclausen.org Wed Oct 21 03:48: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 3FDF83A6843 for ; Wed, 21 Oct 2009 03:48: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 648rZ3qmcOQU for ; Wed, 21 Oct 2009 03:48:23 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 686DE3A6821 for ; Wed, 21 Oct 2009 03:48:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 5C3813231747; Wed, 21 Oct 2009 03:48:32 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id A0F123228059; Wed, 21 Oct 2009 03:48:30 -0700 (PDT) Message-Id: <43AF0FAC-32E8-4019-AA21-EB44A12FC28C@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4ADEDDA9.1030209@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, 21 Oct 2009 12:48:28 +0200 References: <840fa9b60910201222y40c68aacyd7afa30a264156a7@mail.gmail.com> <4ADEDDA9.1030209@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org, RYUJI WAKIKAWA , Emmanuel Baccelli Subject: Re: [Autoconf] IP Addressing Model for Ad Hoc Networks 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, 21 Oct 2009 10:48:24 -0000 Alex, All, I kinda understand your reaction, let me try to explain the reasoning. Until now draft-baccelli-autoconf-adhoc-addr-mode was the only =20 addressing model document available. Clearly the working group has =20 been engaged in reviewing and discussing the document actively, on the =20= list and in meetings. It was the impression from those discussions =20 that the document and the discussions had captured the issues that had =20= been raised - at least, we were aware of no as-yet unaddressed (in the =20= document or in the discussions) issues. We thought it was a good idea to go ahead and move this to a WG =20 document and continue the iterations at the WG level in hopes of =20 accelerating making progress. Our read from the WG is, that everybody wants to get this model =20 document passed and out of the way -- and then move on to the actual =20 autoconf mechanisms/protocols sooner rather than later. Yes, we didn't really ask the WG permission explicitly this time. This =20= means we might have to ask forgiveness, if we in fact moved too =20 quickly. We're willing to do that, of course. We're also ready to ask =20= Mark and Emmanuel to resubmit as a non-working group document if that =20= becomes the case. Above all we have the feeling that the WG needs to move forward, not =20 backward, and that draft-ietf-autoconf-adhoc-addr-model-00.txt seemed =20= to be the best start on that path forward. I will therefore also second the request for Emmanuel that any =20 technical issues with the document be brought forward such that we can =20= either get Mark and Emmanuel to fold those into the document -- or can =20= ask that the document be resubmitted as a non-working group document =20 if that is not possible, and then ask the WG for a strategy to move =20 forward. I note that we're about 7 months past the milestone for initial =20 document submission, and one month past the deadline for IESG =20 submission or WG closure, so there's a discussions with the ADs coming =20= up soon, I'm sure..... Cheers, Thomas On Oct 21, 2009, at 12:08 PM, Alexandru Petrescu wrote: > Emmanuel Baccelli a =E9crit : >> Hi Alex, >> Thanks for your feedback. Can you be more explicit about what is in =20= >> the draft, that you disagree with, if anything? > > I said, did you ask this WG before submitting a WG item? > > Alex > (sorry for being too direct) > >> Regards, >> Emmanuel >> On Tue, Oct 20, 2009 at 9:22 PM, Alexandru Petrescu = > > wrote: >> Hi Emmanuel, >> Well - thank you for this new draft. >> However - shouldn't we agree in the WG before the document =20 >> becomes a >> WG item (draft-ietf-autoconf)? >> It is strange to see the document submitted as WG item all of a >> sudden. What is going on? >> Alex >> E. Baccelli wrote recently: >> > Hi autoconfers, >> > >> > a new version of the addressing model draft is out since =20 >> yesterday. >> > = http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model-00 >> > >> > Please send to the list any comments you may have about it. >> > >> > Regards, >> > >> > Emmanuel >> > >> _______________________________________________ >> 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 From alexandru.petrescu@gmail.com Wed Oct 21 05:57: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 A90D428C0DF for ; Wed, 21 Oct 2009 05:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[AWL=0.186, 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 t8iVdGL4-B3Q for ; Wed, 21 Oct 2009 05:57:39 -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 91A9028C0E4 for ; Wed, 21 Oct 2009 05:57:38 -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 n9LCvi05018164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Oct 2009 14:57:44 +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 n9LCviBV005161; Wed, 21 Oct 2009 14:57:44 +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 n9LCvg7P003732; Wed, 21 Oct 2009 14:57:43 +0200 Message-ID: <4ADF0546.2080804@gmail.com> Date: Wed, 21 Oct 2009 14:57:42 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <840fa9b60910201222y40c68aacyd7afa30a264156a7@mail.gmail.com> <4ADEDDA9.1030209@gmail.com> <43AF0FAC-32E8-4019-AA21-EB44A12FC28C@thomasclausen.org> In-Reply-To: <43AF0FAC-32E8-4019-AA21-EB44A12FC28C@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, RYUJI WAKIKAWA , Emmanuel Baccelli Subject: Re: [Autoconf] Procedure (was: IP Addressing Model for Ad Hoc Networks) 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, 21 Oct 2009 12:57:40 -0000 Thomas, I thought there was a Design Team formed, and the output of this DT was draft-baccelli-autoconf-adhoc-addr-model "IP addressing model in ad hoc networks". As a DT document, it has more weight than being simply 'the only doc available'. But also as a DT document it is subject to WG adoption. When you say "we thought it was a good idea to..." - who is "we"? Myself and at least somebody else part of this WG were surprised about this submission. I don't say I wouldn't have voted for, but I was surprised to see it appearing as draft-ietf-autoconf. You are asking whether a re-submission is needed: I don't know, I have not seen this situation before. This is confnusing, at least from a procedural standpoint. See below the relevant paragraphs from rfc2418 about DTs, FWIW. I know that when a WG item submission is made to the System, an email approval is required from the Chairs. Maybe we should suggest the System (tools.ietf.org) to add something involving the WG as well. Yours, Alex rfc2418: > 6.5. Design teams > > It is often useful, and perhaps inevitable, for a sub-group of a > working group to develop a proposal to solve a particular problem. > Such a sub-group is called a design team. In order for a design team > to remain small and agile, it is acceptable to have closed membership > and private meetings. Design teams may range from an informal chat > between people in a hallway to a formal set of expert volunteers that > the WG chair or AD appoints to attack a controversial problem. The > output of a design team is always subject to approval, rejection or > modification by the WG as a whole. Thomas Heide Clausen a écrit : > Alex, All, > > I kinda understand your reaction, let me try to explain the reasoning. > > Until now draft-baccelli-autoconf-adhoc-addr-mode was the only > addressing model document available. Clearly the working group has been > engaged in revidewing and discussing the document actively, on the list > and in meetings. It was the impression from those discussions that the > document and the discussions had captured the issues that had been > raised - at least, we were aware of no as-yet unaddressed (in the > document or in the discussions) issues. > > We thought it was a good idea to go ahead and move this to a WG document > and continue the iterations at the WG level in hopes of accelerating > making progress. > > Our read from the WG is, that everybody wants to get this model document > passed and out of the way -- and then move on to the actual autoconf > mechanisms/protocols sooner rather than later. > > Yes, we didn't really ask the WG permission explicitly this time. This > means we might have to ask forgiveness, if we in fact moved too quickly. > We're willing to do that, of course. We're also ready to ask Mark and > Emmanuel to resubmit as a non-working group document if that becomes the > case. > > Above all we have the feeling that the WG needs to move forward, not > backward, and that draft-ietf-autoconf-adhoc-addr-model-00.txt seemed to > be the best start on that path forward. > > I will therefore also second the request for Emmanuel that any technical > issues with the document be brought forward such that we can either get > Mark and Emmanuel to fold those into the document -- or can ask that the > document be resubmitted as a non-working group document if that is not > possible, and then ask the WG for a strategy to move forward. > > I note that we're about 7 months past the milestone for initial document > submission, and one month past the deadline for IESG submission or WG > closure, so there's a discussions with the ADs coming up soon, I'm > sure..... > > Cheers, > > Thomas > > On Oct 21, 2009, at 12:08 PM, Alexandru Petrescu wrote: > >> Emmanuel Baccelli a écrit : >>> Hi Alex, >>> Thanks for your feedback. Can you be more explicit about what is in >>> the draft, that you disagree with, if anything? >> >> I said, did you ask this WG before submitting a WG item? >> >> Alex >> (sorry for being too direct) >> >>> Regards, >>> Emmanuel >>> On Tue, Oct 20, 2009 at 9:22 PM, Alexandru Petrescu >>> > >>> wrote: >>> Hi Emmanuel, >>> Well - thank you for this new draft. >>> However - shouldn't we agree in the WG before the document becomes a >>> WG item (draft-ietf-autoconf)? >>> It is strange to see the document submitted as WG item all of a >>> sudden. What is going on? >>> Alex >>> E. Baccelli wrote recently: >>> > Hi autoconfers, >>> > >>> > a new version of the addressing model draft is out since >>> yesterday. >>> > http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model-00 >>> > >>> > Please send to the list any comments you may have about it. >>> > >>> > Regards, >>> > >>> > Emmanuel >>> > >>> _______________________________________________ >>> 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 > > From cjbc@it.uc3m.es Wed Oct 21 09:35: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 C2EE128C0FE for ; Wed, 21 Oct 2009 09:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, 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 ASWdFXrvAyz5 for ; Wed, 21 Oct 2009 09:35:38 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id D852328C114 for ; Wed, 21 Oct 2009 09:35:37 -0700 (PDT) Received: from [IPv6:::1] (luciernaga.it.uc3m.es [163.117.140.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 98F6A7F36EB; Wed, 21 Oct 2009 18:35:43 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Alexandru Petrescu In-Reply-To: <4ADF0546.2080804@gmail.com> References: <840fa9b60910201222y40c68aacyd7afa30a264156a7@mail.gmail.com> <4ADEDDA9.1030209@gmail.com> <43AF0FAC-32E8-4019-AA21-EB44A12FC28C@thomasclausen.org> <4ADF0546.2080804@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-DEG17zMbBd2xwdudqUEH" Organization: Universidad Carlos III de Madrid Date: Wed, 21 Oct 2009 18:35:42 +0200 Message-Id: <1256142942.3046.13.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16960.003 Cc: autoconf@ietf.org, Emmanuel Baccelli , RYUJI WAKIKAWA Subject: Re: [Autoconf] Procedure (was: IP Addressing Model for Ad Hoc Networks) 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: Wed, 21 Oct 2009 16:35:39 -0000 --=-DEG17zMbBd2xwdudqUEH Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi, I fully agree with Alex's view on this. The procedures are there to be followed, even if in this particular case the DT draft were 100% fine and all the WG members supported it (the technical merits of the draft and the WG support is not the point of this discussion, that's part of a different one that Emmanuel did well in opening). My two cents on this (as another "surprised WG member"), Carlos On Wed, 2009-10-21 at 14:57 +0200, Alexandru Petrescu wrote: > Thomas, >=20 > I thought there was a Design Team formed, and the output of this DT was=20 > draft-baccelli-autoconf-adhoc-addr-model "IP addressing model in ad hoc=20 > networks". As a DT document, it has more weight than being simply 'the=20 > only doc available'. But also as a DT document it is subject to WG=20 > adoption. >=20 > When you say "we thought it was a good idea to..." - who is "we"?=20 > Myself and at least somebody else part of this WG were surprised about=20 > this submission. I don't say I wouldn't have voted for, but I was=20 > surprised to see it appearing as draft-ietf-autoconf. >=20 > You are asking whether a re-submission is needed: I don't know, I have=20 > not seen this situation before. >=20 > This is confnusing, at least from a procedural standpoint. See below=20 > the relevant paragraphs from rfc2418 about DTs, FWIW. >=20 > I know that when a WG item submission is made to the System, an email=20 > approval is required from the Chairs. Maybe we should suggest the=20 > System (tools.ietf.org) to add something involving the WG as well. >=20 > Yours, >=20 > Alex >=20 > rfc2418: > > 6.5. Design teams > >=20 > > It is often useful, and perhaps inevitable, for a sub-group of a > > working group to develop a proposal to solve a particular problem. > > Such a sub-group is called a design team. In order for a design tea= m > > to remain small and agile, it is acceptable to have closed membershi= p > > and private meetings. Design teams may range from an informal chat > > between people in a hallway to a formal set of expert volunteers tha= t > > the WG chair or AD appoints to attack a controversial problem. The > > output of a design team is always subject to approval, rejection or > > modification by the WG as a whole. >=20 >=20 > Thomas Heide Clausen a =E9crit : > > Alex, All, > >=20 > > I kinda understand your reaction, let me try to explain the reasoning. > >=20 > > Until now draft-baccelli-autoconf-adhoc-addr-mode was the only=20 > > addressing model document available. Clearly the working group has been= =20 > > engaged in revidewing and discussing the document actively, on the list= =20 > > and in meetings. It was the impression from those discussions that the=20 > > document and the discussions had captured the issues that had been=20 > > raised - at least, we were aware of no as-yet unaddressed (in the=20 > > document or in the discussions) issues. > >=20 > > We thought it was a good idea to go ahead and move this to a WG documen= t=20 > > and continue the iterations at the WG level in hopes of accelerating=20 > > making progress. > >=20 > > Our read from the WG is, that everybody wants to get this model documen= t=20 > > passed and out of the way -- and then move on to the actual autoconf=20 > > mechanisms/protocols sooner rather than later. > >=20 > > Yes, we didn't really ask the WG permission explicitly this time. This=20 > > means we might have to ask forgiveness, if we in fact moved too quickly= .=20 > > We're willing to do that, of course. We're also ready to ask Mark and=20 > > Emmanuel to resubmit as a non-working group document if that becomes th= e=20 > > case. > >=20 > > Above all we have the feeling that the WG needs to move forward, not=20 > > backward, and that draft-ietf-autoconf-adhoc-addr-model-00.txt seemed t= o=20 > > be the best start on that path forward. > >=20 > > I will therefore also second the request for Emmanuel that any technica= l=20 > > issues with the document be brought forward such that we can either get= =20 > > Mark and Emmanuel to fold those into the document -- or can ask that th= e=20 > > document be resubmitted as a non-working group document if that is not=20 > > possible, and then ask the WG for a strategy to move forward. > >=20 > > I note that we're about 7 months past the milestone for initial documen= t=20 > > submission, and one month past the deadline for IESG submission or WG=20 > > closure, so there's a discussions with the ADs coming up soon, I'm=20 > > sure..... > >=20 > > Cheers, > >=20 > > Thomas > >=20 > > On Oct 21, 2009, at 12:08 PM, Alexandru Petrescu wrote: > >=20 > >> Emmanuel Baccelli a =E9crit : > >>> Hi Alex, > >>> Thanks for your feedback. Can you be more explicit about what is in=20 > >>> the draft, that you disagree with, if anything? > >> > >> I said, did you ask this WG before submitting a WG item? > >> > >> Alex > >> (sorry for being too direct) > >> > >>> Regards, > >>> Emmanuel > >>> On Tue, Oct 20, 2009 at 9:22 PM, Alexandru Petrescu=20 > >>> >=20 > >>> wrote: > >>> Hi Emmanuel, > >>> Well - thank you for this new draft. > >>> However - shouldn't we agree in the WG before the document becomes= a > >>> WG item (draft-ietf-autoconf)? > >>> It is strange to see the document submitted as WG item all of a > >>> sudden. What is going on? > >>> Alex > >>> E. Baccelli wrote recently: > >>> > Hi autoconfers, > >>> > > >>> > a new version of the addressing model draft is out since=20 > >>> yesterday. > >>> > http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model= -00 > >>> > > >>> > Please send to the list any comments you may have about it. > >>> > > >>> > Regards, > >>> > > >>> > Emmanuel > >>> > > >>> _______________________________________________ > >>> 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 > >=20 > >=20 >=20 >=20 > _______________________________________________ > 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 --=-DEG17zMbBd2xwdudqUEH 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) iEYEABECAAYFAkrfOF4ACgkQNdy6TdFwT2cCvACgkY3WmGQ+h+8qLuKqdGqMQNq5 oCEAoN59IN3hz19T2LReYv4xm8x7HhOO =tLiV -----END PGP SIGNATURE----- --=-DEG17zMbBd2xwdudqUEH-- From Fred.L.Templin@boeing.com Wed Oct 21 11:33: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 568623A69DB for ; Wed, 21 Oct 2009 11:33:02 -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 jIaY0tWyMXIP for ; Wed, 21 Oct 2009 11:33:01 -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 68A113A69DA for ; Wed, 21 Oct 2009 11:33:01 -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 n9LIX8KR022802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Oct 2009 13:33:08 -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 n9LIX72t015759; Wed, 21 Oct 2009 11:33:08 -0700 (PDT) Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n9LIX7C1015750 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 21 Oct 2009 11:33:07 -0700 (PDT) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Wed, 21 Oct 2009 11:33:07 -0700 From: "Templin, Fred L" To: Mark Townsley , "autoconf@ietf.org" Date: Wed, 21 Oct 2009 11:33:06 -0700 Thread-Topic: IPv4 link-locals Thread-Index: AcpSdKzD6dbd2O0bRqWcDJHiYDfYYwAB3buA Message-ID: <12F4112206976147A34FEC0277597CCF27A41ACBAC@XCH-NW-15V.nw.nos.boeing.com> References: <4ADED440.2080403@cisco.com> In-Reply-To: <4ADED440.2080403@cisco.com> 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-16960.003 x-tm-as-result: No--71.713400-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 Subject: Re: [Autoconf] IPv4 link-locals 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, 21 Oct 2009 18:33:02 -0000 Hi Mark, > -----Original Message----- > From: Mark Townsley [mailto:townsley@cisco.com] > Sent: Wednesday, October 21, 2009 2:29 AM > To: Templin, Fred L; autoconf@ietf.org > Subject: IPv4 link-locals >=20 >=20 > Fred wrote: > > Emmanuel, > > > > Section 6.1 of your draft should say the same thing about IPv4 link-lo= cal > > addresses [RFC3927] as was said about IPv6 link-local addresses in > > Section 6.2. The only difference being that when (or rather if) an IPv4 > > interface configures a routable address the link-local one is typically > > deprecated. > > > > Fred >=20 > Fred, this is the text that ended up in -00: >=20 > Note that the use of IPv4 link-local addresses [RFC3927] in this > context should be discouraged for most applications, as the > limitations outlined in Section 6.2 for IPv6 link-local addresses > also concern IPv4 link-local addresses. These limitations are > further exacerbated by the smaller pool of IPv4 link-local addresses > to choose from and thus increased reliance on DAD. Thanks for pointing this out. > However, I think that we need to say a little more here to your point. Yes, a bit more is needed. > Also, I think that while it is reasonable to discourage link-local usage > in IPv6 (as hopefully we are more able to readily autoconfigure a ULA or > Global Ipv6 address) the situation in IPv4 is a bit different as > obtaining a unique Global or Private IPv4 address may be quite a bit > more difficult. Therefore, usage of IPv4 link-locals may be necessary in > some cases (I'm thinking of mdns-based service discovery, for example). Agreed. > So, I'd like to propose something like this: >=20 > "The use of IPv4 link-local addresses [RFC3927] is discouraged for most > applications. The limitations outlined in Section 6.2 for IPv6 > link-local addresses also concern IPv4 link-local addresses, and are > further exacerbated by the smaller pool of IPv4 link-local addresses to > choose from and thus increased reliance on DAD. However, given the > increased difficulty of obtaining a Global or Private [RFC1918] IPv4 > address, use of IPv4 link-locals may be the only readily available > option in some circumstances. Applications running in an ad-hoc > environment must be well-aware that link-connectivity is constantly in > flux, and if link-locals are used, ensure that this is not a detrimental > factor to proper operation. An application that may be able to use IPv4 > link-locals effectively is one that consists of a stateless > request-response action and no more. An application that may not operate > with IPv4 link-locals effectively is one that relies on nodes to have a > consistent or long-lived IPv4 address (e.g., connection-oriented > communication bound to the IP address). In the event an interface > obtains a non-link-local IPv4 address, the link-local IPv4 address > should be deprecated." I am fine with this, but it might benefit from a paragraph break somewhere. It might also be worth checking RFC3927 to see if anything that is being said here is redundant, but I would not object to the wording as you have it. Fred fred.l.templin@boeing.com > - Mark >=20 >=20 >=20 >=20 >=20 >=20 >=20 From alexandru.petrescu@gmail.com Wed Oct 21 14:32: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 AFD4128C104 for ; Wed, 21 Oct 2009 14:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=0.630, 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 G-YM7OL1pB7z for ; Wed, 21 Oct 2009 14:32: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 2D12C3A6922 for ; Wed, 21 Oct 2009 14:32:42 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 60923D48124; Wed, 21 Oct 2009 23:32:45 +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 721EFD4812B; Wed, 21 Oct 2009 23:32:42 +0200 (CEST) Message-ID: <4ADF7DF7.7060201@gmail.com> Date: Wed, 21 Oct 2009 23:32:39 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: RYUJI WAKIKAWA References: <840fa9b60910201222y40c68aacyd7afa30a264156a7@mail.gmail.com> <4ADEDDA9.1030209@gmail.com> <43AF0FAC-32E8-4019-AA21-EB44A12FC28C@thomasclausen.org> <4ADF0546.2080804@gmail.com> <13D5B6FF-6127-4499-93E8-8370F7CB6013@us.toyota-itc.com> In-Reply-To: <13D5B6FF-6127-4499-93E8-8370F7CB6013@us.toyota-itc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091021-0, 21/10/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] Procedure 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, 21 Oct 2009 21:32:45 -0000 Ryuji, This is the second time things go strange in this WG. The first time was at the DT formation time. With respect to this document, it is not up to me to speak, but it may be the case that another draft may talk same title as this draft. This all looks _Very_ _Very_ strange. Makes me change mind! Alex RYUJI WAKIKAWA a écrit : > Hi Alex and all, > > Thomas and I did discuss this action in a hurry before hiroshima. > As a result, we need to explain this situation after the WG document > publication. > We understand that the explanation to WG should be made before the > action and > really apologize to this point. > > Let me add a few more points to Thomas's email. > > First, we formed a DT for the strawman of the WG document. > However, we have decided to publish the DT document as an individual > document, > since we didn't know whether WG support the idea of DT at that point. > > Here is a copy from my email to the list. > > On 2009/03/12, at 17:44, Ryuji Wakikawa wrote: > >> Dear all, >> >> As Jari mentioned in the new plan for the AUTOCONF WG, we have decided >> to form a design team to rapidly produce a -00 strawman of the first >> working group deliverable, discussing (citing Jari) "a practical way >> of configuring MANET networks". > > After more than 6 months, we have discussed this document in our WG. > It seems to us that a document is reasonable to accept as a WG document. > For example, the consensus call of IPv4 link-local issue was made to > the individual document (which is rare case in IETF). > It's time to concentrate our efforts to the WG goal, producing "IP > addressing model for MANET". > > We believe DT will lead the discussion in AUTOCONF WG, > but this document now belongs to WG (i.e. not to DT anymore). > Anybody can review and discuss the document in the WG. > Your continuous discussion and review are highly important and appreciated. > > It it does not make sense to you, please send email to two chairs > (Thomas and Ryuji). > If we found WG wants to have clear consensus call to adapt draft-bacelli, > WG chairs can step the procedure back and ask the consensus call. > > thanks, > ryuji > > > On 2009/10/21, at 5:57, Alexandru Petrescu wrote: > >> Thomas, >> >> I thought there was a Design Team formed, and the output of this DT >> was draft-baccelli-autoconf-adhoc-addr-model "IP addressing model in >> ad hoc networks". As a DT document, it has more weight than being >> simply 'the only doc available'. But also as a DT document it is >> subject to WG adoption. >> >> When you say "we thought it was a good idea to..." - who is "we"? >> Myself and at least somebody else part of this WG were surprised about >> this submission. I don't say I wouldn't have voted for, but I was >> surprised to see it appearing as draft-ietf-autoconf. >> >> You are asking whether a re-submission is needed: I don't know, I have >> not seen this situation before. >> >> This is confnusing, at least from a procedural standpoint. See below >> the relevant paragraphs from rfc2418 about DTs, FWIW. >> >> I know that when a WG item submission is made to the System, an email >> approval is required from the Chairs. Maybe we should suggest the >> System (tools.ietf.org) to add something involving the WG as well. >> >> Yours, >> >> Alex >> >> rfc2418: >>> 6.5. Design teams >>> It is often useful, and perhaps inevitable, for a sub-group of a >>> working group to develop a proposal to solve a particular problem. >>> Such a sub-group is called a design team. In order for a design team >>> to remain small and agile, it is acceptable to have closed membership >>> and private meetings. Design teams may range from an informal chat >>> between people in a hallway to a formal set of expert volunteers that >>> the WG chair or AD appoints to attack a controversial problem. The >>> output of a design team is always subject to approval, rejection or >>> modification by the WG as a whole. >> >> >> Thomas Heide Clausen a écrit : >>> Alex, All, >>> I kinda understand your reaction, let me try to explain the reasoning. >>> Until now draft-baccelli-autoconf-adhoc-addr-mode was the only >>> addressing model document available. Clearly the working group has >>> been engaged in revidewing and discussing the document actively, on >>> the list and in meetings. It was the impression from those >>> discussions that the document and the discussions had captured the >>> issues that had been raised - at least, we were aware of no as-yet >>> unaddressed (in the document or in the discussions) issues. >>> We thought it was a good idea to go ahead and move this to a WG >>> document and continue the iterations at the WG level in hopes of >>> accelerating making progress. >>> Our read from the WG is, that everybody wants to get this model >>> document passed and out of the way -- and then move on to the actual >>> autoconf mechanisms/protocols sooner rather than later. >>> Yes, we didn't really ask the WG permission explicitly this time. >>> This means we might have to ask forgiveness, if we in fact moved too >>> quickly. We're willing to do that, of course. We're also ready to ask >>> Mark and Emmanuel to resubmit as a non-working group document if that >>> becomes the case. >>> Above all we have the feeling that the WG needs to move forward, not >>> backward, and that draft-ietf-autoconf-adhoc-addr-model-00.txt seemed >>> to be the best start on that path forward. >>> I will therefore also second the request for Emmanuel that any >>> technical issues with the document be brought forward such that we >>> can either get Mark and Emmanuel to fold those into the document -- >>> or can ask that the document be resubmitted as a non-working group >>> document if that is not possible, and then ask the WG for a strategy >>> to move forward. >>> I note that we're about 7 months past the milestone for initial >>> document submission, and one month past the deadline for IESG >>> submission or WG closure, so there's a discussions with the ADs >>> coming up soon, I'm sure..... >>> Cheers, >>> Thomas >>> On Oct 21, 2009, at 12:08 PM, Alexandru Petrescu wrote: >>>> Emmanuel Baccelli a écrit : >>>>> Hi Alex, >>>>> Thanks for your feedback. Can you be more explicit about what is in >>>>> the draft, that you disagree with, if anything? >>>> >>>> I said, did you ask this WG before submitting a WG item? >>>> >>>> Alex >>>> (sorry for being too direct) >>>> >>>>> Regards, >>>>> Emmanuel >>>>> On Tue, Oct 20, 2009 at 9:22 PM, Alexandru Petrescu >>>>> > >>>>> wrote: >>>>> Hi Emmanuel, >>>>> Well - thank you for this new draft. >>>>> However - shouldn't we agree in the WG before the document becomes a >>>>> WG item (draft-ietf-autoconf)? >>>>> It is strange to see the document submitted as WG item all of a >>>>> sudden. What is going on? >>>>> Alex >>>>> E. Baccelli wrote recently: >>>>> > Hi autoconfers, >>>>> > >>>>> > a new version of the addressing model draft is out since >>>>> yesterday. >>>>> > >>>>> http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model-00 >>>>> > >>>>> > Please send to the list any comments you may have about it. >>>>> > >>>>> > Regards, >>>>> > >>>>> > Emmanuel >>>>> > >>>>> _______________________________________________ >>>>> 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 >> >> > > From alexandru.petrescu@gmail.com Wed Oct 21 14:42: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 1482328C100 for ; Wed, 21 Oct 2009 14:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[AWL=0.588, 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 ojke1zq92p7B for ; Wed, 21 Oct 2009 14:42:32 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id D54373A685E for ; Wed, 21 Oct 2009 14:42:30 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 031E1D480D7 for ; Wed, 21 Oct 2009 23:42:36 +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 F3FCCD48052 for ; Wed, 21 Oct 2009 23:42:33 +0200 (CEST) Message-ID: <4ADF8046.8040504@gmail.com> Date: Wed, 21 Oct 2009 23:42:30 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: autoconf@ietf.org References: <20091019233002.15F4328C164@core3.amsl.com> In-Reply-To: <20091019233002.15F4328C164@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091021-0, 21/10/2009), Outbound message X-Antivirus-Status: Clean Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 21 Oct 2009 21:42:33 -0000 AUTOCONFers, I just noticed this draft just announced: Internet-Drafts@ietf.org a écrit : > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bernardos-autoconf-addressing-model-00.txt This draft says, among others: > MANET interfaces MUST also be configured with IPv6 Link-local > addresses (as required by RFC 4861 [RFC4861] and RFC 4291 [RFC4291]). > Two main concerns may arise when considering the use of IPv6 Link- > local addresses: > > o Address uniqueness: the event of having two duplicate addresses in > the same link has proved to be very low (EUI64 derived interface > identifiers very rarely collide, since MAC addresses are expected > to be globally unique), and even some mechanisms have been > proposed to reduce the collision probability > [I-D.soto-mobileip-random-iids]. Therefore, in most scenarios it > is safe to assume that the probability of having two or more > duplicated link-local addresses in a MANET is negiglible. For > those scenarios, in which this cannot be safely assumed, we refer > to the DAD considerations of Section 3.3. > > o Reachability: connectivity among neighbours in wireless links may > be intermittent and/or short-lived. Therefore, the use of link- > local addresses may lead to reachability issues, since two nodes > that were in direct coverage range at one moment, might not be > anymore shortly after. These problems might also arise in wired > networks (nodes going up/down), but it is not the common case. > > Having brought to attention these concerns, it is further left to the > designers of MANET routing protocols (and other protocols) to > determine whether link-local addresses can be used in an effective > way. I must say I fully agree with the above text, because it says link-locals are "MUST". It is more positive towards link-locals, I agree with it. I agree with it more than I agree with this text in draft-ietf-autoconf-adhoc-addr-model-00.txt: > Note that while link-local addresses are assumed to be "on link", the > utility of link-local addresses is limited as described in Section 6. ... which has a negative co-notation in that use of the "limited" word. So - please clarify this situation. Alex > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From alexandru.petrescu@gmail.com Wed Oct 21 15:08: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 765543A69A4 for ; Wed, 21 Oct 2009 15:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.49 X-Spam-Level: X-Spam-Status: No, score=-0.49 tagged_above=-999 required=5 tests=[AWL=-0.655, 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 1sL8GzjGtFfo for ; Wed, 21 Oct 2009 15:07:59 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 75A5E3A6825 for ; Wed, 21 Oct 2009 15:07:57 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 9CA0DD4806C for ; Thu, 22 Oct 2009 00:08: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 A876CD48096 for ; Thu, 22 Oct 2009 00:08:01 +0200 (CEST) Message-ID: <4ADF863E.8040408@gmail.com> Date: Thu, 22 Oct 2009 00:07:58 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "autoconf@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 091021-0, 21/10/2009), Outbound message X-Antivirus-Status: Clean Subject: Re: [Autoconf] Procedure 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, 21 Oct 2009 22:08:00 -0000 > From: RYUJI WAKIKAWA To: Alexandru Petrescu > Date: Wed, 21 Oct 2009 14:40:26 -0700 > Subject: Re: Procedure Hi Alex, > > On 2009/10/21, at 14:32, Alexandru Petrescu wrote: > >> Ryuji, >> >> This is the second time things go strange in this WG. The first >> time was at the DT formation time. >> > > > what was the problem of the DT formation time? DT announcement after DT announcement. I will not remind you now but I talked about it at the time on the jabber and on the mailing list. > After revising the WG charter, we formed a DT to identify the clear > WG item. Now it looks as if you better had gone the way of AD sponsoring, and not forming a DT working for a WG about which there seems to be little care - but much secrecy. Sorry to say so but that's my impression. You had a public mailing list on the DT - that was ok. But there's no discussion on it about this decision of submitting the DT draft into WG item. >> With respect to this document, it is not up to me to speak, but it >> may be the case that another draft may talk same title as this >> draft. >> > > > DT is not officially formed to produce an individual document. We > clearly spent so much time to improve this document. How about the new autoconf document I just saw announced and to which I agree much more? (about link-local addresses: it starts saying they are a MUST) - I agree to that stance much more than the DT document. In that sense I agree much more with that new draft than with the DT draft. Please fix this - it's not my problem (don't tell me I already agreed with the DT text on link-locals) - this is a WG caring problem. Alex > > ryuji From ryuji.wakikawa@gmail.com Wed Oct 21 15:25: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 B33503A68C2 for ; Wed, 21 Oct 2009 15:25:29 -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 wFDzJatVyzm8 for ; Wed, 21 Oct 2009 15:25:28 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by core3.amsl.com (Postfix) with ESMTP id 9BCA13A6784 for ; Wed, 21 Oct 2009 15:25:28 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so1704646fgg.13 for ; Wed, 21 Oct 2009 15:25:33 -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=AYUn6xkMJoHGXbwvXjd41maF5uEHlUOFx4Jf6sBmcjY=; b=UMjNY7xdnRUIn8sQWxg/1WcTZHeMQhrV2GpJ9Bzy8p5d5N/MV+xyboD+3Kf8IdYlTw 62ZZGXGMuyehXiANXl3/Ywlf132dLXl5xOtSrifsRtaPgoiye19RpzVf6DVjdbWaBnMo p0s+SV8cF3rJOZ/W+29uhunyOVdYLjAEoAQJg= 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=nbvqAuTb/D/fvUZURa1rA0ZdBIiISgqx+eTDjw1YCi56SO26FqMbw6FZ40GYe53l+v vonZ877PY6nP0wcfVQN2RA2hKTgMnuxMjuoVQrKLWBnMhRF5dfrbYYhxET23r9G5FuXV bbglBVnJM0R8I9Vfy8ltEXYLxLQ90lMnvorcY= Received: by 10.86.12.35 with SMTP id 35mr5044906fgl.20.1256163933443; Wed, 21 Oct 2009 15:25:33 -0700 (PDT) Received: from macbookpro-ryuji.paloalto.toyota-itc.com ([206.132.173.18]) by mx.google.com with ESMTPS id 4sm601197fge.9.2009.10.21.15.25.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 21 Oct 2009 15:25:32 -0700 (PDT) From: Ryuji Wakikawa To: Alexandru Petrescu In-Reply-To: <4ADF863E.8040408@gmail.com> References: <4ADF863E.8040408@gmail.com> Message-Id: <6B0ACB39-C603-48FA-89FC-8A887BD1BC7D@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 21 Oct 2009 15:25:21 -0700 X-Mailer: Apple Mail (2.936) Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Procedure 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, 21 Oct 2009 22:25:29 -0000 Hi Alex, On 2009/10/21, at 15:07, Alexandru Petrescu wrote: >> From: RYUJI WAKIKAWA To: Alexandru Petrescu >> Date: Wed, 21 Oct 2009 14:40:26 >> -0700 Subject: Re: Procedure Hi Alex, >> On 2009/10/21, at 14:32, Alexandru Petrescu wrote: >>> Ryuji, >>> This is the second time things go strange in this WG. The first >>> time was at the DT formation time. >> what was the problem of the DT formation time? > > DT announcement after DT announcement. I will not remind you now > but I > talked about it at the time on the jabber and on the mailing list. announcement after formation? What was the problem here? That was what Chairs and ADs have agreed. > >> After revising the WG charter, we formed a DT to identify the clear >> WG item. > > Now it looks as if you better had gone the way of AD sponsoring, and > not forming a DT working for a WG about which there seems to be > little care - but much secrecy. Sorry to say so but that's my > impression. > > You had a public mailing list on the DT - that was ok. But there's > no discussion on it about this decision of submitting the DT draft > into WG item. > >>> With respect to this document, it is not up to me to speak, but it >>> may be the case that another draft may talk same title as this >>> draft. >> DT is not officially formed to produce an individual document. We >> clearly spent so much time to improve this document. > > How about the new autoconf document I just saw announced and to > which I agree much more? (about link-local addresses: it starts > saying they are a MUST) - I agree to that stance much more than the > DT document. AFAIK, the document conflicts with what we have agreed so far in WG, specially LL address stuff. > In that sense I agree much more with that new draft than with the DT > draft. What was the previous consensus call for then? > Please fix this - it's not my problem (don't tell me I already > agreed with the DT text on link-locals) - this is a WG caring problem. How do you want us to fix it? sending consensus call to adapt draft- bacelli? regards, ryuji > > Alex > >> ryuji > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From charles.perkins@earthlink.net Wed Oct 21 15:45:34 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 1EE0728C119 for ; Wed, 21 Oct 2009 15:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[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 pgg8kHyymhbG for ; Wed, 21 Oct 2009 15:45:33 -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 2065328C107 for ; Wed, 21 Oct 2009 15:45:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=eDbLIHIUarTm/izXixJR3gx4v1KVAjelMTD+DABRQesOO/G7wuVfmCxf+mLVar2R; 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.7]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1N0jw6-00027T-6l; Wed, 21 Oct 2009 18:45:42 -0400 Message-ID: <4ADF8F12.6020002@earthlink.net> Date: Wed, 21 Oct 2009 15:45:38 -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: <4ADF863E.8040408@gmail.com> In-Reply-To: <4ADF863E.8040408@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52fd35e82fa09985e01d6bd5160f13d3f3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Procedure 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, 21 Oct 2009 22:45:34 -0000 Hello Alex, Alexandru Petrescu wrote: > Now it looks as if you better had gone the way of AD sponsoring, and > not forming a DT working for a WG about which there seems to be little > care - but much secrecy. Sorry to say so but that's my impression. > > You had a public mailing list on the DT - that was ok. But there's no > discussion on it about this decision of submitting the DT draft into > WG item. I don't remember the discussion about making the DT draft into a WG item, and I was on the design team. Nevertheless, I do not feel threatened by any trend towards secrecy. It's a lot more reasonable to just imagine that the WG chairs were trying to act in the best interest of the working group after months and months of discussion. Discussion != secrecy. But anyway I agree it would have been better to gauge consensus before making the DT draft into a working-group document. Somehow, I thought that had been done already, but I wasn't paying attention so closely. > > How about the new autoconf document I just saw announced and to which > I agree much more? (about link-local addresses: it starts saying they > are a MUST) - I agree to that stance much more than the DT document. You never responded to my explanation about why your proposed solution to the 4-node problem would almost certainly fail. So as far as I can tell this desire for mandating Link-Local is religion and not any sort of engineering. A stance is an opinion, not necessarily bolstered by facts or the possibility of making progress. > > > Please fix this - it's not my problem (don't tell me I already agreed > with the DT text on link-locals) - this is a WG caring problem. Here I really disagree. Why do you say there is a problem with "WG caring"? I am not sure what that means, but it sounds bad. In my opinion, with my interactions on the list and discussions on the design team, the WG chairs have shown me that they do care for the health of the working group. Do you claim otherwise? Regards, Charlie P. From charles.perkins@earthlink.net Wed Oct 21 16: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 00F983A6848 for ; Wed, 21 Oct 2009 16:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAlBqPPlZGEe for ; Wed, 21 Oct 2009 16:08:14 -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 CD31A3A6825 for ; Wed, 21 Oct 2009 16:08:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=L8nJvdNs1WS+egkiguvQHweg7zD0jXtK3hIT8SWutKAL03zFYFHCVDIxacXWi4i9; 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.7]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1N0kI1-0002mY-7A; Wed, 21 Oct 2009 19:08:21 -0400 Message-ID: <4ADF9464.9060409@earthlink.net> Date: Wed, 21 Oct 2009 16:08:20 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Carlos J. Bernardos" , "ext Velt, R. (Ronald) in 't" References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> In-Reply-To: <4ADF8046.8040504@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f523d781f65fa99a71cb1c9ecb8bea2ffab350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 21 Oct 2009 23:08:15 -0000 Hello Carlos and Ronald, Intrigued by Alex's email to the [autoconf] mailing list, I read your draft, which suggests the mandate: "MANET interfaces MUST also be configured with IPv6 Link-local addresses". But there is no indication in the draft about why that mandate might result in anything useful. What if [autoconf] recommended assignment of a distinguished link-local address to every MANET node? We could, for instance, designate the value fe80::FFFF as the distinguished useless link-local address designed _solely_ for the purpose of rigorous compliance with RFC 4861. Would this be satisfactory for the purposes you espouse in your draft? I also note that in your draft you advocate reliance on the typical (but not guaranteed) uniqueness of IEEE MAC addresses, and also turning off DAD or hacking the parameters. Did you try to calculate the overhead of, say, beaconing NA messages every 50 milliseconds, and the resulting too-frequent ND operations? Do you have any comments on the N^2 nature of this source of congestion? Regards, Charlie P. Alexandru Petrescu wrote: > AUTOCONFers, > > I just noticed this draft just announced: > > Internet-Drafts@ietf.org a écrit : >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-bernardos-autoconf-addressing-model-00.txt >> > > This draft says, among others: > >> MANET interfaces MUST also be configured with IPv6 Link-local >> addresses (as required by RFC 4861 [RFC4861] and RFC 4291 [RFC4291]). >> Two main concerns may arise when considering the use of IPv6 Link- >> local addresses: >> >> o Address uniqueness: the event of having two duplicate addresses in >> the same link has proved to be very low (EUI64 derived interface >> identifiers very rarely collide, since MAC addresses are expected >> to be globally unique), and even some mechanisms have been >> proposed to reduce the collision probability >> [I-D.soto-mobileip-random-iids]. Therefore, in most scenarios it >> is safe to assume that the probability of having two or more >> duplicated link-local addresses in a MANET is negiglible. For >> those scenarios, in which this cannot be safely assumed, we refer >> to the DAD considerations of Section 3.3. >> >> o Reachability: connectivity among neighbours in wireless links may >> be intermittent and/or short-lived. Therefore, the use of link- >> local addresses may lead to reachability issues, since two nodes >> that were in direct coverage range at one moment, might not be >> anymore shortly after. These problems might also arise in wired >> networks (nodes going up/down), but it is not the common case. >> >> Having brought to attention these concerns, it is further left to the >> designers of MANET routing protocols (and other protocols) to >> determine whether link-local addresses can be used in an effective >> way. > > I must say I fully agree with the above text, because it says > link-locals are "MUST". It is more positive towards link-locals, I > agree with it. > > I agree with it more than I agree with this text in > draft-ietf-autoconf-adhoc-addr-model-00.txt: >> Note that while link-local addresses are assumed to be "on link", the >> utility of link-local addresses is limited as described in Section 6. > > ... which has a negative co-notation in that use of the "limited" word. > > So - please clarify this situation. > > Alex > >> > > >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > > From ietf@thomasclausen.org Wed Oct 21 16:49: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 F00803A69E7 for ; Wed, 21 Oct 2009 16:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6] 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 BGaG9dziexnw for ; Wed, 21 Oct 2009 16:49:25 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 0DF973A698C for ; Wed, 21 Oct 2009 16:49:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 4488B32317A7 for ; Wed, 21 Oct 2009 16:49:34 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 2A6323231747 for ; Wed, 21 Oct 2009 16:49:32 -0700 (PDT) Message-Id: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> From: Thomas Heide Clausen To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-29-836380296 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 22 Oct 2009 01:49:30 +0200 X-Mailer: Apple Mail (2.936) Subject: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model 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, 21 Oct 2009 23:49:26 -0000 --Apple-Mail-29-836380296 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit All, It appeared to the chairs that the comments raised at the Stockholm IETF, as well as on the list subsequently, concerning the document: http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model had been addressed fully by the editors, and to the WGs satisfaction - at least, there were no issue raised to the latter/latest version hereof. The chairs therefore found it a good idea to move the document forward as a WG document, and progress this document as such. We therefore approved for publication: http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model We (the chairs) still believe that this is the proper approach in order to make progress for the WG. Do note that the WG is 7 months past the milestone for initial document submission, and 1 month past the milestone for having progressed the document to the IESG and/or closed up shop! And, there has been no discussions (in meetings or on this list) on alternative candidate documents for the work item which [autoconf] is chartered to accomplish. To put it bluntly, this WG is far far behind schedule and this document seemed, and still seems, by virtue of having been widely discussed and agreed upon, as the best shot at making progress for this WG. That said, we (and, this we is also the chairs) will take this opportunity to ask the WGs opinion on how to progress. If you have any opinion, please let it be known to the WG (via this mailing list) before 29/10/09 (i.e. Thursday next week) at noon CET. Please be specific and constructive, i.e., pick one of: o if you think that the WG should proceed with draft-ietf-autoconf- adhoc-addr-model as a baseline, say so! o if you think there're cardinal (but fixable) issues missing or wrong with draft-ietf-autoconf-adhoc-addr-model, then let the WG know what these issues are, and propose a solution before the deadline. The Editors will certainly do their best to address the issues. o if you think that draft-ietf-autoconf-adhoc-addr-model is beyond hope, let the WG know explicitly how you suggest that we progress at this point -- considering the current timeline!! Cheers, Ryuji & Thomas --Apple-Mail-29-836380296 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable = http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model=

had been addressed fully by the = editors, and to the WGs satisfaction - at least, there were no issue = raised to the latter/latest version hereof. The chairs therefore found = it a good idea to move the document forward as a WG document, and = progress this document as such. We therefore approved for = publication:

h= ttp://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model<= /div>

We (the chairs)  still believe that this = is the proper approach in order to make progress for the = WG.

Do note that the WG is 7 months past the = milestone for initial document submission, and 1 month past the = milestone for having progressed the document to the IESG and/or closed = up shop!  And, there has been no discussions (in meetings or on = this list) on alternative candidate documents for the work item which = [autoconf] is chartered to accomplish. 

To = put it bluntly, this WG is far far behind schedule and this document = seemed, and still seems, by virtue of having been widely discussed and = agreed upon, as the best shot at making progress for this = WG.

That said, we (and, this we is also the = chairs) will take this opportunity to ask the WGs opinion on how to = progress. If you have any opinion, please let it be known to the WG = (via this mailing list) before 29/10/09 (i.e. Thursday next = week) at noon CET. Please be specific and constructive, i.e., = pick one of:

= if you think that the WG should proceed with  = as a baseline, say so! 

o if you think there're cardinal = (but fixable) issues missing or wrong with 
= issues are, and propose a = solution before the deadline. The Editors 
= will certainly do their best to address the = issues.

= o if you think = that  let the WG know = explicitly how you suggest that we progress  at this point = -- 
  considering the current = timeline!!

Cheers,

Ryuji= & Thomas
= --Apple-Mail-29-836380296-- From cjbc@it.uc3m.es Wed Oct 21 17:10: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 B28383A6886 for ; Wed, 21 Oct 2009 17:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.35 X-Spam-Level: X-Spam-Status: No, score=-5.35 tagged_above=-999 required=5 tests=[AWL=0.349, 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 pDsd9pdn7cu8 for ; Wed, 21 Oct 2009 17:10:27 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 0A5833A66B4 for ; Wed, 21 Oct 2009 17:10:26 -0700 (PDT) Received: from [IPv6:::1] (luciernaga.it.uc3m.es [163.117.140.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id C551E6C2475; Thu, 22 Oct 2009 02:10:33 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Charles E. Perkins" In-Reply-To: <4ADF9464.9060409@earthlink.net> References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-XA94DvCMbchy90kfelgO" Organization: Universidad Carlos III de Madrid Date: Thu, 22 Oct 2009 02:10:28 +0200 Message-Id: <1256170228.12205.20.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16962.000 Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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: Thu, 22 Oct 2009 00:10:28 -0000 --=-XA94DvCMbchy90kfelgO Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Charlie, On Wed, 2009-10-21 at 16:08 -0700, Charles E. Perkins wrote: > Hello Carlos and Ronald, >=20 > Intrigued by Alex's email to the [autoconf] mailing list, I read > your draft, which suggests the mandate: Thanks for reading the draft. We are working on a -01 version (we submitted -00 to meet the deadline and we hope to make some changes before announcing it on the ML), but I'll provide my view on your questions. > "MANET interfaces MUST also be configured with > IPv6 Link-local addresses". >=20 > But there is no indication in the draft about why that > mandate might result in anything useful. >=20 > What if [autoconf] recommended assignment of a distinguished > link-local address to every MANET node? We could, for > instance, designate the value fe80::FFFF as the distinguished > useless link-local address designed _solely_ for the purpose > of rigorous compliance with RFC 4861. Would this be > satisfactory for the purposes you espouse in your draft? No, this would not be satisfactory. Link locals are not only mandated by RFC 4861 but also used by some protocols, so that's why we consider important to configure them (so they can be used) in MANETs. >=20 > I also note that in your draft you advocate reliance on the > typical (but not guaranteed) uniqueness of IEEE MAC addresses, It's true that it is not guaranteed, but the probability of collision is so low, that I'm not sure it's worth arguing about the necessity of using DAD. > and also turning off DAD or hacking the parameters. Did you > try to calculate the overhead of, say, beaconing NA messages > every 50 milliseconds, and the resulting too-frequent ND > operations? Do you have any comments on the N^2 nature > of this source of congestion? This could be certainly a scalability problem, but "hacking/configuring" ND is just one proposed mechanism to tackle with fluctuating reachability issues. There are other ways proposed in the draft (such a stronger interaction with the routing protocol) and surely there are more. Even if globals are used instead, we would have a fluctuating reachability issue, since the next IP hop used to reach a certain destination might move out of radio coverage (you need to detect this by ND or the routing protocol). I think the same kind-of solutions that be used there can also be used when link-locals are used. Besides, we do not mandate to use link-locals in the draft, we just think there are use cases where they are useful and therefore we should not prevent their use in MANETs. Again, thanks for reading the draft. Regards, Carlos >=20 > Regards, > Charlie P. >=20 >=20 > Alexandru Petrescu wrote: > > AUTOCONFers, > > > > I just noticed this draft just announced: > > > > Internet-Drafts@ietf.org a =E9crit : > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-bernardos-autoconf-addressin= g-model-00.txt=20 > >> > > > > This draft says, among others: > > > >> MANET interfaces MUST also be configured with IPv6 Link-local > >> addresses (as required by RFC 4861 [RFC4861] and RFC 4291 [RFC4291]= ). > >> Two main concerns may arise when considering the use of IPv6 Link- > >> local addresses: > >> > >> o Address uniqueness: the event of having two duplicate addresses = in > >> the same link has proved to be very low (EUI64 derived interface > >> identifiers very rarely collide, since MAC addresses are expecte= d > >> to be globally unique), and even some mechanisms have been > >> proposed to reduce the collision probability > >> [I-D.soto-mobileip-random-iids]. Therefore, in most scenarios i= t > >> is safe to assume that the probability of having two or more > >> duplicated link-local addresses in a MANET is negiglible. For > >> those scenarios, in which this cannot be safely assumed, we refe= r > >> to the DAD considerations of Section 3.3. > >> > >> o Reachability: connectivity among neighbours in wireless links ma= y > >> be intermittent and/or short-lived. Therefore, the use of link- > >> local addresses may lead to reachability issues, since two nodes > >> that were in direct coverage range at one moment, might not be > >> anymore shortly after. These problems might also arise in wired > >> networks (nodes going up/down), but it is not the common case. > >> > >> Having brought to attention these concerns, it is further left to t= he > >> designers of MANET routing protocols (and other protocols) to > >> determine whether link-local addresses can be used in an effective > >> way. > > > > I must say I fully agree with the above text, because it says=20 > > link-locals are "MUST". It is more positive towards link-locals, I=20 > > agree with it. > > > > I agree with it more than I agree with this text in=20 > > draft-ietf-autoconf-adhoc-addr-model-00.txt: > >> Note that while link-local addresses are assumed to be "on link", t= he > >> utility of link-local addresses is limited as described in Section = 6. > > > > ... which has a negative co-notation in that use of the "limited" word. > > > > So - please clarify this situation. > > > > Alex > > > >> > > > > > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> Below is the data which will enable a MIME compliant mail reader > >> implementation to automatically retrieve the ASCII version of the > >> Internet-Draft. > >> > >> > >> ----------------------------------------------------------------------= -- > >> > >> _______________________________________________ > >> I-D-Announce mailing list > >> I-D-Announce@ietf.org > >> https://www.ietf.org/mailman/listinfo/i-d-announce > >> Internet-Draft directories: http://www.ietf.org/shadow.html > >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www.ietf.org/mailman/listinfo/autoconf > > > > >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-XA94DvCMbchy90kfelgO 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) iEYEABECAAYFAkrfou4ACgkQNdy6TdFwT2ex5QCg3+KB0mVVC51+LPfL0Vxr2oyl 7/IAoJwFWCyApx60Kw+WTcXk410tRhRl =fmSX -----END PGP SIGNATURE----- --=-XA94DvCMbchy90kfelgO-- From sratliff@cisco.com Wed Oct 21 17:24: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 C80C03A6955 for ; Wed, 21 Oct 2009 17:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.869 X-Spam-Level: X-Spam-Status: No, score=-3.869 tagged_above=-999 required=5 tests=[AWL=0.734, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, MIME_QP_LONG_LINE=1.396, 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 kzHZTtJDOQfK for ; Wed, 21 Oct 2009 17:24:43 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id D72283A682E for ; Wed, 21 Oct 2009 17:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=8511; q=dns/txt; s=rtpiport01001; t=1256171092; x=1257380692; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20sratliff=20|Subject:=20Re: =20[Autoconf]=20On=20WG=20progress=20and=0D=0A=20draft-ie tf-autoconf-adhoc-addr-model|Date:=20Wed,=2021=20Oct=2020 09=2020:24:49=20-0400|Message-ID:=20|To:=20Thomas=20Heide=20Clausen=20,=20|Mime-version:=201.0 |In-Reply-To:=20<7FDC9EB7-F208-45A2-ACD7-283B980C23E3@tho masclausen.org>; bh=saUpqtZswa9oamC+eFPqeeLrEWEr+a7Snrx/bApjDkM=; b=IcQfox7yNxwBs1jTZWasGu30CHflrtpV2cbjKOZuY5FvL5OQYK0VCh9l CdJ2PeontDrY90+rnE7UarSIQw/6mLTTuDf28V8npJvH5kxhS6e95CU9O h/uxrI4iC40qwelViL0RimOALzuwbDlOiT7T8SsZYf5ZMcIHT9i10JfXS I=; Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4FAHZD30pAZnwM/2dsb2JhbACCJDGXLKgfmFaCM4IKBA X-IronPort-AV: E=Sophos;i="4.44,600,1249257600"; d="scan'208,217";a="64222077" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 22 Oct 2009 00:24:51 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9M0OpVU022915; Thu, 22 Oct 2009 00:24:51 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 20:24:51 -0400 Received: from 10.116.179.211 ([10.116.179.211]) by xmb-rtp-208.amer.cisco.com ([64.102.31.43]) with Microsoft Exchange Server HTTP-DAV ; Thu, 22 Oct 2009 00:24:50 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 21 Oct 2009 20:24:49 -0400 From: sratliff To: Thomas Heide Clausen , Message-ID: Thread-Topic: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model Thread-Index: AcpSrhCdF1H6Nbz7NEuq3niFkjNx5A== In-Reply-To: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3339001489_11658968" X-OriginalArrivalTime: 22 Oct 2009 00:24:51.0217 (UTC) FILETIME=[11EF6810:01CA52AE] Subject: Re: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model 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, 22 Oct 2009 00:24:48 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3339001489_11658968 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Thomas,=20 I think the document is fine, and that we should proceed. I have no problem= s with the change from =B3draft-bacelli=B2 to =B3draft-ietf-autoconf=B2 -- from what = I remember, the WG had expressed interest in pursuing the issue, and I don=B9t think I=B9ve seen any alternatives offered in a while. As you eloquently state, this working group is (yet again) behind schedule, on the one-and-only deliverable. Frankly, if we=B9re going to engage in a protracted discussion of the minutiae of whether or not this should be =B3draft-bacelli=B2 vs. =B3draft-ietf-autoconf=B2, it=B9s time to pull the plug on this WG, and put all of us out of our misery. Regards, Stan On 10/21/09 7:49 PM, "Thomas Heide Clausen" wrote: > All, >=20 > It appeared to the chairs that the comments raised at the Stockholm IETF,= as > well as on the list subsequently, concerning the document: >=20 > > > http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model >=20 > had been addressed fully by the editors, and to the WGs satisfaction - at > least, there were no issue raised to the latter/latest version hereof. Th= e > chairs therefore found it a good idea to move the document forward as a W= G > document, and progress this document as such. We therefore approved for > publication: >=20 > http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model >=20 > We (the chairs) still believe that this is the proper approach in order = to > make progress for the WG. >=20 > Do note that the WG is 7 months past the milestone for initial document > submission, and 1 month past the milestone for having progressed the docu= ment > to the IESG and/or closed up shop! And, there has been no discussions (i= n > meetings or on this list) on alternative candidate documents for the work= item > which [autoconf] is chartered to accomplish. >=20 > To put it bluntly, this WG is far far behind schedule and this document > seemed, and still seems, by virtue of having been widely discussed and ag= reed > upon, as the best shot at making progress for this WG. >=20 > That said, we (and, this we is also the chairs) will take this opportunit= y to > ask the WGs opinion on how to progress. If you have any opinion, please l= et it > be known to the WG (via this mailing list) before 29/10/09 (i.e. Thursday= next > week) at noon CET. Please be specific and constructive, i.e., pick one of= : >=20 > o if you think that the WG should proceed with > draft-ietf-autoconf-adhoc-addr-model > as a baseline, say so! >=20 > o if you think there're cardinal (but fixable) issues missing or wrong wi= th > draft-ietf-autoconf-adhoc-addr-model, then let the WG know what these > issues are, and propose a solution before the deadline. The Editors > will certainly do their best to address the issues. >=20 > o if you think that draft-ietf-autoconf-adhoc-addr-model is beyond hope, > let the WG know explicitly how you suggest that we progress at this poin= t -- > considering the current timeline!! >=20 > Cheers, >=20 > Ryuji & Thomas >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf --B_3339001489_11658968 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-mod= el Thomas,

I think the document is fine, and that we should proceed. I have no problem= s with the change from “draft-bacelli” to “draft-ietf-auto= conf” -- from what I remember, the WG had expressed interest in pursui= ng the issue, and I don’t think I’ve seen any alternatives offer= ed in a while.

As you eloquently state, this working group is (yet again) behind schedule,= on the one-and-only deliverable. Frankly, if we’re going to engage in= a protracted discussion of the minutiae of whether or not this should be &#= 8220;draft-bacelli” vs. “draft-ietf-autoconf”, it’s = time to pull the plug on this WG, and put all of us out of our misery.

Regards,
Stan


On 10/21/09 7:49 PM, "Thomas Heide Clausen" <ietf@thomasclausen.org> wrote:

<= SPAN STYLE=3D'font-size:11pt'>All,

It appeared to the chairs that the comments raised at the Stockholm IETF, a= s well as on the list subsequently, concerning the document:

 <http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-m= odel>  <http://tools.ietf.org/html/draft-baccelli-autoconf-= adhoc-addr-model> http://tools.ietf.org/html/draft-baccelli-autocon= f-adhoc-addr-model

had been addressed fully by the editors, and to the WGs satisfaction - at l= east, there were no issue raised to the latter/latest version hereof. The ch= airs therefore found it a good idea to move the document forward as a WG doc= ument, and progress this document as such. We therefore approved for publica= tion:

h= ttp://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model

We (the chairs)  still believe that this is the proper approach in ord= er to make progress for the WG.

Do note that the WG is 7 months past the milestone for initial document sub= mission, and 1 month past the milestone for having progressed the document t= o the IESG and/or closed up shop!  And, there has been no discussions (= in meetings or on this list) on alternative candidate documents for the work= item which [autoconf] is chartered to accomplish.

To put it bluntly, this WG is far far behind schedule and this document see= med, and still seems, by virtue of having been widely discussed and agreed u= pon, as the best shot at making progress for this WG.

That said, we (and, this we is also the chairs) will take this opportunity = to ask the WGs opinion on how to progress. If you have any opinion, please l= et it be known to the WG (via this mailing list) before 29/10/09 (i.e. Thurs= day next week) at noon CET. Please be specific and constructive, i.e., pick = one of:

o if you think that the WG should proceed with draft-ietf-autoconf-adhoc-ad= dr-model
as a baseline, say so!

o if you think there're cardinal (but fixable) issues missing or wrong with=
draft-ietf-autoconf-adhoc-addr-model, then let the WG know what these
issues are, and propose a solution before the deadline. The Editors
will certainly do their best to address the issues.

o if you think that draft-ietf-autoconf-adhoc-addr-model is beyond hope, let the WG know explicitly how you suggest that we progress  at this p= oint --
 considering the current timeline!!

Cheers,

Ryuji & Thomas

___________= ____________________________________
Autoconf mailing list
Autoconf@ietf.org
https://www.ietf.o= rg/mailman/listinfo/autoconf
--B_3339001489_11658968-- From charles.perkins@earthlink.net Wed Oct 21 21:00: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 45FD83A69B0 for ; Wed, 21 Oct 2009 21:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_52=0.6] 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 MriFKqef+FPp for ; Wed, 21 Oct 2009 21:00:34 -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 645E73A69AB for ; Wed, 21 Oct 2009 21:00:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=dUfMpKnhs71Dupq12YQyaS74E75WXQkEL7ZuVWMtezB0VQKzMQo7RYs986Bd5qmW; 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-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1N0oqx-000591-FO; Thu, 22 Oct 2009 00:00:43 -0400 Message-ID: <4ADFD8E9.8070209@earthlink.net> Date: Wed, 21 Oct 2009 21:00:41 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> In-Reply-To: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f523e5638225898cc57ee165ef3ca43b99a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model 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, 22 Oct 2009 04:00:35 -0000 Hello folks, I think that the WG should proceed with draft-ietf-autoconf-adhoc-addr-model as a baseline. Regards, Charlie P. Thomas Heide Clausen wrote: > All, > > It appeared to the chairs that the comments raised at the Stockholm > IETF, as well as on the list subsequently, concerning the document: > > http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model > > had been addressed fully by the editors, and to the WGs satisfaction - > at least, there were no issue raised to the latter/latest version > hereof. The chairs therefore found it a good idea to move the document > forward as a WG document, and progress this document as such. We > therefore approved for publication: > > http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model > > We (the chairs) still believe that this is the proper approach in > order to make progress for the WG. > > Do note that the WG is 7 months past the milestone for initial > document submission, and 1 month past the milestone for having > progressed the document to the IESG and/or closed up shop! And, there > has been no discussions (in meetings or on this list) on alternative > candidate documents for the work item which [autoconf] is chartered to > accomplish. > > To put it bluntly, this WG is far far behind schedule and this > document seemed, and still seems, by virtue of having been widely > discussed and agreed upon, as the best shot at making progress for > this WG. > > That said, we (and, this we is also the chairs) will take this > opportunity to ask the WGs opinion on how to progress. If you have any > opinion, please let it be known to the WG (via this mailing list) > before 29/10/09 (i.e. Thursday next week) at noon CET. Please be > specific and constructive, i.e., pick one of: > > o if you think that the WG should proceed > with draft-ietf-autoconf-adhoc-addr-model > as a baseline, say so! > > o if you think there're cardinal (but fixable) issues missing or wrong > with > draft-ietf-autoconf-adhoc-addr-model, then let the WG know what these > issues are, and propose a solution before the deadline. The Editors > will certainly do their best to address the issues. > > o if you think that draft-ietf-autoconf-adhoc-addr-model is beyond hope, > let the WG know explicitly how you suggest that we progress at this > point -- > considering the current timeline!! > > Cheers, > > Ryuji & Thomas > ------------------------------------------------------------------------ > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From emmanuel.baccelli@gmail.com Thu Oct 22 00:37: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 C61983A6864 for ; Thu, 22 Oct 2009 00:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[AWL=0.329, 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 V6KzdaQeW3wX for ; Thu, 22 Oct 2009 00:37:30 -0700 (PDT) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 76B933A67D4 for ; Thu, 22 Oct 2009 00:37:30 -0700 (PDT) Received: by ywh13 with SMTP id 13so10415928ywh.29 for ; Thu, 22 Oct 2009 00:37:37 -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=c3naxR7LUmGIVtS9i+4lEobB5s7SFKiog0dxnHgj3N8=; b=ZXDmt9NYQ0nGNEE7Pcf5LOjWrDNIPZPV95Q/lS/HVshpz9jHyGO1cMAWYh9IILz+ud mLU+IUOuXnOByOGzXAPo3dpdRhArp6GOvXiUILMtSm6Dysdw5y6NrGhaoDsIaCcDZ7co YnJGzLz7hazLcUc0Rtf7G3rmJeQtEmjmrzUfw= 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=RRsv5XA9iYwUXGBZ+4HxyZUXLiAtbiozEi2FzM/Ii6YMkqGYOnwVuYHiufBXXejy3V D9Ws01h2BtW/nJ6qdCZeFaNZLH2oFCyvJJTW6tiLp4C4hOF/eej03/m7vdet9/eK4I3n 9chswGs3ioM1vL3Zsz8ZIlBi6DISiyPz3DKGU= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.90.128.9 with SMTP id a9mr1297378agd.117.1256197057187; Thu, 22 Oct 2009 00:37:37 -0700 (PDT) In-Reply-To: <4ADF8046.8040504@gmail.com> References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> From: Emmanuel Baccelli Date: Thu, 22 Oct 2009 09:37:17 +0200 X-Google-Sender-Auth: 129621351d46b3ba Message-ID: To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=00163630f8855c8e9d0476812b48 Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 22 Oct 2009 07:37:31 -0000 --00163630f8855c8e9d0476812b48 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alex, I also read the draft, and I did not see any fundamental difference in with the draft the working group has been working on for months, i.e. draft-ietf-autoconf-adhoc-addr-model. This is quite reassuring: apparently the working group did not totally waste its time until now ;) More comments below. On Wed, Oct 21, 2009 at 11:42 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > AUTOCONFers, > > I just noticed this draft just announced: > > Internet-Drafts@ietf.org a =E9crit : > >> A URL for this Internet-Draft is: >> >> http://www.ietf.org/internet-drafts/draft-bernardos-autoconf-addressing-= model-00.txt >> > > This draft says, among others: > > MANET interfaces MUST also be configured with IPv6 Link-local >> addresses (as required by RFC 4861 [RFC4861] and RFC 4291 [RFC4291]). >> Two main concerns may arise when considering the use of IPv6 Link- >> local addresses: >> >> o Address uniqueness: the event of having two duplicate addresses in >> the same link has proved to be very low (EUI64 derived interface >> identifiers very rarely collide, since MAC addresses are expected >> to be globally unique), and even some mechanisms have been >> proposed to reduce the collision probability >> [I-D.soto-mobileip-random-iids]. Therefore, in most scenarios it >> is safe to assume that the probability of having two or more >> duplicated link-local addresses in a MANET is negiglible. For >> those scenarios, in which this cannot be safely assumed, we refer >> to the DAD considerations of Section 3.3. >> >> o Reachability: connectivity among neighbours in wireless links may >> be intermittent and/or short-lived. Therefore, the use of link- >> local addresses may lead to reachability issues, since two nodes >> that were in direct coverage range at one moment, might not be >> anymore shortly after. These problems might also arise in wired >> networks (nodes going up/down), but it is not the common case. >> >> Having brought to attention these concerns, it is further left to the >> designers of MANET routing protocols (and other protocols) to >> determine whether link-local addresses can be used in an effective >> way. >> > > I must say I fully agree with the above text, because it says link-locals > are "MUST". It is more positive towards link-locals, I agree with it. > draft-ietf-autoconf-adhoc-addr-model-00 says no different, in section 6.2: "an IPv6 link-local address is assigned to each interface as per [RFC4291]"= . Similarly, in the same section, the draft also mentions concerns with the use of link local addresses. The difference is that draft-ietf-autoconf-adhoc-addr-model-00 also concludes on the matter (a model should offer such conclusion in my mind, i= f not, it is not a model). The conclusion is, in section 6.2, that it "should be encouraged to primarily focus on configuring IP addresses that are not link-local". So in effect, link-locals are not forbidden, but their use is discouraged. Note that implicitely, the same conclusion is in draft-bernardos-autoconf-addressing-model-00.txt. > > I agree with it more than I agree with this text in > draft-ietf-autoconf-adhoc-addr-model-00.txt: > >> Note that while link-local addresses are assumed to be "on link", the >> utility of link-local addresses is limited as described in Section 6. >> > > ... which has a negative co-notation in that use of the "limited" word. > If you think the term "limitations" is too negative compared to the term "concerns" (used instead in draft-bernardos-autoconf-addressing-model-00.txt), swapping such words woul= d be an easy fix. Personally, I do not have any issues with this. If anybody has practical suggestions as to how to modify draft-ietf-autoconf-adhoc-addr-model-00, please let it be known at this point. Appart from word-tweaking here and there, it seems that we essentially all agree on the model. So let's move on to actually designing solutions... Regards, Emmanuel --00163630f8855c8e9d0476812b48 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alex,

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


On Wed, Oct 21, 2009 at 11:42 PM, Alexan= dru Petrescu <alexandru.petrescu@gmail.com> wrote:
AUTOCONFers,

I just noticed this draft just announced:

Internet-Draf= ts@ietf.org a =E9crit :
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts= /draft-bernardos-autoconf-addressing-model-00.txt

This draft says, among others:

=A0 MANET interfaces MUST also be configured with IPv6 Link-local
=A0 addresses (as required by RFC 4861 [RFC4861] and RFC 4291 [RFC4291]).<= br> =A0 Two main concerns may arise when considering the use of IPv6 Link-
=A0 local addresses:

=A0 o =A0Address uniqueness: the event of having two duplicate addresses i= n
=A0 =A0 =A0the same link has proved to be very low (EUI64 derived interfac= e
=A0 =A0 =A0identifiers very rarely collide, since MAC addresses are expect= ed
=A0 =A0 =A0to be globally unique), and even some mechanisms have been
=A0 =A0 =A0proposed to reduce the collision probability
=A0 =A0 =A0[I-D.soto-mobileip-random-iids]. =A0Therefore, in most scenario= s it
=A0 =A0 =A0is safe to assume that the probability of having two or more =A0 =A0 =A0duplicated link-local addresses in a MANET is negiglible. =A0Fo= r
=A0 =A0 =A0those scenarios, in which this cannot be safely assumed, we ref= er
=A0 =A0 =A0to the DAD considerations of Section 3.3.

=A0 o =A0Reachability: connectivity among neighbours in wireless links may=
=A0 =A0 =A0be intermittent and/or short-lived. =A0Therefore, the use of li= nk-
=A0 =A0 =A0local addresses may lead to reachability issues, since two node= s
=A0 =A0 =A0that were in direct coverage range at one moment, might not be<= br> =A0 =A0 =A0anymore shortly after. =A0These problems might also arise in wi= red
=A0 =A0 =A0networks (nodes going up/down), but it is not the common case.<= br>
=A0 Having brought to attention these concerns, it is further left to the<= br> =A0 designers of MANET routing protocols (and other protocols) to
=A0 determine whether link-local addresses can be used in an effective
=A0 way.

I must say I fully agree with the above text, because it says link-locals a= re "MUST". =A0It is more positive towards link-locals, I agree wi= th it.


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

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


=A0

I agree with it more than I agree with this text in draft-ietf-autoconf-adh= oc-addr-model-00.txt:
=A0 Note that while link-local addresses are assumed to be "on link&q= uot;, the
=A0 utility of link-local addresses is limited as described in Section 6.<= br>

... which has a negative co-notation in that use of the "limited"= word.


If you think the term "limitations= " is too negative compared to the term "concerns" (used inst= ead in draft-bernardos-autoconf-addressing-model-00.txt), swapping such wor= ds would be an easy fix. Personally, I do not have any issues with this.
If anybody has practical suggestions as to how to modify draft-ietf-aut= oconf-adhoc-addr-model-00, please let it be=A0 known at this point.
Appart from word-tweaking here and there, it seems that we essentially all= agree on the model. So let's move on to actually designing solutions..= .

Regards,

Emmanuel


--00163630f8855c8e9d0476812b48-- From ulrich@herberg.name Thu Oct 22 01:19: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 6806F3A67D4 for ; Thu, 22 Oct 2009 01:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[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 oJtdw0GTfOBZ for ; Thu, 22 Oct 2009 01:19:41 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 007F33A63EC for ; Thu, 22 Oct 2009 01:19:40 -0700 (PDT) Received: by fxm18 with SMTP id 18so8853178fxm.37 for ; Thu, 22 Oct 2009 01:19:47 -0700 (PDT) MIME-Version: 1.0 Sender: ulrich@herberg.name Received: by 10.204.11.18 with SMTP id r18mr9180152bkr.15.1256199586778; Thu, 22 Oct 2009 01:19:46 -0700 (PDT) In-Reply-To: <4ADF8F12.6020002@earthlink.net> References: <4ADF863E.8040408@gmail.com> <4ADF8F12.6020002@earthlink.net> Date: Thu, 22 Oct 2009 10:19:46 +0200 X-Google-Sender-Auth: d25f8b41ad15e322 Message-ID: <25c114b90910220119y26fe9ef7lcad24fe85a29f844@mail.gmail.com> From: Ulrich Herberg To: "Charles E. Perkins" Content-Type: multipart/alternative; boundary=00032555a15a230d67047681c2d7 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Procedure 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, 22 Oct 2009 08:19:42 -0000 --00032555a15a230d67047681c2d7 Content-Type: text/plain; charset=ISO-8859-1 Hi Alex, I agree with Charlie. While I also do not remember a discussion about whether to make the draft a working group draft, I do think it is a good idea. I also understand the chair's decision to publish the draft as WG draft before the deadline of draft submission last Monday. This working group is far behind schedule and we really need to progress, or otherwise the WG will die. I don't think it will help us now to start a long political discussion about whether the procedures of the chairs were appropriate or not. That said, I think that for future decisions, the chairs might consider a consensus call on the mailing list before submitting a new WG draft before the submission deadline. Best regards, Ulrich On Thu, Oct 22, 2009 at 12:45 AM, Charles E. Perkins < charles.perkins@earthlink.net> wrote: > Hello Alex, > > Alexandru Petrescu wrote: > >> Now it looks as if you better had gone the way of AD sponsoring, and not >> forming a DT working for a WG about which there seems to be little care - >> but much secrecy. Sorry to say so but that's my impression. >> >> You had a public mailing list on the DT - that was ok. But there's no >> discussion on it about this decision of submitting the DT draft into WG >> item. >> > > I don't remember the discussion about making the DT > draft into a WG item, and I was on the design team. > > Nevertheless, I do not feel threatened by any > trend towards secrecy. It's a lot more reasonable > to just imagine that the WG chairs were trying to > act in the best interest of the working group after > months and months of discussion. > > Discussion != secrecy. > > But anyway I agree it would have been better to > gauge consensus before making the DT draft into > a working-group document. Somehow, I thought > that had been done already, but I wasn't paying > attention so closely. > > >> How about the new autoconf document I just saw announced and to which I >> agree much more? (about link-local addresses: it starts saying they are a >> MUST) - I agree to that stance much more than the DT document. >> > > You never responded to my explanation about > why your proposed solution to the 4-node problem > would almost certainly fail. So as far as I can tell > this desire for mandating Link-Local is religion and > not any sort of engineering. > > A stance is an opinion, not necessarily bolstered > by facts or the possibility of making progress. > > >> >> Please fix this - it's not my problem (don't tell me I already agreed with >> the DT text on link-locals) - this is a WG caring problem. >> > > Here I really disagree. Why do you say > there is a problem with "WG caring"? I am > not sure what that means, but it sounds bad. > In my opinion, with my interactions on the list > and discussions on the design team, the WG > chairs have shown me that they do care for the > health of the working group. > > Do you claim otherwise? > > Regards, > Charlie P. > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > --00032555a15a230d67047681c2d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alex,

I agree with Charlie. While I also do not remember a discus= sion about whether to make the draft a working group draft, I do think it i= s a good idea. I also understand the chair's decision to publish the dr= aft as WG draft before the deadline of draft submission last Monday. This w= orking group is far behind schedule and we really need to progress, or othe= rwise the WG will die. I don't think it will help us now to start a lon= g political discussion about whether the procedures of the chairs were appr= opriate or not.
That said, I think that for future decisions, the chairs might consider a c= onsensus call on the mailing list before submitting a new WG draft before t= he submission deadline.

Best regards,
Ulrich



On Thu, Oct 22, 2009 at 12:45 AM, Charles E. Perkins <= charles.perkins@earthlink.= net> wrote:
Hello Alex,


Alexandru Petrescu wrote:
Now it looks as if you better had gone the way of AD sponsoring, and not fo= rming a DT working for a WG about which there seems to be little care - but= much secrecy. =A0Sorry to say so but that's my impression.

You had a public mailing list on the DT - that was ok. =A0But there's n= o discussion on it about this decision of submitting the DT draft into WG i= tem.

I don't remember the discussion about making the DT
draft into a WG item, and I was on the design team.

Nevertheless, I do not feel threatened by any
trend towards secrecy. =A0It's a lot more reasonable
to just imagine that the WG chairs were trying to
act in the best interest of the working group after
months and months of discussion.

Discussion !=3D secrecy.

But anyway I agree it would have been better to
gauge consensus before making the DT draft into
a working-group document. =A0Somehow, I thought
that had been done already, but I wasn't paying
attention so closely.



How about the new autoconf document I just saw announced and to which I agr= ee much more? =A0(about link-local addresses: it starts saying they are a M= UST) - I agree to that stance much more than the DT document.

You never responded to my explanation about
why your proposed solution to the 4-node problem
would almost certainly fail. =A0 So as far as I can tell
this desire for mandating Link-Local is religion and
not any sort of engineering.

A stance is an opinion, not necessarily bolstered
by facts or the possibility of making progress.




Please fix this - it's not my problem (don't tell me I already agre= ed with the DT text on link-locals) - this is a WG caring problem.

Here I really disagree. =A0Why do you say
there is a problem with "WG caring"? =A0I am
not sure what that means, but it sounds bad.
In my opinion, with my interactions on the list
and discussions on the design team, the WG
chairs have shown me that they do care for the
health of the working group.

Do you claim otherwise?

Regards,
Charlie P.


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

--00032555a15a230d67047681c2d7-- From ulrich@herberg.name Thu Oct 22 01:21: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 203503A6918 for ; Thu, 22 Oct 2009 01:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6] 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 tGsGZPoH3lLJ for ; Thu, 22 Oct 2009 01:21:39 -0700 (PDT) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id A1D2F3A6837 for ; Thu, 22 Oct 2009 01:21:38 -0700 (PDT) Received: by bwz23 with SMTP id 23so430620bwz.29 for ; Thu, 22 Oct 2009 01:21:44 -0700 (PDT) MIME-Version: 1.0 Sender: ulrich@herberg.name Received: by 10.204.153.198 with SMTP id l6mr8998623bkw.191.1256199703000; Thu, 22 Oct 2009 01:21:43 -0700 (PDT) In-Reply-To: <4ADFD8E9.8070209@earthlink.net> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <4ADFD8E9.8070209@earthlink.net> Date: Thu, 22 Oct 2009 10:21:42 +0200 X-Google-Sender-Auth: 3040e3a9c49e4fcd Message-ID: <25c114b90910220121y1ecd87d7n4d6c82e96cd1d83b@mail.gmail.com> From: Ulrich Herberg To: "Charles E. Perkins" Content-Type: multipart/alternative; boundary=0015175ce28c1078f4047681c9e3 Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model 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, 22 Oct 2009 08:21:40 -0000 --0015175ce28c1078f4047681c9e3 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 22, 2009 at 6:00 AM, Charles E. Perkins < charles.perkins@earthlink.net> wrote: > I think that the WG should proceed with > draft-ietf-autoconf-adhoc-addr-model as a baseline. > Me too. Ulrich > > Thomas Heide Clausen wrote: > >> All, >> >> It appeared to the chairs that the comments raised at the Stockholm IETF, >> as well as on the list subsequently, concerning the document: >> >> http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model >> >> had been addressed fully by the editors, and to the WGs satisfaction - at >> least, there were no issue raised to the latter/latest version hereof. The >> chairs therefore found it a good idea to move the document forward as a WG >> document, and progress this document as such. We therefore approved for >> publication: >> >> http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model >> >> We (the chairs) still believe that this is the proper approach in order >> to make progress for the WG. >> >> Do note that the WG is 7 months past the milestone for initial document >> submission, and 1 month past the milestone for having progressed the >> document to the IESG and/or closed up shop! And, there has been no >> discussions (in meetings or on this list) on alternative candidate documents >> for the work item which [autoconf] is chartered to accomplish. >> To put it bluntly, this WG is far far behind schedule and this document >> seemed, and still seems, by virtue of having been widely discussed and >> agreed upon, as the best shot at making progress for this WG. >> >> That said, we (and, this we is also the chairs) will take this opportunity >> to ask the WGs opinion on how to progress. If you have any opinion, please >> let it be known to the WG (via this mailing list) before 29/10/09 (i.e. >> Thursday next week) at noon CET. Please be specific and constructive, i.e., >> pick one of: >> >> o if you think that the WG should proceed with >> draft-ietf-autoconf-adhoc-addr-model >> as a baseline, say so! >> o if you think there're cardinal (but fixable) issues missing or wrong >> with draft-ietf-autoconf-adhoc-addr-model, then let the WG know what these >> issues are, and propose a solution before the deadline. The Editors will >> certainly do their best to address the issues. >> >> o if you think that draft-ietf-autoconf-adhoc-addr-model is beyond hope, >> let the WG know explicitly how you suggest that we progress at this point >> -- considering the current timeline!! >> >> Cheers, >> >> Ryuji & Thomas >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 > --0015175ce28c1078f4047681c9e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Oct 22, 2009 at 6:00 AM, Charles E. = Perkins <charles.perkins@earthlink.net> wrote:
I think that the WG should proceed with draft-ietf-autoconf-adhoc-addr-mode= l as a baseline.

Me too.

Ulrich

=A0<= /div>

Thomas Heide Clausen wrote:
<= div class=3D"h5"> All,

It appeared to the chairs that the comments raised at the Stockholm IETF, a= s well as on the list subsequently, concerning the document:

http://tools.ietf.org/html/draft-baccelli-autoconf-a= dhoc-addr-model

had been addressed fully by the editors, and to the WGs satisfaction - at l= east, there were no issue raised to the latter/latest version hereof. The c= hairs therefore found it a good idea to move the document forward as a WG d= ocument, and progress this document as such. We therefore approved for publ= ication:

http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-add= r-model

We (the chairs) =A0still believe that this is the proper approach in order = to make progress for the WG.

Do note that the WG is 7 months past the milestone for initial document sub= mission, and 1 month past the milestone for having progressed the document = to the IESG and/or closed up shop! =A0And, there has been no discussions (i= n meetings or on this list) on alternative candidate documents for the work= item which [autoconf] is chartered to accomplish.
To put it bluntly, this WG is far far behind schedule and this document see= med, and still seems, by virtue of having been widely discussed and agreed = upon, as the best shot at making progress for this WG.

That said, we (and, this we is also the chairs) will take this opportunity = to ask the WGs opinion on how to progress. If you have any opinion, please = let it be known to the WG (via this mailing list) before 29/10/09 (i.e. Thu= rsday next week) at noon CET. Please be specific and constructive, i.e., pi= ck one of:

o if you think that the WG should proceed with draft-ietf-autoconf-adhoc-ad= dr-model
as a baseline, say so!
o if you think there're cardinal (but fixable) issues missing or wrong = with draft-ietf-autoconf-adhoc-addr-model, then let the WG know what these = issues are, and propose a solution before the deadline. The Editors will ce= rtainly do their best to address the issues.

o if you think that draft-ietf-autoconf-adhoc-addr-model is beyond hope, le= t the WG know explicitly how you suggest that we progress =A0at this point = -- =A0considering the current timeline!!

Cheers,

Ryuji & Thomas
------------------------------------------------------------------------

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

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

--0015175ce28c1078f4047681c9e3-- From alexandru.petrescu@gmail.com Thu Oct 22 05:37: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 7435C3A69FD for ; Thu, 22 Oct 2009 05:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AWL=0.173, 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 hOPWx3es4F8O for ; Thu, 22 Oct 2009 05:37:42 -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 5824A3A69EF for ; Thu, 22 Oct 2009 05:37:41 -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 n9MCbmZV030512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Oct 2009 14:37:48 +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 n9MCbmk3023129; Thu, 22 Oct 2009 14:37:48 +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 n9MCbm2h017567; Thu, 22 Oct 2009 14:37:48 +0200 Message-ID: <4AE0521C.4090005@gmail.com> Date: Thu, 22 Oct 2009 14:37:48 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ryuji Wakikawa References: <4ADF863E.8040408@gmail.com> <6B0ACB39-C603-48FA-89FC-8A887BD1BC7D@gmail.com> In-Reply-To: <6B0ACB39-C603-48FA-89FC-8A887BD1BC7D@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Procedure 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, 22 Oct 2009 12:37:43 -0000 Ryuji Wakikawa a écrit : > Hi Alex, > > On 2009/10/21, at 15:07, Alexandru Petrescu wrote: > >>> From: RYUJI WAKIKAWA To: Alexandru Petrescu >>> Date: Wed, 21 Oct 2009 14:40:26 -0700 >>> Subject: Re: Procedure Hi Alex, >>> On 2009/10/21, at 14:32, Alexandru Petrescu wrote: >>>> Ryuji, >>>> This is the second time things go strange in this WG. The first >>>> time was at the DT formation time. >>> what was the problem of the DT formation time? >> >> DT announcement after DT announcement. I will not remind you now but I >> talked about it at the time on the jabber and on the mailing list. > > announcement after formation? What was the problem here? > That was what Chairs and ADs have agreed. > >> >>> After revising the WG charter, we formed a DT to identify the clear >>> WG item. >> >> Now it looks as if you better had gone the way of AD sponsoring, and >> not forming a DT working for a WG about which there seems to be little >> care - but much secrecy. Sorry to say so but that's my impression. >> >> You had a public mailing list on the DT - that was ok. But there's no >> discussion on it about this decision of submitting the DT draft into >> WG item. >> >>>> With respect to this document, it is not up to me to speak, but it >>>> may be the case that another draft may talk same title as this >>>> draft. >>> DT is not officially formed to produce an individual document. We >>> clearly spent so much time to improve this document. >> >> How about the new autoconf document I just saw announced and to which >> I agree much more? (about link-local addresses: it starts saying they >> are a MUST) - I agree to that stance much more than the DT document. > > AFAIK, the document conflicts with what we have agreed so far in WG, > specially LL address stuff. Ryuji, I don't trust this. This is all about confidence. One can't build confidence this way. Following the list of past events, I can expect there will be no LC on the WG item document either, ship straight to IESG. And this is what AD sponsoring is about, you don't need a WG at all. And hence frustration grows and distrust builds up. >> In that sense I agree much more with that new draft than with the DT >> draft. > > What was the previous consensus call for then? That is right, the consensus call was for the LL addresses stuff. But why no consensus call on adoption of the DT document? >> Please fix this - it's not my problem (don't tell me I already agreed >> with the DT text on link-locals) - this is a WG caring problem. > > How do you want us to fix it? sending consensus call to adapt > draft-bacelli? Isn't it too late for that? How do "adopt" a document already submitted as WG item? Alex > > regards, > ryuji > > >> >> Alex >> >>> ryuji >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > From alexandru.petrescu@gmail.com Thu Oct 22 05:47: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 DCAB33A68E5 for ; Thu, 22 Oct 2009 05:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.342 X-Spam-Level: X-Spam-Status: No, score=-1.342 tagged_above=-999 required=5 tests=[AWL=-0.582, BAYES_05=-1.11, 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 k3M8CiiQ62do for ; Thu, 22 Oct 2009 05:47:29 -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 C3F9B3A6874 for ; Thu, 22 Oct 2009 05:47:28 -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 n9MCla4F012597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Oct 2009 14:47:36 +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 n9MClaPv026382; Thu, 22 Oct 2009 14:47:36 +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 n9MClZs7021718; Thu, 22 Oct 2009 14:47:35 +0200 Message-ID: <4AE05467.4030100@gmail.com> Date: Thu, 22 Oct 2009 14:47:35 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4ADF863E.8040408@gmail.com> <4ADF8F12.6020002@earthlink.net> In-Reply-To: <4ADF8F12.6020002@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Procedure 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, 22 Oct 2009 12:47:30 -0000 Charles E. Perkins a écrit : > Hello Alex, > > Alexandru Petrescu wrote: >> Now it looks as if you better had gone the way of AD sponsoring, >> and not forming a DT working for a WG about which there seems to be >> little care - but much secrecy. Sorry to say so but that's my >> impression. >> >> You had a public mailing list on the DT - that was ok. But there's >> no discussion on it about this decision of submitting the DT draft >> into WG item. > > I don't remember the discussion about making the DT draft into a WG > item, and I was on the design team. > > Nevertheless, I do not feel threatened by any trend towards secrecy. > It's a lot more reasonable to just imagine that the WG chairs were > trying to act in the best interest of the working group after months > and months of discussion. This is a choice you made. Months and months of discussion about LL stuff - yes, tiring. At the end, I decided myself I could live with LLs as the DT document says they are, and proceed. At the same time, this new document was submitted, and has LL text in which is much more appropriate to my thoughts. Were the Chairs to raise a question today: "which LL text you prefer? DT draft's LL text? Or new-draft LL's text" I'd surely vote for the second. > Discussion != secrecy. Right. > But anyway I agree it would have been better to gauge consensus > before making the DT draft into a working-group document. Somehow, I > thought that had been done already, but I wasn't paying attention so > closely. Ok. >> How about the new autoconf document I just saw announced and to >> which I agree much more? (about link-local addresses: it starts >> saying they are a MUST) - I agree to that stance much more than the >> DT document. > > You never responded to my explanation about why your proposed > solution to the 4-node problem would almost certainly fail. So as > far as I can tell this desire for mandating Link-Local is religion > and not any sort of engineering. Hey, Charles, you never responded to my mail which was a response to yours. If you want me, I can respond to yours. But why should I spent the effort when I see that the WG is not even consulted at WG item adoption. > A stance is an opinion, not necessarily bolstered by facts or the > possibility of making progress. > >> >> >> Please fix this - it's not my problem (don't tell me I already >> agreed with the DT text on link-locals) - this is a WG caring >> problem. > > Here I really disagree. Why do you say there is a problem with "WG > caring"? I am not sure what that means, but it sounds bad. IT sounds bad, because I feel like the Chairs do not care of the WG opinion. This is as explicit as it sounds. > In my opinion, with my interactions on the list and discussions on > the design team, the WG chairs have shown me that they do care for > the health of the working group. > > Do you claim otherwise? Charles, yes - I claim otherwise. I claim that submitting a WG item without consulting the WG is sign of not caring ("to care") of the WG opinion. Alex From alexandru.petrescu@gmail.com Thu Oct 22 06:09:27 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 37F783A6A0B for ; Thu, 22 Oct 2009 06:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.052 X-Spam-Level: X-Spam-Status: No, score=-2.052 tagged_above=-999 required=5 tests=[AWL=0.197, 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 Lja5cEfyVdbF for ; Thu, 22 Oct 2009 06:09:26 -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 F3C883A68A2 for ; Thu, 22 Oct 2009 06:09:25 -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 n9MD9Wbm010783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Oct 2009 15:09:32 +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 n9MD9WXE000741; Thu, 22 Oct 2009 15:09:32 +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 n9MD9VjF030713; Thu, 22 Oct 2009 15:09:31 +0200 Message-ID: <4AE0598B.5040600@gmail.com> Date: Thu, 22 Oct 2009 15:09:31 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ulrich Herberg References: <4ADF863E.8040408@gmail.com> <4ADF8F12.6020002@earthlink.net> <25c114b90910220119y26fe9ef7lcad24fe85a29f844@mail.gmail.com> In-Reply-To: <25c114b90910220119y26fe9ef7lcad24fe85a29f844@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Procedure 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, 22 Oct 2009 13:09:27 -0000 Hi Ulrich, Ulrich Herberg a écrit : > Hi Alex, > > I agree with Charlie. While I also do not remember a discussion about > whether to make the draft a working group draft, I do think it is a good > idea. I also understand the chair's decision to publish the draft as WG > draft before the deadline of draft submission last Monday. This working > group is far behind schedule and we really need to progress, or > otherwise the WG will die. I don't think it will help us now to start a > long political discussion about whether the procedures of the chairs > were appropriate or not. This is not about politics. This is about procedure. Procedure is what sticks groups together geared towards one goal, procedure is what builds confidence among people rarely meeting and with otherwise very different interests. Without procedure there would be no WG, no DT, no IETF. Of course, blindly following procedures is not necessarily productive - it's good to challenge the establishment. And right now the establishment is the variable-geometry DT which has the most voices and choices in this WG. > That said, I think that for future decisions, the chairs might consider > a consensus call on the mailing list before submitting a new WG draft > before the submission deadline. That sounds as a good idea for future decisions, I agree with you. For this document, an approach could be to ship this document to IESG as AD sponsored. Alex > > Best regards, > Ulrich > > > > On Thu, Oct 22, 2009 at 12:45 AM, Charles E. Perkins > > > wrote: > > Hello Alex, > > > Alexandru Petrescu wrote: > > Now it looks as if you better had gone the way of AD sponsoring, > and not forming a DT working for a WG about which there seems to > be little care - but much secrecy. Sorry to say so but that's > my impression. > > You had a public mailing list on the DT - that was ok. But > there's no discussion on it about this decision of submitting > the DT draft into WG item. > > > I don't remember the discussion about making the DT > draft into a WG item, and I was on the design team. > > Nevertheless, I do not feel threatened by any > trend towards secrecy. It's a lot more reasonable > to just imagine that the WG chairs were trying to > act in the best interest of the working group after > months and months of discussion. > > Discussion != secrecy. > > But anyway I agree it would have been better to > gauge consensus before making the DT draft into > a working-group document. Somehow, I thought > that had been done already, but I wasn't paying > attention so closely. > > > > How about the new autoconf document I just saw announced and to > which I agree much more? (about link-local addresses: it starts > saying they are a MUST) - I agree to that stance much more than > the DT document. > > > You never responded to my explanation about > why your proposed solution to the 4-node problem > would almost certainly fail. So as far as I can tell > this desire for mandating Link-Local is religion and > not any sort of engineering. > > A stance is an opinion, not necessarily bolstered > by facts or the possibility of making progress. > > > > > Please fix this - it's not my problem (don't tell me I already > agreed with the DT text on link-locals) - this is a WG caring > problem. > > > Here I really disagree. Why do you say > there is a problem with "WG caring"? I am > not sure what that means, but it sounds bad. > In my opinion, with my interactions on the list > and discussions on the design team, the WG > chairs have shown me that they do care for the > health of the working group. > > Do you claim otherwise? > > Regards, > Charlie P. > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > > From alexandru.petrescu@gmail.com Thu Oct 22 06:15: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 A3CC228C154 for ; Thu, 22 Oct 2009 06:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[AWL=0.186, 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 ly2C4MIpWNvg for ; Thu, 22 Oct 2009 06:15:23 -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 973BD28C151 for ; Thu, 22 Oct 2009 06:15:23 -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 n9MDFWX8014377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Oct 2009 15:15:32 +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 n9MDFVkt003035; Thu, 22 Oct 2009 15:15:31 +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 n9MDFVP3001462; Thu, 22 Oct 2009 15:15:31 +0200 Message-ID: <4AE05AF3.9060303@gmail.com> Date: Thu, 22 Oct 2009 15:15:31 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Emmanuel Baccelli References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@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] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 22 Oct 2009 13:15:24 -0000 Hi Emmanuel, I will go straight to our core issues below: Emmanuel Baccelli a écrit : [...] > The difference is that draft-ietf-autoconf-adhoc-addr-model-00 also > concludes on the matter (a model should offer such conclusion in my > mind, if not, it is not a model). The conclusion is, in section 6.2, > that it "should be encouraged to primarily focus on configuring IP > addresses that are not link-local". > So in effect, link-locals are not > forbidden, but their use is discouraged. We keep talking past each other. I maintain the use of LL addresses should be encouraged in MANETs. > Note that implicitely, the same > conclusion is in draft-bernardos-autoconf-addressing-model-00.txt. That draft starts with a clear "MUST LL" and then recommend to implementer to use when appropriate. >> ... which has a negative co-notation in that use of the "limited" word. > > > > If you think the term "limitations" is too negative compared to the term > "concerns" (used instead in > draft-bernardos-autoconf-addressing-model-00.txt), swapping such words > would be an easy fix. Personally, I do not have any issues with this. > > If anybody has practical suggestions as to how to modify > draft-ietf-autoconf-adhoc-addr-model-00, please let it be known at this > point. Why should I? Only to get a reply back saying it is not good? > Appart from word-tweaking here and there, it seems that we essentially > all agree on the model. So let's move on to actually designing solutions... Not this way, sorry... Alex From emmanuel.baccelli@gmail.com Thu Oct 22 06:35: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 9B2A028B797 for ; Thu, 22 Oct 2009 06:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.694 X-Spam-Level: X-Spam-Status: No, score=-1.694 tagged_above=-999 required=5 tests=[AWL=0.282, 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 fAhN36IA7I1e for ; Thu, 22 Oct 2009 06:35:14 -0700 (PDT) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 80F333A67C1 for ; Thu, 22 Oct 2009 06:35:14 -0700 (PDT) Received: by gxk28 with SMTP id 28so6964954gxk.9 for ; Thu, 22 Oct 2009 06:35:21 -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=FuMScBT19tEoR7ZhMjbOhe7I1XiFW4K76FaE7v/n4Fs=; b=ZQcNzvKXqvNGPPOCiiwggStqg2mMNUg+QA32HdcXJrnwjoHHLRau9jJ+YnBKd7aT2D g5xpwD7SncHSXKlGn6SQ3VhcsCu0y+MxTOJXttqBsBdWvlMrPE0YD7m8ZeN7ZOoRNqSn 2xk6RB4L0M8s8j20bX5zDa7Uo1PTKrWJHf+TA= 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=FDCAYI9oRsJjBBlZbD4/L7lSgaMu5P+gAyVeVv8ZwgLJnkaJ5ulXh+NTGQ6OVEKzy7 CaFObekh+PKkwgYAMlqwwOU2JYb7z5QJkaycTBkZ8j2m2y+3Uv87BpNYTpSaAHWn/aly DmVSkBINYuuIUogGvHZCNntEZtqgwGX6YkSro= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.90.222.1 with SMTP id u1mr5956914agg.103.1256218521356; Thu, 22 Oct 2009 06:35:21 -0700 (PDT) In-Reply-To: <4AE0598B.5040600@gmail.com> References: <4ADF863E.8040408@gmail.com> <4ADF8F12.6020002@earthlink.net> <25c114b90910220119y26fe9ef7lcad24fe85a29f844@mail.gmail.com> <4AE0598B.5040600@gmail.com> From: Emmanuel Baccelli Date: Thu, 22 Oct 2009 15:35:01 +0200 X-Google-Sender-Auth: 0da4a1710168149b Message-ID: To: "autoconf@ietf.org" Content-Type: multipart/alternative; boundary=001636283e94b9cb640476862a27 Subject: Re: [Autoconf] Procedure 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, 22 Oct 2009 13:35:15 -0000 --001636283e94b9cb640476862a27 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alex,see below. On Thu, Oct 22, 2009 at 3:09 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Hi Ulrich, > > Ulrich Herberg a =E9crit : > >> Hi Alex, >> >> I agree with Charlie. While I also do not remember a discussion about >> whether to make the draft a working group draft, I do think it is a good >> idea. I also understand the chair's decision to publish the draft as WG >> draft before the deadline of draft submission last Monday. This working >> group is far behind schedule and we really need to progress, or otherwis= e >> the WG will die. I don't think it will help us now to start a long polit= ical >> discussion about whether the procedures of the chairs were appropriate o= r >> not. >> > > This is not about politics. > > This is about procedure. Procedure is what sticks groups together geared > towards one goal, procedure is what builds confidence among people rarely > meeting and with otherwise very different interests. > > Without procedure there would be no WG, no DT, no IETF. > > Of course, blindly following procedures is not necessarily productive - > it's good to challenge the establishment. > > And right now the establishment is the variable-geometry DT which has the > most voices and choices in this WG. > > That said, I think that for future decisions, the chairs might consider = a >> consensus call on the mailing list before submitting a new WG draft befo= re >> the submission deadline. >> > > That sounds as a good idea for future decisions, I agree with you. > > For this document, an approach could be to ship this document to IESG as = AD > sponsored. > > Alex > > Or we could continue what we have been doing for several months: incrementa= l improvement of the draft with the feedback from the working group, and then send to the IESG. Thus, from my point of view, your comments are simply unfair. I, as author of draft-ietf-autoconf-adhoc-addr-model-00, feel like we have been working together in this WG, for a long time, to get to this document which describes the rough consensus on the question. Do check the archive of the Autoconf mailing list if you need to. So I would appreciate if debatable and purely procedural considerations wer= e not wrongly mixed with the technical work that has indeed taken place until now. Let's remain practical here, if we are to get anywhere! Emmanuel --001636283e94b9cb640476862a27 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alex,
see below.

On Thu, Oct 22, 2009= at 3:09 PM, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrot= e:
Hi Ulrich,

Ulrich Herberg a =E9crit :

Hi Alex,

I agree with Charlie. While I also do not remember a discussion about wheth= er to make the draft a working group draft, I do think it is a good idea. I= also understand the chair's decision to publish the draft as WG draft = before the deadline of draft submission last Monday. This working group is = far behind schedule and we really need to progress, or otherwise the WG wil= l die. I don't think it will help us now to start a long political disc= ussion about whether the procedures of the chairs were appropriate or not.<= br>

This is not about politics.

This is about procedure. =A0Procedure is what sticks groups together geared= towards one goal, procedure is what builds confidence among people rarely = meeting and with otherwise very different interests.

Without procedure there would be no WG, no DT, no IETF.

Of course, blindly following procedures is not necessarily productive - it&= #39;s good to challenge the establishment.

And right now the establishment is the variable-geometry DT which has the m= ost voices and choices in this WG.


That said, I think that for future decisions, the chairs might consider a c= onsensus call on the mailing list before submitting a new WG draft before t= he submission deadline.

That sounds as a good idea for future decisions, I agree with you.

For this document, an approach could be to ship this document to IESG as AD= sponsored.

Alex


Or we could continue what we h= ave been doing for several months: incremental improvement of the draft wit= h the feedback from the working group, and then send to the IESG.=A0

Thus,=A0from my point of view, your comments are simply= unfair. I, as author of=A0draft-ietf-autoconf-adhoc-addr-model-00, feel li= ke we have been working together in this WG, for a long time, to get to thi= s document which describes the rough consensus on the question. Do check th= e archive of the Autoconf mailing list if you need to.

So I would appreciate if debatable and purely procedura= l considerations were not wrongly mixed with the technical work that has in= deed taken place until now. Let's remain practical here, if we are to g= et anywhere!

Emmanuel


--001636283e94b9cb640476862a27-- From alexandru.petrescu@gmail.com Thu Oct 22 06:36: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 066C13A692B for ; Thu, 22 Oct 2009 06:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.176, 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 qkbvhKl1HISB for ; Thu, 22 Oct 2009 06:36:16 -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 CA2A33A686D for ; Thu, 22 Oct 2009 06:36:15 -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 n9MDWkt1031831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Oct 2009 15:32:46 +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 n9MDWjsL008578; Thu, 22 Oct 2009 15:32:45 +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 n9MDWi7S008428; Thu, 22 Oct 2009 15:32:45 +0200 Message-ID: <4AE05EFC.2060501@gmail.com> Date: Thu, 22 Oct 2009 15:32:44 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Mark Townsley References: <4ADED440.2080403@cisco.com> In-Reply-To: <4ADED440.2080403@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] IPv4 link-locals 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, 22 Oct 2009 13:36:17 -0000 Mark Townsley a écrit : > > Fred wrote: >> Emmanuel, >> >> Section 6.1 of your draft should say the same thing about IPv4 >> link-local addresses [RFC3927] as was said about IPv6 link-local >> addresses in Section 6.2. The only difference being that when (or >> rather if) an IPv4 interface configures a routable address the >> link-local one is typically deprecated. >> >> Fred > > Fred, this is the text that ended up in -00: > > Note that the use of IPv4 link-local addresses [RFC3927] in this > context should be discouraged for most applications, as the > limitations outlined in Section 6.2 for IPv6 link-local addresses > also concern IPv4 link-local addresses. These limitations are > further exacerbated by the smaller pool of IPv4 link-local addresses > to choose from and thus increased reliance on DAD. > > However, I think that we need to say a little more here to your > point. Also, I think that while it is reasonable to discourage > link-local usage in IPv6 (as hopefully we are more able to readily > autoconfigure a ULA or Global Ipv6 address) the situation in IPv4 is > a bit different as obtaining a unique Global or Private IPv4 address > may be quite a bit more difficult. Therefore, usage of IPv4 > link-locals may be necessary in some cases (I'm thinking of > mdns-based service discovery, for example). So, I'd like to propose > something like this: > > "The use of IPv4 link-local addresses [RFC3927] is discouraged for > most applications. I disagree. I have an example showing otherwise. ActiveSync is run on a large share of the current market devices pertaining to MANETs. They all do IPv4 link-local addresses for a very wide range of applications. One can't "discourage" that. One should first ack the widespread deployment of IPv4 link-local address use. > The limitations outlined in Section 6.2 for IPv6 link-local addresses > also concern IPv4 link-local addresses, and are further exacerbated > by the smaller pool of IPv4 link-local addresses to choose from and > thus increased reliance on DAD. However, given the increased > difficulty of obtaining a Global or Private [RFC1918] IPv4 address, Which difficulty? I personally have the feeling it's more and more easy to obtain public IPv4 addresses. I had to struggle in 2000 for a class C, but a few months ago I could get one very easily. Maybe because people rush to IPv6 deployment... Maybe a reference should be given here to support the statement that public IPv4 addresses are hard to get, and for whom. (a fast reader would be tempted into thinking that the [RFC1918] is such a reference, but no). > use of IPv4 link-locals may be the only readily available option in > some circumstances. Applications running in an ad-hoc environment > must be well-aware that link-connectivity is constantly in flux, and > if link-locals are used, ensure that this is not a detrimental factor > to proper operation. An application that may be able to use IPv4 > link-locals effectively is one that consists of a stateless > request-response action and no more. Er? What is this? My web browser on my PDA is such a "stateless request-response action"? And my gps IP tools too? Both use IPv4 link-local addresses. > An application that may not operate with IPv4 link-locals effectively > is one that relies on nodes to have a consistent or long-lived IPv4 > address (e.g., connection-oriented communication bound to the IP > address). Why? An IPv4 link-local address can be very long-lived. Typically apps on devices with IPv4 link-local addresses live behind NATs. These NATs may change their "CoA" address (if I can say so) and may have problems because of that. But that is the problem of these NATs, not of the device using hte IPv4 link-local address. > In the event an interface obtains a non-link-local IPv4 > address, the link-local IPv4 address should be deprecated." Well, it depends for which purpose? Which protocol? Which application? I think there are IPv4 apps and protocols which can only use IPv4 link-local addresses, even if there is an IPv4 global address on the interface. I think you already say so at the beginning (mDNS). There's also ActiveSync app. Alex > > - Mark > > > > > > > > > _______________________________________________ Autoconf mailing list > Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf > From cjbc@it.uc3m.es Thu Oct 22 09:03: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 0F41E3A6927 for ; Thu, 22 Oct 2009 09:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.166 X-Spam-Level: X-Spam-Status: No, score=-5.166 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_52=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 cOHnwXYyMWl0 for ; Thu, 22 Oct 2009 09:03:07 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 8BF7628B797 for ; Thu, 22 Oct 2009 09:03:07 -0700 (PDT) Received: from [IPv6:::1] (luciernaga.it.uc3m.es [163.117.140.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id C39B0656AAA; Thu, 22 Oct 2009 18:03:15 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Thomas Heide Clausen In-Reply-To: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-SBW8y2eG5KEcWxhb1OM9" Organization: Universidad Carlos III de Madrid Date: Thu, 22 Oct 2009 18:03:16 +0200 Message-Id: <1256227396.6218.19.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16964.000 Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model 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: Thu, 22 Oct 2009 16:03:09 -0000 --=-SBW8y2eG5KEcWxhb1OM9 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Thomas, My individual and personal opinion -- also biased, since I'm co-authoring draft-bernardos-autoconf-addressing-model-00 (btw, we plan to submit a -01 before the cutoff deadline) -- is that since we now have one alternative candidate document for the work item which [autoconf] is chartered to accomplish (when we were working on it we didn't know there was already a WG document on this charter item), we may consider as WG our document as input as well. Then, we may have at least some discussion (on the ML -- please wait until we release -01 if you don't mind) and in Hiroshima (if we can present our draft) and then make a similar call as you did below, potentially considering somehow also the input that draft-bernardos-autoconf-addressing-model may bring (if the WG considers there is any). I know that we are late, we have been unfortunately always late in this WG (I participated in the BOF in 2005 and kept on contributing somehow since then, and still we haven't achieved any milestone, more than 4 years later). But still, I don't see this as a valid reason for taking decisions in a hurry (such as adopting WG documents without asking the WG), and I honestly think it would be good for the WG to have the chance to have some discussion on our draft and then come up with the best possible input that the WG can produce. Just my -- unavoidable (although I fought not to be) biased -- opinion on this. Thanks, Carlos On Thu, 2009-10-22 at 01:49 +0200, Thomas Heide Clausen wrote: > All, >=20 >=20 > It appeared to the chairs that the comments raised at the Stockholm > IETF, as well as on the list subsequently, concerning the document: >=20 >=20 > http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model >=20 >=20 > had been addressed fully by the editors, and to the WGs satisfaction - > at least, there were no issue raised to the latter/latest version > hereof. The chairs therefore found it a good idea to move the document > forward as a WG document, and progress this document as such. We > therefore approved for publication: >=20 >=20 > http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model >=20 >=20 > We (the chairs) still believe that this is the proper approach in > order to make progress for the WG. >=20 >=20 > Do note that the WG is 7 months past the milestone for initial > document submission, and 1 month past the milestone for having > progressed the document to the IESG and/or closed up shop! And, there > has been no discussions (in meetings or on this list) on alternative > candidate documents for the work item which [autoconf] is chartered to > accomplish.=20 >=20 >=20 > To put it bluntly, this WG is far far behind schedule and this > document seemed, and still seems, by virtue of having been widely > discussed and agreed upon, as the best shot at making progress for > this WG. >=20 >=20 > That said, we (and, this we is also the chairs) will take this > opportunity to ask the WGs opinion on how to progress. If you have any > opinion, please let it be known to the WG (via this mailing list) > before 29/10/09 (i.e. Thursday next week) at noon CET. Please be > specific and constructive, i.e., pick one of: >=20 >=20 > o if you think that the WG should proceed > with draft-ietf-autoconf-adhoc-addr-model > as a baseline, say so!=20 >=20 >=20 > o if you think there're cardinal (but fixable) issues missing or wrong > with=20 > draft-ietf-autoconf-adhoc-addr-model, then let the WG know what these=20 > issues are, and propose a solution before the deadline. The Editors=20 > will certainly do their best to address the issues. >=20 >=20 > o if you think that draft-ietf-autoconf-adhoc-addr-model is beyond > hope,=20 > let the WG know explicitly how you suggest that we progress at this > point --=20 > considering the current timeline!! >=20 >=20 > Cheers, >=20 >=20 > Ryuji & Thomas > _______________________________________________ > 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 --=-SBW8y2eG5KEcWxhb1OM9 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) iEYEABECAAYFAkrggkQACgkQNdy6TdFwT2fEugCgoU5ds/mwuQZeqDY1KgINrqJI 80cAoLsX06Xscd6+51AB4P2qlCvlje8R =dsg2 -----END PGP SIGNATURE----- --=-SBW8y2eG5KEcWxhb1OM9-- From charles.perkins@earthlink.net Thu Oct 22 09:30: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 594643A6883 for ; Thu, 22 Oct 2009 09:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[AWL=-0.744, 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 xzdwSUs4Js1u for ; Thu, 22 Oct 2009 09:30:41 -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 A1C383A687C for ; Thu, 22 Oct 2009 09:30:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=avljKxDapWclSu8fSCN7ZIWNx0BGJOq8dRjqpJWLIk8tUBo2DFpznzTGfP9WA8D7; 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.153]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1N10Yt-0007sJ-4l; Thu, 22 Oct 2009 12:30:51 -0400 Message-ID: <4AE088BA.6010609@earthlink.net> Date: Thu, 22 Oct 2009 09:30: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: <4ADF863E.8040408@gmail.com> <4ADF8F12.6020002@earthlink.net> <4AE05467.4030100@gmail.com> In-Reply-To: <4AE05467.4030100@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f528b764ccc7eabd1cd11726969784209c1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Procedure 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, 22 Oct 2009 16:30:42 -0000 Hello Alex, In my inbox, I do not have any email from you after my last response, sent at 9/23/2009 11:07 AM to [autoconf] mailing list. I will send you my last email without copying the list to avoid boring people to death by rehashing old arguments (oops, sorry, I guess they're already being bored to death this week). Regards, Charlie P. Alexandru Petrescu wrote: > Charles E. Perkins a écrit : > >> >> You never responded to my explanation about why your proposed >> solution to the 4-node problem would almost certainly fail. So as >> far as I can tell this desire for mandating Link-Local is religion >> and not any sort of engineering. > > Hey, Charles, you never responded to my mail which was a response to > yours. If you want me, I can respond to yours. But why should I > spent the effort when I see that the WG is not even consulted at WG > item adoption. > From charles.perkins@earthlink.net Thu Oct 22 09:50: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 6AE8B3A6983 for ; Thu, 22 Oct 2009 09:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.831 X-Spam-Level: X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[AWL=0.149, 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 d6MUV93eFLZF for ; Thu, 22 Oct 2009 09:50:18 -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 16E243A6985 for ; Thu, 22 Oct 2009 09:50:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=CnPbdJ16OLlqsYKOt/u3gCwjww/I/jOFERPP/9A2QQe4ETYhid/uG2L0CXf5czcY; 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.153]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1N10rr-0000mo-Eh; Thu, 22 Oct 2009 12:50:27 -0400 Message-ID: <4AE08D52.60101@earthlink.net> Date: Thu, 22 Oct 2009 09:50:26 -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> <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-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5259c3ef14b8cf17f2861c31bf53a182ad350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: [Autoconf] [warning -- weeks old mail under discussion] Re: 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: Thu, 22 Oct 2009 16:50:19 -0000 Hello Alex, I did find this other email which predated my last response to you. That latter response would also have shown what was wrong with this solution, but it didn't explicitly rebut the DHCP-ness of your suggested solution. First, I don't agree with the often suggested assumption that we can rely on MAC addresses for uniqueness. Maybe we ought to have a new design team or even working group for that, but I think such results are usually required to be clearly labeled as, for instance, "XXXX over IEEE 802.11" or some such. If you really think that DHCP is even remotely feasible for the general scenario, I can try to dig through the timeouts and state maintenance on the servers and relays to identify the half-dozen ways in which the solution is not workable. I have to say that it seems to me that you are using DHCP and ND and NUD as "theorems" upon which you construct a "theory" of operation. Unfortunately, the hypotheses and conditionals upon which those "theorems" rely are not satisfied in the case of mobile wireless devices of the type under discussion in [autoconf], unless of course you have magical properties such as unique MAC addresses or slow speeds. So when you quote "theorems" such as DHCP, without going to the trouble of verifying the requisite preconditions, you are investing confidence in a design that would fall apart like a house of cards in a windstorm. Shall I make some time next week to go through the exercise yet again? Even without doing so, the following statement calls out shrilly for serious skepticism and, in a world inclined towards practical goals, dismissal: > -designate B, C and D to request a prefix each time they think their > neighbors on one interface has changed. Ten or more neighbors, moving at any reasonable speed, and your design is toast -- DHCP or no DHCP. Regards, Charlie P. Alexandru Petrescu wrote: > 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 charles.perkins@earthlink.net Thu Oct 22 10:06: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 186C63A68A0 for ; Thu, 22 Oct 2009 10:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.124, 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 6rg1Z0c9CwFJ for ; Thu, 22 Oct 2009 10:05:59 -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 1EA6C28B56A for ; Thu, 22 Oct 2009 10:05:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ebgXW2DGNqxOxiAP3wZNBr8ONZNkZzse08S7FuiEUIor78yTWThnbla3HXnaEtdN; 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.153]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1N1170-0006sI-OM; Thu, 22 Oct 2009 13:06:06 -0400 Message-ID: <4AE090FE.3000001@earthlink.net> Date: Thu, 22 Oct 2009 10:06:06 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> In-Reply-To: <1256170228.12205.20.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5221f0103dd5efd689fc224ef932b5ab34350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 22 Oct 2009 17:06:00 -0000 Hello Carlos, Carlos Jesús Bernardos Cano wrote: > >> "MANET interfaces MUST also be configured with >> IPv6 Link-local addresses". >> >> But there is no indication in the draft about why that >> mandate might result in anything useful. >> >> What if [autoconf] recommended assignment of a distinguished >> link-local address to every MANET node? We could, for >> instance, designate the value fe80::FFFF as the distinguished >> useless link-local address designed _solely_ for the purpose >> of rigorous compliance with RFC 4861. Would this be >> satisfactory for the purposes you espouse in your draft? >> > > No, this would not be satisfactory. Link locals are not only mandated by > RFC 4861 but also used by some protocols, so that's why we consider > important to configure them (so they can be used) in MANETs. > Can you say which protocols are of interest in this connection? > >> I also note that in your draft you advocate reliance on the >> typical (but not guaranteed) uniqueness of IEEE MAC addresses, >> > > It's true that it is not guaranteed, but the probability of collision is > so low, that I'm not sure it's worth arguing about the necessity of > using DAD. > This is, I think, the major point of disagreement. So, for instance, most wireless devices in the world do NOT have IEEE 802 MAC addresses. I'd like to enable a world where they can use [autoconf] protocols and [manet] protocols. > >> and also turning off DAD or hacking the parameters. Did you >> try to calculate the overhead of, say, beaconing NA messages >> every 50 milliseconds, and the resulting too-frequent ND >> operations? Do you have any comments on the N^2 nature >> of this source of congestion? >> > > This could be certainly a scalability problem, but "hacking/configuring" > ND is just one proposed mechanism to tackle with fluctuating > reachability issues. There are other ways proposed in the draft (such a > stronger interaction with the routing protocol) and surely there are > more. > Using a routing protocol to insure uniqueness of link-local addresses seems, on the face of it, to be a serious layer violation. However, I like to keep an open mind :-). > Even if globals are used instead, we would have a fluctuating > reachability issue, since the next IP hop used to reach a certain > destination might move out of radio coverage (you need to detect this by > ND or the routing protocol). I think the same kind-of solutions that be > used there can also be used when link-locals are used. Besides, we do > not mandate to use link-locals in the draft, we just think there are use > cases where they are useful and therefore we should not prevent their > use in MANETs. > There is a huge difference between global and link-local. It makes all the difference in the world. Namely, global addresses are reasonable to include in payloads for protocol messages that can be forwarded across multiple hops. Link-local addresses do NOT share this property. They're _local_ addresses! Please explain the relationship between the following two sentences: > "MANET interfaces MUST also be configured with > IPv6 Link-local addresses" and > "Besides, we do > not mandate to use link-locals in the draft, we just think there are use > cases where they are useful and therefore we should not prevent their > use in MANETs." Regards, Charlie P. From Fred.L.Templin@boeing.com Thu Oct 22 10:31: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 E8FA128C0EF for ; Thu, 22 Oct 2009 10:31:36 -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 SbDpA7ZOjcYE for ; Thu, 22 Oct 2009 10:31:36 -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 0EC1E3A6994 for ; Thu, 22 Oct 2009 10:31:34 -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 n9MHVbIY015845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 22 Oct 2009 12:31:37 -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 n9MHVaKI015316; Thu, 22 Oct 2009 10:31:36 -0700 (PDT) Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n9MHVa13015313 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 22 Oct 2009 10:31:36 -0700 (PDT) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Thu, 22 Oct 2009 10:31:36 -0700 From: "Templin, Fred L" To: "Charles E. Perkins" Date: Thu, 22 Oct 2009 10:31:34 -0700 Thread-Topic: [Autoconf] I-DAction:draft-bernardos-autoconf-addressing-model-00.txt Thread-Index: AcpTOig/0zuKfuq1SEiiJUSyx4lrBQAAW5/g Message-ID: <12F4112206976147A34FEC0277597CCF27A41ACDD9@XCH-NW-15V.nw.nos.boeing.com> References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gm ail.com> <4ADF9464.9060409@earthlink.net><1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> In-Reply-To: <4AE090FE.3000001@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-16962.004 x-tm-as-result: No--46.338500-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] I-DAction:draft-bernardos-autoconf-addressing-model-00.txt 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, 22 Oct 2009 17:31:37 -0000 Charlie, > This is, I think, the major point of disagreement. So, for instance, > most wireless devices in the world do NOT have IEEE 802 MAC > addresses The reason some of those wireless devices do not have IEEE 802 MAC addresses is because carrying two 6-octet addresses on each packet would waste too much precious RF transmission resources. But, these are the very same devices that would prefer to use IPv4 instead of IPv6 for MANET-local communications in order to limit the overhead for carrying IPv6 addresses when the increased IPv6 addressing space is not needed. One other point - you seem to be drawing a hard line that DAD must be perfect. But, the IP link service model is best-effort (not reliable delivery) so that DAD failures are possible on any IP link, and not just the ones we typically talk about wrt MANET. Fred fred.l.templin@boeing.com=20 From alexandru.petrescu@gmail.com Thu Oct 22 10:41: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 6DF6E28C0EB for ; Thu, 22 Oct 2009 10:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[AWL=0.159, 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 ansIvEWaUCZr for ; Thu, 22 Oct 2009 10:41:54 -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 8FDEE28C0EF for ; Thu, 22 Oct 2009 10:41:53 -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 n9MHg0eI000989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Oct 2009 19:42:00 +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 n9MHg0cA002181; Thu, 22 Oct 2009 19:42:00 +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 n9MHfxS9027042; Thu, 22 Oct 2009 19:41:59 +0200 Message-ID: <4AE09967.9060809@gmail.com> Date: Thu, 22 Oct 2009 19:41:59 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4AE088E3.6080304@earthlink.net> In-Reply-To: <4AE088E3.6080304@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] various (was: [Fwd: Re: 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: Thu, 22 Oct 2009 17:41:55 -0000 Charles, thanks for reminding me this message. I take the freedom to copy the list, in reply. Our conversation stopped because... Charles E. Perkins a écrit : >>> 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. My part of our conversation stopped here. We have very different assumptions on the number of network interfaces a node has in AUTOCONF. You believe 1, I believe more. The DT document does not say how many there are. I think it should. I already suggested to clarify this - "how many interfaces does an AUTOCONF node has"? > 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? Right... do you mean to generalize AUTOCONF to everything else which we don't know what is? >> 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. Here I agree with you. It's like you don't forbid what I'm doing, but you don't want to mention it either (in the DT document). SO I can live with it. >> 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. Er? Why is it so? What do you mean? What kind of expected rate of motion to you expect? And what kind of coverage areas do you expect? > 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. Charles - I do this in the lab with three nodes sending RAs. 20 nodes is not much further away. If there is a risk of a massive collision problem with RAs I can think of re-using the RA sending in an exponential back-off manner to avoid collisions. Not sure to which extent is it implemented, and if it is not, we will look into it. > 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. Nein, Charles. I believe in the solid robustness of the IP stacks I am using. If these things you talk about happen, I can correct them by either re-specifying, or better implementing. Until I see these problems in practice I can't agree with you. I would even challenge you whether you talk implementation experience here, or logical extension of conceptual aspects. > 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. Charles, ok, you make it sound scaring. What happens in my lab is very friendly. LArger tests are planned (to the extent of what wifi link layer allows - surely not thousands). If I had 1000s of nodes then I would _subnet_ this with routers in the middle -- for sure! That means at least bridging, and most probably routing. That means several interfaces on a node. There exists practically no digital wireless link layer I am aware of which supports thousands of nodes within direct IP reach, same subnet, all-node-multicast link-local scope. AODV - is a good thing from what I read. I have never tried it in practice. SOmetimes people ask why don't I use AODV or OLSR on the mobile routers in vehicles I talked about - and then I say maybe they're too heavy for what's needed in some particular cases. And I am afraid there's no consensus on either one. >> 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. I disagree. One prefix per interface is better. >> -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. When NUD says so. [...] >>> 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. Unrecommending them is what DT document does. It's not forbidding, it is not recommending. >>> 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. Depends on the scenario - vehicles on a highway, wagons of a train, and others are very much rectilinear topologies. > The other networks are, however, much > harder to draw with ASCII stick figures. YEs. I do about the ones I need. IT helps me understanding and communicating them. The ones we don't understand and don't communicate - will never fly. >>> 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. Any subnetting into those? (just curious). Thanks, Alex >> (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. > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > > > From alexandru.petrescu@gmail.com Thu Oct 22 10:47: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 B254E3A69AD for ; Thu, 22 Oct 2009 10:47:15 -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.148, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_31=0.6] 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 ftKX5cc+Vr0e for ; Thu, 22 Oct 2009 10:47:14 -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 9C8C33A6995 for ; Thu, 22 Oct 2009 10:47:14 -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 n9MHlLmn030037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Oct 2009 19:47:21 +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 n9MHlLTa002650; Thu, 22 Oct 2009 19:47:21 +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 n9MHlL4O028414; Thu, 22 Oct 2009 19:47:21 +0200 Message-ID: <4AE09AA9.3080805@gmail.com> Date: Thu, 22 Oct 2009 19:47:21 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4ADF863E.8040408@gmail.com> <4ADF8F12.6020002@earthlink.net> <4AE05467.4030100@gmail.com> <4AE088BA.6010609@earthlink.net> In-Reply-To: <4AE088BA.6010609@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Procedure 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, 22 Oct 2009 17:47:15 -0000 Charles E. Perkins a écrit : > > Hello Alex, > > In my inbox, I do not have any email from you after my > last response, sent at 9/23/2009 11:07 AM to [autoconf] > mailing list. I will send you my last email without copying > the list to avoid boring people to death by rehashing old > arguments (oops, sorry, I guess they're already being > bored to death this week). Charles, Thank you, got the message. I wanted to explain you that I didn't reply to your message earlier this year because I felt like you don;t listen to what I said. Rehashing old arguments, bored to death this week, etc. - are these indicators of weaknesses such as sudden submission without WG approval? Bored people don't proceed this way. In that message exchange there are number of issues that need clarification. The issue tracker may be recommendable. -how many interfaces does a node have? -how to subnet 1000 nodes? -which link layer do you consider? -what are the movemement models and coverage areas considered? These are fundamental things without which no engineer can do anything other than speculating and dancing on the top of pines, if I can say so. (well ok, I am talking for myself). Alex > > Regards, > Charlie P. > > > Alexandru Petrescu wrote: >> Charles E. Perkins a écrit : >> >>> >>> You never responded to my explanation about why your proposed >>> solution to the 4-node problem would almost certainly fail. So as >>> far as I can tell this desire for mandating Link-Local is religion >>> and not any sort of engineering. >> >> Hey, Charles, you never responded to my mail which was a response to >> yours. If you want me, I can respond to yours. But why should I >> spent the effort when I see that the WG is not even consulted at WG >> item adoption. >> > > From Fred.L.Templin@boeing.com Thu Oct 22 10:53: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 D7DD83A6778 for ; Thu, 22 Oct 2009 10:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.953 X-Spam-Level: X-Spam-Status: No, score=-5.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 w9lqEY1eoqzZ for ; Thu, 22 Oct 2009 10:53:24 -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 7C6903A68CC for ; Thu, 22 Oct 2009 10:53:24 -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 n9MHrYGp023197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 22 Oct 2009 10:53:34 -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 n9MHrX5u013953 for ; Thu, 22 Oct 2009 10:53:33 -0700 (PDT) Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n9MHrXsA013945 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Thu, 22 Oct 2009 10:53:33 -0700 (PDT) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Thu, 22 Oct 2009 10:53:33 -0700 From: "Templin, Fred L" CC: "autoconf@ietf.org" Date: Thu, 22 Oct 2009 10:53:31 -0700 Thread-Topic: Illegal Procedure (was: RE: [Autoconf] Procedure) Thread-Index: AcpTP95oWszsJuLjTgKBCZZdvcR8FwAAHY1w Message-ID: <12F4112206976147A34FEC0277597CCF27A41ACDE9@XCH-NW-15V.nw.nos.boeing.com> References: <4ADF863E.8040408@gmail.com> <4ADF8F12.6020002@earthlink.net><4AE05467.4030100@gmail.com> <4AE088BA.6010609@earthlink.net> <4AE09AA9.3080805@gmail.com> In-Reply-To: <4AE09AA9.3080805@gmail.com> 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-16962.004 x-tm-as-result: No--40.372800-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 Subject: [Autoconf] Illegal Procedure (was: RE: Procedure) 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, 22 Oct 2009 17:53:25 -0000 Illegal Procedure - 5 yard penalty - now 4th and 6 instead of 4th and 1 - time to punt. From charles.perkins@earthlink.net Thu Oct 22 10:54:53 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 E539E3A6952 for ; Thu, 22 Oct 2009 10:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=0.106, 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 ZaaNmBby3NvI for ; Thu, 22 Oct 2009 10:54:53 -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 083163A6778 for ; Thu, 22 Oct 2009 10:54:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=dq6KhNrGz4PoCT1hYyCNC28ZvzT2tTQmcIQVx72HO1AUWQeWSvFxY1se0ED/bS5E; 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.153]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1N11sM-0006kN-Ny; Thu, 22 Oct 2009 13:55:02 -0400 Message-ID: <4AE09C76.2030101@earthlink.net> Date: Thu, 22 Oct 2009 10:55:02 -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: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gm ail.com> <4ADF9464.9060409@earthlink.net><1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <12F4112206976147A34FEC0277597CCF27A41ACDD9@XCH-NW-15V.nw.nos.boeing.com> In-Reply-To: <12F4112206976147A34FEC0277597CCF27A41ACDD9@XCH-NW-15V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f524044c61d499da67b42f22ad3408e222f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] I-DAction:draft-bernardos-autoconf-addressing-model-00.txt 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, 22 Oct 2009 17:54:54 -0000 Hello Fred, Templin, Fred L wrote: > Charlie, > > >> This is, I think, the major point of disagreement. So, for instance, >> most wireless devices in the world do NOT have IEEE 802 MAC >> addresses >> > > The reason some of those wireless devices do not have > IEEE 802 MAC addresses is because carrying two 6-octet > addresses on each packet would waste too much precious > RF transmission resources. But, these are the very same > devices that would prefer to use IPv4 instead of IPv6 > for MANET-local communications in order to limit the > overhead for carrying IPv6 addresses when the increased > IPv6 addressing space is not needed. > I hope by this statement you do not intend to exclude that class of devices from participation in the IPv6 Internet. As far as the _internetworking_ aspect is concerned, I reckon that the addressability and routing ought to be IPv6. As far as the delivery over a particular link is concerned, I am sure we can both think of ways to ameliorate the size of the headers. The payloads are more problematic! So, it is extremely important to eliminate excess signaling. My point is that requiring link-locals will engender a great deal of excess signaling. And, furthermore, we can achieve our goals of address autoconfiguration without requiring them. Delivering user-plane data will still benefit greatly from the various techniques for header compression that might be further inspired by the use of IPv6 addresses. > One other point - you seem to be drawing a hard line that > DAD must be perfect. But, the IP link service model is > best-effort (not reliable delivery) so that DAD failures > are possible on any IP link, and not just the ones we > typically talk about wrt MANET. > This is a good point. IP is not reliable delivery. But it doesn't deliver packets to the _wrong_ endpoint. And, duplicate addresses are, in the design universe I am familiar with, totally poison. I think they are far worse than dropped packets. Regards, Charlie P. From alexandru.petrescu@gmail.com Thu Oct 22 11:00: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 494A228C132 for ; Thu, 22 Oct 2009 11:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=0.158, 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 QRZFo9a5gY0i for ; Thu, 22 Oct 2009 11:00:42 -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 B111D28C0FB for ; Thu, 22 Oct 2009 11:00:41 -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 n9MI0Yk4013082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Oct 2009 20:00:34 +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 n9MI0YDq003705; Thu, 22 Oct 2009 20:00:34 +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 n9MI0XY6030514; Thu, 22 Oct 2009 20:00:33 +0200 Message-ID: <4AE09DC1.2080307@gmail.com> Date: Thu, 22 Oct 2009 20:00:33 +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> <4ABA5A8F.4020800@gmail.com> <4ABA5E20.8090608@gmail.com> <4AE08D52.60101@earthlink.net> In-Reply-To: <4AE08D52.60101@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] [warning -- weeks old mail under discussion] Re: 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: Thu, 22 Oct 2009 18:00:43 -0000 Charles E. Perkins a écrit : > > Hello Alex, > > I did find this other email which predated my last > response to you. YEs, thank you. > That latter response would also > have shown what was wrong with this solution, but > it didn't explicitly rebut the DHCP-ness of your > suggested solution. > > First, I don't agree with the often suggested > assumption that we can rely on MAC addresses > for uniqueness. Maybe we ought to have a new > design team or even working group for that, but > I think such results are usually required to be clearly > labeled as, for instance, "XXXX over IEEE 802.11" > or some such. Ok, I agree, we should label AUTOCONF as 802.11. > If you really think that DHCP is even remotely > feasible for the general scenario, I can try to dig through > the timeouts and state maintenance on the servers > and relays to identify the half-dozen ways in which > the solution is not workable. No, not necessary, thanks. > I have to say that it > seems to me that you are using DHCP and ND and > NUD as "theorems" upon which you construct a > "theory" of operation. Unfortunately, the hypotheses > and conditionals upon which those "theorems" rely are > not satisfied in the case of mobile wireless devices of > the type under discussion in [autoconf], unless of > course you have magical properties such as unique > MAC addresses or slow speeds. > > So when you quote "theorems" such as DHCP, > without going to the trouble of verifying the requisite > preconditions, you are investing confidence in a > design that would fall apart like a house of cards in > a windstorm. Hmm... how else is one supposed to make logical argumentations? > Shall I make some time next week to go through > the exercise yet again? No. > Even without doing so, the following statement calls > out shrilly for serious skepticism and, in a world inclined > towards practical goals, dismissal: > >> -designate B, C and D to request a prefix each time they think their >> neighbors on one interface has changed. Hmm... at least I read some good ways of expressing your negative feelings towards some technical proposal. > Ten or more neighbors, moving at any reasonable speed, > and your design is toast -- DHCP or no DHCP. Charles - "speed" as we tend to interpret it may have no sense when we consider coverage areas. Node speed of 300kmph equals 0 if the coverage is very large. Node speed of 300kmph going through a 50m wifi area - ok, no DHCP: but then one wonders _why_ would a car need to communicate anything through that 50m wifi area. DHCP or no DHCP... what coverage area? what link layer? DHCP can be very fast. Alex > > Regards, > Charlie P. > > > Alexandru Petrescu wrote: >> 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 Fred.L.Templin@boeing.com Thu Oct 22 11:02: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 469283A6985 for ; Thu, 22 Oct 2009 11:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 C+ZknG3XEJkI for ; Thu, 22 Oct 2009 11:02:10 -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 936C53A69F1 for ; Thu, 22 Oct 2009 11:02:10 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n9MI0YHv027806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 22 Oct 2009 11:00:35 -0700 (PDT) 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 n9MI0YoP018975; Thu, 22 Oct 2009 13:00:34 -0500 (CDT) Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n9MI0Gn6018119 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 22 Oct 2009 13:00:34 -0500 (CDT) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Thu, 22 Oct 2009 11:00:23 -0700 From: "Templin, Fred L" To: "Charles E. Perkins" Date: Thu, 22 Oct 2009 11:00:22 -0700 Thread-Topic: [Autoconf] I-DAction:draft-bernardos-autoconf-addressing-model-00.txt Thread-Index: AcpTQPRlWijm1CLySNav8IuXCvOAPQAAF5tg Message-ID: <12F4112206976147A34FEC0277597CCF27A41ACDF3@XCH-NW-15V.nw.nos.boeing.com> References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gm ail.com> <4ADF9464.9060409@earthlink.net><1256170228.12205.20.camel@acorde.it.uc3m. es> <4AE090FE.3000001@earthlink.net> <12F4112206976147A34FEC0277597CCF27A41ACDD9@XCH-NW-15V.nw.nos.boeing.com> <4AE09C76.2030101@earthlink.net> In-Reply-To: <4AE09C76.2030101@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] I-DAction:draft-bernardos-autoconf-addressing-model-00.txt 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, 22 Oct 2009 18:02:11 -0000 Charlie, =20 > I hope by this statement you do not intend to exclude that class > of devices from participation in the IPv6 Internet Never would I suggest such a thing; indeed, I am counting on IPv6 Internet participation. Fred fred.l.templin@boeing.com From alexandru.petrescu@gmail.com Thu Oct 22 11:10: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 BF3703A68F8 for ; Thu, 22 Oct 2009 11:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=0.152, 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 rDEFVc6-ZalU for ; Thu, 22 Oct 2009 11:10:15 -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 8A1F93A659B for ; Thu, 22 Oct 2009 11:10:15 -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 n9MI73tW031290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Oct 2009 20:07:03 +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 n9MI72Bo004147; Thu, 22 Oct 2009 20:07:02 +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 n9MI72K0031494; Thu, 22 Oct 2009 20:07:02 +0200 Message-ID: <4AE09F46.1060907@gmail.com> Date: Thu, 22 Oct 2009 20:07:02 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Templin, Fred L" References: <4ADF863E.8040408@gmail.com> <4ADF8F12.6020002@earthlink.net><4AE05467.4030100@gmail.com> <4AE088BA.6010609@earthlink.net> <4AE09AA9.3080805@gmail.com> <12F4112206976147A34FEC0277597CCF27A41ACDE9@XCH-NW-15V.nw.nos.boeing.com> In-Reply-To: <12F4112206976147A34FEC0277597CCF27A41ACDE9@XCH-NW-15V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Illegal Procedure 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, 22 Oct 2009 18:10:16 -0000 Templin, Fred L a écrit : > Illegal Procedure - 5 yard penalty - now 4th and 6 > instead of 4th and 1 - time to punt. Sounds as a sport procedure or so... Alex > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From charles.perkins@earthlink.net Thu Oct 22 11:42: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 6BAFF3A69BF for ; Thu, 22 Oct 2009 11:42:59 -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 LDhjB+RIo62z for ; Thu, 22 Oct 2009 11:42:57 -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 5730F3A696C for ; Thu, 22 Oct 2009 11:42:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=iescCOvGOGlYRHmktmUFs/hYuTeKN3vUzPmY8RQn8pc4F3xjvLTlufnuH5TMFJCD; 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.153]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1N12cs-0001Uy-UX; Thu, 22 Oct 2009 14:43:07 -0400 Message-ID: <4AE0A7BA.2060002@earthlink.net> Date: Thu, 22 Oct 2009 11:43:06 -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> <4ABA5E20.8090608@gmail.com> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> In-Reply-To: <4AE09DC1.2080307@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f524f104668c818b3baf4eb2204b1d714fb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] [warning -- weeks old mail under discussion] Re: 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: Thu, 22 Oct 2009 18:42:59 -0000 Hello Alex, Alexandru Petrescu wrote: > >> First, I don't agree with the often suggested >> assumption that we can rely on MAC addresses >> for uniqueness. Maybe we ought to have a new >> design team or even working group for that, but >> I think such results are usually required to be clearly >> labeled as, for instance, "XXXX over IEEE 802.11" >> or some such. > > Ok, I agree, we should label AUTOCONF as 802.11. Well, you may agree with some other people on that point, but I do not agree with it, and maybe it's time to get some clarity on this point. >> >> So when you quote "theorems" such as DHCP, >> without going to the trouble of verifying the requisite >> preconditions, you are investing confidence in a >> design that would fall apart like a house of cards in >> a windstorm. > > > Hmm... how else is one supposed to make logical argumentations? By making assumptions that are supportable in the area of interest. > > >> Ten or more neighbors, moving at any reasonable speed, >> and your design is toast -- DHCP or no DHCP. > > Charles - "speed" as we tend to interpret it may have no sense when we > consider coverage areas. Node speed of 300kmph equals 0 if the > coverage is very large. This is a good point. Perhaps the proper quantity of interest is the average transition time through the range of coverage from a neighboring node. > > Node speed of 300kmph going through a 50m wifi area - ok, no DHCP: but > then one wonders _why_ would a car need to communicate anything > through that 50m wifi area. I personally think this is a great idea, if for instance we had WiFi on the streetlamps and freeway dividers. At $1.00 per transceiver chip, it's a reasonable alternative! It draws a lot less power than the light bulb. > > DHCP or no DHCP... what coverage area? what link layer? > > DHCP can be very fast. In order to counter this statement (or, more accurately, show why it is not relevant), I would have to go through the exercise -- but you had relieved me of that task. I'm not going to do that unless necessary. But, roughly speaking, the answer is that you can't have DHCP unless you know where the server(s) and the relays are. And when the nodes are moving, you don't know. And you can't quote NUD and NA as theorems because of the reasons I already outlined in previous messages. And even if you could, before long you'd have to get some new relay because you need the relay to be local. And more than likely your DHCP server will be occasionally partitioned into temporary isolation. But then it's back! But the relay is gone! And then there's something else to go wrong. But, are _all_ nodes relays? But, which server has the state? Or is there just one server? But that won't ever work! Every time I think about it, I just know it's wrong. I do not have any belief whatsoever in this theorem. And, with three nodes, you'll never see the problem. Never! Regards, Charlie P. From cjbc@it.uc3m.es Thu Oct 22 11:53: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 714963A68E4 for ; Thu, 22 Oct 2009 11:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.45 X-Spam-Level: X-Spam-Status: No, score=-5.45 tagged_above=-999 required=5 tests=[AWL=0.249, 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 brQv6zD5-emT for ; Thu, 22 Oct 2009 11:53:21 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id EE0D33A67F7 for ; Thu, 22 Oct 2009 11:53:20 -0700 (PDT) Received: from [IPv6:::1] (luciernaga.it.uc3m.es [163.117.140.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 363977F3944; Thu, 22 Oct 2009 20:53:25 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Charles E. Perkins" In-Reply-To: <4AE090FE.3000001@earthlink.net> References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-q/YwcugNj+FFavUaMFPL" Organization: Universidad Carlos III de Madrid Date: Thu, 22 Oct 2009 20:53:26 +0200 Message-Id: <1256237606.5373.22.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16964.000 Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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: Thu, 22 Oct 2009 18:53:22 -0000 --=-q/YwcugNj+FFavUaMFPL Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Charlie, On Thu, 2009-10-22 at 10:06 -0700, Charles E. Perkins wrote: > Hello Carlos, >=20 > Carlos Jes=FAs Bernardos Cano wrote: > > > >> "MANET interfaces MUST also be configured with > >> IPv6 Link-local addresses". > >> > >> But there is no indication in the draft about why that > >> mandate might result in anything useful. > >> > >> What if [autoconf] recommended assignment of a distinguished > >> link-local address to every MANET node? We could, for > >> instance, designate the value fe80::FFFF as the distinguished > >> useless link-local address designed _solely_ for the purpose > >> of rigorous compliance with RFC 4861. Would this be > >> satisfactory for the purposes you espouse in your draft? > >> =20 > > > > No, this would not be satisfactory. Link locals are not only mandated b= y > > RFC 4861 but also used by some protocols, so that's why we consider > > important to configure them (so they can be used) in MANETs. > > =20 >=20 > Can you say which protocols are of interest in this connection? Some routing protocols make use of link-locals, right? >=20 > > =20 > >> I also note that in your draft you advocate reliance on the > >> typical (but not guaranteed) uniqueness of IEEE MAC addresses, > >> =20 > > > > It's true that it is not guaranteed, but the probability of collision i= s > > so low, that I'm not sure it's worth arguing about the necessity of > > using DAD. > > =20 >=20 > This is, I think, the major point of disagreement. So, for instance, > most wireless devices in the world do NOT have IEEE 802 MAC > addresses. I'd like to enable a world where they can use [autoconf] > protocols and [manet] protocols. >=20 Well, for these scenarios we also propose in the draft to use some of the mechanisms that have been proposed in the past (such as draft-soto-mobileip-random-iids)to reduce the collision probability. > > =20 > >> and also turning off DAD or hacking the parameters. Did you > >> try to calculate the overhead of, say, beaconing NA messages > >> every 50 milliseconds, and the resulting too-frequent ND > >> operations? Do you have any comments on the N^2 nature > >> of this source of congestion? > >> =20 > > > > This could be certainly a scalability problem, but "hacking/configuring= " > > ND is just one proposed mechanism to tackle with fluctuating > > reachability issues. There are other ways proposed in the draft (such a > > stronger interaction with the routing protocol) and surely there are > > more. > > =20 >=20 > Using a routing protocol to insure uniqueness of > link-local addresses seems, on the face of it, to be > a serious layer violation. However, I like to keep > an open mind :-). I guess I didn't explain myself clearly... I never said that routing protocols should be used to insure uniqueness of link-local addresses (though they may be use to detect duplication, as it has been proposed in several passive "DAD" approaches, such as PACMAN). What I was trying to say is that a stronger interaction with the routing protocol might be used to detect that a neighbour is no longer reachable, instead of purely relying on NUD. >=20 > > Even if globals are used instead, we would have a fluctuating > > reachability issue, since the next IP hop used to reach a certain > > destination might move out of radio coverage (you need to detect this b= y > > ND or the routing protocol). I think the same kind-of solutions that be > > used there can also be used when link-locals are used. Besides, we do > > not mandate to use link-locals in the draft, we just think there are us= e > > cases where they are useful and therefore we should not prevent their > > use in MANETs. > > =20 >=20 > There is a huge difference between global and link-local. It makes > all the difference in the world. Namely, global addresses are reasonable > to include in payloads for protocol messages that can be forwarded > across multiple hops. Link-local addresses do NOT share this > property. >=20 > They're _local_ addresses! Yes, I know what a link-local address is :-D. I think we were talking about reachability of a 1-hop node, that is, the next IP hop of a communication (if we are using link-locals, then next IP hop =3D=3D destination). >=20 > Please explain the relationship between the following two sentences: >=20 > > "MANET interfaces MUST also be configured with > > IPv6 Link-local addresses" >=20 > and > > "Besides, we do > > not mandate to use link-locals in the draft, we just think there are us= e > > cases where they are useful and therefore we should not prevent their > > use in MANETs." The relationship is the following: LLs MUST be configured, but we don't mandate their use. It is a MUST, because there are IPv6 specs that say so and because there are IPv6 protocols/applications that may want to use them, but this does not imply that we force protocols/applications to use them (it's up to the protocol/application designer to decide whether to use them or not). Thanks, Carlos >=20 > Regards, > Charlie P. >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-q/YwcugNj+FFavUaMFPL 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) iEYEABECAAYFAkrgqiYACgkQNdy6TdFwT2eGKgCgsh9wVkhDPMeGPKZ8Qlejc2V2 2tgAoNPjN0suX2ySr1Y/lQHFFRfb85SA =Jz3U -----END PGP SIGNATURE----- --=-q/YwcugNj+FFavUaMFPL-- From charles.perkins@earthlink.net Thu Oct 22 12:07: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 E40FD28C0F5 for ; Thu, 22 Oct 2009 12:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=0.083, 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 kHDxyL+XHUFF for ; Thu, 22 Oct 2009 12:07:58 -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 F00F13A659B for ; Thu, 22 Oct 2009 12:07:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=swUCXA4PE1gG3pkH79Ob/+98bHHGM6gqJ6iRWnMc48JM6ovoqPDSmJN+rQPRoMci; 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.153]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1N1313-0008Qr-VQ; Thu, 22 Oct 2009 15:08:06 -0400 Message-ID: <4AE0AD94.7050800@earthlink.net> Date: Thu, 22 Oct 2009 12:08:04 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> In-Reply-To: <1256237606.5373.22.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f522857d728949d817a60c0c8b97e68dd65350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 22 Oct 2009 19:07:59 -0000 Hello Carlos, Carlos Jesús Bernardos Cano wrote: > >>> No, this would not be satisfactory. Link locals are not only mandated by >>> RFC 4861 but also used by some protocols, so that's why we consider >>> important to configure them (so they can be used) in MANETs. >>> >>> >> Can you say which protocols are of interest in this connection? >> > > Some routing protocols make use of link-locals, right? > [manet] was started as a working group because OSPF and other routing protocols were measured to consume well over 100% of the available bandwidth (data from NRL). Which protocols would you like to employ? > > Well, for these scenarios we also propose in the draft to use some of > the mechanisms that have been proposed in the past (such as > draft-soto-mobileip-random-iids)to reduce the collision probability. > This is a great idea... BUT: the solution space should not be limited to ONLY those solutions that can make use of such techniques. > >>> >>> >> Using a routing protocol to insure uniqueness of >> link-local addresses seems, on the face of it, to be >> a serious layer violation. However, I like to keep >> an open mind :-). >> > > I guess I didn't explain myself clearly... I never said that routing > protocols should be used to insure uniqueness of link-local addresses > (though they may be use to detect duplication, as it has been proposed > in several passive "DAD" approaches, such as PACMAN). What I was trying > to say is that a stronger interaction with the routing protocol might be > used to detect that a neighbour is no longer reachable, instead of > purely relying on NUD. > That is true, but it is by no mean restricted to just routing protocols. You could also use the lack of TCP acknowledgment for such purposes. Some solutions make use of promiscuous-mode reception to check whether the neighbor has relayed your packet to some more distant destination. > > ... I think we were talking > about reachability of a 1-hop node, that is, the next IP hop of a > communication (if we are using link-locals, then next IP hop == > destination). > Well, on this point, we are totally on the same page :-). But, of course, if you happen to know an address for your neighbor that has larger scope than link-local, you are free to make use of it. > >> Please explain the relationship between the following two sentences: >> >> >>> "MANET interfaces MUST also be configured with >>> IPv6 Link-local addresses" >>> >> and >> >>> "Besides, we do >>> not mandate to use link-locals in the draft, we just think there are use >>> cases where they are useful and therefore we should not prevent their >>> use in MANETs." >>> > > The relationship is the following: LLs MUST be configured, but we don't > mandate their use. It is a MUST, because there are IPv6 specs that say > so and because there are IPv6 protocols/applications that may want to > use them, but this does not imply that we force protocols/applications > to use them (it's up to the protocol/application designer to decide > whether to use them or not). > > I am pretty sure (having been there) that the IPv6 mandates in question were placed without regard to the realities of ad hoc networks. In fact, I think it can be safely said that these mandates are relevant only to networks where certain subnet structures are clearly realized. And anyway I think it is really important in this context to be clear about which protocols are to be put into service, and just what is their reliance on link-local addresses. Regards, Charlie P. From charles.perkins@earthlink.net Thu Oct 22 12:17: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 D2E7A28C198 for ; Thu, 22 Oct 2009 12:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[AWL=0.074, 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 1XTo8mXlYTTP for ; Thu, 22 Oct 2009 12:17:48 -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 4E66528C185 for ; Thu, 22 Oct 2009 12:17:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=l5Nv07y9LHwV7Rq/L+N28D2u4AZpzPfeuOLVOxDMx6xrn8CSRCHb7wVqUGRZI5PT; 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.153]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1N13AZ-0000FZ-I0; Thu, 22 Oct 2009 15:17:55 -0400 Message-ID: <4AE0AFE2.20200@earthlink.net> Date: Thu, 22 Oct 2009 12:17:54 -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: <4AE088E3.6080304@earthlink.net> <4AE09967.9060809@gmail.com> In-Reply-To: <4AE09967.9060809@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52c483502548ba779bd4a7c5572c5bf0d6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] various 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, 22 Oct 2009 19:17:49 -0000 Hello Alex, Alexandru Petrescu wrote: > Charles, thanks for reminding me this message. I take the freedom to > copy the list, in reply. > > Our conversation stopped because... > > Charles E. Perkins a écrit : >>>> 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. > > My part of our conversation stopped here. Hmmm.... hard to build bridges that way... > > We have very different assumptions on the number of network interfaces > a node has in AUTOCONF. You believe 1, I believe more. > > The DT document does not say how many there are. I think it should. > > I already suggested to clarify this - "how many interfaces does an > AUTOCONF node has"? Where are these other interfaces? I understand about radio transmissions, spectrum utilization, channel assignment, and all that. If you just have one radio channel, I am pretty sure that you will get into deep trouble trying to model it as numerous network interfaces. Which is not to make any limitations on the number of subnet prefixes you may choose to assign to that singular interface. But multiple _network interfaces_? I guess they must all be virtual :-). >> 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? > > Right... do you mean to generalize AUTOCONF to everything else which > we don't know what is? I have a good imagination, and I can't imagine what this means. The discussion I have had is based on systems I have been involved with actually building. > > >>> 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. > > Here I agree with you. > > It's like you don't forbid what I'm doing, but you don't want to > mention it either (in the DT document). SO I can live with it. The document needs to specify certain things -- hopefully, a minimal number of things. In my opinion, it needs to avoid any attempt to enumerate the total universe of possibilities. Instead it should just make the fewest number of mandates so that we can get a clearer picture of the solution space. > >>> 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. > > Er? Why is it so? What do you mean? I mean, NUD won't work, and NA won't help, at the speeds of interest. > > What kind of expected rate of motion to you expect? And what kind of > coverage areas do you expect? Vehicular motion should be squarely within our jurisdiction, as one example. WiMAX or LTE, with a more rational approach to link establishment, or WiFi on the streetlamps, should be possible. > >> 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. > > Charles - I do this in the lab with three nodes sending RAs. 20 nodes > is not much further away. It's a factor of six away. And your failure phenomena grow quadratically in two dimensions. So we're already talking almost two orders of magnitude (check your log tables). And twenty nodes is nothing. > > If there is a risk of a massive collision problem with RAs I can > think of re-using the RA sending in an exponential back-off manner to > avoid collisions. Not sure to which extent is it implemented, and if > it is not, we will look into it. Please report your findings. > >> 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. > > Nein, Charles. I believe in the solid robustness of the IP stacks I > am using. I notice that your belief system extends to DHCP and NA. Other practitioners who have checked the underpinnings of these belief systems have reached other conclusions. > If these things you talk about happen, I can correct them by either > re-specifying, or better implementing. I think you ought to do that before fixing into concrete the reliability of your belief system. > > Until I see these problems in practice I can't agree with you. I > would even challenge you whether you talk implementation experience > here, or logical extension of conceptual aspects. It is true that I have not implemented AODV with thousands of nodes. It has been simulated to over ten thousand nodes. Even with the improved scalability afforded by non-adherence to NUD/NA/..., the scalability stinks. If we are further crippled by the aforementioned devices, the scalability will be limited to merely laboratory curiosities. > >> 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. > > Charles, ok, you make it sound scaring. What happens in my lab is > very friendly. Three nodes. > > LArger tests are planned (to the extent of what wifi link layer > allows - surely not thousands). You are designing for (single-subnet ??) WiFi. I didn't think this was a WiFi-only group. I also think we have to allow for multi-hop transmissions beyond the range of any one node in the network. Do you disagree? > > If I had 1000s of nodes then I would _subnet_ this with routers in the > middle -- for sure! That means at least bridging, and most probably > routing. That means several interfaces on a node. I like routing. I think it's a great idea. I think it is wrong to establish the uniqueness of link-layer addresses by routing. Of course, uniqueness by fiat seems to work for those who have it handy. > > There exists practically no digital wireless link layer I am aware of > which supports thousands of nodes within direct IP reach, same subnet, > all-node-multicast link-local scope. This is exactly the point. We want to have large deployments NOT all on the same subnet! Do you only want single-subnet deployments?? > > AODV - is a good thing from what I read. I have never tried it in > practice. AODV needs major improvements. I know what needs to be done, but I can't do it right now. [hint to Thomas :-)] > > SOmetimes people ask why don't I use AODV or OLSR on the mobile > routers in vehicles I talked about - and then I say maybe they're too > heavy for what's needed in some particular cases. And I am afraid > there's no consensus on either one. They are too heavy -- but compared to DAD and NUD, they are light as a feather. > > >>> 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. > > I disagree. One prefix per interface is better. Then we're back to figuring out why a node with a single radio channel should have multiple network interfaces. > >>> -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. > > When NUD says so. I'm pretty sure you can't do that at scale. > >> >> I don't remember anyone forbidding link-local addresses. > > Unrecommending them is what DT document does. It's not forbidding, it > is not recommending. So why would the document recommend them? Why can't we just leave them alone? > >> >> I'm not sure what rectilinear scaling would be, but I would >> not expect most networks to necessarily conform to any >> rectilinear layouts. > > Depends on the scenario - vehicles on a highway, wagons of a train, > and others are very much rectilinear topologies. They are _vaguely_ rectilinear, sometimes. I recall that this has some impact when designing techniques for fixing locations and interpolating, but not too much help for routing. > > > >> The other networks are, however, much >> harder to draw with ASCII stick figures. > > YEs. > > I do about the ones I need. IT helps me understanding and > communicating them. > > The ones we don't understand and don't communicate - will never fly. Do you mean to say that we can only understand rectilinear networks? Then I insist that you must speak for yourself, and furthermore that [autoconf] must not place this restriction. > > >> >> I'm thinking about AODV-style networks with hundreds >> or thousands of nodes. > > Any subnetting into those? (just curious). Yes, we made extensive investigation into the requirements for subnetting. It was an interesting exercise, to figure out various implications on ICMP and so on. Regards, Charlie P. From alexandru.petrescu@gmail.com Thu Oct 22 14:10:44 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 BE48628C0E8 for ; Thu, 22 Oct 2009 14:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.659 X-Spam-Level: X-Spam-Status: No, score=-1.659 tagged_above=-999 required=5 tests=[AWL=0.590, 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 lauMnH6i0GNB for ; Thu, 22 Oct 2009 14:10:43 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id A61A13A687D for ; Thu, 22 Oct 2009 14:10:41 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id E86B7D480D7; Thu, 22 Oct 2009 23:10:47 +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 A9055D4811A; Thu, 22 Oct 2009 23:10:44 +0200 (CEST) Message-ID: <4AE0CA51.5070300@gmail.com> Date: Thu, 22 Oct 2009 23:10:41 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4AE088E3.6080304@earthlink.net> <4AE09967.9060809@gmail.com> <4AE0AFE2.20200@earthlink.net> In-Reply-To: <4AE0AFE2.20200@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091022-0, 22/10/2009), Outbound message X-Antivirus-Status: Clean Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] summarizing various - nothing new 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, 22 Oct 2009 21:10:44 -0000 Charles, I again loose focus. Let me summarize. We (CP and yours truly) don't agree on the following: the number of ifaces on a node, the necessity to consider specific topologies and movement descriptions, ND is good or not for here, scalability of RAs on same link, DHCP is good or not for here, size of subnets and number of nodes, necessity to limit or not to WiFi, number of intermediary hops. We agree on some minor things which won't lead me anywhere. For link-locals, Charles suggests we should leave them alone. Alex PS: below answers I owe to your questions, FWIW. Charles E. Perkins a écrit : [...] >> I already suggested to clarify this - "how many interfaces does an >> AUTOCONF node has"? > > Where are these other interfaces? I understand about radio > transmissions, spectrum utilization, channel assignment, and all > that. If you just have one radio channel, I am pretty sure that you > will get into deep trouble trying to model it as numerous network > interfaces. > > Which is not to make any limitations on the number of subnet prefixes > you may choose to assign to that singular interface. But multiple > _network interfaces_? I guess they must all be virtual :-). Either. I prefer to start with at least two physical interfaces per node when doing routing. If not possible then see whether the link-layer can offer two virtual interfaces on a single physical interface (wifi can). If that is not possible either... hard to see doing IP routing any further. [...] >> If there is a risk of a massive collision problem with RAs I can >> think of re-using the RA sending in an exponential back-off manner >> to avoid collisions. Not sure to which extent is it implemented, >> and if it is not, we will look into it. > > Please report your findings. Well yes, in the future, maybe. I am not sure whether I do it here or in MEXT. I am not sure whether anyone needs it at all anyways. My developments are good for me, for my work and for my projects. If I had to struggle 1 year now to get the link-locals accepted here imagine when I post a draft making exclusive use of them :-) Look at Carlos draft saying LLs are a MUST, which is just a reiteration of existing things - immediate pushback :-( [...] >> LArger tests are planned (to the extent of what wifi link layer >> allows - surely not thousands). > > You are designing for (single-subnet ??) WiFi. YEs, it is exchanging RAs on a single subnet WiFi, which has no prefix on it other than the link-local addresses and prefix fe80. It is egress interfaces of Mobile Routers, ifaces put together in "ad-hoc" mode. The ingress ifaces are also wifi but different essids, different channels, no "ad-hoc" mode, etc. The nodes "behind" the Mobile Routers use global IP addresses, yet their egress interfaces are exclusively link-locally addressed. > I didn't think this was a WiFi-only group. Ok. > I also think we have to allow for multi-hop transmissions beyond the > range of any one node in the network. Do you disagree? Depends what you mean by multi-hop. There are some star topologies which have very few IP hops in between (2, 3max) and which can work if the inner core is exclusively link-locally addressed. This is a goal which is reachable. But once you start talking multi-hop like unlimited number of IP hops in between, with thousands of nodes, with arbitrarily varying topologies that even a simple human can't describe - this goal is not reachable. >> If I had 1000s of nodes then I would _subnet_ this with routers in >> the middle -- for sure! That means at least bridging, and most >> probably routing. That means several interfaces on a node. > > I like routing. I think it's a great idea. I think it is wrong to > establish the uniqueness of link-layer addresses by routing. Well I don't propose to establish the uniqueness of link-layer addresses by routing. They're inherently unique because of the nature of the considered link layer - wifi. >> There exists practically no digital wireless link layer I am aware >> of which supports thousands of nodes within direct IP reach, same >> subnet, all-node-multicast link-local scope. > > This is exactly the point. We want to have large deployments NOT all > on the same subnet! Do you only want single-subnet deployments?? I want the _core_ of my MR-to-MR communications to be exclusively link-locally addressed. IT is small in terms of number of intermediary hops. It is understandable. It does not use thousands of nodes on that core. There are of course several subnets, and one of them is the "core" if I can name it so. There is no magic in what I propose. [...] >>>> 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. >> >> I disagree. One prefix per interface is better. > > Then we're back to figuring out why a node with a single radio > channel should have multiple network interfaces. I would go as far as putting two such nodes together such that I can get two interfaces on the union node and IP route between them naturally. >>> I don't remember anyone forbidding link-local addresses. >> >> Unrecommending them is what DT document does. It's not forbidding, >> it is not recommending. > > So why would the document recommend them? Why can't we just leave > them alone? Ok! LEave them alone. State in the document "we leave the LLs alone". Unfortunately now it unrecommends them. [...] >>> The other networks are, however, much harder to draw with ASCII >>> stick figures. >> >> YEs. >> >> I do about the ones I need. IT helps me understanding and >> communicating them. >> >> The ones we don't understand and don't communicate - will never >> fly. > > Do you mean to say that we can only understand rectilinear networks? > Then I insist that you must speak for yourself, and furthermore that > [autoconf] must not place this restriction. WEll, I meant that rectilinear topologies like this: Node1----Node2----Node3---....---Noden Where intermediary nodes each has 2 interfaces are easy to understand and deploy IP on them. "Rectilinear" is probably not the right term, because I don't impose a restriction on the physical disposition - they could be in a circle too, for example. But I require that each of the intermediary nodes has two interfaces. This topoology is easy to understand and deploy IP on. And yes I speak for myself. And yes, I know you don't want to restrict to _any_ kind of particular topology, be that rectilinear, circle or any other form or shape, and that there exist imagination enough to come up with topologies which nobody else has ever imagined before. IT's a good research topic. Alex From charles.perkins@earthlink.net Thu Oct 22 14:53: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 C015C28C0E7 for ; Thu, 22 Oct 2009 14:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[AWL=0.068, 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 EdxHxZ480frz for ; Thu, 22 Oct 2009 14:53:51 -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 9124128C13E for ; Thu, 22 Oct 2009 14:53:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=pLXgHCFB0BguG6iGDI214ebt9VB/XgclPWpH1lBQqX8v/V4c1sQW0wsoKDsiO+W9; 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.153]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1N15bc-00050W-IQ; Thu, 22 Oct 2009 17:54:01 -0400 Message-ID: <4AE0D477.1070809@earthlink.net> Date: Thu, 22 Oct 2009 14:53:59 -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: <4AE088E3.6080304@earthlink.net> <4AE09967.9060809@gmail.com> <4AE0AFE2.20200@earthlink.net> <4AE0CA51.5070300@gmail.com> In-Reply-To: <4AE0CA51.5070300@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5247cd5ffc4c892de74b3970217f8f2947350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] summarizing various - nothing new 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, 22 Oct 2009 21:53:52 -0000 Hello Alex, Alexandru Petrescu wrote: > Charles, I again loose focus. I can help. > > Let me summarize. We (CP and yours truly) don't agree on the > following: the number of ifaces on a node, I do not restrict to multiple interfaces, and you do. > the necessity to consider > specific topologies and movement descriptions, I think autoconf should not be restricted to particular topologies, and you seem to. I do not think we should restrict movements, and your implication is that you do think we should. > ND is good or not for > here, scalability of RAs on same link, DHCP is good or not for here, Well, I showed why they won't work. > size of subnets and number of nodes, necessity to limit or not to > WiFi, number of intermediary hops. I do not restrict, and you seem to restrict. > > For link-locals, Charles suggests we should leave them alone. > > To be more precise, I think we should make it clear that link-local addresses are not required because uniqueness is not necessarily guaranteed (and difficult to assure) for non-IEEE interfaces. > Charles E. Perkins a écrit : > > I prefer to start with at least two physical interfaces per node when > doing routing. If not possible then see whether the link-layer can > offer two virtual interfaces on a single physical interface (wifi can). > > If that is not possible either... hard to see doing IP routing any > further. Well, we did it, and lots of other people did it. If you want to see it, there are numerous papers. It's not hard to see. > > > > If I had to struggle 1 year now to get the link-locals accepted here > imagine when I post a draft making exclusive use of them :-) Post away. I hope you test it on more than three nodes. > > Look at Carlos draft saying LLs are a MUST, which is just a reiteration > of existing things - immediate pushback :-( The point is that we can't use existing things. > > >> >> You are designing for (single-subnet ??) WiFi. > > YEs, it is exchanging RAs on a single subnet WiFi, which has no prefix > on it other than the link-local addresses and prefix fe80. And you don't want to allow other people to design more general systems?? > > It is egress interfaces of Mobile Routers, ifaces put together in > "ad-hoc" mode. The ingress ifaces are also wifi but different essids, > different channels, no "ad-hoc" mode, etc. Hmm... no "ad-hoc" mode.... hmmm.... a very poor fit for [manet] routing protocols. > > The nodes "behind" the Mobile Routers use global IP addresses, yet their > egress interfaces are exclusively link-locally addressed. What if there aren't any nodes "behind" any other nodes? > > > > >> I also think we have to allow for multi-hop transmissions beyond the >> range of any one node in the network. Do you disagree? > > Depends what you mean by multi-hop. There are some star topologies > which have very few IP hops in between (2, 3max) and which can work if > the inner core is exclusively link-locally addressed. > > This is a goal which is reachable. There are many good reachable goals -- goals which HAVE been reached in previous work. Goals that go far beyond this terrible restriction. Goals that deal with networks with _no_ "inner core". Do you deny that these goals are worthwhile to reach with standardized solutions? > > But once you start talking multi-hop like unlimited number of IP hops > in between, with thousands of nodes, with arbitrarily varying > topologies that even a simple human can't describe - this goal is not > reachable. It has been reached. Your statement is wrong. > >>> If I had 1000s of nodes then I would _subnet_ this with routers in >>> the middle -- for sure! That means at least bridging, and most >>> probably routing. That means several interfaces on a node. >> >> I like routing. I think it's a great idea. I think it is wrong to >> establish the uniqueness of link-layer addresses by routing. > > Well I don't propose to establish the uniqueness of link-layer > addresses by routing. They're inherently unique because of the nature > of the considered link layer - wifi. That should be a separate document, maybe from a separate group, with people who want a more restricted focus. And even with the restricted focus I predict it will fail if you rely on ND and DHCP. > > I want the _core_ of my MR-to-MR communications to be exclusively > link-locally addressed. IT is small in terms of number of > intermediary hops. It is understandable. It does not use thousands > of nodes on that core. I don't want to mandate reliance on any such core. I thought we were dealing with _ad-hoc_ networks. > > There are of course several subnets, and one of them is the "core" if > I can name it so. > > There is no magic in what I propose. What you propose is needlessly restrictive to impose on all working group solutions. > >> >> Then we're back to figuring out why a node with a single radio >> channel should have multiple network interfaces. > > I would go as far as putting two such nodes together such that I can > get two interfaces on the union node and IP route between them naturally. Not very economically viable. Mandating this is a prescription for almost certain failure. >> >> So why would the document recommend them? Why can't we just leave >> them alone? > > Ok! LEave them alone. State in the document "we leave the LLs alone". > > Unfortunately now it unrecommends them. To be precise, it points out where the dangers lie. > >> >> Do you mean to say that we can only understand rectilinear networks? >> Then I insist that you must speak for yourself, and furthermore that >> [autoconf] must not place this restriction. > > WEll, I meant that rectilinear topologies like this: > > Node1----Node2----Node3---....---Noden > > Where intermediary nodes each has 2 interfaces are easy to understand > and deploy IP on them. "Rectilinear" is probably not the right term, > because I don't impose a restriction on the physical disposition - > they could be in a circle too, for example. > > But I require that each of the intermediary nodes has two interfaces. That's a really really bad idea I think. > > This topoology is easy to understand and deploy IP on. Why not restrict to topologies of only two nodes? Or even just one node? Those topologies are even easier to understand. > > And yes I speak for myself. And yes, I know you don't want to > restrict to _any_ kind of particular topology, be that rectilinear, > circle or any other form or shape, and that there exist imagination > enough to come up with topologies which nobody else has ever imagined > before. IT's a good research topic. It's a good topic for standardization. And, to be perfectly frank, you cannot identify the topology of the Internet either. I can't imagine wanting to restrict the Internet to conform to only certain topologies. Regards, Charlie P. From alexandru.petrescu@gmail.com Thu Oct 22 15:22: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 ED6D628C1A6 for ; Thu, 22 Oct 2009 15:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.947 X-Spam-Level: X-Spam-Status: No, score=-0.947 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_05=-1.11, 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 sP5BZjdcsAcS for ; Thu, 22 Oct 2009 15:22:36 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id B856228C19E for ; Thu, 22 Oct 2009 15:22:34 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 4D632D4801A; Fri, 23 Oct 2009 00:22:39 +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 F0CB9D48076; Fri, 23 Oct 2009 00:22:36 +0200 (CEST) Message-ID: <4AE0DB2A.7090902@gmail.com> Date: Fri, 23 Oct 2009 00:22:34 +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> <4ABA5A8F.4020800@gmail.com> <4ABA5E20.8090608@gmail.com> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> In-Reply-To: <4AE0A7BA.2060002@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091022-0, 22/10/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] [warning -- weeks old mail under discussion] Re: 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: Thu, 22 Oct 2009 22:22:37 -0000 Charles E. Perkins a écrit : [...] >>> Ten or more neighbors, moving at any reasonable speed, and your >>> design is toast -- DHCP or no DHCP. >> >> Charles - "speed" as we tend to interpret it may have no sense when >> we consider coverage areas. Node speed of 300kmph equals 0 if the >> coverage is very large. > > This is a good point. Perhaps the proper quantity of interest is the > average transition time through the range of coverage from a > neighboring node. Average transition time (ATT) through some coverage sounds more tempting than simply "speed". So a vehicle would have an ATT of 3.6seconds (50kmph, 50m wifi). 3.6s is enough to perform DHCP and many other things. >> Node speed of 300kmph going through a 50m wifi area - ok, no DHCP: >> but then one wonders _why_ would a car need to communicate anything >> through that 50m wifi area. > > I personally think this is a great idea, if for instance we had WiFi > on the streetlamps and freeway dividers. It could work for certain values of ATT, I am sure. > At $1.00 per transceiver chip, it's a reasonable alternative! It > draws a lot less power than the light bulb. > >> DHCP or no DHCP... what coverage area? what link layer? >> >> DHCP can be very fast. > > In order to counter this statement (or, more accurately, show why it > is not relevant), I would have to go through the exercise -- but you > had relieved me of that task. I know why people say DHCP is slow. I've measured it. There are quirks with some implementations of the timers. It's mostly in the discovery phase. It's the same fundamental reasons why some people complain about slow WiFi link-layer handovers, and slow Mobile IP, and slow NUD, slow ND - which I've also measured. Basically one can't do discovery otherwise than emitting and then _waiting_ a pre-defined amount of time. It's the basics of the basics. What one can do is to shorten the time one waits, at the risk of not hearing some things and maybe hitting into someone, or missing the presence of some DHCP Server. AUTOCONF can't propose a discovery mechanism better than the discovery phases of DHCP, ND, and FastBSS. People would have already done it well before. > I'm not going to do that unless necessary. > > But, roughly speaking, the answer is that you can't have DHCP unless > you know where the server(s) and the relays are. Err... yes, more or less. The Client performs a discovery phase, sending first to a predefined multicast address and then waiting. > And when the nodes > are moving, you don't know. Well - you do know for some time. > And you can't quote NUD and NA as > theorems because of the reasons I already outlined in previous > messages. And even if you could, before long you'd have to get some > new relay because you need the relay to be local. And more than > likely your DHCP server will be occasionally partitioned into > temporary isolation. But then it's back! But the relay is gone! > And then there's something else to go wrong. But, are _all_ nodes > relays? But, which server has the state? Or is there just one > server? But that won't ever work! > > Every time I think about it, I just know it's wrong. I do not have > any belief whatsoever in this theorem. And, with three nodes, you'll > never see the problem. Never! Well I look at it as a distributed election problem. Dynamically elect the Servers and the Relays, among them. Of course, afterwards, the elected DHCP Server needs to learn the addresses of the relays and to have routes to them. These issues can be solved by using link-local addresses. This entire mechanism will work during some lapse of time during which the devices are within relatively stable distance. When links start breaking, nodes disappear, other nodes appear - re-execute the entire election process. Now, don't tell me that things move so fast that there is not enough time to deal with re-election: there will always be things which move too fast for whoever and whatever mechanism to break, including whatever AUTOCONF designs. Alex From alexandru.petrescu@gmail.com Thu Oct 22 15:38: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 03FE03A692F for ; Thu, 22 Oct 2009 15:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.682 X-Spam-Level: X-Spam-Status: No, score=-1.682 tagged_above=-999 required=5 tests=[AWL=0.567, 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 L1f5x5JU60D6 for ; Thu, 22 Oct 2009 15:38:11 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 8EBD83A67C0 for ; Thu, 22 Oct 2009 15:38:08 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id EDC04D4802A; Fri, 23 Oct 2009 00:38:15 +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 D7D76D480A6; Fri, 23 Oct 2009 00:38:12 +0200 (CEST) Message-ID: <4AE0DED2.8000907@gmail.com> Date: Fri, 23 Oct 2009 00:38:10 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4AE088E3.6080304@earthlink.net> <4AE09967.9060809@gmail.com> <4AE0AFE2.20200@earthlink.net> <4AE0CA51.5070300@gmail.com> <4AE0D477.1070809@earthlink.net> In-Reply-To: <4AE0D477.1070809@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091022-0, 22/10/2009), Outbound message X-Antivirus-Status: Clean Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] summarizing various - nothing new 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, 22 Oct 2009 22:38:12 -0000 Discussions on restrictions, I propose numerous constraints on the size and type of the topology such that the topic can be tackled. Charles proposes to not have any restriction of this kind. Charles finally uses a strong argument: there are no restrictions on the Internet topology either, so supposedly there should be no restrictions in the AUTOCONF topology either. Are we developing a new Internet here in AUTOCONF? Charles also expresses doubts: even if such restrictions are in place, the use of ND and DHCP is not promissing. Alex Charles E. Perkins a écrit : >> If that is not possible either... hard to see doing IP routing any >> further. > > Well, we did it, and lots of other people did it. If you want to see > it, there are numerous papers. It's not hard to see. > >> >> >> >> If I had to struggle 1 year now to get the link-locals accepted >> here imagine when I post a draft making exclusive use of them :-) > Post away. I hope you test it on more than three nodes. > >> >> Look at Carlos draft saying LLs are a MUST, which is just a >> reiteration of existing things - immediate pushback :-( > > The point is that we can't use existing things. > >> >> >>> >>> You are designing for (single-subnet ??) WiFi. >> >> YEs, it is exchanging RAs on a single subnet WiFi, which has no >> prefix on it other than the link-local addresses and prefix fe80. > > And you don't want to allow other people to design more general > systems?? > >> >> It is egress interfaces of Mobile Routers, ifaces put together in >> "ad-hoc" mode. The ingress ifaces are also wifi but different >> essids, different channels, no "ad-hoc" mode, etc. > > Hmm... no "ad-hoc" mode.... hmmm.... a very poor fit for [manet] > routing protocols. > >> >> The nodes "behind" the Mobile Routers use global IP addresses, yet >> their egress interfaces are exclusively link-locally addressed. > What if there aren't any nodes "behind" any other nodes? > >> >> >> >> >>> I also think we have to allow for multi-hop transmissions beyond >>> the range of any one node in the network. Do you disagree? >> >> Depends what you mean by multi-hop. There are some star topologies >> which have very few IP hops in between (2, 3max) and which can >> work if the inner core is exclusively link-locally addressed. >> >> This is a goal which is reachable. > > There are many good reachable goals -- goals which HAVE been reached > in previous work. Goals that go far beyond this terrible > restriction. Goals that deal with networks with _no_ "inner core". > Do you deny that these goals are worthwhile to reach with > standardized solutions? > >> >> But once you start talking multi-hop like unlimited number of IP >> hops in between, with thousands of nodes, with arbitrarily varying >> topologies that even a simple human can't describe - this goal is >> not reachable. > > It has been reached. Your statement is wrong. > >> >>>> If I had 1000s of nodes then I would _subnet_ this with routers >>>> in the middle -- for sure! That means at least bridging, and >>>> most probably routing. That means several interfaces on a >>>> node. >>> >>> I like routing. I think it's a great idea. I think it is wrong >>> to establish the uniqueness of link-layer addresses by routing. >> >> Well I don't propose to establish the uniqueness of link-layer >> addresses by routing. They're inherently unique because of the >> nature of the considered link layer - wifi. > > That should be a separate document, maybe from a separate group, with > people who want a more restricted focus. And even with the > restricted focus I predict it will fail if you rely on ND and DHCP. > >> >> I want the _core_ of my MR-to-MR communications to be exclusively >> link-locally addressed. IT is small in terms of number of >> intermediary hops. It is understandable. It does not use >> thousands of nodes on that core. > > I don't want to mandate reliance on any such core. I thought we were > dealing with _ad-hoc_ networks. > > >> >> There are of course several subnets, and one of them is the "core" >> if I can name it so. >> >> There is no magic in what I propose. > What you propose is needlessly restrictive to impose on all working > group solutions. > >> >>> >>> Then we're back to figuring out why a node with a single radio >>> channel should have multiple network interfaces. >> >> I would go as far as putting two such nodes together such that I >> can get two interfaces on the union node and IP route between them >> naturally. > > Not very economically viable. Mandating this is a prescription for > almost certain failure. > >>> >>> So why would the document recommend them? Why can't we just >>> leave them alone? >> >> Ok! LEave them alone. State in the document "we leave the LLs >> alone". >> >> Unfortunately now it unrecommends them. > > To be precise, it points out where the dangers lie. > >> >>> >>> Do you mean to say that we can only understand rectilinear >>> networks? Then I insist that you must speak for yourself, and >>> furthermore that [autoconf] must not place this restriction. >> >> WEll, I meant that rectilinear topologies like this: >> >> Node1----Node2----Node3---....---Noden >> >> Where intermediary nodes each has 2 interfaces are easy to >> understand and deploy IP on them. "Rectilinear" is probably not >> the right term, because I don't impose a restriction on the >> physical disposition - they could be in a circle too, for example. >> >> But I require that each of the intermediary nodes has two >> interfaces. > That's a really really bad idea I think. > >> >> This topoology is easy to understand and deploy IP on. > > Why not restrict to topologies of only two nodes? > > Or even just one node? > > Those topologies are even easier to understand. > >> >> And yes I speak for myself. And yes, I know you don't want to >> restrict to _any_ kind of particular topology, be that rectilinear, >> circle or any other form or shape, and that there exist >> imagination enough to come up with topologies which nobody else has >> ever imagined before. IT's a good research topic. > > It's a good topic for standardization. And, to be perfectly frank, > you cannot identify the topology of the Internet either. I can't > imagine wanting to restrict the Internet to conform to only certain > topologies. From ietf@thomasclausen.org Thu Oct 22 15:45:21 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 224BA3A67EC for ; Thu, 22 Oct 2009 15:45:21 -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 4V5Cmxdu7u5C for ; Thu, 22 Oct 2009 15:45:20 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id EF9133A67C0 for ; Thu, 22 Oct 2009 15:45:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id BCBF632317AF; Thu, 22 Oct 2009 15:45:26 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id F28D132317A9; Thu, 22 Oct 2009 15:45:23 -0700 (PDT) Message-Id: From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE0DED2.8000907@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: Fri, 23 Oct 2009 00:45:21 +0200 References: <4AE088E3.6080304@earthlink.net> <4AE09967.9060809@gmail.com> <4AE0AFE2.20200@earthlink.net> <4AE0CA51.5070300@gmail.com> <4AE0D477.1070809@earthlink.net> <4AE0DED2.8000907@gmail.com> X-Mailer: Apple Mail (2.936) Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] summarizing various - nothing new 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, 22 Oct 2009 22:45:21 -0000 Dear Alex, I think that the point Charlie is trying to make is, that the =20 constraints and restrictions that you propose do not correspond to the =20= reality of the MANETs that are in operation today.... How do the MANETs that you build look, Alex? Thomas On Oct 23, 2009, at 12:38 AM, Alexandru Petrescu wrote: > Discussions on restrictions, > > I propose numerous constraints on the size and type of the topology =20= > such that the topic can be tackled. > > Charles proposes to not have any restriction of this kind. > > Charles finally uses a strong argument: there are no restrictions on =20= > the Internet topology either, so supposedly there should be no =20 > restrictions in the AUTOCONF topology either. > > Are we developing a new Internet here in AUTOCONF? > > Charles also expresses doubts: even if such restrictions are in =20 > place, the use of ND and DHCP is not promissing. > > Alex > > > Charles E. Perkins a =E9crit : >>> If that is not possible either... hard to see doing IP routing any >>> further. >> Well, we did it, and lots of other people did it. If you want to see >> it, there are numerous papers. It's not hard to see. >>> If I had to struggle 1 year now to get the link-locals accepted >>> here imagine when I post a draft making exclusive use of them :-) >> Post away. I hope you test it on more than three nodes. >>> Look at Carlos draft saying LLs are a MUST, which is just a >>> reiteration of existing things - immediate pushback :-( >> The point is that we can't use existing things. >>>> You are designing for (single-subnet ??) WiFi. >>> YEs, it is exchanging RAs on a single subnet WiFi, which has no >>> prefix on it other than the link-local addresses and prefix fe80. >> And you don't want to allow other people to design more general >> systems?? >>> It is egress interfaces of Mobile Routers, ifaces put together in =20= >>> "ad-hoc" mode. The ingress ifaces are also wifi but different >>> essids, different channels, no "ad-hoc" mode, etc. >> Hmm... no "ad-hoc" mode.... hmmm.... a very poor fit for [manet] >> routing protocols. >>> The nodes "behind" the Mobile Routers use global IP addresses, yet >>> their egress interfaces are exclusively link-locally addressed. >> What if there aren't any nodes "behind" any other nodes? >>>> I also think we have to allow for multi-hop transmissions beyond >>>> the range of any one node in the network. Do you disagree? >>> Depends what you mean by multi-hop. There are some star topologies >>> which have very few IP hops in between (2, 3max) and which can >>> work if the inner core is exclusively link-locally addressed. >>> This is a goal which is reachable. >> There are many good reachable goals -- goals which HAVE been =20 >> reached in previous work. Goals that go far beyond this terrible >> restriction. Goals that deal with networks with _no_ "inner core". >> Do you deny that these goals are worthwhile to reach with >> standardized solutions? >>> But once you start talking multi-hop like unlimited number of IP >>> hops in between, with thousands of nodes, with arbitrarily varying >>> topologies that even a simple human can't describe - this goal is >>> not reachable. >> It has been reached. Your statement is wrong. >>>>> If I had 1000s of nodes then I would _subnet_ this with routers >>>>> in the middle -- for sure! That means at least bridging, and >>>>> most probably routing. That means several interfaces on a >>>>> node. >>>> I like routing. I think it's a great idea. I think it is wrong >>>> to establish the uniqueness of link-layer addresses by routing. >>> Well I don't propose to establish the uniqueness of link-layer =20 >>> addresses by routing. They're inherently unique because of the >>> nature of the considered link layer - wifi. >> That should be a separate document, maybe from a separate group, with >> people who want a more restricted focus. And even with the =20 >> restricted focus I predict it will fail if you rely on ND and DHCP. >>> I want the _core_ of my MR-to-MR communications to be exclusively =20= >>> link-locally addressed. IT is small in terms of number of =20 >>> intermediary hops. It is understandable. It does not use >>> thousands of nodes on that core. >> I don't want to mandate reliance on any such core. I thought we were >> dealing with _ad-hoc_ networks. >>> There are of course several subnets, and one of them is the "core" >>> if I can name it so. >>> There is no magic in what I propose. >> What you propose is needlessly restrictive to impose on all working >> group solutions. >>>> Then we're back to figuring out why a node with a single radio =20 >>>> channel should have multiple network interfaces. >>> I would go as far as putting two such nodes together such that I >>> can get two interfaces on the union node and IP route between them >>> naturally. >> Not very economically viable. Mandating this is a prescription for >> almost certain failure. >>>> So why would the document recommend them? Why can't we just >>>> leave them alone? >>> Ok! LEave them alone. State in the document "we leave the LLs >>> alone". >>> Unfortunately now it unrecommends them. >> To be precise, it points out where the dangers lie. >>>> Do you mean to say that we can only understand rectilinear >>>> networks? Then I insist that you must speak for yourself, and >>>> furthermore that [autoconf] must not place this restriction. >>> WEll, I meant that rectilinear topologies like this: >>> Node1----Node2----Node3---....---Noden >>> Where intermediary nodes each has 2 interfaces are easy to >>> understand and deploy IP on them. "Rectilinear" is probably not >>> the right term, because I don't impose a restriction on the >>> physical disposition - they could be in a circle too, for example. >>> But I require that each of the intermediary nodes has two >>> interfaces. >> That's a really really bad idea I think. >>> This topoology is easy to understand and deploy IP on. >> Why not restrict to topologies of only two nodes? >> Or even just one node? >> Those topologies are even easier to understand. >>> And yes I speak for myself. And yes, I know you don't want to =20 >>> restrict to _any_ kind of particular topology, be that rectilinear, >>> circle or any other form or shape, and that there exist >>> imagination enough to come up with topologies which nobody else has >>> ever imagined before. IT's a good research topic. >> It's a good topic for standardization. And, to be perfectly frank, >> you cannot identify the topology of the Internet either. I can't >> imagine wanting to restrict the Internet to conform to only certain >> topologies. > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From alexandru.petrescu@gmail.com Thu Oct 22 16:07: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 3BCCE3A6A21 for ; Thu, 22 Oct 2009 16:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.71 X-Spam-Level: X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[AWL=0.539, 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 eg4156lUHJiD for ; Thu, 22 Oct 2009 16:07:05 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id C7A443A6964 for ; Thu, 22 Oct 2009 16:07:03 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id B0396D48035; Fri, 23 Oct 2009 01:07:09 +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 56F1AD48018; Fri, 23 Oct 2009 01:07:06 +0200 (CEST) Message-ID: <4AE0E597.8040609@gmail.com> Date: Fri, 23 Oct 2009 01:07:03 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <4AE088E3.6080304@earthlink.net> <4AE09967.9060809@gmail.com> <4AE0AFE2.20200@earthlink.net> <4AE0CA51.5070300@gmail.com> <4AE0D477.1070809@earthlink.net> <4AE0DED2.8000907@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091022-0, 22/10/2009), Outbound message X-Antivirus-Status: Clean Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] summarizing various - nothing new 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, 22 Oct 2009 23:07:06 -0000 Hi Thomas, Thomas Heide Clausen a écrit : > Dear Alex, > > I think that the point Charlie is trying to make is, that the > constraints and restrictions that you propose do not correspond to the > reality of the MANETs that are in operation today.... > > How do the MANETs that you build look, Alex? The one network that I have now running in the lab and which may tempt somebody to call a MANET has 3 Mobile Routers. That's it. It's very stable physically, it's very constrained and is all planned in advance - it has nothing of the unplanned "adhoc"iness of unconstrained MANETs. Moreover it relies very much on the use of IPv6 link-local addresses. Why? Alex > > Thomas > > > On Oct 23, 2009, at 12:38 AM, Alexandru Petrescu wrote: > >> Discussions on restrictions, >> >> I propose numerous constraints on the size and type of the topology >> such that the topic can be tackled. >> >> Charles proposes to not have any restriction of this kind. >> >> Charles finally uses a strong argument: there are no restrictions on >> the Internet topology either, so supposedly there should be no >> restrictions in the AUTOCONF topology either. >> >> Are we developing a new Internet here in AUTOCONF? >> >> Charles also expresses doubts: even if such restrictions are in place, >> the use of ND and DHCP is not promissing. >> >> Alex >> >> >> Charles E. Perkins a écrit : >>>> If that is not possible either... hard to see doing IP routing any >>>> further. >>> Well, we did it, and lots of other people did it. If you want to see >>> it, there are numerous papers. It's not hard to see. >>>> If I had to struggle 1 year now to get the link-locals accepted >>>> here imagine when I post a draft making exclusive use of them :-) >>> Post away. I hope you test it on more than three nodes. >>>> Look at Carlos draft saying LLs are a MUST, which is just a >>>> reiteration of existing things - immediate pushback :-( >>> The point is that we can't use existing things. >>>>> You are designing for (single-subnet ??) WiFi. >>>> YEs, it is exchanging RAs on a single subnet WiFi, which has no >>>> prefix on it other than the link-local addresses and prefix fe80. >>> And you don't want to allow other people to design more general >>> systems?? >>>> It is egress interfaces of Mobile Routers, ifaces put together in >>>> "ad-hoc" mode. The ingress ifaces are also wifi but different >>>> essids, different channels, no "ad-hoc" mode, etc. >>> Hmm... no "ad-hoc" mode.... hmmm.... a very poor fit for [manet] >>> routing protocols. >>>> The nodes "behind" the Mobile Routers use global IP addresses, yet >>>> their egress interfaces are exclusively link-locally addressed. >>> What if there aren't any nodes "behind" any other nodes? >>>>> I also think we have to allow for multi-hop transmissions beyond >>>>> the range of any one node in the network. Do you disagree? >>>> Depends what you mean by multi-hop. There are some star topologies >>>> which have very few IP hops in between (2, 3max) and which can >>>> work if the inner core is exclusively link-locally addressed. >>>> This is a goal which is reachable. >>> There are many good reachable goals -- goals which HAVE been reached >>> in previous work. Goals that go far beyond this terrible >>> restriction. Goals that deal with networks with _no_ "inner core". >>> Do you deny that these goals are worthwhile to reach with >>> standardized solutions? >>>> But once you start talking multi-hop like unlimited number of IP >>>> hops in between, with thousands of nodes, with arbitrarily varying >>>> topologies that even a simple human can't describe - this goal is >>>> not reachable. >>> It has been reached. Your statement is wrong. >>>>>> If I had 1000s of nodes then I would _subnet_ this with routers >>>>>> in the middle -- for sure! That means at least bridging, and >>>>>> most probably routing. That means several interfaces on a >>>>>> node. >>>>> I like routing. I think it's a great idea. I think it is wrong >>>>> to establish the uniqueness of link-layer addresses by routing. >>>> Well I don't propose to establish the uniqueness of link-layer >>>> addresses by routing. They're inherently unique because of the >>>> nature of the considered link layer - wifi. >>> That should be a separate document, maybe from a separate group, with >>> people who want a more restricted focus. And even with the >>> restricted focus I predict it will fail if you rely on ND and DHCP. >>>> I want the _core_ of my MR-to-MR communications to be exclusively >>>> link-locally addressed. IT is small in terms of number of >>>> intermediary hops. It is understandable. It does not use >>>> thousands of nodes on that core. >>> I don't want to mandate reliance on any such core. I thought we were >>> dealing with _ad-hoc_ networks. >>>> There are of course several subnets, and one of them is the "core" >>>> if I can name it so. >>>> There is no magic in what I propose. >>> What you propose is needlessly restrictive to impose on all working >>> group solutions. >>>>> Then we're back to figuring out why a node with a single radio >>>>> channel should have multiple network interfaces. >>>> I would go as far as putting two such nodes together such that I >>>> can get two interfaces on the union node and IP route between them >>>> naturally. >>> Not very economically viable. Mandating this is a prescription for >>> almost certain failure. >>>>> So why would the document recommend them? Why can't we just >>>>> leave them alone? >>>> Ok! LEave them alone. State in the document "we leave the LLs >>>> alone". >>>> Unfortunately now it unrecommends them. >>> To be precise, it points out where the dangers lie. >>>>> Do you mean to say that we can only understand rectilinear >>>>> networks? Then I insist that you must speak for yourself, and >>>>> furthermore that [autoconf] must not place this restriction. >>>> WEll, I meant that rectilinear topologies like this: >>>> Node1----Node2----Node3---....---Noden >>>> Where intermediary nodes each has 2 interfaces are easy to >>>> understand and deploy IP on them. "Rectilinear" is probably not >>>> the right term, because I don't impose a restriction on the >>>> physical disposition - they could be in a circle too, for example. >>>> But I require that each of the intermediary nodes has two >>>> interfaces. >>> That's a really really bad idea I think. >>>> This topoology is easy to understand and deploy IP on. >>> Why not restrict to topologies of only two nodes? >>> Or even just one node? >>> Those topologies are even easier to understand. >>>> And yes I speak for myself. And yes, I know you don't want to >>>> restrict to _any_ kind of particular topology, be that rectilinear, >>>> circle or any other form or shape, and that there exist >>>> imagination enough to come up with topologies which nobody else has >>>> ever imagined before. IT's a good research topic. >>> It's a good topic for standardization. And, to be perfectly frank, >>> you cannot identify the topology of the Internet either. I can't >>> imagine wanting to restrict the Internet to conform to only certain >>> topologies. >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > From ietf@thomasclausen.org Thu Oct 22 16:10: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 9EF863A6A21 for ; Thu, 22 Oct 2009 16:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 cemVtMJ009Tl for ; Thu, 22 Oct 2009 16:10:07 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 787543A69FA for ; Thu, 22 Oct 2009 16:10:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id BFA5132317B4; Thu, 22 Oct 2009 16:10:17 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 569B832317A9; Thu, 22 Oct 2009 16:10:16 -0700 (PDT) Message-Id: <8A4B2870-C12A-4ED8-9ECE-0923B9B8F4C5@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE0E597.8040609@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: Fri, 23 Oct 2009 01:10:13 +0200 References: <4AE088E3.6080304@earthlink.net> <4AE09967.9060809@gmail.com> <4AE0AFE2.20200@earthlink.net> <4AE0CA51.5070300@gmail.com> <4AE0D477.1070809@earthlink.net> <4AE0DED2.8000907@gmail.com> <4AE0E597.8040609@gmail.com> X-Mailer: Apple Mail (2.936) Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] summarizing various - nothing new 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, 22 Oct 2009 23:10:08 -0000 On Oct 23, 2009, at 1:07 AM, Alexandru Petrescu wrote: > Hi Thomas, > > Thomas Heide Clausen a =E9crit : >> Dear Alex, >> I think that the point Charlie is trying to make is, that the =20 >> constraints and restrictions that you propose do not correspond to =20= >> the reality of the MANETs that are in operation today.... >> How do the MANETs that you build look, Alex? > > The one network that I have now running in the lab and which may =20 > tempt somebody to call a MANET has 3 Mobile Routers. That's it. =20 > It's very stable physically, it's very constrained and is all =20 > planned in advance - it has nothing of the unplanned "adhoc"iness of =20= > unconstrained MANETs. Moreover it relies very much on the use of =20 > IPv6 link-local addresses. > > Why? Just observing that this is a very very different from a typical MANET =20= in pretty much every possible way. Thomas > > Alex > >> Thomas >> On Oct 23, 2009, at 12:38 AM, Alexandru Petrescu wrote: >>> Discussions on restrictions, >>> >>> I propose numerous constraints on the size and type of the =20 >>> topology such that the topic can be tackled. >>> >>> Charles proposes to not have any restriction of this kind. >>> >>> Charles finally uses a strong argument: there are no restrictions =20= >>> on the Internet topology either, so supposedly there should be no =20= >>> restrictions in the AUTOCONF topology either. >>> >>> Are we developing a new Internet here in AUTOCONF? >>> >>> Charles also expresses doubts: even if such restrictions are in =20 >>> place, the use of ND and DHCP is not promissing. >>> >>> Alex >>> >>> >>> Charles E. Perkins a =E9crit : >>>>> If that is not possible either... hard to see doing IP routing any >>>>> further. >>>> Well, we did it, and lots of other people did it. If you want to =20= >>>> see >>>> it, there are numerous papers. It's not hard to see. >>>>> If I had to struggle 1 year now to get the link-locals accepted >>>>> here imagine when I post a draft making exclusive use of them :-) >>>> Post away. I hope you test it on more than three nodes. >>>>> Look at Carlos draft saying LLs are a MUST, which is just a >>>>> reiteration of existing things - immediate pushback :-( >>>> The point is that we can't use existing things. >>>>>> You are designing for (single-subnet ??) WiFi. >>>>> YEs, it is exchanging RAs on a single subnet WiFi, which has no >>>>> prefix on it other than the link-local addresses and prefix fe80. >>>> And you don't want to allow other people to design more general >>>> systems?? >>>>> It is egress interfaces of Mobile Routers, ifaces put together =20 >>>>> in "ad-hoc" mode. The ingress ifaces are also wifi but different >>>>> essids, different channels, no "ad-hoc" mode, etc. >>>> Hmm... no "ad-hoc" mode.... hmmm.... a very poor fit for [manet] >>>> routing protocols. >>>>> The nodes "behind" the Mobile Routers use global IP addresses, yet >>>>> their egress interfaces are exclusively link-locally addressed. >>>> What if there aren't any nodes "behind" any other nodes? >>>>>> I also think we have to allow for multi-hop transmissions beyond >>>>>> the range of any one node in the network. Do you disagree? >>>>> Depends what you mean by multi-hop. There are some star =20 >>>>> topologies >>>>> which have very few IP hops in between (2, 3max) and which can >>>>> work if the inner core is exclusively link-locally addressed. >>>>> This is a goal which is reachable. >>>> There are many good reachable goals -- goals which HAVE been =20 >>>> reached in previous work. Goals that go far beyond this terrible >>>> restriction. Goals that deal with networks with _no_ "inner core". >>>> Do you deny that these goals are worthwhile to reach with >>>> standardized solutions? >>>>> But once you start talking multi-hop like unlimited number of IP >>>>> hops in between, with thousands of nodes, with arbitrarily varying >>>>> topologies that even a simple human can't describe - this goal is >>>>> not reachable. >>>> It has been reached. Your statement is wrong. >>>>>>> If I had 1000s of nodes then I would _subnet_ this with routers >>>>>>> in the middle -- for sure! That means at least bridging, and >>>>>>> most probably routing. That means several interfaces on a >>>>>>> node. >>>>>> I like routing. I think it's a great idea. I think it is wrong >>>>>> to establish the uniqueness of link-layer addresses by routing. >>>>> Well I don't propose to establish the uniqueness of link-layer =20 >>>>> addresses by routing. They're inherently unique because of the >>>>> nature of the considered link layer - wifi. >>>> That should be a separate document, maybe from a separate group, =20= >>>> with >>>> people who want a more restricted focus. And even with the =20 >>>> restricted focus I predict it will fail if you rely on ND and DHCP. >>>>> I want the _core_ of my MR-to-MR communications to be =20 >>>>> exclusively link-locally addressed. IT is small in terms of =20 >>>>> number of intermediary hops. It is understandable. It does not =20= >>>>> use >>>>> thousands of nodes on that core. >>>> I don't want to mandate reliance on any such core. I thought we =20 >>>> were >>>> dealing with _ad-hoc_ networks. >>>>> There are of course several subnets, and one of them is the "core" >>>>> if I can name it so. >>>>> There is no magic in what I propose. >>>> What you propose is needlessly restrictive to impose on all working >>>> group solutions. >>>>>> Then we're back to figuring out why a node with a single radio =20= >>>>>> channel should have multiple network interfaces. >>>>> I would go as far as putting two such nodes together such that I >>>>> can get two interfaces on the union node and IP route between them >>>>> naturally. >>>> Not very economically viable. Mandating this is a prescription for >>>> almost certain failure. >>>>>> So why would the document recommend them? Why can't we just >>>>>> leave them alone? >>>>> Ok! LEave them alone. State in the document "we leave the LLs >>>>> alone". >>>>> Unfortunately now it unrecommends them. >>>> To be precise, it points out where the dangers lie. >>>>>> Do you mean to say that we can only understand rectilinear >>>>>> networks? Then I insist that you must speak for yourself, and >>>>>> furthermore that [autoconf] must not place this restriction. >>>>> WEll, I meant that rectilinear topologies like this: >>>>> Node1----Node2----Node3---....---Noden >>>>> Where intermediary nodes each has 2 interfaces are easy to >>>>> understand and deploy IP on them. "Rectilinear" is probably not >>>>> the right term, because I don't impose a restriction on the >>>>> physical disposition - they could be in a circle too, for example. >>>>> But I require that each of the intermediary nodes has two >>>>> interfaces. >>>> That's a really really bad idea I think. >>>>> This topoology is easy to understand and deploy IP on. >>>> Why not restrict to topologies of only two nodes? >>>> Or even just one node? >>>> Those topologies are even easier to understand. >>>>> And yes I speak for myself. And yes, I know you don't want to =20 >>>>> restrict to _any_ kind of particular topology, be that =20 >>>>> rectilinear, >>>>> circle or any other form or shape, and that there exist >>>>> imagination enough to come up with topologies which nobody else =20= >>>>> has >>>>> ever imagined before. IT's a good research topic. >>>> It's a good topic for standardization. And, to be perfectly frank, >>>> you cannot identify the topology of the Internet either. I can't >>>> imagine wanting to restrict the Internet to conform to only certain >>>> topologies. >>> >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf > From ietf@thomasclausen.org Thu Oct 22 16:14:46 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 8C9513A6833 for ; Thu, 22 Oct 2009 16:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 poan1qdBum1q for ; Thu, 22 Oct 2009 16:14: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 6B52A3A6830 for ; Thu, 22 Oct 2009 16:14:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id D09353231747; Thu, 22 Oct 2009 16:14:55 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 6D50B32317AD; Thu, 22 Oct 2009 16:14:54 -0700 (PDT) Message-Id: <1D83564F-22D6-4FCF-8F19-756AF5529B85@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE0E597.8040609@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: Fri, 23 Oct 2009 01:14:52 +0200 References: <4AE088E3.6080304@earthlink.net> <4AE09967.9060809@gmail.com> <4AE0AFE2.20200@earthlink.net> <4AE0CA51.5070300@gmail.com> <4AE0D477.1070809@earthlink.net> <4AE0DED2.8000907@gmail.com> <4AE0E597.8040609@gmail.com> X-Mailer: Apple Mail (2.936) Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] summarizing various - nothing new 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, 22 Oct 2009 23:14:46 -0000 On Oct 23, 2009, at 1:07 AM, Alexandru Petrescu wrote: > Hi Thomas, > > Thomas Heide Clausen a =E9crit : >> Dear Alex, >> I think that the point Charlie is trying to make is, that the =20 >> constraints and restrictions that you propose do not correspond to =20= >> the reality of the MANETs that are in operation today.... >> How do the MANETs that you build look, Alex? > > The one network that I have now running in the lab and which may =20 > tempt somebody to call a MANET has 3 Mobile Routers. That's it. =20 > It's very stable physically, it's very constrained and is all =20 > planned in advance - it has nothing of the unplanned "adhoc"iness of =20= > unconstrained MANETs. Moreover it relies very much on the use of =20 > IPv6 link-local addresses. > > Why? > It just hit me.... MANET =3D Mobile Ad hoc NETwork Your lab-network is stable (so not Mobile) and planned in advance (so =20= not Ad hoc). I'd suggest not extrapolating MANET behavior based on your =20 observations from this (non-MANET) lab-network of yours. Thomas > Alex > >> Thomas >> On Oct 23, 2009, at 12:38 AM, Alexandru Petrescu wrote: >>> Discussions on restrictions, >>> >>> I propose numerous constraints on the size and type of the =20 >>> topology such that the topic can be tackled. >>> >>> Charles proposes to not have any restriction of this kind. >>> >>> Charles finally uses a strong argument: there are no restrictions =20= >>> on the Internet topology either, so supposedly there should be no =20= >>> restrictions in the AUTOCONF topology either. >>> >>> Are we developing a new Internet here in AUTOCONF? >>> >>> Charles also expresses doubts: even if such restrictions are in =20 >>> place, the use of ND and DHCP is not promissing. >>> >>> Alex >>> >>> >>> Charles E. Perkins a =E9crit : >>>>> If that is not possible either... hard to see doing IP routing any >>>>> further. >>>> Well, we did it, and lots of other people did it. If you want to =20= >>>> see >>>> it, there are numerous papers. It's not hard to see. >>>>> If I had to struggle 1 year now to get the link-locals accepted >>>>> here imagine when I post a draft making exclusive use of them :-) >>>> Post away. I hope you test it on more than three nodes. >>>>> Look at Carlos draft saying LLs are a MUST, which is just a >>>>> reiteration of existing things - immediate pushback :-( >>>> The point is that we can't use existing things. >>>>>> You are designing for (single-subnet ??) WiFi. >>>>> YEs, it is exchanging RAs on a single subnet WiFi, which has no >>>>> prefix on it other than the link-local addresses and prefix fe80. >>>> And you don't want to allow other people to design more general >>>> systems?? >>>>> It is egress interfaces of Mobile Routers, ifaces put together =20 >>>>> in "ad-hoc" mode. The ingress ifaces are also wifi but different >>>>> essids, different channels, no "ad-hoc" mode, etc. >>>> Hmm... no "ad-hoc" mode.... hmmm.... a very poor fit for [manet] >>>> routing protocols. >>>>> The nodes "behind" the Mobile Routers use global IP addresses, yet >>>>> their egress interfaces are exclusively link-locally addressed. >>>> What if there aren't any nodes "behind" any other nodes? >>>>>> I also think we have to allow for multi-hop transmissions beyond >>>>>> the range of any one node in the network. Do you disagree? >>>>> Depends what you mean by multi-hop. There are some star =20 >>>>> topologies >>>>> which have very few IP hops in between (2, 3max) and which can >>>>> work if the inner core is exclusively link-locally addressed. >>>>> This is a goal which is reachable. >>>> There are many good reachable goals -- goals which HAVE been =20 >>>> reached in previous work. Goals that go far beyond this terrible >>>> restriction. Goals that deal with networks with _no_ "inner core". >>>> Do you deny that these goals are worthwhile to reach with >>>> standardized solutions? >>>>> But once you start talking multi-hop like unlimited number of IP >>>>> hops in between, with thousands of nodes, with arbitrarily varying >>>>> topologies that even a simple human can't describe - this goal is >>>>> not reachable. >>>> It has been reached. Your statement is wrong. >>>>>>> If I had 1000s of nodes then I would _subnet_ this with routers >>>>>>> in the middle -- for sure! That means at least bridging, and >>>>>>> most probably routing. That means several interfaces on a >>>>>>> node. >>>>>> I like routing. I think it's a great idea. I think it is wrong >>>>>> to establish the uniqueness of link-layer addresses by routing. >>>>> Well I don't propose to establish the uniqueness of link-layer =20 >>>>> addresses by routing. They're inherently unique because of the >>>>> nature of the considered link layer - wifi. >>>> That should be a separate document, maybe from a separate group, =20= >>>> with >>>> people who want a more restricted focus. And even with the =20 >>>> restricted focus I predict it will fail if you rely on ND and DHCP. >>>>> I want the _core_ of my MR-to-MR communications to be =20 >>>>> exclusively link-locally addressed. IT is small in terms of =20 >>>>> number of intermediary hops. It is understandable. It does not =20= >>>>> use >>>>> thousands of nodes on that core. >>>> I don't want to mandate reliance on any such core. I thought we =20 >>>> were >>>> dealing with _ad-hoc_ networks. >>>>> There are of course several subnets, and one of them is the "core" >>>>> if I can name it so. >>>>> There is no magic in what I propose. >>>> What you propose is needlessly restrictive to impose on all working >>>> group solutions. >>>>>> Then we're back to figuring out why a node with a single radio =20= >>>>>> channel should have multiple network interfaces. >>>>> I would go as far as putting two such nodes together such that I >>>>> can get two interfaces on the union node and IP route between them >>>>> naturally. >>>> Not very economically viable. Mandating this is a prescription for >>>> almost certain failure. >>>>>> So why would the document recommend them? Why can't we just >>>>>> leave them alone? >>>>> Ok! LEave them alone. State in the document "we leave the LLs >>>>> alone". >>>>> Unfortunately now it unrecommends them. >>>> To be precise, it points out where the dangers lie. >>>>>> Do you mean to say that we can only understand rectilinear >>>>>> networks? Then I insist that you must speak for yourself, and >>>>>> furthermore that [autoconf] must not place this restriction. >>>>> WEll, I meant that rectilinear topologies like this: >>>>> Node1----Node2----Node3---....---Noden >>>>> Where intermediary nodes each has 2 interfaces are easy to >>>>> understand and deploy IP on them. "Rectilinear" is probably not >>>>> the right term, because I don't impose a restriction on the >>>>> physical disposition - they could be in a circle too, for example. >>>>> But I require that each of the intermediary nodes has two >>>>> interfaces. >>>> That's a really really bad idea I think. >>>>> This topoology is easy to understand and deploy IP on. >>>> Why not restrict to topologies of only two nodes? >>>> Or even just one node? >>>> Those topologies are even easier to understand. >>>>> And yes I speak for myself. And yes, I know you don't want to =20 >>>>> restrict to _any_ kind of particular topology, be that =20 >>>>> rectilinear, >>>>> circle or any other form or shape, and that there exist >>>>> imagination enough to come up with topologies which nobody else =20= >>>>> has >>>>> ever imagined before. IT's a good research topic. >>>> It's a good topic for standardization. And, to be perfectly frank, >>>> you cannot identify the topology of the Internet either. I can't >>>> imagine wanting to restrict the Internet to conform to only certain >>>> topologies. >>> >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf > From alexandru.petrescu@gmail.com Thu Oct 22 16:27: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 CBB3A3A692F for ; Thu, 22 Oct 2009 16:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.736 X-Spam-Level: X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[AWL=0.513, 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 O+1S48RETjuo for ; Thu, 22 Oct 2009 16:27:17 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 532203A67EF for ; Thu, 22 Oct 2009 16:27:15 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 3D11AD48049; Fri, 23 Oct 2009 01:27:21 +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 0D304D48037; Fri, 23 Oct 2009 01:27:18 +0200 (CEST) Message-ID: <4AE0EA54.1000004@gmail.com> Date: Fri, 23 Oct 2009 01:27:16 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <4AE088E3.6080304@earthlink.net> <4AE09967.9060809@gmail.com> <4AE0AFE2.20200@earthlink.net> <4AE0CA51.5070300@gmail.com> <4AE0D477.1070809@earthlink.net> <4AE0DED2.8000907@gmail.com> <4AE0E597.8040609@gmail.com> <8A4B2870-C12A-4ED8-9ECE-0923B9B8F4C5@thomasclausen.org> In-Reply-To: <8A4B2870-C12A-4ED8-9ECE-0923B9B8F4C5@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091022-0, 22/10/2009), Outbound message X-Antivirus-Status: Clean Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] summarizing various - nothing new 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, 22 Oct 2009 23:27:18 -0000 Thomas Heide Clausen a écrit : > > On Oct 23, 2009, at 1:07 AM, Alexandru Petrescu wrote: > >> Hi Thomas, >> >> Thomas Heide Clausen a écrit : >>> Dear Alex, >>> I think that the point Charlie is trying to make is, that the >>> constraints and restrictions that you propose do not correspond to >>> the reality of the MANETs that are in operation today.... >>> How do the MANETs that you build look, Alex? >> >> The one network that I have now running in the lab and which may tempt >> somebody to call a MANET has 3 Mobile Routers. That's it. It's very >> stable physically, it's very constrained and is all planned in advance >> - it has nothing of the unplanned "adhoc"iness of unconstrained >> MANETs. Moreover it relies very much on the use of IPv6 link-local >> addresses. >> >> Why? > > Just observing that this is a very very different from a typical MANET > in pretty much every possible way. Well ok, it's a good observation. Alex > > Thomas > > >> >> Alex >> >>> Thomas >>> On Oct 23, 2009, at 12:38 AM, Alexandru Petrescu wrote: >>>> Discussions on restrictions, >>>> >>>> I propose numerous constraints on the size and type of the topology >>>> such that the topic can be tackled. >>>> >>>> Charles proposes to not have any restriction of this kind. >>>> >>>> Charles finally uses a strong argument: there are no restrictions on >>>> the Internet topology either, so supposedly there should be no >>>> restrictions in the AUTOCONF topology either. >>>> >>>> Are we developing a new Internet here in AUTOCONF? >>>> >>>> Charles also expresses doubts: even if such restrictions are in >>>> place, the use of ND and DHCP is not promissing. >>>> >>>> Alex >>>> >>>> >>>> Charles E. Perkins a écrit : >>>>>> If that is not possible either... hard to see doing IP routing any >>>>>> further. >>>>> Well, we did it, and lots of other people did it. If you want to see >>>>> it, there are numerous papers. It's not hard to see. >>>>>> If I had to struggle 1 year now to get the link-locals accepted >>>>>> here imagine when I post a draft making exclusive use of them :-) >>>>> Post away. I hope you test it on more than three nodes. >>>>>> Look at Carlos draft saying LLs are a MUST, which is just a >>>>>> reiteration of existing things - immediate pushback :-( >>>>> The point is that we can't use existing things. >>>>>>> You are designing for (single-subnet ??) WiFi. >>>>>> YEs, it is exchanging RAs on a single subnet WiFi, which has no >>>>>> prefix on it other than the link-local addresses and prefix fe80. >>>>> And you don't want to allow other people to design more general >>>>> systems?? >>>>>> It is egress interfaces of Mobile Routers, ifaces put together in >>>>>> "ad-hoc" mode. The ingress ifaces are also wifi but different >>>>>> essids, different channels, no "ad-hoc" mode, etc. >>>>> Hmm... no "ad-hoc" mode.... hmmm.... a very poor fit for [manet] >>>>> routing protocols. >>>>>> The nodes "behind" the Mobile Routers use global IP addresses, yet >>>>>> their egress interfaces are exclusively link-locally addressed. >>>>> What if there aren't any nodes "behind" any other nodes? >>>>>>> I also think we have to allow for multi-hop transmissions beyond >>>>>>> the range of any one node in the network. Do you disagree? >>>>>> Depends what you mean by multi-hop. There are some star topologies >>>>>> which have very few IP hops in between (2, 3max) and which can >>>>>> work if the inner core is exclusively link-locally addressed. >>>>>> This is a goal which is reachable. >>>>> There are many good reachable goals -- goals which HAVE been >>>>> reached in previous work. Goals that go far beyond this terrible >>>>> restriction. Goals that deal with networks with _no_ "inner core". >>>>> Do you deny that these goals are worthwhile to reach with >>>>> standardized solutions? >>>>>> But once you start talking multi-hop like unlimited number of IP >>>>>> hops in between, with thousands of nodes, with arbitrarily varying >>>>>> topologies that even a simple human can't describe - this goal is >>>>>> not reachable. >>>>> It has been reached. Your statement is wrong. >>>>>>>> If I had 1000s of nodes then I would _subnet_ this with routers >>>>>>>> in the middle -- for sure! That means at least bridging, and >>>>>>>> most probably routing. That means several interfaces on a >>>>>>>> node. >>>>>>> I like routing. I think it's a great idea. I think it is wrong >>>>>>> to establish the uniqueness of link-layer addresses by routing. >>>>>> Well I don't propose to establish the uniqueness of link-layer >>>>>> addresses by routing. They're inherently unique because of the >>>>>> nature of the considered link layer - wifi. >>>>> That should be a separate document, maybe from a separate group, with >>>>> people who want a more restricted focus. And even with the >>>>> restricted focus I predict it will fail if you rely on ND and DHCP. >>>>>> I want the _core_ of my MR-to-MR communications to be exclusively >>>>>> link-locally addressed. IT is small in terms of number of >>>>>> intermediary hops. It is understandable. It does not use >>>>>> thousands of nodes on that core. >>>>> I don't want to mandate reliance on any such core. I thought we were >>>>> dealing with _ad-hoc_ networks. >>>>>> There are of course several subnets, and one of them is the "core" >>>>>> if I can name it so. >>>>>> There is no magic in what I propose. >>>>> What you propose is needlessly restrictive to impose on all working >>>>> group solutions. >>>>>>> Then we're back to figuring out why a node with a single radio >>>>>>> channel should have multiple network interfaces. >>>>>> I would go as far as putting two such nodes together such that I >>>>>> can get two interfaces on the union node and IP route between them >>>>>> naturally. >>>>> Not very economically viable. Mandating this is a prescription for >>>>> almost certain failure. >>>>>>> So why would the document recommend them? Why can't we just >>>>>>> leave them alone? >>>>>> Ok! LEave them alone. State in the document "we leave the LLs >>>>>> alone". >>>>>> Unfortunately now it unrecommends them. >>>>> To be precise, it points out where the dangers lie. >>>>>>> Do you mean to say that we can only understand rectilinear >>>>>>> networks? Then I insist that you must speak for yourself, and >>>>>>> furthermore that [autoconf] must not place this restriction. >>>>>> WEll, I meant that rectilinear topologies like this: >>>>>> Node1----Node2----Node3---....---Noden >>>>>> Where intermediary nodes each has 2 interfaces are easy to >>>>>> understand and deploy IP on them. "Rectilinear" is probably not >>>>>> the right term, because I don't impose a restriction on the >>>>>> physical disposition - they could be in a circle too, for example. >>>>>> But I require that each of the intermediary nodes has two >>>>>> interfaces. >>>>> That's a really really bad idea I think. >>>>>> This topoology is easy to understand and deploy IP on. >>>>> Why not restrict to topologies of only two nodes? >>>>> Or even just one node? >>>>> Those topologies are even easier to understand. >>>>>> And yes I speak for myself. And yes, I know you don't want to >>>>>> restrict to _any_ kind of particular topology, be that rectilinear, >>>>>> circle or any other form or shape, and that there exist >>>>>> imagination enough to come up with topologies which nobody else has >>>>>> ever imagined before. IT's a good research topic. >>>>> It's a good topic for standardization. And, to be perfectly frank, >>>>> you cannot identify the topology of the Internet either. I can't >>>>> imagine wanting to restrict the Internet to conform to only certain >>>>> topologies. >>>> >>>> _______________________________________________ >>>> Autoconf mailing list >>>> Autoconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/autoconf >> > > From alexandru.petrescu@gmail.com Thu Oct 22 16:32: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 2F2773A6825 for ; Thu, 22 Oct 2009 16:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.759 X-Spam-Level: X-Spam-Status: No, score=-1.759 tagged_above=-999 required=5 tests=[AWL=0.490, 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 0ZmIcMPrY66e for ; Thu, 22 Oct 2009 16:32:25 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id A37713A67C0 for ; Thu, 22 Oct 2009 16:32:23 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 8F84CD48028; Fri, 23 Oct 2009 01:32:28 +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 64680D48061; Fri, 23 Oct 2009 01:32:26 +0200 (CEST) Message-ID: <4AE0EB87.2000103@gmail.com> Date: Fri, 23 Oct 2009 01:32:23 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <4AE088E3.6080304@earthlink.net> <4AE09967.9060809@gmail.com> <4AE0AFE2.20200@earthlink.net> <4AE0CA51.5070300@gmail.com> <4AE0D477.1070809@earthlink.net> <4AE0DED2.8000907@gmail.com> <4AE0E597.8040609@gmail.com> <1D83564F-22D6-4FCF-8F19-756AF5529B85@thomasclausen.org> In-Reply-To: <1D83564F-22D6-4FCF-8F19-756AF5529B85@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091022-0, 22/10/2009), Outbound message X-Antivirus-Status: Clean Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] summarizing various - nothing new 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, 22 Oct 2009 23:32:26 -0000 Thomas Heide Clausen a écrit : > > On Oct 23, 2009, at 1:07 AM, Alexandru Petrescu wrote: > >> Hi Thomas, >> >> Thomas Heide Clausen a écrit : >>> Dear Alex, >>> I think that the point Charlie is trying to make is, that the >>> constraints and restrictions that you propose do not correspond to >>> the reality of the MANETs that are in operation today.... >>> How do the MANETs that you build look, Alex? >> >> The one network that I have now running in the lab and which may tempt >> somebody to call a MANET has 3 Mobile Routers. That's it. It's very >> stable physically, it's very constrained and is all planned in advance >> - it has nothing of the unplanned "adhoc"iness of unconstrained >> MANETs. Moreover it relies very much on the use of IPv6 link-local >> addresses. >> >> Why? >> > > It just hit me.... > > MANET = Mobile Ad hoc NETwork > > Your lab-network is stable (so not Mobile) and planned in advance (so > not Ad hoc). > > I'd suggest not extrapolating MANET behavior based on your observations > from this (non-MANET) lab-network of yours. Ok, suggestion taken. You'll be surprised but I feel more comfortable calling it a "non-MANET lab-network of mine" :-) Alex > > Thomas > > > >> Alex >> >>> Thomas >>> On Oct 23, 2009, at 12:38 AM, Alexandru Petrescu wrote: >>>> Discussions on restrictions, >>>> >>>> I propose numerous constraints on the size and type of the topology >>>> such that the topic can be tackled. >>>> >>>> Charles proposes to not have any restriction of this kind. >>>> >>>> Charles finally uses a strong argument: there are no restrictions on >>>> the Internet topology either, so supposedly there should be no >>>> restrictions in the AUTOCONF topology either. >>>> >>>> Are we developing a new Internet here in AUTOCONF? >>>> >>>> Charles also expresses doubts: even if such restrictions are in >>>> place, the use of ND and DHCP is not promissing. >>>> >>>> Alex >>>> >>>> >>>> Charles E. Perkins a écrit : >>>>>> If that is not possible either... hard to see doing IP routing any >>>>>> further. >>>>> Well, we did it, and lots of other people did it. If you want to see >>>>> it, there are numerous papers. It's not hard to see. >>>>>> If I had to struggle 1 year now to get the link-locals accepted >>>>>> here imagine when I post a draft making exclusive use of them :-) >>>>> Post away. I hope you test it on more than three nodes. >>>>>> Look at Carlos draft saying LLs are a MUST, which is just a >>>>>> reiteration of existing things - immediate pushback :-( >>>>> The point is that we can't use existing things. >>>>>>> You are designing for (single-subnet ??) WiFi. >>>>>> YEs, it is exchanging RAs on a single subnet WiFi, which has no >>>>>> prefix on it other than the link-local addresses and prefix fe80. >>>>> And you don't want to allow other people to design more general >>>>> systems?? >>>>>> It is egress interfaces of Mobile Routers, ifaces put together in >>>>>> "ad-hoc" mode. The ingress ifaces are also wifi but different >>>>>> essids, different channels, no "ad-hoc" mode, etc. >>>>> Hmm... no "ad-hoc" mode.... hmmm.... a very poor fit for [manet] >>>>> routing protocols. >>>>>> The nodes "behind" the Mobile Routers use global IP addresses, yet >>>>>> their egress interfaces are exclusively link-locally addressed. >>>>> What if there aren't any nodes "behind" any other nodes? >>>>>>> I also think we have to allow for multi-hop transmissions beyond >>>>>>> the range of any one node in the network. Do you disagree? >>>>>> Depends what you mean by multi-hop. There are some star topologies >>>>>> which have very few IP hops in between (2, 3max) and which can >>>>>> work if the inner core is exclusively link-locally addressed. >>>>>> This is a goal which is reachable. >>>>> There are many good reachable goals -- goals which HAVE been >>>>> reached in previous work. Goals that go far beyond this terrible >>>>> restriction. Goals that deal with networks with _no_ "inner core". >>>>> Do you deny that these goals are worthwhile to reach with >>>>> standardized solutions? >>>>>> But once you start talking multi-hop like unlimited number of IP >>>>>> hops in between, with thousands of nodes, with arbitrarily varying >>>>>> topologies that even a simple human can't describe - this goal is >>>>>> not reachable. >>>>> It has been reached. Your statement is wrong. >>>>>>>> If I had 1000s of nodes then I would _subnet_ this with routers >>>>>>>> in the middle -- for sure! That means at least bridging, and >>>>>>>> most probably routing. That means several interfaces on a >>>>>>>> node. >>>>>>> I like routing. I think it's a great idea. I think it is wrong >>>>>>> to establish the uniqueness of link-layer addresses by routing. >>>>>> Well I don't propose to establish the uniqueness of link-layer >>>>>> addresses by routing. They're inherently unique because of the >>>>>> nature of the considered link layer - wifi. >>>>> That should be a separate document, maybe from a separate group, with >>>>> people who want a more restricted focus. And even with the >>>>> restricted focus I predict it will fail if you rely on ND and DHCP. >>>>>> I want the _core_ of my MR-to-MR communications to be exclusively >>>>>> link-locally addressed. IT is small in terms of number of >>>>>> intermediary hops. It is understandable. It does not use >>>>>> thousands of nodes on that core. >>>>> I don't want to mandate reliance on any such core. I thought we were >>>>> dealing with _ad-hoc_ networks. >>>>>> There are of course several subnets, and one of them is the "core" >>>>>> if I can name it so. >>>>>> There is no magic in what I propose. >>>>> What you propose is needlessly restrictive to impose on all working >>>>> group solutions. >>>>>>> Then we're back to figuring out why a node with a single radio >>>>>>> channel should have multiple network interfaces. >>>>>> I would go as far as putting two such nodes together such that I >>>>>> can get two interfaces on the union node and IP route between them >>>>>> naturally. >>>>> Not very economically viable. Mandating this is a prescription for >>>>> almost certain failure. >>>>>>> So why would the document recommend them? Why can't we just >>>>>>> leave them alone? >>>>>> Ok! LEave them alone. State in the document "we leave the LLs >>>>>> alone". >>>>>> Unfortunately now it unrecommends them. >>>>> To be precise, it points out where the dangers lie. >>>>>>> Do you mean to say that we can only understand rectilinear >>>>>>> networks? Then I insist that you must speak for yourself, and >>>>>>> furthermore that [autoconf] must not place this restriction. >>>>>> WEll, I meant that rectilinear topologies like this: >>>>>> Node1----Node2----Node3---....---Noden >>>>>> Where intermediary nodes each has 2 interfaces are easy to >>>>>> understand and deploy IP on them. "Rectilinear" is probably not >>>>>> the right term, because I don't impose a restriction on the >>>>>> physical disposition - they could be in a circle too, for example. >>>>>> But I require that each of the intermediary nodes has two >>>>>> interfaces. >>>>> That's a really really bad idea I think. >>>>>> This topoology is easy to understand and deploy IP on. >>>>> Why not restrict to topologies of only two nodes? >>>>> Or even just one node? >>>>> Those topologies are even easier to understand. >>>>>> And yes I speak for myself. And yes, I know you don't want to >>>>>> restrict to _any_ kind of particular topology, be that rectilinear, >>>>>> circle or any other form or shape, and that there exist >>>>>> imagination enough to come up with topologies which nobody else has >>>>>> ever imagined before. IT's a good research topic. >>>>> It's a good topic for standardization. And, to be perfectly frank, >>>>> you cannot identify the topology of the Internet either. I can't >>>>> imagine wanting to restrict the Internet to conform to only certain >>>>> topologies. >>>> >>>> _______________________________________________ >>>> Autoconf mailing list >>>> Autoconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/autoconf >> > > From charles.perkins@earthlink.net Thu Oct 22 23:47: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 448AA3A68D8 for ; Thu, 22 Oct 2009 23:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 yQrk5ihHNC3C for ; Thu, 22 Oct 2009 23:47:41 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 15B573A68C1 for ; Thu, 22 Oct 2009 23:47:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=FD77QE3HrEeAuw3fsftlFU+ID3g84eHde+qmbugKvmiAIqcQMwDEsCLsO43FGtdB; 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-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1N1DwF-0005LU-Gl; Fri, 23 Oct 2009 02:47:51 -0400 Message-ID: <4AE15196.8080804@earthlink.net> Date: Thu, 22 Oct 2009 23:47: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> <4ABA5E20.8090608@gmail.com> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <4AE0DB2A.7090902@gmail.com> In-Reply-To: <4AE0DB2A.7090902@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5230ce36241b203bc980983e7d37ee7c46350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] [warning -- weeks old mail under discussion] Re: 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: Fri, 23 Oct 2009 06:47:42 -0000 Hello Alex, This is probably going to be my last rejoinder for a while. Alexandru Petrescu wrote: > > Average transition time (ATT) through some coverage sounds more > tempting than simply "speed". > > So a vehicle would have an ATT of 3.6seconds (50kmph, 50m wifi). > > 3.6s is enough to perform DHCP and many other things. This is true, once the functional entities (e.g., DHCP server) have been identified and established. > >> >> In order to counter this statement (or, more accurately, show why it >> is not relevant), I would have to go through the exercise -- but you >> had relieved me of that task. > > I know why people say DHCP is slow. I've measured it. There are > quirks with some implementations of the timers. It's mostly in the > discovery phase. It's the same fundamental reasons why some people > complain about slow WiFi link-layer handovers, and slow Mobile IP, and > slow NUD, slow ND - which I've also measured. Those slownesses are not all the same, and some have different causes. > > Basically one can't do discovery otherwise than emitting and then > _waiting_ a pre-defined amount of time. It's the basics of the basics. But that observation does not cause the problem to go away. > > What one can do is to shorten the time one waits, at the risk of not > hearing some things and maybe hitting into someone, or missing the > presence of some DHCP Server. This is a very abstract statement, not so easily realizable in practice. And maybe even more difficult to do it for all the protocols you mentioned at the same time. > > > AUTOCONF can't propose a discovery mechanism better than the discovery > phases of DHCP, ND, and FastBSS. People would have already done it > well before. In fact, we did do it. Otherwise I wouldn't have been so interested in the working group. > > > The Client performs a discovery phase, sending first to a predefined > multicast address and then waiting. > >> And when the nodes >> are moving, you don't know. > > Well - you do know for some time. Yes, but that amount of time is highly variable and not so predictable. > >> And you can't quote NUD and NA as theorems because of the reasons I >> already outlined in previous >> messages. And even if you could, before long you'd have to get some >> new relay because you need the relay to be local. And more than >> likely your DHCP server will be occasionally partitioned into >> temporary isolation. But then it's back! But the relay is gone! >> And then there's something else to go wrong. But, are _all_ nodes >> relays? But, which server has the state? Or is there just one >> server? But that won't ever work! >> >> Every time I think about it, I just know it's wrong. I do not have >> any belief whatsoever in this theorem. And, with three nodes, you'll >> never see the problem. Never! > > Well I look at it as a distributed election problem. Dynamically > elect the Servers and the Relays, among them. Of course, afterwards, > the elected DHCP Server needs to learn the addresses of the relays and > to have routes to them. These issues can be solved by using > link-local addresses. Once you have unique link-local addresses, yes you can make such an election using them. Or, you could make an election without requiring link-local addresses. Or you could supply a more efficient function to replace the DHCP server without requiring link-local addresses and reducing the signaling overhead substantially. So when do we start the design phase and end the 24x7 process of haggling over link-locals? Oh, wait, now we have to first resubmit the simple draft for approval. I hope that doesn't take too much longer. > > This entire mechanism will work during some lapse of time during which > the devices are within relatively stable distance. Yes, sort-of. > > When links start breaking, nodes disappear, other nodes appear - > re-execute the entire election process. And how do you know that a node disappeared two or seven hops away? And what if three nodes disappear in the same time granule? Do you get three simultaneous network floods? > > Now, don't tell me that things move so fast that there is not enough > time to deal with re-election: there will always be things which move > too fast for whoever and whatever mechanism to break, including > whatever AUTOCONF designs. Why would I say that? I'd just say that you are imposing an election operation that will further shrink the realm of applicability for solutions that might be developed. I fully expect that by the time we restrict to the realm of applicability appropriate for DHCP, NA, NUD, and unique link-locals, we'll have a few nodes in the lab running 802.11. Regards, Charlie P. > From teco@inf-net.nl Fri Oct 23 03:44: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 BE44B3A67DB for ; Fri, 23 Oct 2009 03:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, J_CHICKENPOX_52=0.6] 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 ANlenExIQrEb for ; Fri, 23 Oct 2009 03:44:56 -0700 (PDT) Received: from CPSMTPM-EML104.kpnxchange.com (cpsmtpm-eml104.kpnxchange.com [195.121.3.8]) by core3.amsl.com (Postfix) with ESMTP id 318233A62C1 for ; Fri, 23 Oct 2009 03:44:55 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML104.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Fri, 23 Oct 2009 12:45:04 +0200 From: "Teco Boot" To: "'Thomas Heide Clausen'" , "'Ryuji Wakikawa'" References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> In-Reply-To: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> Date: Fri, 23 Oct 2009 12:45:05 +0200 Message-ID: <001601ca53cd$e202b5f0$a60821d0$@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: AcpSqSglR2+APHK2RymUpBB7mlbykwBFxjMQ Content-Language: nl X-OriginalArrivalTime: 23 Oct 2009 10:45:04.0948 (UTC) FILETIME=[E175DF40:01CA53CD] Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model 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: Fri, 23 Oct 2009 10:44:57 -0000 Hi Ryuji, Thomas, > o if you think that the WG should proceed with draft-ietf-autoconf-adhoc-addr-model > as a baseline, say so! I am neutral on this. I think my comments on earlier versions are not well incorporated and the document misses essential elements for a practical addressing scheme for MANETs, such as global addresses and usage of ULAs. I think the recently published "bernardos alternative" is more complete and also better specifies LL usage. I prefer not extending useless discussions on LLs, but careful wording for it. > o if you think there're cardinal (but fixable) issues missing or wrong with > draft-ietf-autoconf-adhoc-addr-model, then let the WG know what these > issues are, and propose a solution before the deadline. The Editors > will certainly do their best to address the issues. I posted this already. http://www.ietf.org/mail-archive/web/autoconf/current/msg01828.html http://www.ietf.org/mail-archive/web/autoconf/current/msg01830.html I do not understand why text is not corrected yet. > o if you think that draft-ietf-autoconf-adhoc-addr-model is beyond hope, > let the WG know explicitly how you suggest that we progress at this point -- > considering the current timeline!! After 3 months, we have a new version with only small updates (enhancements or wrong text, make your choice). I think this progress is extremely disappointing. Or "beyond hope". A question on procedure: can we decide to swap the content of draft-ietf-autoconf-adhoc-addr-model, e.g. a new version with content of draft-bernardos-autoconf-addressing-model or a merger of those? Anyway, we have more progress than listed on the Autoconf page: we have completed our fourth goal: there is a initial draft on addressing model in ad hoc networks. And we might not be that far away from our last milestone. Regards, Teco From alexandru.petrescu@gmail.com Fri Oct 23 03:51: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 23A273A6828 for ; Fri, 23 Oct 2009 03:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.809 X-Spam-Level: X-Spam-Status: No, score=-1.809 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_52=0.6] 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 dXnjli6QMFWH for ; Fri, 23 Oct 2009 03:51:10 -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 18C223A67DF for ; Fri, 23 Oct 2009 03:51:09 -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 n9NApI8W027797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Oct 2009 12:51:18 +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 n9NApIiM001421; Fri, 23 Oct 2009 12:51:18 +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 n9NApHS8004422; Fri, 23 Oct 2009 12:51:18 +0200 Message-ID: <4AE18AA5.7010609@gmail.com> Date: Fri, 23 Oct 2009 12:51:17 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Teco Boot References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <001601ca53cd$e202b5f0$a60821d0$@nl> In-Reply-To: <001601ca53cd$e202b5f0$a60821d0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model 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: Fri, 23 Oct 2009 10:51:11 -0000 Teco Boot a écrit : > Hi Ryuji, Thomas, > >> o if you think that the WG should proceed with > draft-ietf-autoconf-adhoc-addr-model >> as a baseline, say so! > > I am neutral on this. > > I think my comments on earlier versions are not well incorporated and the > document misses essential elements for a practical addressing scheme for > MANETs, such as global addresses and usage of ULAs. I think the recently > published "bernardos alternative" is more complete and also better specifies > LL usage. > > I prefer not extending useless discussions on LLs, but careful wording for > it. > > >> o if you think there're cardinal (but fixable) issues missing or wrong > with >> draft-ietf-autoconf-adhoc-addr-model, then let the WG know what > these >> issues are, and propose a solution before the deadline. The Editors >> will certainly do their best to address the issues. > > I posted this already. > http://www.ietf.org/mail-archive/web/autoconf/current/msg01828.html > http://www.ietf.org/mail-archive/web/autoconf/current/msg01830.html > I do not understand why text is not corrected yet. > > >> o if you think that draft-ietf-autoconf-adhoc-addr-model is beyond > hope, >> let the WG know explicitly how you suggest that we progress at this > point -- >> considering the current timeline!! > > After 3 months, we have a new version with only small updates (enhancements > or > wrong text, make your choice). I think this progress is extremely > disappointing. > Or "beyond hope". > > > A question on procedure: can we decide to swap the content of > draft-ietf-autoconf-adhoc-addr-model, e.g. a new version with content of > draft-bernardos-autoconf-addressing-model or a merger of those? This is something I tend to agree to. I am suggesting the same thing: copy relevant things from draft-bernardos and paste on the WG item document. Of course, it depends how this is done, but it is a good direction IMHO. Alex > > > Anyway, we have more progress than listed on the Autoconf page: we have > completed our fourth goal: there is a initial draft on addressing model > in ad hoc networks. And we might not be that far away from our last > milestone. > > > Regards, Teco > > > > > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From dream.hjlim@gmail.com Fri Oct 23 06:56: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 9B9A73A683E for ; Fri, 23 Oct 2009 06:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6] 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 khYqFjvJW3pz for ; Fri, 23 Oct 2009 06:56:48 -0700 (PDT) Received: from mail-px0-f173.google.com (mail-px0-f173.google.com [209.85.216.173]) by core3.amsl.com (Postfix) with ESMTP id ACBDB3A672E for ; Fri, 23 Oct 2009 06:56:48 -0700 (PDT) Received: by pxi3 with SMTP id 3so407630pxi.29 for ; Fri, 23 Oct 2009 06:56:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ciO2kqBG4HGzbu6GTPIrSSO57TmP6A8niD6HxRwHtgQ=; b=q+DL1yQZ6hbXJhkBGhjqUL44p/I0OkPS8OfpKWlGBRJASzMLNxy1seoaJpyl08L3iH ThNdSz4l+kEtOIxCFrgH5LrS64uDvQK5xgHvGgNT6N20Ptl9NhVZulqbpLpKIPLrBZzE BK0UEcdNYV2oUnt4yjk9re5/KsORqK/14hvmU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WWo4PKQ+Opbz0vcFYKGsBavl/TCSn6xDu99ld3ZTGS+XINk1kGl4F70n68ytb/BE/z aoZ/8ahc58q4pz6f2dJitkA1HRwSy0ucbXuPFAYxDTMIu7qrwZ8/12pFOCtccWA9xn76 +QjXg9OcHZxLlrNMlRSXXBHBYWSmRA4dG9E2E= MIME-Version: 1.0 Received: by 10.114.162.38 with SMTP id k38mr3627988wae.138.1256306215291; Fri, 23 Oct 2009 06:56:55 -0700 (PDT) In-Reply-To: <4AE18AA5.7010609@gmail.com> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <001601ca53cd$e202b5f0$a60821d0$@nl> <4AE18AA5.7010609@gmail.com> Date: Fri, 23 Oct 2009 22:56:55 +0900 Message-ID: <7e8d02d40910230656t5fdd1ab4k3eaee44a1929a1c8@mail.gmail.com> From: HyungJin Lim To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=00504502f60db10ad204769a950c Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model 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: Fri, 23 Oct 2009 13:56:49 -0000 --00504502f60db10ad204769a950c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, This is Hyung-Jin Lim. I am still reading AUTOCONF mailing lists. I also agree to Teco's suggestion totally. Thanks. 2009/10/23 Alexandru Petrescu > Teco Boot a =E9crit : > > Hi Ryuji, Thomas, >> >> o if you think that the WG should proceed with >>> >> draft-ietf-autoconf-adhoc-addr-model >> >>> as a baseline, say so! >>> >> >> I am neutral on this. >> >> I think my comments on earlier versions are not well incorporated and th= e >> document misses essential elements for a practical addressing scheme for >> MANETs, such as global addresses and usage of ULAs. I think the recently >> published "bernardos alternative" is more complete and also better speci= fies >> LL usage. >> I prefer not extending useless discussions on LLs, but careful wording f= or >> it. >> >> >> o if you think there're cardinal (but fixable) issues missing or >>> wrong >>> >> with >> >>> draft-ietf-autoconf-adhoc-addr-model, then let the WG know what >>> >> these >> >>> issues are, and propose a solution before the deadline. The >>> Editors will certainly do their best to address the issues. >>> >> >> I posted this already. >> http://www.ietf.org/mail-archive/web/autoconf/current/msg01828.html >> http://www.ietf.org/mail-archive/web/autoconf/current/msg01830.html >> I do not understand why text is not corrected yet. >> >> >> o if you think that draft-ietf-autoconf-adhoc-addr-model is beyond >>> >> hope, >> >>> let the WG know explicitly how you suggest that we progress at >>> this >>> >> point -- >> >>> considering the current timeline!! >>> >> >> After 3 months, we have a new version with only small updates >> (enhancements >> or wrong text, make your choice). I think this progress is extremely >> disappointing. Or "beyond hope". >> >> >> A question on procedure: can we decide to swap the content of >> draft-ietf-autoconf-adhoc-addr-model, e.g. a new version with content of >> draft-bernardos-autoconf-addressing-model or a merger of those? >> > > This is something I tend to agree to. I am suggesting the same thing: co= py > relevant things from draft-bernardos and paste on the WG item document. > > Of course, it depends how this is done, but it is a good direction IMHO. > > Alex > > > >> >> Anyway, we have more progress than listed on the Autoconf page: we have >> completed our fourth goal: there is a initial draft on addressing model = in >> ad hoc networks. And we might not be that far away from our last >> milestone. >> >> Regards, Teco >> >> >> >> >> >> >> _______________________________________________ >> 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 > --00504502f60db10ad204769a950c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=A0
This is Hyung-Jin Lim.
I am still reading AUTOCONF mailing lists.
=A0
I also agree=A0to Teco's suggestion totally.
Thanks.
2009/10/23 Alexandru Petrescu = <alexandru.petrescu@gmai= l.com>
Teco Boot a =E9crit :=20

Hi Ryuji, Thomas,

o =A0 =A0 =A0 if you think that = the WG should proceed with
draft-ietf-autoconf-adhoc-addr-m= odel
=A0 =A0 =A0 =A0as a baseline, sa= y so!

I am neutral on this.

I think my comments= on earlier versions are not well incorporated and the document misses esse= ntial elements for a practical addressing scheme for MANETs, such as global= addresses and usage of ULAs. I think the recently published "bernardo= s alternative" is more complete and also better specifies
LL usage.
I prefer not extending useless discussions on LLs, but carefu= l wording for
it.


o =A0 =A0 =A0 if you think there= 're cardinal (but fixable) issues missing or wrong
with=
=A0 =A0 =A0 =A0draft-ietf-autoco= nf-adhoc-addr-model, then let the WG know what
these
=A0 =A0 =A0 =A0issues are, and p= ropose a solution before the deadline. The Editors =A0 =A0 =A0 =A0will cert= ainly do their best to address the issues.

I posted this already. http://www.i= etf.org/mail-archive/web/autoconf/current/msg01828.html
http://www.ietf.org/mail-archive/web/autoconf/current/msg01830.= html
I do not understand why text is not corrected yet.


o =A0 =A0 =A0 if you think that = draft-ietf-autoconf-adhoc-addr-model is beyond
hope,
=A0 =A0 =A0 =A0let the WG know e= xplicitly how you suggest that we progress =A0at this
point= --
=A0 =A0 =A0 =A0considering the c= urrent timeline!!

After 3 months, we have a new version= with only small updates (enhancements
or wrong text, make your choice). I think this progress is extremely
dis= appointing. Or "beyond hope".


A question on procedure:= can we decide to swap the content of draft-ietf-autoconf-adhoc-addr-model,= e.g. a new version with content of draft-bernardos-autoconf-addressing-mod= el or a merger of those?

This is something I tend to agree to. =A0I am = suggesting the same thing: copy relevant things from draft-bernardos and pa= ste on the WG item document.

Of course, it depends how this is done,= but it is a good direction IMHO.

Alex=20




Anyway, we have more pro= gress than listed on the Autoconf page: we have
completed our fourth goa= l: there is a initial draft on addressing model in ad hoc networks. And we = might not be that far away from our last
milestone.

Regards, Teco






_______________= ________________________________
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/auto= conf

--00504502f60db10ad204769a950c-- From ietf@thomasclausen.org Fri Oct 23 07:10: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 84E123A67E1 for ; Fri, 23 Oct 2009 07:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 q0N6B9hixndH for ; Fri, 23 Oct 2009 07:10:07 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id C54933A67D9 for ; Fri, 23 Oct 2009 07:10:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id BEE1D3231776; Fri, 23 Oct 2009 07:10:18 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id DA7B83231747; Fri, 23 Oct 2009 07:10:17 -0700 (PDT) Message-Id: <1048A1CE-CCAB-4EFD-9DEE-3D8BE5254A85@thomasclausen.org> From: Thomas Heide Clausen To: Teco Boot In-Reply-To: <001601ca53cd$e202b5f0$a60821d0$@nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 23 Oct 2009 16:10:15 +0200 References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <001601ca53cd$e202b5f0$a60821d0$@nl> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model 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: Fri, 23 Oct 2009 14:10:08 -0000 > After 3 months, we have a new version with only small updates > (enhancements > or > wrong text, make your choice). I think this progress is extremely > disappointing. > Or "beyond hope". > > > A question on procedure: can we decide to swap the content of > draft-ietf-autoconf-adhoc-addr-model, e.g. a new version with > content of > draft-bernardos-autoconf-addressing-model or a merger of those? Constructive proposals for improvement to documents should *always* be very welcome, especially if they're concrete such as proposed text. I can only encourage that you [the plural version of "you"] propose such text on the list, and that we all discuss it -- then decide how to progress with it? I know that you [ Teco ] have made proposals in the past. I must admit that I do not recall to which extend exactly these were reflected in the text. Would you be able to restate your proposals as "text to insert into the I-D at a specific place, possibly replacing something existing", in a separate thread on the list? We can then all discuss them and, if the outcome is that we agree on inclusion, together whip the editors to incorporate them? Thanks, Thomas From ryuji.wakikawa@gmail.com Sat Oct 24 02:23: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 B7B203A69A6 for ; Sat, 24 Oct 2009 02:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_52=0.6] 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 FhPPJRTgtWJI for ; Sat, 24 Oct 2009 02:23:24 -0700 (PDT) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id BBE413A699C for ; Sat, 24 Oct 2009 02:23:24 -0700 (PDT) Received: by pwi4 with SMTP id 4so2584745pwi.29 for ; Sat, 24 Oct 2009 02:23:33 -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=pHLLdR+tJKlX1qN7q39zEl+FncLxznXd6W/xH/Yt6Pg=; b=wWxUwMDcb8m0A74gLCH12oJ8xUGId/gxrhdD5YK7+EvrcfN1/54rfcyV5vrwH9CeAT c5UDewlvZ6jJcsKclU6BukjYt6epiRBM70ktkTt6msBntIBlvD2wLDCejrR4fHXNycaH Gaqblbf7ZMaEz7fKhfE6NIrHsiRSeQefxz94I= 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=lWb4/KaVhhkeFFha6F20UnJsR8lv7n06D23DaR4ueU6Zb1ld7nbCg3vcMo8NQ38hmN ko30Z4WNu87ppFa3nUtjp/EimcnR+f+O1YXGU+RhCa0MZzOzZa/6WnmvVNJ6EbIrsc6J 38S4F2Yh1fZH01k+gMj/W0wJVZJFd+8PQ7UhM= Received: by 10.114.252.2 with SMTP id z2mr17519893wah.156.1256376213829; Sat, 24 Oct 2009 02:23:33 -0700 (PDT) Received: from ?10.0.1.2? (c-98-248-44-75.hsd1.ca.comcast.net [98.248.44.75]) by mx.google.com with ESMTPS id 22sm776930pzk.14.2009.10.24.02.23.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 24 Oct 2009 02:23:32 -0700 (PDT) From: Ryuji Wakikawa To: cjbc@it.uc3m.es In-Reply-To: <1256227396.6218.19.camel@acorde.it.uc3m.es> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <1256227396.6218.19.camel@acorde.it.uc3m.es> Message-Id: <543D8662-79A1-4E7D-AD68-56508AB37CDF@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 24 Oct 2009 02:23:29 -0700 X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model 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: Sat, 24 Oct 2009 09:23:25 -0000 Hi Carlos, Thanks for the draft and your suggestion. we haven't seen your draft =20 before publishing draft-ietf doc. Anyway, you can discuss your draft on the list, but let us postpone =20 the decision. I want to complete this consensus call first. We still have dates to Hiroshima and want to see more opinions from WG. I saw Alex, Teco supporting your document. My concern is that we finished consensus call for LL address treatment =20= and agreed the texts. We should not step back and bring new discussion on this thread. regards, ryuji On 2009/10/22, at 9:03, Carlos Jes=C3=BAs Bernardos Cano wrote: > Hi Thomas, > > My individual and personal opinion -- also biased, since I'm > co-authoring draft-bernardos-autoconf-addressing-model-00 (btw, we =20 > plan > to submit a -01 before the cutoff deadline) -- is that since we now > have one alternative candidate document for the work item which > [autoconf] is chartered to accomplish (when we were working on it we > didn't know there was already a WG document on this charter item), we > may consider as WG our document as input as well. Then, we may have at > least some discussion (on the ML -- please wait until we release -01 =20= > if > you don't mind) and in Hiroshima (if we can present our draft) and =20 > then > make a similar call as you did below, potentially considering somehow > also the input that draft-bernardos-autoconf-addressing-model may =20 > bring > (if the WG considers there is any). > > I know that we are late, we have been unfortunately always late = in =20 > this > WG (I participated in the BOF in 2005 and kept on contributing somehow > since then, and still we haven't achieved any milestone, more than 4 > years later). But still, I don't see this as a valid reason for taking > decisions in a hurry (such as adopting WG documents without asking the > WG), and I honestly think it would be good for the WG to have the =20 > chance > to have some discussion on our draft and then come up with the best > possible input that the WG can produce. > > Just my -- unavoidable (although I fought not to be) biased -- =20= > opinion > on this. > > Thanks, > > Carlos > > On Thu, 2009-10-22 at 01:49 +0200, Thomas Heide Clausen wrote: >> All, >> >> >> It appeared to the chairs that the comments raised at the Stockholm >> IETF, as well as on the list subsequently, concerning the document: >> >> >> http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model >> >> >> had been addressed fully by the editors, and to the WGs =20 >> satisfaction - >> at least, there were no issue raised to the latter/latest version >> hereof. The chairs therefore found it a good idea to move the =20 >> document >> forward as a WG document, and progress this document as such. We >> therefore approved for publication: >> >> >> http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model >> >> >> We (the chairs) still believe that this is the proper approach in >> order to make progress for the WG. >> >> >> Do note that the WG is 7 months past the milestone for initial >> document submission, and 1 month past the milestone for having >> progressed the document to the IESG and/or closed up shop! And, =20 >> there >> has been no discussions (in meetings or on this list) on alternative >> candidate documents for the work item which [autoconf] is chartered =20= >> to >> accomplish. >> >> >> To put it bluntly, this WG is far far behind schedule and this >> document seemed, and still seems, by virtue of having been widely >> discussed and agreed upon, as the best shot at making progress for >> this WG. >> >> >> That said, we (and, this we is also the chairs) will take this >> opportunity to ask the WGs opinion on how to progress. If you have =20= >> any >> opinion, please let it be known to the WG (via this mailing list) >> before 29/10/09 (i.e. Thursday next week) at noon CET. Please be >> specific and constructive, i.e., pick one of: >> >> >> o if you think that the WG should proceed >> with draft-ietf-autoconf-adhoc-addr-model >> as a baseline, say so! >> >> >> o if you think there're cardinal (but fixable) issues missing or =20 >> wrong >> with >> draft-ietf-autoconf-adhoc-addr-model, then let the WG know what these >> issues are, and propose a solution before the deadline. The Editors >> will certainly do their best to address the issues. >> >> >> o if you think that draft-ietf-autoconf-adhoc-addr-model is beyond >> hope, >> let the WG know explicitly how you suggest that we progress at this >> point -- >> considering the current timeline!! >> >> >> Cheers, >> >> >> Ryuji & Thomas >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > --=20 > Carlos Jes=C3=BAs Bernardos Cano http://www.netcoms.net > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From ryuji.wakikawa@gmail.com Sat Oct 24 02:23:27 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 7592428C0CE for ; Sat, 24 Oct 2009 02:23:27 -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 5EshBDvj7+rD for ; Sat, 24 Oct 2009 02:23:26 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id D4B3A3A699C for ; Sat, 24 Oct 2009 02:23:25 -0700 (PDT) Received: by ewy4 with SMTP id 4so2290886ewy.37 for ; Sat, 24 Oct 2009 02:23:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gHjMVEFTnrOVBKknWDHQi/X4qKq4MICx7JW0ZxW0Pi8=; b=Hz75kgSHAj+XZWjP0pmX8urZQW+7by/UmozDcpsV720dpGHkSwV5Kkc4ewyrsV5OME c/MepHMeCu+YNMKxHMruhV02IC00yB/1r2MbUOSR8HBKNP6XdAuTvCNsCFwIk3v2Gk+T RbG7NtIeVEOSCAPgJ4SIuGxK19S/Cg9T3WXQQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=WvHrGZMdQxb/RZZmBOG6Zofc0CyL1x39QFM88jQ5k80J2PjaVU5J6H2QH+/shmqcPE 76odaS2IWZPqImWCiIvqWfB0quSb2djnr0q8wDhC0c7Z7ac7Kw7nm8J57D2YfAVW+npE bX7R0xm2l3zc1sKTmTeMsjXi/wJDMjJZlcZ3c= MIME-Version: 1.0 Received: by 10.216.87.131 with SMTP id y3mr1289379wee.9.1256376213845; Sat, 24 Oct 2009 02:23:33 -0700 (PDT) In-Reply-To: <4AE0521C.4090005@gmail.com> References: <4ADF863E.8040408@gmail.com> <6B0ACB39-C603-48FA-89FC-8A887BD1BC7D@gmail.com> <4AE0521C.4090005@gmail.com> Date: Sat, 24 Oct 2009 02:23:33 -0700 Message-ID: <84840efa0910240223r5c9ac9ccrc5553102449da26e@mail.gmail.com> From: Ryuji Wakikawa To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Procedure X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ryuji@sfc.wide.ad.jp List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2009 09:23:27 -0000 Hi Alex, 2009/10/22 Alexandru Petrescu : > Ryuji Wakikawa a =E9crit : >> >> Hi Alex, >> >> On 2009/10/21, at 15:07, Alexandru Petrescu wrote: >> >>>> From: RYUJI WAKIKAWA To: Alexandru Petrescu >>>> Date: Wed, 21 Oct 2009 14:40:26 -0700 >>>> Subject: Re: Procedure Hi Alex, >>>> On 2009/10/21, at 14:32, Alexandru Petrescu wrote: >>>>> >>>>> Ryuji, >>>>> This is the second time things go strange in this WG. =A0The first >>>>> time was at the DT formation time. >>>> >>>> what was the problem of the DT formation time? >>> >>> DT announcement after DT announcement. =A0I will not remind you now but= I >>> talked about it at the time on the jabber and on the mailing list. >> >> announcement after formation? What was the problem here? >> That was what Chairs and ADs have agreed. >> >>> >>>> After revising the WG charter, we formed a DT to identify the clear >>>> WG item. >>> >>> Now it looks as if you better had gone the way of AD sponsoring, and no= t >>> forming a DT working for a WG about which there seems to be little care= - >>> but much secrecy. =A0Sorry to say so but that's my impression. >>> >>> You had a public mailing list on the DT - that was ok. =A0But there's n= o >>> discussion on it about this decision of submitting the DT draft into WG >>> item. >>> >>>>> With respect to this document, it is not up to me to speak, but it >>>>> may be the case that another draft may talk same title as this >>>>> draft. >>>> >>>> DT is not officially formed to produce an individual document. We >>>> clearly spent so much time to improve this document. >>> >>> How about the new autoconf document I just saw announced and to which I >>> agree much more? =A0(about link-local addresses: it starts saying they = are a >>> MUST) - I agree to that stance much more than the DT document. >> >> AFAIK, the document conflicts with what we have agreed so far in WG, >> specially LL address stuff. > > Ryuji, I don't trust this. It's up to you. > This is all about confidence. =A0One can't build confidence this way. this is not on purpose. If you feel so, we sorry for that. > Following the list of past events, I can expect there will be no LC on th= e > WG item document either, ship straight to IESG. =A0And this is what AD > sponsoring is about, you don't need a WG at all. how come. We need WGLC and IETF-LC which are official procedure, we cannot ignore them. Don't argue with your imagination. > And hence frustration grows and distrust builds up. > >>> In that sense I agree much more with that new draft than with the DT >>> draft. >> >> What was the previous consensus call for then? > > That is right, the consensus call was for the LL addresses stuff. consensus call was also for the DT document. > But why no consensus call on adoption of the DT document? timing issue. >>> Please fix this - it's not my problem (don't tell me I already agreed >>> with the DT text on link-locals) - this is a WG caring problem. >> >> How do you want us to fix it? sending consensus call to adapt >> draft-bacelli? > > Isn't it too late for that? =A0How do "adopt" a document already submitte= d as > WG item? We can always withdraw a WG document. That's we have a right to do if that is WG consensus. ryuji > Alex > > >> >> regards, >> ryuji >> >> >>> >>> Alex >>> >>>> ryuji >>> >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf >> >> > > > From alexandru.petrescu@gmail.com Sat Oct 24 02:35:04 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 108973A6969 for ; Sat, 24 Oct 2009 02:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.18 X-Spam-Level: X-Spam-Status: No, score=-1.18 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_21=0.6, J_CHICKENPOX_52=0.6] 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 7PRBikVYhp6E for ; Sat, 24 Oct 2009 02:35: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 B52B53A68F3 for ; Sat, 24 Oct 2009 02:35:01 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 5D8E6D4814F; Sat, 24 Oct 2009 11:35:07 +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 9F264D480C3; Sat, 24 Oct 2009 11:35:04 +0200 (CEST) Message-ID: <4AE2CA44.9020802@gmail.com> Date: Sat, 24 Oct 2009 11:35:00 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ryuji Wakikawa References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <1256227396.6218.19.camel@acorde.it.uc3m.es> <543D8662-79A1-4E7D-AD68-56508AB37CDF@gmail.com> In-Reply-To: <543D8662-79A1-4E7D-AD68-56508AB37CDF@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091023-0, 23/10/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model 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: Sat, 24 Oct 2009 09:35:04 -0000 Ryuji Wakikawa a écrit : > Hi Carlos, > > Thanks for the draft and your suggestion. we haven't seen your draft > before publishing draft-ietf doc. > Anyway, you can discuss your draft on the list, but let us postpone the > decision. > I want to complete this consensus call first. > We still have dates to Hiroshima and want to see more opinions from WG. > I saw Alex, Teco supporting your document. There is also HyungJin having expressed support. Alex > > My concern is that we finished consensus call for LL address treatment > and agreed the texts. > We should not step back and bring new discussion on this thread. > > regards, > ryuji > > On 2009/10/22, at 9:03, Carlos Jesús Bernardos Cano wrote: > >> Hi Thomas, >> >> My individual and personal opinion -- also biased, since I'm >> co-authoring draft-bernardos-autoconf-addressing-model-00 (btw, we plan >> to submit a -01 before the cutoff deadline) -- is that since we now >> have one alternative candidate document for the work item which >> [autoconf] is chartered to accomplish (when we were working on it we >> didn't know there was already a WG document on this charter item), we >> may consider as WG our document as input as well. Then, we may have at >> least some discussion (on the ML -- please wait until we release -01 if >> you don't mind) and in Hiroshima (if we can present our draft) and then >> make a similar call as you did below, potentially considering somehow >> also the input that draft-bernardos-autoconf-addressing-model may bring >> (if the WG considers there is any). >> >> I know that we are late, we have been unfortunately always late in >> this >> WG (I participated in the BOF in 2005 and kept on contributing somehow >> since then, and still we haven't achieved any milestone, more than 4 >> years later). But still, I don't see this as a valid reason for taking >> decisions in a hurry (such as adopting WG documents without asking the >> WG), and I honestly think it would be good for the WG to have the chance >> to have some discussion on our draft and then come up with the best >> possible input that the WG can produce. >> >> Just my -- unavoidable (although I fought not to be) biased -- >> opinion >> on this. >> >> Thanks, >> >> Carlos >> >> On Thu, 2009-10-22 at 01:49 +0200, Thomas Heide Clausen wrote: >>> All, >>> >>> >>> It appeared to the chairs that the comments raised at the Stockholm >>> IETF, as well as on the list subsequently, concerning the document: >>> >>> >>> http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model >>> >>> >>> had been addressed fully by the editors, and to the WGs satisfaction - >>> at least, there were no issue raised to the latter/latest version >>> hereof. The chairs therefore found it a good idea to move the document >>> forward as a WG document, and progress this document as such. We >>> therefore approved for publication: >>> >>> >>> http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model >>> >>> >>> We (the chairs) still believe that this is the proper approach in >>> order to make progress for the WG. >>> >>> >>> Do note that the WG is 7 months past the milestone for initial >>> document submission, and 1 month past the milestone for having >>> progressed the document to the IESG and/or closed up shop! And, there >>> has been no discussions (in meetings or on this list) on alternative >>> candidate documents for the work item which [autoconf] is chartered to >>> accomplish. >>> >>> >>> To put it bluntly, this WG is far far behind schedule and this >>> document seemed, and still seems, by virtue of having been widely >>> discussed and agreed upon, as the best shot at making progress for >>> this WG. >>> >>> >>> That said, we (and, this we is also the chairs) will take this >>> opportunity to ask the WGs opinion on how to progress. If you have any >>> opinion, please let it be known to the WG (via this mailing list) >>> before 29/10/09 (i.e. Thursday next week) at noon CET. Please be >>> specific and constructive, i.e., pick one of: >>> >>> >>> o if you think that the WG should proceed >>> with draft-ietf-autoconf-adhoc-addr-model >>> as a baseline, say so! >>> >>> >>> o if you think there're cardinal (but fixable) issues missing or wrong >>> with >>> draft-ietf-autoconf-adhoc-addr-model, then let the WG know what these >>> issues are, and propose a solution before the deadline. The Editors >>> will certainly do their best to address the issues. >>> >>> >>> o if you think that draft-ietf-autoconf-adhoc-addr-model is beyond >>> hope, >>> let the WG know explicitly how you suggest that we progress at this >>> point -- >>> considering the current timeline!! >>> >>> >>> Cheers, >>> >>> >>> Ryuji & Thomas >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf >> -- >> Carlos Jesús Bernardos Cano http://www.netcoms.net >> GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 >> _______________________________________________ >> 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 ryuji.wakikawa@gmail.com Sat Oct 24 02:36:44 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 6066D3A6969 for ; Sat, 24 Oct 2009 02:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_52=0.6] 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 MxbUuLhNVPmA for ; Sat, 24 Oct 2009 02:36:43 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id E83C33A693A for ; Sat, 24 Oct 2009 02:36:42 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 9so2178035eyd.51 for ; Sat, 24 Oct 2009 02:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NTZJF0UOQA03GitlLJQe6sR+w/4uGH+3nNHfCSrI4Tk=; b=oZpsmcLXxaNj53H17WAw5is/CjKx8LX8hn1HGfiqnYX1H6WefI9ZJf/R81WehRPOaX SwP9Oc8F2TJ02IRUCj+nSskB7P91XUYQ6Ric3uSwrcVITjKfolyAkFxZSONlfSPb+58/ H3cPp3Y0AFu994jbo1BhPBOEP8VcZZcSq3CRQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=ArZBUx0/sV30gkUFJ5dynhIz55WK0+tcuvdbLy2PNOD6fQUgmJnxYTXZ35aek5v80p 6QOMIBJLFFC0VN5ynnX825ydNPm+czVf6ALy3WjZIspFoMUWfno5RK3dr1tnh+XDqtRd eNiDwpdgHGd3WDaTDFrbBJW0sgwcx28Tlvl88= MIME-Version: 1.0 Received: by 10.216.87.131 with SMTP id y3mr1292272wee.9.1256377010843; Sat, 24 Oct 2009 02:36:50 -0700 (PDT) In-Reply-To: <4AE2CA44.9020802@gmail.com> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <1256227396.6218.19.camel@acorde.it.uc3m.es> <543D8662-79A1-4E7D-AD68-56508AB37CDF@gmail.com> <4AE2CA44.9020802@gmail.com> Date: Sat, 24 Oct 2009 02:36:50 -0700 Message-ID: <84840efa0910240236t3b40543dp337fc82a908286e7@mail.gmail.com> From: Ryuji Wakikawa To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ryuji@sfc.wide.ad.jp List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2009 09:36:44 -0000 2009/10/24 Alexandru Petrescu : > Ryuji Wakikawa a =E9crit : >> >> Hi Carlos, >> >> Thanks for the draft and your suggestion. we haven't seen your draft >> before publishing draft-ietf doc. >> Anyway, you can discuss your draft on the list, but let us postpone the >> decision. >> I want to complete this consensus call first. >> We still have dates to Hiroshima and want to see more opinions from WG. >> I saw Alex, Teco supporting your document. > > There is also HyungJin having expressed support. I missed his email. Yes, we now have 4 people including Carlos. regards, ryuji > > Alex > >> >> My concern is that we finished consensus call for LL address treatment a= nd >> agreed the texts. >> We should not step back and bring new discussion on this thread. >> >> regards, >> ryuji >> >> On 2009/10/22, at 9:03, Carlos Jes=FAs Bernardos Cano wrote: >> >>> Hi Thomas, >>> >>> =A0 =A0My individual and personal opinion -- also biased, since I'm >>> co-authoring draft-bernardos-autoconf-addressing-model-00 (btw, we plan >>> to submit a =A0-01 before the cutoff deadline) -- is that since we now >>> have one alternative candidate document for the work item which >>> [autoconf] is chartered to accomplish (when we were working on it we >>> didn't know there was already a WG document on this charter item), we >>> may consider as WG our document as input as well. Then, we may have at >>> least some discussion (on the ML -- please wait until we release -01 if >>> you don't mind) and in Hiroshima (if we can present our draft) and then >>> make a similar call as you did below, potentially considering somehow >>> also the input that draft-bernardos-autoconf-addressing-model may bring >>> (if the WG considers there is any). >>> >>> =A0 =A0I know that we are late, we have been unfortunately always late = in >>> this >>> WG (I participated in the BOF in 2005 and kept on contributing somehow >>> since then, and still we haven't achieved any milestone, more than 4 >>> years later). But still, I don't see this as a valid reason for taking >>> decisions in a hurry (such as adopting WG documents without asking the >>> WG), and I honestly think it would be good for the WG to have the chanc= e >>> to have some discussion on our draft and then come up with the best >>> possible input that the WG can produce. >>> >>> =A0 =A0Just my -- unavoidable (although I fought not to be) biased -- o= pinion >>> on this. >>> >>> =A0 =A0Thanks, >>> >>> =A0 =A0Carlos >>> >>> On Thu, 2009-10-22 at 01:49 +0200, Thomas Heide Clausen wrote: >>>> >>>> All, >>>> >>>> >>>> It appeared to the chairs that the comments raised at the Stockholm >>>> IETF, as well as on the list subsequently, concerning the document: >>>> >>>> >>>> http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model >>>> >>>> >>>> had been addressed fully by the editors, and to the WGs satisfaction - >>>> at least, there were no issue raised to the latter/latest version >>>> hereof. The chairs therefore found it a good idea to move the document >>>> forward as a WG document, and progress this document as such. We >>>> therefore approved for publication: >>>> >>>> >>>> http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model >>>> >>>> >>>> We (the chairs) =A0still believe that this is the proper approach in >>>> order to make progress for the WG. >>>> >>>> >>>> Do note that the WG is 7 months past the milestone for initial >>>> document submission, and 1 month past the milestone for having >>>> progressed the document to the IESG and/or closed up shop! =A0And, the= re >>>> has been no discussions (in meetings or on this list) on alternative >>>> candidate documents for the work item which [autoconf] is chartered to >>>> accomplish. >>>> >>>> >>>> To put it bluntly, this WG is far far behind schedule and this >>>> document seemed, and still seems, by virtue of having been widely >>>> discussed and agreed upon, as the best shot at making progress for >>>> this WG. >>>> >>>> >>>> That said, we (and, this we is also the chairs) will take this >>>> opportunity to ask the WGs opinion on how to progress. If you have any >>>> opinion, please let it be known to the WG (via this mailing list) >>>> before 29/10/09 (i.e. Thursday next week) at noon CET. Please be >>>> specific and constructive, i.e., pick one of: >>>> >>>> >>>> o if you think that the WG should proceed >>>> with draft-ietf-autoconf-adhoc-addr-model >>>> as a baseline, say so! >>>> >>>> >>>> o if you think there're cardinal (but fixable) issues missing or wrong >>>> with >>>> draft-ietf-autoconf-adhoc-addr-model, then let the WG know what these >>>> issues are, and propose a solution before the deadline. The Editors >>>> will certainly do their best to address the issues. >>>> >>>> >>>> o if you think that draft-ietf-autoconf-adhoc-addr-model is beyond >>>> hope, >>>> let the WG know explicitly how you suggest that we progress =A0at this >>>> point -- >>>> =A0considering the current timeline!! >>>> >>>> >>>> Cheers, >>>> >>>> >>>> Ryuji & Thomas >>>> _______________________________________________ >>>> Autoconf mailing list >>>> Autoconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/autoconf >>> >>> -- >>> Carlos Jes=FAs Bernardos Cano =A0 =A0 http://www.netcoms.net >>> GPG FP: D29B 0A6A 639A A561 93CA =A04D55 35DC BA4D D170 4F67 >>> _______________________________________________ >>> 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 ryuji.wakikawa@gmail.com Sat Oct 24 02:48: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 0169928C0E6 for ; Sat, 24 Oct 2009 02:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.600, 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 FYZUhaGwLeZy for ; Sat, 24 Oct 2009 02:48:56 -0700 (PDT) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id B00ED3A67D1 for ; Sat, 24 Oct 2009 02:48:56 -0700 (PDT) Received: by ywh13 with SMTP id 13so13466220ywh.29 for ; Sat, 24 Oct 2009 02:49:05 -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=8WFOTZc7xhcdX3lk8QJsueyZ8Ke1RKue03K2Sygl36Y=; b=Jmcem5n7yxXohn+klkosukVfP+j11gCHxx5jVVqjaiV31u61lhpuBgOJ5/+GVo6db/ DpzMkEimDBW6HV1OXWU8kXXPOnYuTbLRxfcYF4rsExtImWaymrWj3HsJnA+n3jKAlq9G x6VAE1lRcM8kQKss1/JpLX+adY2l1fjX7sQyI= 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=lXlE7hmBT6SDG43nuE9oWWDXCWlRSv57c9cjt5+5+cONMhwxnzvi9OXCqoGb6+ipry ssA1Xn4qPWT1MT08VSXdIqw/IKwS8PpgOgaIW94rIWqTOGRRrREHKzYXsh+aT42H0crV 21j+QsVRMSnowNRmGmPIcjbLZpFIeXO6mshNE= Received: by 10.150.48.6 with SMTP id v6mr19956871ybv.131.1256377745189; Sat, 24 Oct 2009 02:49:05 -0700 (PDT) Received: from ?10.0.1.2? (c-98-248-44-75.hsd1.ca.comcast.net [98.248.44.75]) by mx.google.com with ESMTPS id 4sm431844ywd.44.2009.10.24.02.49.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 24 Oct 2009 02:49:03 -0700 (PDT) From: Ryuji Wakikawa To: Alexandru Petrescu In-Reply-To: <4AE0DB2A.7090902@gmail.com> 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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <4AE0DB2A.7090902@gmail.com> Message-Id: <5AA9128C-9931-4793-A750-1916BE56E866@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: Sat, 24 Oct 2009 02:49:00 -0700 X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] [warning -- weeks old mail under discussion] Re: 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: Sat, 24 Oct 2009 09:48:58 -0000 Hi Alex, On 2009/10/22, at 15:22, Alexandru Petrescu wrote: > Charles E. Perkins a =E9crit : > [...] >>>> Ten or more neighbors, moving at any reasonable speed, and your >>>> design is toast -- DHCP or no DHCP. >>> Charles - "speed" as we tend to interpret it may have no sense when >>> we consider coverage areas. Node speed of 300kmph equals 0 if the >>> coverage is very large. >> This is a good point. Perhaps the proper quantity of interest is the >> average transition time through the range of coverage from a >> neighboring node. > > Average transition time (ATT) through some coverage sounds more =20 > tempting than simply "speed". > > So a vehicle would have an ATT of 3.6seconds (50kmph, 50m wifi). > > 3.6s is enough to perform DHCP and many other things. If you assume wifi, this is not true. You exclude the wireless =20 discovery/association time (L2 processing). You will not get DHCP offer from the server in this case. This is =20 reality. ryuji > >>> Node speed of 300kmph going through a 50m wifi area - ok, no DHCP: >>> but then one wonders _why_ would a car need to communicate anything >>> through that 50m wifi area. >> I personally think this is a great idea, if for instance we had WiFi >> on the streetlamps and freeway dividers. > > It could work for certain values of ATT, I am sure. > >> At $1.00 per transceiver chip, it's a reasonable alternative! It >> draws a lot less power than the light bulb. > > >>> DHCP or no DHCP... what coverage area? what link layer? >>> DHCP can be very fast. >> In order to counter this statement (or, more accurately, show why it >> is not relevant), I would have to go through the exercise -- but you >> had relieved me of that task. > > I know why people say DHCP is slow. I've measured it. There are =20 > quirks with some implementations of the timers. It's mostly in the =20= > discovery phase. It's the same fundamental reasons why some people =20= > complain about slow WiFi link-layer handovers, and slow Mobile IP, =20 > and slow NUD, slow ND - which I've also measured. > > Basically one can't do discovery otherwise than emitting and then =20 > _waiting_ a pre-defined amount of time. It's the basics of the =20 > basics. > > What one can do is to shorten the time one waits, at the risk of not =20= > hearing some things and maybe hitting into someone, or missing the =20 > presence of some DHCP Server. > > AUTOCONF can't propose a discovery mechanism better than the =20 > discovery phases of DHCP, ND, and FastBSS. People would have =20 > already done it well before. > >> I'm not going to do that unless necessary. >> But, roughly speaking, the answer is that you can't have DHCP unless >> you know where the server(s) and the relays are. > > Err... yes, more or less. > > The Client performs a discovery phase, sending first to a predefined =20= > multicast address and then waiting. > >> And when the nodes >> are moving, you don't know. > > Well - you do know for some time. > >> And you can't quote NUD and NA as theorems because of the reasons I =20= >> already outlined in previous >> messages. And even if you could, before long you'd have to get some >> new relay because you need the relay to be local. And more than >> likely your DHCP server will be occasionally partitioned into =20 >> temporary isolation. But then it's back! But the relay is gone! >> And then there's something else to go wrong. But, are _all_ nodes >> relays? But, which server has the state? Or is there just one >> server? But that won't ever work! >> Every time I think about it, I just know it's wrong. I do not have >> any belief whatsoever in this theorem. And, with three nodes, you'll >> never see the problem. Never! > > Well I look at it as a distributed election problem. Dynamically =20 > elect the Servers and the Relays, among them. Of course, =20 > afterwards, the elected DHCP Server needs to learn the addresses of =20= > the relays and to have routes to them. These issues can be solved =20= > by using link-local addresses. > > This entire mechanism will work during some lapse of time during =20 > which the devices are within relatively stable distance. > > When links start breaking, nodes disappear, other nodes appear - re-=20= > execute the entire election process. > > Now, don't tell me that things move so fast that there is not enough =20= > time to deal with re-election: there will always be things which =20 > move too fast for whoever and whatever mechanism to break, including =20= > whatever AUTOCONF designs. > > Alex > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From ryuji.wakikawa@gmail.com Sat Oct 24 02:51:50 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 A1EB83A69B0 for ; Sat, 24 Oct 2009 02:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 qfdWH-ndn+wr for ; Sat, 24 Oct 2009 02:51:49 -0700 (PDT) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id A66723A69AC for ; Sat, 24 Oct 2009 02:51:49 -0700 (PDT) Received: by pwi4 with SMTP id 4so2591202pwi.29 for ; Sat, 24 Oct 2009 02:51:55 -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=o0ZSSmKUt44+g2xbNiQiFSG1L7mSkTwz5MklU41p5P4=; b=PuPt4/0ZWCaqXrSO08EJrbMojHRu+wSvFhW67yGm9Vp3Dnt5xu2dY9eNwy/qU/lwkU yh+vSLN3ynKxFsuvU1ycbGBTzxnEHhSGcoPI0ipXJ2ZuFVWKaWZtU2j+s7zaNlhVF9MV VZSykIMiXuIFi7DZDvVB+QhBu6eJOglw0q/jE= 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=v5PgcXLjZUZ7RBD38ojKpa5EQlFEM1h8RRbUaV/HDjWhFoBjOazD8LiNswe+Rn2hHL ZzpVp8VHPkRacKLxCz2Bo9PhbCUc30GZJmIs5TMTIHXsE608zWgWMXW/+Ozqw1mjCVK2 H74pVoepJvLmodwEyL2eygr9bMPEhAY8+9j5I= Received: by 10.115.149.10 with SMTP id b10mr2556294wao.157.1256377915779; Sat, 24 Oct 2009 02:51:55 -0700 (PDT) Received: from ?10.0.1.2? (c-98-248-44-75.hsd1.ca.comcast.net [98.248.44.75]) by mx.google.com with ESMTPS id 22sm822349pzk.10.2009.10.24.02.51.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 24 Oct 2009 02:51:54 -0700 (PDT) From: Ryuji Wakikawa To: Charles E. Perkins In-Reply-To: <4AE0A7BA.2060002@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> <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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> 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: Sat, 24 Oct 2009 02:51:52 -0700 X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] [warning -- weeks old mail under discussion] Re: 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: Sat, 24 Oct 2009 09:51:50 -0000 On 2009/10/22, at 11:43, Charles E. Perkins wrote: > > Hello Alex, > > Alexandru Petrescu wrote: >> >>> First, I don't agree with the often suggested >>> assumption that we can rely on MAC addresses >>> for uniqueness. Maybe we ought to have a new >>> design team or even working group for that, but >>> I think such results are usually required to be clearly >>> labeled as, for instance, "XXXX over IEEE 802.11" >>> or some such. >> >> Ok, I agree, we should label AUTOCONF as 802.11. > > Well, you may agree with some other people on that point, > but I do not agree with it, and maybe it's time to get some > clarity on this point. We shouldn't assume 802.11 only. I agree with Charlie that MAC addresses uniqueness is not sufficient. That's what we started the discussion of LL address treatment. We cannot guarantee the LL address uniqueness along the current IPv6 spec. A second after DAD, the neighbors can be changed and LL address can now be duplicated. In some scenarios, this issue might not be applied. However, unless there is a case, we cannot ignore this issue in AUTOCONF. ryuji > >>> >>> So when you quote "theorems" such as DHCP, >>> without going to the trouble of verifying the requisite >>> preconditions, you are investing confidence in a >>> design that would fall apart like a house of cards in >>> a windstorm. >> >> >> Hmm... how else is one supposed to make logical argumentations? > > By making assumptions that are supportable in the > area of interest. > >> >> >>> Ten or more neighbors, moving at any reasonable speed, >>> and your design is toast -- DHCP or no DHCP. >> >> Charles - "speed" as we tend to interpret it may have no sense when >> we consider coverage areas. Node speed of 300kmph equals 0 if the >> coverage is very large. > > This is a good point. Perhaps the proper quantity of interest > is the average transition time through the range of coverage > from a neighboring node. > >> >> Node speed of 300kmph going through a 50m wifi area - ok, no DHCP: >> but then one wonders _why_ would a car need to communicate anything >> through that 50m wifi area. > > I personally think this is a great idea, if for instance we had > WiFi on the streetlamps and freeway dividers. At $1.00 > per transceiver chip, it's a reasonable alternative! It draws > a lot less power than the light bulb. > >> >> DHCP or no DHCP... what coverage area? what link layer? >> >> DHCP can be very fast. > > In order to counter this statement (or, more accurately, > show why it is not relevant), I would have to go through > the exercise -- but you had relieved me of that task. > > I'm not going to do that unless necessary. > > But, roughly speaking, the answer is that you can't > have DHCP unless you know where the server(s) and > the relays are. And when the nodes are moving, you > don't know. And you can't quote NUD and NA as > theorems because of the reasons I already outlined > in previous messages. And even if you could, before > long you'd have to get some new relay because you > need the relay to be local. And more than likely your > DHCP server will be occasionally partitioned into > temporary isolation. But then it's back! But the > relay is gone! And then there's something else to > go wrong. But, are _all_ nodes relays? But, which > server has the state? Or is there just one server? > But that won't ever work! > > Every time I think about it, I just know it's wrong. > I do not have any belief whatsoever in this theorem. > And, with three nodes, you'll never see the problem. > Never! > > Regards, > Charlie P. > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From ryuji.wakikawa@gmail.com Sat Oct 24 03:00: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 1B81F28C0E6 for ; Sat, 24 Oct 2009 03:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] 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 sIttEPgNKrMS for ; Sat, 24 Oct 2009 03:00:31 -0700 (PDT) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 4D6EB3A6847 for ; Sat, 24 Oct 2009 03:00:31 -0700 (PDT) Received: by pzk6 with SMTP id 6so1281884pzk.29 for ; Sat, 24 Oct 2009 03:00:40 -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=zGdgajhjcckJSLrUxw2zDlRhaCQBtL2vwU/QrjsNlk4=; b=O+yPz6G90w8Twlen5NcsJh2PsRYhZR9Xa4Jg3nOQkOdEqfLyJWLdr+6UcsRYT9xNs0 UzRPveouVlxC5/0hQR6cKNRsLUddBS9owVynKDWOMe1GUChs3XJO5WSiCqXIepy0ayNU 2zFhKJpHS98BsdufzGnpml+45RPc1fz766n3I= 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=V/cLyjgwU1E0Bl6yBkADrW5Q7ATvu3EefLKluP6RO5wycjQjFQeG4aVV+DlaWB2/4z eb/EDf8iWqK6KGp17t31Y9rcQyp5/zfd0ldQR37GMo5SrG5+5PPIPQcZnMSpouGeo1I9 0D6LWjoLcCZKDylPow8qKAQnTAaAFkAGOySwc= Received: by 10.115.101.27 with SMTP id d27mr17584540wam.126.1256378439988; Sat, 24 Oct 2009 03:00:39 -0700 (PDT) Received: from ?10.0.1.2? (c-98-248-44-75.hsd1.ca.comcast.net [98.248.44.75]) by mx.google.com with ESMTPS id 20sm1337825pxi.11.2009.10.24.03.00.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 24 Oct 2009 03:00:38 -0700 (PDT) From: Ryuji Wakikawa To: cjbc@it.uc3m.es In-Reply-To: <1256170228.12205.20.camel@acorde.it.uc3m.es> References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> Message-Id: <0E0F03A1-EC0C-4FF9-AB17-DB2029F7363E@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 24 Oct 2009 03:00:36 -0700 X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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: Sat, 24 Oct 2009 10:00:33 -0000 Hi Carlos, On 2009/10/21, at 17:10, Carlos Jes=C3=BAs Bernardos Cano wrote: > Hi Charlie, > > On Wed, 2009-10-21 at 16:08 -0700, Charles E. Perkins wrote: >> Hello Carlos and Ronald, >> >> Intrigued by Alex's email to the [autoconf] mailing list, I read >> your draft, which suggests the mandate: > > Thanks for reading the draft. We are working on a -01 version (we > submitted -00 to meet the deadline and we hope to make some changes > before announcing it on the ML), but I'll provide my view on your > questions. > >> "MANET interfaces MUST also be configured with >> IPv6 Link-local addresses". >> >> But there is no indication in the draft about why that >> mandate might result in anything useful. >> >> What if [autoconf] recommended assignment of a distinguished >> link-local address to every MANET node? We could, for >> instance, designate the value fe80::FFFF as the distinguished >> useless link-local address designed _solely_ for the purpose >> of rigorous compliance with RFC 4861. Would this be >> satisfactory for the purposes you espouse in your draft? > > No, this would not be satisfactory. Link locals are not only =20 > mandated by > RFC 4861 but also used by some protocols, so that's why we consider > important to configure them (so they can be used) in MANETs. We have to understand all the protocols using link-local address expect the uniqueness of LL-address defined as RFC4861. If LL address cannot be guaranteed uniqueness as RFC4861, we cannot guarantee the correct behavior of other protocols. >> I also note that in your draft you advocate reliance on the >> typical (but not guaranteed) uniqueness of IEEE MAC addresses, > > It's true that it is not guaranteed, but the probability of =20 > collision is > so low, that I'm not sure it's worth arguing about the necessity of > using DAD. see above. AFAIK, It's necessary to make sure the LL address uniqueness if we =20 will use it. regards, ryuji > >> and also turning off DAD or hacking the parameters. Did you >> try to calculate the overhead of, say, beaconing NA messages >> every 50 milliseconds, and the resulting too-frequent ND >> operations? Do you have any comments on the N^2 nature >> of this source of congestion? > > This could be certainly a scalability problem, but "hacking/=20 > configuring" > ND is just one proposed mechanism to tackle with fluctuating > reachability issues. There are other ways proposed in the draft =20 > (such a > stronger interaction with the routing protocol) and surely there are > more. > > Even if globals are used instead, we would have a fluctuating > reachability issue, since the next IP hop used to reach a certain > destination might move out of radio coverage (you need to detect =20 > this by > ND or the routing protocol). I think the same kind-of solutions that =20= > be > used there can also be used when link-locals are used. Besides, we do > not mandate to use link-locals in the draft, we just think there are =20= > use > cases where they are useful and therefore we should not prevent their > use in MANETs. > > Again, thanks for reading the draft. > > Regards, > > Carlos > >> >> Regards, >> Charlie P. >> >> >> Alexandru Petrescu wrote: >>> AUTOCONFers, >>> >>> I just noticed this draft just announced: >>> >>> Internet-Drafts@ietf.org a =C3=A9crit : >>>> A URL for this Internet-Draft is: >>>> = http://www.ietf.org/internet-drafts/draft-bernardos-autoconf-addressing-mo= del-00.txt >>>> >>> >>> This draft says, among others: >>> >>>> MANET interfaces MUST also be configured with IPv6 Link-local >>>> addresses (as required by RFC 4861 [RFC4861] and RFC 4291 =20 >>>> [RFC4291]). >>>> Two main concerns may arise when considering the use of IPv6 =20 >>>> Link- >>>> local addresses: >>>> >>>> o Address uniqueness: the event of having two duplicate =20 >>>> addresses in >>>> the same link has proved to be very low (EUI64 derived =20 >>>> interface >>>> identifiers very rarely collide, since MAC addresses are =20 >>>> expected >>>> to be globally unique), and even some mechanisms have been >>>> proposed to reduce the collision probability >>>> [I-D.soto-mobileip-random-iids]. Therefore, in most =20 >>>> scenarios it >>>> is safe to assume that the probability of having two or more >>>> duplicated link-local addresses in a MANET is negiglible. For >>>> those scenarios, in which this cannot be safely assumed, we =20= >>>> refer >>>> to the DAD considerations of Section 3.3. >>>> >>>> o Reachability: connectivity among neighbours in wireless =20 >>>> links may >>>> be intermittent and/or short-lived. Therefore, the use of =20 >>>> link- >>>> local addresses may lead to reachability issues, since two =20 >>>> nodes >>>> that were in direct coverage range at one moment, might not be >>>> anymore shortly after. These problems might also arise in =20 >>>> wired >>>> networks (nodes going up/down), but it is not the common case. >>>> >>>> Having brought to attention these concerns, it is further left =20= >>>> to the >>>> designers of MANET routing protocols (and other protocols) to >>>> determine whether link-local addresses can be used in an =20 >>>> effective >>>> way. >>> >>> I must say I fully agree with the above text, because it says >>> link-locals are "MUST". It is more positive towards link-locals, I >>> agree with it. >>> >>> I agree with it more than I agree with this text in >>> draft-ietf-autoconf-adhoc-addr-model-00.txt: >>>> Note that while link-local addresses are assumed to be "on =20 >>>> link", the >>>> utility of link-local addresses is limited as described in =20 >>>> Section 6. >>> >>> ... which has a negative co-notation in that use of the "limited" =20= >>> word. >>> >>> So - please clarify this situation. >>> >>> Alex >>> >>>> >>> >>> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> Below is the data which will enable a MIME compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >>>> >>>> >>>> = ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf >>> >>> >> > --=20 > Carlos Jes=C3=BAs Bernardos Cano http://www.netcoms.net > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From ryuji.wakikawa@gmail.com Sat Oct 24 03:11: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 36F0328C0E8 for ; Sat, 24 Oct 2009 03:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] 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 nMQeOeJu4UuX for ; Sat, 24 Oct 2009 03:11:32 -0700 (PDT) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 7CC7028C0E6 for ; Sat, 24 Oct 2009 03:11:32 -0700 (PDT) Received: by pzk6 with SMTP id 6so1285070pzk.29 for ; Sat, 24 Oct 2009 03:11:41 -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=/gva9lrpTZ3cnzZUQETiKCrRutw4zFR2Rw31VQkS7fU=; b=jlF9+8/YCoBKLIvwAr6Y8rgJFV7Uhm0N9zNLV+oN29jlm0V201un53QR0vIK6TdxjE 7JPqB8R8bO21PT5vQkRpQhqF0oBxshZPpmy8wrJ1dYzbO1vAbpzOfNGLW7TDDiFvCnvh 9lwkZtfy5mm2XXLN7VacMUShyCJBlR7CaV5Jw= 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=g89i/JwkFuYiPKtthHf+V5eZ6TIKKPtcxgHn37qlkPnDs1Ga5zjB+2FGY0NlG6m+fA DUEhMNx2j73BFbxKDpGFos+Hfh2nRDwLDjzK5vgrsGDfZHLN5BS5zxmhkh9PnNj+JSW0 tk2zPL2GQ54b0Ehzjq0Sc7okPcOzyrJDm+b74= Received: by 10.115.103.23 with SMTP id f23mr17538786wam.226.1256379101345; Sat, 24 Oct 2009 03:11:41 -0700 (PDT) Received: from ?10.0.1.2? (c-98-248-44-75.hsd1.ca.comcast.net [98.248.44.75]) by mx.google.com with ESMTPS id 20sm977978pzk.9.2009.10.24.03.11.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 24 Oct 2009 03:11:40 -0700 (PDT) From: Ryuji Wakikawa To: cjbc@it.uc3m.es In-Reply-To: <1256237606.5373.22.camel@acorde.it.uc3m.es> References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> Message-Id: <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 24 Oct 2009 03:11:38 -0700 X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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: Sat, 24 Oct 2009 10:11:33 -0000 Hi Carlos, On 2009/10/22, at 11:53, Carlos Jes=C3=BAs Bernardos Cano wrote: > Hi Charlie, >> >> Please explain the relationship between the following two sentences: >> >>> "MANET interfaces MUST also be configured with >>> IPv6 Link-local addresses" >> >> and >>> "Besides, we do >>> not mandate to use link-locals in the draft, we just think there =20 >>> are use >>> cases where they are useful and therefore we should not prevent =20 >>> their >>> use in MANETs." > > The relationship is the following: LLs MUST be configured, but we =20 > don't > mandate their use. It is a MUST, because there are IPv6 specs that say > so and because there are IPv6 protocols/applications that may want to > use them, but this does not imply that we force protocols/applications > to use them (it's up to the protocol/application designer to decide > whether to use them or not). The differences from the DT draft on this point are - mandating LL address - no warning to use it ? The DT document does not prohibit using LL address, but it clearly =20 warn the possible problems (which are MANET specific). What is your problem of the texts in the DT document? You can still run existing protocols using the link-local with the =20 same condition of your draft (i.e. no DAD). We should not let this DAD functionality as an optional. If we want to use LL, we have to provide uniqueness to LL and mandate =20= DAD for it. This is because we shouldn't assume any L1/L2 technology in IP. regards, ryuji > > Thanks, > > Carlos > >> >> Regards, >> Charlie P. >> > --=20 > Carlos Jes=C3=BAs Bernardos Cano http://www.netcoms.net > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From alexandru.petrescu@gmail.com Sat Oct 24 03:21: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 ADF8A28C110 for ; Sat, 24 Oct 2009 03:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.775 X-Spam-Level: X-Spam-Status: No, score=-1.775 tagged_above=-999 required=5 tests=[AWL=0.474, 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 RpOBOLi-6vWW for ; Sat, 24 Oct 2009 03:21:53 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 540273A67EB for ; Sat, 24 Oct 2009 03:21:51 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id DC3AFD48136; Sat, 24 Oct 2009 12:21:58 +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 82493D4811A; Sat, 24 Oct 2009 12:21:55 +0200 (CEST) Message-ID: <4AE2D53F.9000208@gmail.com> Date: Sat, 24 Oct 2009 12:21:51 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) 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><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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <4AE0DB2A.7090902@gmail.com> <5AA9128C-9931-4793-A750-1916BE56E866@gmail.com> In-Reply-To: <5AA9128C-9931-4793-A750-1916BE56E866@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091023-0, 23/10/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] [warning -- weeks old mail under discussion] Re: 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: Sat, 24 Oct 2009 10:21:54 -0000 Ryuji Wakikawa a écrit : > Hi Alex, > > On 2009/10/22, at 15:22, Alexandru Petrescu wrote: > >> Charles E. Perkins a écrit : >> [...] >>>>> Ten or more neighbors, moving at any reasonable speed, and your >>>>> design is toast -- DHCP or no DHCP. >>>> Charles - "speed" as we tend to interpret it may have no sense when >>>> we consider coverage areas. Node speed of 300kmph equals 0 if the >>>> coverage is very large. >>> This is a good point. Perhaps the proper quantity of interest is the >>> average transition time through the range of coverage from a >>> neighboring node. >> >> Average transition time (ATT) through some coverage sounds more >> tempting than simply "speed". >> >> So a vehicle would have an ATT of 3.6seconds (50kmph, 50m wifi). >> >> 3.6s is enough to perform DHCP and many other things. > > If you assume wifi, this is not true. You exclude the wireless > discovery/association time (L2 processing). No, I dont exclude the L2 processing. There are L2 attachment implementations which take shorter time than others. There are 2, 4 or 6 wifi L2 messages (depending if security is used) for discovery and the L2 discovery phase can be very fast for some implementations. It pretty much depends on the implementation of the L2 Client's waiting timers, the ESSID unniqueness among APs, the Client's knowledge of MAC address of AP based on location information (GPS), the use of which L2 security mechanism, the use of AP mode or adhoc mode. > You will not get DHCP offer from the server in this case. This is reality. There are implementations and implementations of this. Some are shorter than others. When I did fast handovers (without FMIP) I could have handovers wifi L2 in the orders of tens of milliseconds, under some circumstances; discovery included. Alex > > ryuji > > >> >>>> Node speed of 300kmph going through a 50m wifi area - ok, no DHCP: >>>> but then one wonders _why_ would a car need to communicate anything >>>> through that 50m wifi area. >>> I personally think this is a great idea, if for instance we had WiFi >>> on the streetlamps and freeway dividers. >> >> It could work for certain values of ATT, I am sure. >> >>> At $1.00 per transceiver chip, it's a reasonable alternative! It >>> draws a lot less power than the light bulb. >> > >>>> DHCP or no DHCP... what coverage area? what link layer? >>>> DHCP can be very fast. >>> In order to counter this statement (or, more accurately, show why it >>> is not relevant), I would have to go through the exercise -- but you >>> had relieved me of that task. >> >> I know why people say DHCP is slow. I've measured it. There are >> quirks with some implementations of the timers. It's mostly in the >> discovery phase. It's the same fundamental reasons why some people >> complain about slow WiFi link-layer handovers, and slow Mobile IP, and >> slow NUD, slow ND - which I've also measured. >> >> Basically one can't do discovery otherwise than emitting and then >> _waiting_ a pre-defined amount of time. It's the basics of the basics. >> >> What one can do is to shorten the time one waits, at the risk of not >> hearing some things and maybe hitting into someone, or missing the >> presence of some DHCP Server. >> >> AUTOCONF can't propose a discovery mechanism better than the discovery >> phases of DHCP, ND, and FastBSS. People would have already done it >> well before. >> >>> I'm not going to do that unless necessary. >>> But, roughly speaking, the answer is that you can't have DHCP unless >>> you know where the server(s) and the relays are. >> >> Err... yes, more or less. >> >> The Client performs a discovery phase, sending first to a predefined >> multicast address and then waiting. >> >>> And when the nodes >>> are moving, you don't know. >> >> Well - you do know for some time. >> >>> And you can't quote NUD and NA as theorems because of the reasons I >>> already outlined in previous >>> messages. And even if you could, before long you'd have to get some >>> new relay because you need the relay to be local. And more than >>> likely your DHCP server will be occasionally partitioned into >>> temporary isolation. But then it's back! But the relay is gone! >>> And then there's something else to go wrong. But, are _all_ nodes >>> relays? But, which server has the state? Or is there just one >>> server? But that won't ever work! >>> Every time I think about it, I just know it's wrong. I do not have >>> any belief whatsoever in this theorem. And, with three nodes, you'll >>> never see the problem. Never! >> >> Well I look at it as a distributed election problem. Dynamically >> elect the Servers and the Relays, among them. Of course, afterwards, >> the elected DHCP Server needs to learn the addresses of the relays and >> to have routes to them. These issues can be solved by using >> link-local addresses. >> >> This entire mechanism will work during some lapse of time during which >> the devices are within relatively stable distance. >> >> When links start breaking, nodes disappear, other nodes appear - >> re-execute the entire election process. >> >> Now, don't tell me that things move so fast that there is not enough >> time to deal with re-election: there will always be things which move >> too fast for whoever and whatever mechanism to break, including >> whatever AUTOCONF designs. >> >> Alex >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > From alexandru.petrescu@gmail.com Sat Oct 24 03:23:44 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 91C3028C12C for ; Sat, 24 Oct 2009 03:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.794 X-Spam-Level: X-Spam-Status: No, score=-1.794 tagged_above=-999 required=5 tests=[AWL=0.455, 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 ZU1fYfdKtzeI for ; Sat, 24 Oct 2009 03:23:43 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 4838328C110 for ; Sat, 24 Oct 2009 03:23:41 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id EBE72D48028; Sat, 24 Oct 2009 12:23:48 +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 B7E30D4805F; Sat, 24 Oct 2009 12:23:45 +0200 (CEST) Message-ID: <4AE2D5AD.6090701@gmail.com> Date: Sat, 24 Oct 2009 12:23:41 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) 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><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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091023-0, 23/10/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] [warning -- weeks old mail under discussion] Re: 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: Sat, 24 Oct 2009 10:23:44 -0000 Ryuji Wakikawa a écrit : > > On 2009/10/22, at 11:43, Charles E. Perkins wrote: > >> >> Hello Alex, >> >> Alexandru Petrescu wrote: >>> >>>> First, I don't agree with the often suggested >>>> assumption that we can rely on MAC addresses >>>> for uniqueness. Maybe we ought to have a new >>>> design team or even working group for that, but >>>> I think such results are usually required to be clearly >>>> labeled as, for instance, "XXXX over IEEE 802.11" >>>> or some such. >>> >>> Ok, I agree, we should label AUTOCONF as 802.11. >> >> Well, you may agree with some other people on that point, >> but I do not agree with it, and maybe it's time to get some >> clarity on this point. > > We shouldn't assume 802.11 only. > I agree with Charlie that MAC addresses uniqueness is not sufficient. > That's what we started the discussion of LL address treatment. > > We cannot guarantee the LL address uniqueness along the current IPv6 spec. Can you enumerate the problems you've seen in practice of not assuming this uniqueness? I have never seen one. I have never seen DAD reporting duplicates either. Theoretically - yes, DAD was designed in the spirit you talk about. Alex > A second after DAD, the neighbors can be changed and LL address can now > be duplicated. > > In some scenarios, this issue might not be applied. However, unless > there is a case, > we cannot ignore this issue in AUTOCONF. > > ryuji > > > > >> >>>> >>>> So when you quote "theorems" such as DHCP, >>>> without going to the trouble of verifying the requisite >>>> preconditions, you are investing confidence in a >>>> design that would fall apart like a house of cards in >>>> a windstorm. >>> >>> >>> Hmm... how else is one supposed to make logical argumentations? >> >> By making assumptions that are supportable in the >> area of interest. >> >>> >>> >>>> Ten or more neighbors, moving at any reasonable speed, >>>> and your design is toast -- DHCP or no DHCP. >>> >>> Charles - "speed" as we tend to interpret it may have no sense when >>> we consider coverage areas. Node speed of 300kmph equals 0 if the >>> coverage is very large. >> >> This is a good point. Perhaps the proper quantity of interest >> is the average transition time through the range of coverage >> from a neighboring node. >> >>> >>> Node speed of 300kmph going through a 50m wifi area - ok, no DHCP: >>> but then one wonders _why_ would a car need to communicate anything >>> through that 50m wifi area. >> >> I personally think this is a great idea, if for instance we had >> WiFi on the streetlamps and freeway dividers. At $1.00 >> per transceiver chip, it's a reasonable alternative! It draws >> a lot less power than the light bulb. >> >>> >>> DHCP or no DHCP... what coverage area? what link layer? >>> >>> DHCP can be very fast. >> >> In order to counter this statement (or, more accurately, >> show why it is not relevant), I would have to go through >> the exercise -- but you had relieved me of that task. >> >> I'm not going to do that unless necessary. >> >> But, roughly speaking, the answer is that you can't >> have DHCP unless you know where the server(s) and >> the relays are. And when the nodes are moving, you >> don't know. And you can't quote NUD and NA as >> theorems because of the reasons I already outlined >> in previous messages. And even if you could, before >> long you'd have to get some new relay because you >> need the relay to be local. And more than likely your >> DHCP server will be occasionally partitioned into >> temporary isolation. But then it's back! But the >> relay is gone! And then there's something else to >> go wrong. But, are _all_ nodes relays? But, which >> server has the state? Or is there just one server? >> But that won't ever work! >> >> Every time I think about it, I just know it's wrong. >> I do not have any belief whatsoever in this theorem. >> And, with three nodes, you'll never see the problem. >> Never! >> >> Regards, >> Charlie P. >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > From alexandru.petrescu@gmail.com Sat Oct 24 03:26: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 2CC6A3A683D for ; Sat, 24 Oct 2009 03:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.811 X-Spam-Level: X-Spam-Status: No, score=-1.811 tagged_above=-999 required=5 tests=[AWL=0.438, 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 UkOC9q91xCkM for ; Sat, 24 Oct 2009 03:26:54 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id DC5703A68FE for ; Sat, 24 Oct 2009 03:26:52 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 84DEDD48069; Sat, 24 Oct 2009 12:26:58 +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 4BC5BD48138; Sat, 24 Oct 2009 12:26:56 +0200 (CEST) Message-ID: <4AE2D66B.90208@gmail.com> Date: Sat, 24 Oct 2009 12:26:51 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) 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><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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091023-0, 23/10/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] [warning -- weeks old mail under discussion] Re: 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: Sat, 24 Oct 2009 10:26:55 -0000 Ryuji Wakikawa a écrit : > > On 2009/10/22, at 11:43, Charles E. Perkins wrote: > >> >> Hello Alex, >> >> Alexandru Petrescu wrote: >>> >>>> First, I don't agree with the often suggested assumption that >>>> we can rely on MAC addresses for uniqueness. Maybe we ought to >>>> have a new design team or even working group for that, but I >>>> think such results are usually required to be clearly labeled >>>> as, for instance, "XXXX over IEEE 802.11" or some such. >>> >>> Ok, I agree, we should label AUTOCONF as 802.11. >> >> Well, you may agree with some other people on that point, but I do >> not agree with it, and maybe it's time to get some clarity on this >> point. > > We shouldn't assume 802.11 only. I agree with Charlie that MAC > addresses uniqueness is not sufficient. That's what we started the > discussion of LL address treatment. > > We cannot guarantee the LL address uniqueness along the current IPv6 > spec. A second after DAD, the neighbors can be changed and LL address > can now be duplicated. > > In some scenarios, this issue might not be applied. I agree on this point, in the scenario I need this issues does not apply. > However, unless there is a case, we cannot ignore this issue in > AUTOCONF. I can't see what are the implications of this, thus Ill stay silent about it. Alex > > ryuji > > > > >> >>>> >>>> So when you quote "theorems" such as DHCP, without going to the >>>> trouble of verifying the requisite preconditions, you are >>>> investing confidence in a design that would fall apart like a >>>> house of cards in a windstorm. >>> >>> >>> Hmm... how else is one supposed to make logical argumentations? >> >> By making assumptions that are supportable in the area of interest. >> >> >> >>> >>> >>>> Ten or more neighbors, moving at any reasonable speed, and your >>>> design is toast -- DHCP or no DHCP. >>> >>> Charles - "speed" as we tend to interpret it may have no sense >>> when we consider coverage areas. Node speed of 300kmph equals 0 >>> if the coverage is very large. >> >> This is a good point. Perhaps the proper quantity of interest is >> the average transition time through the range of coverage from a >> neighboring node. >> >>> >>> Node speed of 300kmph going through a 50m wifi area - ok, no >>> DHCP: but then one wonders _why_ would a car need to communicate >>> anything through that 50m wifi area. >> >> I personally think this is a great idea, if for instance we had >> WiFi on the streetlamps and freeway dividers. At $1.00 per >> transceiver chip, it's a reasonable alternative! It draws a lot >> less power than the light bulb. >> >>> >>> DHCP or no DHCP... what coverage area? what link layer? >>> >>> DHCP can be very fast. >> >> In order to counter this statement (or, more accurately, show why >> it is not relevant), I would have to go through the exercise -- but >> you had relieved me of that task. >> >> I'm not going to do that unless necessary. >> >> But, roughly speaking, the answer is that you can't have DHCP >> unless you know where the server(s) and the relays are. And when >> the nodes are moving, you don't know. And you can't quote NUD and >> NA as theorems because of the reasons I already outlined in >> previous messages. And even if you could, before long you'd have >> to get some new relay because you need the relay to be local. And >> more than likely your DHCP server will be occasionally partitioned >> into temporary isolation. But then it's back! But the relay is >> gone! And then there's something else to go wrong. But, are _all_ >> nodes relays? But, which server has the state? Or is there just >> one server? But that won't ever work! >> >> Every time I think about it, I just know it's wrong. I do not have >> any belief whatsoever in this theorem. And, with three nodes, >> you'll never see the problem. Never! >> >> Regards, Charlie P. >> >> _______________________________________________ Autoconf mailing >> list Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > From ryuji.wakikawa@gmail.com Sat Oct 24 03:37: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 346953A67AB for ; Sat, 24 Oct 2009 03:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, 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 IfVNTTn45wTZ for ; Sat, 24 Oct 2009 03:37:36 -0700 (PDT) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id EE9893A6767 for ; Sat, 24 Oct 2009 03:37:35 -0700 (PDT) Received: by pwi4 with SMTP id 4so2601538pwi.29 for ; Sat, 24 Oct 2009 03:37:45 -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=6hjfx4qxNvJMKp+KllTDw8RDtjqd05Piz9cnZB8VRY4=; b=NTtmf9u3rlHgNd1YS1fW1YgravsAqHOaQQWn4vV5FTUvbGBtdNjRlg6N2CtFuC8eBc CfBxP7IHajaE8x+om9//C+IQ7BV2X1AgP7RF4tlGlsMumm7V9hTqlCQ5gmV41qcKXoBm XWHnj+uz0KGd4/U1SLWueperPQXuukj7HHcD4= 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=RpyATqD4PZZFI+7vPVfaVEj/9sTXH2Luy/Rm8YcJFNY8XstcyotrFsDxwj1ydMZP+4 7AIxXuE1A1VMHG0gG7l4fqYkYN4jmMEGgvJ3kNjFMZBJTD6oQWuuESzoshBGWyye2n27 SObzAfsTzmNSuQj2djSnlBarLmlmQQltIRzhg= Received: by 10.114.253.24 with SMTP id a24mr17619768wai.201.1256380664994; Sat, 24 Oct 2009 03:37:44 -0700 (PDT) Received: from ?10.0.1.2? (c-98-248-44-75.hsd1.ca.comcast.net [98.248.44.75]) by mx.google.com with ESMTPS id 23sm2028622pzk.8.2009.10.24.03.37.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 24 Oct 2009 03:37:43 -0700 (PDT) From: Ryuji Wakikawa To: Alexandru Petrescu In-Reply-To: <4AE2D53F.9000208@gmail.com> 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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <4AE0DB2A.7090902@gmail.com> <5AA9128C-9931-4793-A750-1916BE56E866@gmail.com> <4AE2D53F.9000208@gmail.com> Message-Id: <366FE0D9-6620-4E59-BF8A-14044FF79B2F@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: Sat, 24 Oct 2009 03:37:41 -0700 X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] [warning -- weeks old mail under discussion] Re: 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: Sat, 24 Oct 2009 10:37:37 -0000 Hi Alex, On 2009/10/24, at 3:21, Alexandru Petrescu wrote: > Ryuji Wakikawa a =E9crit : >> Hi Alex, >> On 2009/10/22, at 15:22, Alexandru Petrescu wrote: >>> Charles E. Perkins a =E9crit : >>> [...] >>>>>> Ten or more neighbors, moving at any reasonable speed, and your >>>>>> design is toast -- DHCP or no DHCP. >>>>> Charles - "speed" as we tend to interpret it may have no sense =20 >>>>> when >>>>> we consider coverage areas. Node speed of 300kmph equals 0 if the >>>>> coverage is very large. >>>> This is a good point. Perhaps the proper quantity of interest is =20= >>>> the >>>> average transition time through the range of coverage from a >>>> neighboring node. >>> >>> Average transition time (ATT) through some coverage sounds more =20 >>> tempting than simply "speed". >>> >>> So a vehicle would have an ATT of 3.6seconds (50kmph, 50m wifi). >>> >>> 3.6s is enough to perform DHCP and many other things. >> If you assume wifi, this is not true. You exclude the wireless =20 >> discovery/association time (L2 processing). > > No, I dont exclude the L2 processing. There are L2 attachment =20 > implementations which take shorter time than others. Ok, but not all implementation can have this feature, right? AUTOCONF cannot mandate this implementation to any WiFi user. > There are 2, 4 or 6 wifi L2 messages (depending if security is used) =20= > for discovery and the L2 discovery phase can be very fast for some =20 > implementations. > > It pretty much depends on the implementation of the L2 Client's =20 > waiting timers, the ESSID unniqueness among APs, the Client's =20 > knowledge of MAC address of AP based on location information (GPS), =20= > the use of which L2 security mechanism, the use of AP mode or adhoc =20= > mode. How can we make sure all MANET routers are configured with these =20 setting? > >> You will not get DHCP offer from the server in this case. This is =20 >> reality. > > There are implementations and implementations of this. > > Some are shorter than others. When I did fast handovers (without =20 > FMIP) I could have handovers wifi L2 in the orders of tens of =20 > milliseconds, under some circumstances; discovery included. again, we cannot assume one specific example for addressing =20 requirements. We suppose to deliver a addressing model for MANET, but not for MANET =20= under specific environment with specific implementation. ryuji > > Alex > >> ryuji >>> >>>>> Node speed of 300kmph going through a 50m wifi area - ok, no DHCP: >>>>> but then one wonders _why_ would a car need to communicate =20 >>>>> anything >>>>> through that 50m wifi area. >>>> I personally think this is a great idea, if for instance we had =20 >>>> WiFi >>>> on the streetlamps and freeway dividers. >>> >>> It could work for certain values of ATT, I am sure. >>> >>>> At $1.00 per transceiver chip, it's a reasonable alternative! It >>>> draws a lot less power than the light bulb. >>> > >>>>> DHCP or no DHCP... what coverage area? what link layer? >>>>> DHCP can be very fast. >>>> In order to counter this statement (or, more accurately, show why =20= >>>> it >>>> is not relevant), I would have to go through the exercise -- but =20= >>>> you >>>> had relieved me of that task. >>> >>> I know why people say DHCP is slow. I've measured it. There are =20= >>> quirks with some implementations of the timers. It's mostly in =20 >>> the discovery phase. It's the same fundamental reasons why some =20 >>> people complain about slow WiFi link-layer handovers, and slow =20 >>> Mobile IP, and slow NUD, slow ND - which I've also measured. >>> >>> Basically one can't do discovery otherwise than emitting and then =20= >>> _waiting_ a pre-defined amount of time. It's the basics of the =20 >>> basics. >>> >>> What one can do is to shorten the time one waits, at the risk of =20 >>> not hearing some things and maybe hitting into someone, or missing =20= >>> the presence of some DHCP Server. >>> >>> AUTOCONF can't propose a discovery mechanism better than the =20 >>> discovery phases of DHCP, ND, and FastBSS. People would have =20 >>> already done it well before. >>> >>>> I'm not going to do that unless necessary. >>>> But, roughly speaking, the answer is that you can't have DHCP =20 >>>> unless >>>> you know where the server(s) and the relays are. >>> >>> Err... yes, more or less. >>> >>> The Client performs a discovery phase, sending first to a =20 >>> predefined multicast address and then waiting. >>> >>>> And when the nodes >>>> are moving, you don't know. >>> >>> Well - you do know for some time. >>> >>>> And you can't quote NUD and NA as theorems because of the reasons =20= >>>> I already outlined in previous >>>> messages. And even if you could, before long you'd have to get =20 >>>> some >>>> new relay because you need the relay to be local. And more than >>>> likely your DHCP server will be occasionally partitioned into =20 >>>> temporary isolation. But then it's back! But the relay is gone! >>>> And then there's something else to go wrong. But, are _all_ nodes >>>> relays? But, which server has the state? Or is there just one >>>> server? But that won't ever work! >>>> Every time I think about it, I just know it's wrong. I do not have >>>> any belief whatsoever in this theorem. And, with three nodes, =20 >>>> you'll >>>> never see the problem. Never! >>> >>> Well I look at it as a distributed election problem. Dynamically =20= >>> elect the Servers and the Relays, among them. Of course, =20 >>> afterwards, the elected DHCP Server needs to learn the addresses =20 >>> of the relays and to have routes to them. These issues can be =20 >>> solved by using link-local addresses. >>> >>> This entire mechanism will work during some lapse of time during =20 >>> which the devices are within relatively stable distance. >>> >>> When links start breaking, nodes disappear, other nodes appear - =20 >>> re-execute the entire election process. >>> >>> Now, don't tell me that things move so fast that there is not =20 >>> enough time to deal with re-election: there will always be things =20= >>> which move too fast for whoever and whatever mechanism to break, =20 >>> including whatever AUTOCONF designs. >>> >>> Alex >>> >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf > From ryuji.wakikawa@gmail.com Sat Oct 24 03:45:44 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 0940F3A685B for ; Sat, 24 Oct 2009 03:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 PcbNDcnlMYPZ for ; Sat, 24 Oct 2009 03:45:43 -0700 (PDT) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id E6F203A682B for ; Sat, 24 Oct 2009 03:45:42 -0700 (PDT) Received: by pzk6 with SMTP id 6so1294513pzk.29 for ; Sat, 24 Oct 2009 03:45:50 -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=lRzAuqLPYNx3GN1Nv6hh+rG+bh3l2HQto8TSLGjwTQs=; b=bJpJjkiFzD7tWuAC/fZVT+m54tnrqK77OICvQ3ayKO/ZJe4gjPBC8A0wA+gH2MaVlI +wlDwImAs6BEyYhTQTQE8lgGLZ9Qj8jZgUd96O2M4x3k+ReY4UOAhrvbrhIdqGBBQcIX Fj5PDcqnBISa+TsMbSM6df1hSeTjrBHFBwiOY= 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=V6EzNu0nJXscrWAiwpzO1pjaE/NcjheIxRGO8wX/5ReUEJSKmAu3UUJNMJtrNnVIJr k19rJvkInFGWum02LEFuNu5tulEJ57ZPIPQSnrTZaVYY3om7waT0366Xfe1vBmBB6Imk rp6YR0TxA0u3ffu91ROA0o/KXpFD9+cpj+izw= Received: by 10.114.138.20 with SMTP id l20mr17692548wad.91.1256381150773; Sat, 24 Oct 2009 03:45:50 -0700 (PDT) Received: from ?10.0.1.2? (c-98-248-44-75.hsd1.ca.comcast.net [98.248.44.75]) by mx.google.com with ESMTPS id 21sm911828pzk.11.2009.10.24.03.45.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 24 Oct 2009 03:45:49 -0700 (PDT) From: Ryuji Wakikawa To: Alexandru Petrescu In-Reply-To: <4AE2D5AD.6090701@gmail.com> 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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <4AE2D5AD.6090701@gmail.com> Message-Id: 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: Sat, 24 Oct 2009 03:45:47 -0700 X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] [warning -- weeks old mail under discussion] Re: 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: Sat, 24 Oct 2009 10:45:44 -0000 Hi Alex, On 2009/10/24, at 3:23, Alexandru Petrescu wrote: > Ryuji Wakikawa a =E9crit : >> On 2009/10/22, at 11:43, Charles E. Perkins wrote: >>> >>> Hello Alex, >>> >>> Alexandru Petrescu wrote: >>>> >>>>> First, I don't agree with the often suggested >>>>> assumption that we can rely on MAC addresses >>>>> for uniqueness. Maybe we ought to have a new >>>>> design team or even working group for that, but >>>>> I think such results are usually required to be clearly >>>>> labeled as, for instance, "XXXX over IEEE 802.11" >>>>> or some such. >>>> >>>> Ok, I agree, we should label AUTOCONF as 802.11. >>> >>> Well, you may agree with some other people on that point, >>> but I do not agree with it, and maybe it's time to get some >>> clarity on this point. >> We shouldn't assume 802.11 only. >> I agree with Charlie that MAC addresses uniqueness is not sufficient. >> That's what we started the discussion of LL address treatment. >> We cannot guarantee the LL address uniqueness along the current =20 >> IPv6 spec. > > Can you enumerate the problems you've seen in practice of not =20 > assuming this uniqueness? > > I have never seen one. I have never seen DAD reporting duplicates =20 > either. I saw many for home address of MIP at returning home because of =20 implementation's bugs,,, The address duplication can be occurred because of not only the MAC =20 address duplication, but also bugs in the implementation. If your observation is true, RFC4862(2462-bis) can be updated like =20 "DAD is an option". But RFC4862 still mandate DAD. Comparing to wired network, our AUTOCONF environment is a bit severe =20 environment for DAD. Anyway, you and i are too unreliable to report DAD is merely occurred;-) ryuji > Theoretically - yes, DAD was designed in the spirit you talk about. > > Alex > >> A second after DAD, the neighbors can be changed and LL address can =20= >> now be duplicated. >> In some scenarios, this issue might not be applied. However, unless =20= >> there is a case, >> we cannot ignore this issue in AUTOCONF. >> ryuji >>> >>>>> >>>>> So when you quote "theorems" such as DHCP, >>>>> without going to the trouble of verifying the requisite >>>>> preconditions, you are investing confidence in a >>>>> design that would fall apart like a house of cards in >>>>> a windstorm. >>>> >>>> >>>> Hmm... how else is one supposed to make logical argumentations? >>> >>> By making assumptions that are supportable in the >>> area of interest. >>> >>>> >>>> >>>>> Ten or more neighbors, moving at any reasonable speed, >>>>> and your design is toast -- DHCP or no DHCP. >>>> >>>> Charles - "speed" as we tend to interpret it may have no sense =20 >>>> when we consider coverage areas. Node speed of 300kmph equals 0 =20= >>>> if the coverage is very large. >>> >>> This is a good point. Perhaps the proper quantity of interest >>> is the average transition time through the range of coverage >>> from a neighboring node. >>> >>>> >>>> Node speed of 300kmph going through a 50m wifi area - ok, no =20 >>>> DHCP: but then one wonders _why_ would a car need to communicate =20= >>>> anything through that 50m wifi area. >>> >>> I personally think this is a great idea, if for instance we had >>> WiFi on the streetlamps and freeway dividers. At $1.00 >>> per transceiver chip, it's a reasonable alternative! It draws >>> a lot less power than the light bulb. >>> >>>> >>>> DHCP or no DHCP... what coverage area? what link layer? >>>> >>>> DHCP can be very fast. >>> >>> In order to counter this statement (or, more accurately, >>> show why it is not relevant), I would have to go through >>> the exercise -- but you had relieved me of that task. >>> >>> I'm not going to do that unless necessary. >>> >>> But, roughly speaking, the answer is that you can't >>> have DHCP unless you know where the server(s) and >>> the relays are. And when the nodes are moving, you >>> don't know. And you can't quote NUD and NA as >>> theorems because of the reasons I already outlined >>> in previous messages. And even if you could, before >>> long you'd have to get some new relay because you >>> need the relay to be local. And more than likely your >>> DHCP server will be occasionally partitioned into >>> temporary isolation. But then it's back! But the >>> relay is gone! And then there's something else to >>> go wrong. But, are _all_ nodes relays? But, which >>> server has the state? Or is there just one server? >>> But that won't ever work! >>> >>> Every time I think about it, I just know it's wrong. >>> I do not have any belief whatsoever in this theorem. >>> And, with three nodes, you'll never see the problem. >>> Never! >>> >>> Regards, >>> Charlie P. >>> >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf > From alexandru.petrescu@gmail.com Sat Oct 24 03:47: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 5C93D3A69B2 for ; Sat, 24 Oct 2009 03:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.843 X-Spam-Level: X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[AWL=0.406, 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 RZNDRICLE8gc for ; Sat, 24 Oct 2009 03:47:08 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id E7D863A6860 for ; Sat, 24 Oct 2009 03:47:06 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 3716AD480BB; Sat, 24 Oct 2009 12:47:13 +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 0C4B1D48047; Sat, 24 Oct 2009 12:47:10 +0200 (CEST) Message-ID: <4AE2DB2A.7000600@gmail.com> Date: Sat, 24 Oct 2009 12:47:06 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) 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><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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <4AE0DB2A.7090902@gmail.com> <5AA9128C-9931-4793-A750-1916BE56E866@gmail.com> <4AE2D53F.9000208@gmail.com> <366FE0D9-6620-4E59-BF8A-14044FF79B2F@gmail.com> In-Reply-To: <366FE0D9-6620-4E59-BF8A-14044FF79B2F@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091023-0, 23/10/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] [warning -- weeks old mail under discussion] Re: 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: Sat, 24 Oct 2009 10:47:09 -0000 Ryuji Wakikawa a écrit : > Hi Alex, > > On 2009/10/24, at 3:21, Alexandru Petrescu wrote: > >> Ryuji Wakikawa a écrit : >>> Hi Alex, >>> On 2009/10/22, at 15:22, Alexandru Petrescu wrote: >>>> Charles E. Perkins a écrit : >>>> [...] >>>>>>> Ten or more neighbors, moving at any reasonable speed, and your >>>>>>> design is toast -- DHCP or no DHCP. >>>>>> Charles - "speed" as we tend to interpret it may have no sense when >>>>>> we consider coverage areas. Node speed of 300kmph equals 0 if the >>>>>> coverage is very large. >>>>> This is a good point. Perhaps the proper quantity of interest is the >>>>> average transition time through the range of coverage from a >>>>> neighboring node. >>>> >>>> Average transition time (ATT) through some coverage sounds more >>>> tempting than simply "speed". >>>> >>>> So a vehicle would have an ATT of 3.6seconds (50kmph, 50m wifi). >>>> >>>> 3.6s is enough to perform DHCP and many other things. >>> If you assume wifi, this is not true. You exclude the wireless >>> discovery/association time (L2 processing). >> >> No, I dont exclude the L2 processing. There are L2 attachment >> implementations which take shorter time than others. > > Ok, but not all implementation can have this feature, right? > AUTOCONF cannot mandate this implementation to any WiFi user. Right, no it cant. >> There are 2, 4 or 6 wifi L2 messages (depending if security is used) >> for discovery and the L2 discovery phase can be very fast for some >> implementations. >> >> It pretty much depends on the implementation of the L2 Client's >> waiting timers, the ESSID unniqueness among APs, the Client's >> knowledge of MAC address of AP based on location information (GPS), >> the use of which L2 security mechanism, the use of AP mode or adhoc mode. > > > How can we make sure all MANET routers are configured with these setting? I dont know about MANET routers. Non-MANET routers may be configured with _some_ of the features I mentioned above, not all. Only one may suffice to reduce a lot the typical handover time of the non-MANET router. >>> You will not get DHCP offer from the server in this case. This is >>> reality. >> >> There are implementations and implementations of this. >> >> Some are shorter than others. When I did fast handovers (without >> FMIP) I could have handovers wifi L2 in the orders of tens of >> milliseconds, under some circumstances; discovery included. > > again, we cannot assume one specific example for addressing requirements. > We suppose to deliver a addressing model for MANET, but not for MANET > under specific environment with specific implementation. Ok, I understand that, thanks. I will concentrate on non-MANET routers which run under specific environments with specific implementations. Alex > > ryuji > >> >> Alex >> >>> ryuji >>>> >>>>>> Node speed of 300kmph going through a 50m wifi area - ok, no DHCP: >>>>>> but then one wonders _why_ would a car need to communicate anything >>>>>> through that 50m wifi area. >>>>> I personally think this is a great idea, if for instance we had WiFi >>>>> on the streetlamps and freeway dividers. >>>> >>>> It could work for certain values of ATT, I am sure. >>>> >>>>> At $1.00 per transceiver chip, it's a reasonable alternative! It >>>>> draws a lot less power than the light bulb. >>>> > >>>>>> DHCP or no DHCP... what coverage area? what link layer? >>>>>> DHCP can be very fast. >>>>> In order to counter this statement (or, more accurately, show why it >>>>> is not relevant), I would have to go through the exercise -- but you >>>>> had relieved me of that task. >>>> >>>> I know why people say DHCP is slow. I've measured it. There are >>>> quirks with some implementations of the timers. It's mostly in the >>>> discovery phase. It's the same fundamental reasons why some people >>>> complain about slow WiFi link-layer handovers, and slow Mobile IP, >>>> and slow NUD, slow ND - which I've also measured. >>>> >>>> Basically one can't do discovery otherwise than emitting and then >>>> _waiting_ a pre-defined amount of time. It's the basics of the basics. >>>> >>>> What one can do is to shorten the time one waits, at the risk of not >>>> hearing some things and maybe hitting into someone, or missing the >>>> presence of some DHCP Server. >>>> >>>> AUTOCONF can't propose a discovery mechanism better than the >>>> discovery phases of DHCP, ND, and FastBSS. People would have >>>> already done it well before. >>>> >>>>> I'm not going to do that unless necessary. >>>>> But, roughly speaking, the answer is that you can't have DHCP unless >>>>> you know where the server(s) and the relays are. >>>> >>>> Err... yes, more or less. >>>> >>>> The Client performs a discovery phase, sending first to a predefined >>>> multicast address and then waiting. >>>> >>>>> And when the nodes >>>>> are moving, you don't know. >>>> >>>> Well - you do know for some time. >>>> >>>>> And you can't quote NUD and NA as theorems because of the reasons I >>>>> already outlined in previous >>>>> messages. And even if you could, before long you'd have to get some >>>>> new relay because you need the relay to be local. And more than >>>>> likely your DHCP server will be occasionally partitioned into >>>>> temporary isolation. But then it's back! But the relay is gone! >>>>> And then there's something else to go wrong. But, are _all_ nodes >>>>> relays? But, which server has the state? Or is there just one >>>>> server? But that won't ever work! >>>>> Every time I think about it, I just know it's wrong. I do not have >>>>> any belief whatsoever in this theorem. And, with three nodes, you'll >>>>> never see the problem. Never! >>>> >>>> Well I look at it as a distributed election problem. Dynamically >>>> elect the Servers and the Relays, among them. Of course, >>>> afterwards, the elected DHCP Server needs to learn the addresses of >>>> the relays and to have routes to them. These issues can be solved >>>> by using link-local addresses. >>>> >>>> This entire mechanism will work during some lapse of time during >>>> which the devices are within relatively stable distance. >>>> >>>> When links start breaking, nodes disappear, other nodes appear - >>>> re-execute the entire election process. >>>> >>>> Now, don't tell me that things move so fast that there is not enough >>>> time to deal with re-election: there will always be things which >>>> move too fast for whoever and whatever mechanism to break, including >>>> whatever AUTOCONF designs. >>>> >>>> Alex >>>> >>>> _______________________________________________ >>>> Autoconf mailing list >>>> Autoconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/autoconf >> > > From ryuji.wakikawa@gmail.com Sat Oct 24 03:47: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 BF8BC3A69B8 for ; Sat, 24 Oct 2009 03:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 b4JaUr0MYj9r for ; Sat, 24 Oct 2009 03:47:58 -0700 (PDT) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id B7E7F3A69B6 for ; Sat, 24 Oct 2009 03:47:58 -0700 (PDT) Received: by pzk6 with SMTP id 6so1295136pzk.29 for ; Sat, 24 Oct 2009 03:48:07 -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=i56SyurNdW7Jul93103D5ussYZ9+UUg6NDK1obcuhjA=; b=pvLIEGvVYMSmhlTMAAqn0ftnhdl4ObLPEry+bxptW7IBsV8OR+z1MF+Rz2F2CeYKSs yOzr1ARltBdO+Bo19mVH4XBBIiYziWzInCAdWdur+l4W14hWqLFL487msXFP03Gc1n1Q I1Vb/y6WHXrQ9ogaXuiJcD1E3wa6OaJHYmfqY= 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=QiBEsWNmJhG+BIxsfOaIV/7h7RpF4gUQDHEP9COEHe78wggIztR+URYJNtdz7XZ9Kq ARBNh/7TDlesPRD+MHuY5TO/kRYbJLcr5As4k6+UNDgVFzLhpz/X4LgcI4mXtIvnYMeL pFPWd9OejJj+lWbYc7too2y/Twt6WYiGIhJqY= Received: by 10.114.9.2 with SMTP id 2mr7208925wai.197.1256381287892; Sat, 24 Oct 2009 03:48:07 -0700 (PDT) Received: from ?10.0.1.2? (c-98-248-44-75.hsd1.ca.comcast.net [98.248.44.75]) by mx.google.com with ESMTPS id 20sm43070pzk.13.2009.10.24.03.48.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 24 Oct 2009 03:48:06 -0700 (PDT) From: Ryuji Wakikawa To: Alexandru Petrescu In-Reply-To: <4AE2D66B.90208@gmail.com> 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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <4AE2D66B.90208@gmail.com> Message-Id: 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: Sat, 24 Oct 2009 03:48:04 -0700 X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] [warning -- weeks old mail under discussion] Re: 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: Sat, 24 Oct 2009 10:47:59 -0000 On 2009/10/24, at 3:26, Alexandru Petrescu wrote: > Ryuji Wakikawa a =E9crit : >> On 2009/10/22, at 11:43, Charles E. Perkins wrote: >>> Hello Alex, >>> Alexandru Petrescu wrote: >>>>> First, I don't agree with the often suggested assumption that we =20= >>>>> can rely on MAC addresses for uniqueness. Maybe we ought to >>>>> have a new design team or even working group for that, but I =20 >>>>> think such results are usually required to be clearly labeled =20 >>>>> as, for instance, "XXXX over IEEE 802.11" or some such. >>>> Ok, I agree, we should label AUTOCONF as 802.11. >>> Well, you may agree with some other people on that point, but I do =20= >>> not agree with it, and maybe it's time to get some clarity on this =20= >>> point. >> We shouldn't assume 802.11 only. I agree with Charlie that MAC =20 >> addresses uniqueness is not sufficient. That's what we started the =20= >> discussion of LL address treatment. >> We cannot guarantee the LL address uniqueness along the current =20 >> IPv6 spec. A second after DAD, the neighbors can be changed and LL =20= >> address >> can now be duplicated. >> In some scenarios, this issue might not be applied. > > I agree on this point, in the scenario I need this issues does not =20 > apply. > >> However, unless there is a case, we cannot ignore this issue in >> AUTOCONF. > > I can't see what are the implications of this, thus Ill stay silent =20= > about it. Unless there is a scenario where address uniqueness cannot be =20 guaranteed, we cannot ignore the address duplication issue in AUTOCONF. ryuji > > Alex > >> ryuji >>>>> So when you quote "theorems" such as DHCP, without going to the >>>>> trouble of verifying the requisite preconditions, you are =20 >>>>> investing confidence in a design that would fall apart like a =20 >>>>> house of cards in a windstorm. >>>> Hmm... how else is one supposed to make logical argumentations? >>> By making assumptions that are supportable in the area of interest. >>>>> Ten or more neighbors, moving at any reasonable speed, and your >>>>> design is toast -- DHCP or no DHCP. >>>> Charles - "speed" as we tend to interpret it may have no sense =20 >>>> when we consider coverage areas. Node speed of 300kmph equals 0 =20= >>>> if the coverage is very large. >>> This is a good point. Perhaps the proper quantity of interest is =20= >>> the average transition time through the range of coverage from a =20 >>> neighboring node. >>>> Node speed of 300kmph going through a 50m wifi area - ok, no =20 >>>> DHCP: but then one wonders _why_ would a car need to communicate =20= >>>> anything through that 50m wifi area. >>> I personally think this is a great idea, if for instance we had =20 >>> WiFi on the streetlamps and freeway dividers. At $1.00 per =20 >>> transceiver chip, it's a reasonable alternative! It draws a lot =20 >>> less power than the light bulb. >>>> DHCP or no DHCP... what coverage area? what link layer? >>>> DHCP can be very fast. >>> In order to counter this statement (or, more accurately, show why =20= >>> it is not relevant), I would have to go through the exercise -- but >>> you had relieved me of that task. >>> I'm not going to do that unless necessary. >>> But, roughly speaking, the answer is that you can't have DHCP =20 >>> unless you know where the server(s) and the relays are. And when =20= >>> the nodes are moving, you don't know. And you can't quote NUD and =20= >>> NA as theorems because of the reasons I already outlined in =20 >>> previous messages. And even if you could, before long you'd have =20= >>> to get some new relay because you need the relay to be local. And =20= >>> more than likely your DHCP server will be occasionally partitioned =20= >>> into temporary isolation. But then it's back! But the relay is =20 >>> gone! And then there's something else to go wrong. But, are _all_ >>> nodes relays? But, which server has the state? Or is there just =20= >>> one server? But that won't ever work! >>> Every time I think about it, I just know it's wrong. I do not have =20= >>> any belief whatsoever in this theorem. And, with three nodes, =20 >>> you'll never see the problem. Never! >>> Regards, Charlie P. >>> _______________________________________________ Autoconf mailing =20 >>> list Autoconf@ietf.org = https://www.ietf.org/mailman/listinfo/autoconf > From alexandru.petrescu@gmail.com Sat Oct 24 03:52: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 E838A28C10C for ; Sat, 24 Oct 2009 03:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.857 X-Spam-Level: X-Spam-Status: No, score=-1.857 tagged_above=-999 required=5 tests=[AWL=0.392, 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 hM8+vkWJbZRt for ; Sat, 24 Oct 2009 03:52:04 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 865023A67F3 for ; Sat, 24 Oct 2009 03:52:02 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 37282D480FF; Sat, 24 Oct 2009 12:52:09 +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 F3BF5D48098; Sat, 24 Oct 2009 12:52:06 +0200 (CEST) Message-ID: <4AE2DC52.4000306@gmail.com> Date: Sat, 24 Oct 2009 12:52:02 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) 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><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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <4AE2D5AD.6090701@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091023-0, 23/10/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] [warning -- weeks old mail under discussion] Re: 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: Sat, 24 Oct 2009 10:52:06 -0000 Ryuji Wakikawa a écrit : > Hi Alex, > > On 2009/10/24, at 3:23, Alexandru Petrescu wrote: > >> Ryuji Wakikawa a écrit : >>> On 2009/10/22, at 11:43, Charles E. Perkins wrote: >>>> >>>> Hello Alex, >>>> >>>> Alexandru Petrescu wrote: >>>>> >>>>>> First, I don't agree with the often suggested >>>>>> assumption that we can rely on MAC addresses >>>>>> for uniqueness. Maybe we ought to have a new >>>>>> design team or even working group for that, but >>>>>> I think such results are usually required to be clearly >>>>>> labeled as, for instance, "XXXX over IEEE 802.11" >>>>>> or some such. >>>>> >>>>> Ok, I agree, we should label AUTOCONF as 802.11. >>>> >>>> Well, you may agree with some other people on that point, >>>> but I do not agree with it, and maybe it's time to get some >>>> clarity on this point. >>> We shouldn't assume 802.11 only. >>> I agree with Charlie that MAC addresses uniqueness is not sufficient. >>> That's what we started the discussion of LL address treatment. >>> We cannot guarantee the LL address uniqueness along the current IPv6 >>> spec. >> >> Can you enumerate the problems you've seen in practice of not assuming >> this uniqueness? >> >> I have never seen one. I have never seen DAD reporting duplicates >> either. > > I saw many for home address of MIP at returning home because of > implementation's bugs,,, Was that on the link-local address or the global address? > The address duplication can be occurred because of not only the MAC > address duplication, but also bugs in the implementation. > > If your observation is true, RFC4862(2462-bis) can be updated like "DAD > is an option". Sounds logical, but no, it is not my intention. DAD can help. You are against not only DAD but also against LLs. > But RFC4862 still mandate DAD. > Comparing to wired network, our AUTOCONF environment is a bit severe > environment for DAD. Ok. > Anyway, you and i are too unreliable to report DAD is merely occurred;-) :-) Well I have seen DAD in action but I haven't seen it reporting duplicated link-local MAC-derived IPv6 addresses. Thus I think I will stay silent about this, simply shrugging when facing people who may have seen it. Alex > > ryuji > > > > > > > >> Theoretically - yes, DAD was designed in the spirit you talk about. >> >> Alex >> >>> A second after DAD, the neighbors can be changed and LL address can >>> now be duplicated. >>> In some scenarios, this issue might not be applied. However, unless >>> there is a case, >>> we cannot ignore this issue in AUTOCONF. >>> ryuji >>>> >>>>>> >>>>>> So when you quote "theorems" such as DHCP, >>>>>> without going to the trouble of verifying the requisite >>>>>> preconditions, you are investing confidence in a >>>>>> design that would fall apart like a house of cards in >>>>>> a windstorm. >>>>> >>>>> >>>>> Hmm... how else is one supposed to make logical argumentations? >>>> >>>> By making assumptions that are supportable in the >>>> area of interest. >>>> >>>>> >>>>> >>>>>> Ten or more neighbors, moving at any reasonable speed, >>>>>> and your design is toast -- DHCP or no DHCP. >>>>> >>>>> Charles - "speed" as we tend to interpret it may have no sense when >>>>> we consider coverage areas. Node speed of 300kmph equals 0 if the >>>>> coverage is very large. >>>> >>>> This is a good point. Perhaps the proper quantity of interest >>>> is the average transition time through the range of coverage >>>> from a neighboring node. >>>> >>>>> >>>>> Node speed of 300kmph going through a 50m wifi area - ok, no DHCP: >>>>> but then one wonders _why_ would a car need to communicate anything >>>>> through that 50m wifi area. >>>> >>>> I personally think this is a great idea, if for instance we had >>>> WiFi on the streetlamps and freeway dividers. At $1.00 >>>> per transceiver chip, it's a reasonable alternative! It draws >>>> a lot less power than the light bulb. >>>> >>>>> >>>>> DHCP or no DHCP... what coverage area? what link layer? >>>>> >>>>> DHCP can be very fast. >>>> >>>> In order to counter this statement (or, more accurately, >>>> show why it is not relevant), I would have to go through >>>> the exercise -- but you had relieved me of that task. >>>> >>>> I'm not going to do that unless necessary. >>>> >>>> But, roughly speaking, the answer is that you can't >>>> have DHCP unless you know where the server(s) and >>>> the relays are. And when the nodes are moving, you >>>> don't know. And you can't quote NUD and NA as >>>> theorems because of the reasons I already outlined >>>> in previous messages. And even if you could, before >>>> long you'd have to get some new relay because you >>>> need the relay to be local. And more than likely your >>>> DHCP server will be occasionally partitioned into >>>> temporary isolation. But then it's back! But the >>>> relay is gone! And then there's something else to >>>> go wrong. But, are _all_ nodes relays? But, which >>>> server has the state? Or is there just one server? >>>> But that won't ever work! >>>> >>>> Every time I think about it, I just know it's wrong. >>>> I do not have any belief whatsoever in this theorem. >>>> And, with three nodes, you'll never see the problem. >>>> Never! >>>> >>>> Regards, >>>> Charlie P. >>>> >>>> _______________________________________________ >>>> Autoconf mailing list >>>> Autoconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/autoconf >> > > From ryuji.wakikawa@gmail.com Sat Oct 24 03:55: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 614BA28C14A for ; Sat, 24 Oct 2009 03:55:37 -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 qvAPGdwP7B1E for ; Sat, 24 Oct 2009 03:55:36 -0700 (PDT) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 30A1928C146 for ; Sat, 24 Oct 2009 03:55:36 -0700 (PDT) Received: by pwi4 with SMTP id 4so2605383pwi.29 for ; Sat, 24 Oct 2009 03:55:45 -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=QQdcqAMjEBL5cLYEik3IjrAuMkAL4/3x6wvgN1P1uGM=; b=YyEI//paEu7Ug59laBtwGpxCmK2Y8BY6GnX0XTvxMViVK3Rgd7rRQgIJ4+tw/hF/EL HAYy6wF9FVbfNxorfvaViEgj0AKE69xstIcmd1Rl3TM3HJtXKpkrb2KItmMZOI5o4eMi wvVo9IbtqQ7VMocvn3vaC908MesfJK+Q3F0+Q= 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=V0S3nh67vJTLo1al8RNK2vHNVR+fVZ1lUMvBuRlvPBbBThXtOlD0Msaa4IBns/Bt0k cXoKiIrk6nNXNAmzqVcc82SJJk036UnWEXT8ghZPtVoSpENg2pr/Tib9jUe3k0Kur8W8 ac2axhH3Fhss4oJS49ikyeJ/e7whtpOSwRic8= Received: by 10.115.66.9 with SMTP id t9mr7779891wak.56.1256381745157; Sat, 24 Oct 2009 03:55:45 -0700 (PDT) Received: from ?10.0.1.2? (c-98-248-44-75.hsd1.ca.comcast.net [98.248.44.75]) by mx.google.com with ESMTPS id 23sm2042212pzk.8.2009.10.24.03.55.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 24 Oct 2009 03:55:44 -0700 (PDT) From: Ryuji Wakikawa To: Alexandru Petrescu In-Reply-To: <4AE2DB2A.7000600@gmail.com> 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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <4AE0DB2A.7090902@gmail.com> <5AA9128C-9931-4793-A750-1916BE56E866@gmail.com> <4AE2D53F.9000208@gmail.com> <366FE0D9-6620-4E59-BF8A-14044FF79B2F@gmail.com> <4AE2DB2A.7000600@gmail.com> Message-Id: <373786A1-8757-42CF-9934-BBF107505B23@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: Sat, 24 Oct 2009 03:55:41 -0700 X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] [warning -- weeks old mail under discussion] Re: 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: Sat, 24 Oct 2009 10:55:37 -0000 Hi Alex, On 2009/10/24, at 3:47, Alexandru Petrescu wrote: > Ryuji Wakikawa a =E9crit : >> Hi Alex, >> On 2009/10/24, at 3:21, Alexandru Petrescu wrote: >>> Ryuji Wakikawa a =E9crit : >>>> Hi Alex, >>>> On 2009/10/22, at 15:22, Alexandru Petrescu wrote: >>>>> Charles E. Perkins a =E9crit : >>>>> [...] >>>>>>>> Ten or more neighbors, moving at any reasonable speed, and your >>>>>>>> design is toast -- DHCP or no DHCP. >>>>>>> Charles - "speed" as we tend to interpret it may have no sense =20= >>>>>>> when >>>>>>> we consider coverage areas. Node speed of 300kmph equals 0 if =20= >>>>>>> the >>>>>>> coverage is very large. >>>>>> This is a good point. Perhaps the proper quantity of interest =20= >>>>>> is the >>>>>> average transition time through the range of coverage from a >>>>>> neighboring node. >>>>> >>>>> Average transition time (ATT) through some coverage sounds more =20= >>>>> tempting than simply "speed". >>>>> >>>>> So a vehicle would have an ATT of 3.6seconds (50kmph, 50m wifi). >>>>> >>>>> 3.6s is enough to perform DHCP and many other things. >>>> If you assume wifi, this is not true. You exclude the wireless =20 >>>> discovery/association time (L2 processing). >>> >>> No, I dont exclude the L2 processing. There are L2 attachment =20 >>> implementations which take shorter time than others. >> Ok, but not all implementation can have this feature, right? >> AUTOCONF cannot mandate this implementation to any WiFi user. > > Right, no it cant. > >>> There are 2, 4 or 6 wifi L2 messages (depending if security is =20 >>> used) for discovery and the L2 discovery phase can be very fast =20 >>> for some implementations. >>> >>> It pretty much depends on the implementation of the L2 Client's =20 >>> waiting timers, the ESSID unniqueness among APs, the Client's =20 >>> knowledge of MAC address of AP based on location information =20 >>> (GPS), the use of which L2 security mechanism, the use of AP mode =20= >>> or adhoc mode. >> How can we make sure all MANET routers are configured with these =20 >> setting? > > I dont know about MANET routers. > > Non-MANET routers may be configured with _some_ of the features I =20 > mentioned above, not all. Only one may suffice to reduce a lot the =20= > typical handover time of the non-MANET router. fine. This is your network. You have all control. > >>>> You will not get DHCP offer from the server in this case. This is =20= >>>> reality. >>> >>> There are implementations and implementations of this. >>> >>> Some are shorter than others. When I did fast handovers (without =20= >>> FMIP) I could have handovers wifi L2 in the orders of tens of =20 >>> milliseconds, under some circumstances; discovery included. >> again, we cannot assume one specific example for addressing =20 >> requirements. >> We suppose to deliver a addressing model for MANET, but not for =20 >> MANET under specific environment with specific implementation. > > Ok, I understand that, thanks. I will concentrate on non-MANET =20 > routers which run under specific environments with specific =20 > implementations. Please understand the addressing model draft is not written only for =20 your environment. The addressing model will be applied to any MANETs. If you want to have your own addressing model, please write up an =20 internet-draft which title may be "MANET addressing model extension for Alex's =20 network". With your draft, we can have better understanding of your scenario and =20= improve your draft. However, unfortunately, AUTOCONF WG is not yet at that stage. We still =20= build the one generic addressing model for MANET. Once we finish the addressing model, you should propose a WG item to =20 define your addressing model. make sense? regards, ryuji > > Alex > >> ryuji >>> >>> Alex >>> >>>> ryuji >>>>> >>>>>>> Node speed of 300kmph going through a 50m wifi area - ok, no =20 >>>>>>> DHCP: >>>>>>> but then one wonders _why_ would a car need to communicate =20 >>>>>>> anything >>>>>>> through that 50m wifi area. >>>>>> I personally think this is a great idea, if for instance we had =20= >>>>>> WiFi >>>>>> on the streetlamps and freeway dividers. >>>>> >>>>> It could work for certain values of ATT, I am sure. >>>>> >>>>>> At $1.00 per transceiver chip, it's a reasonable alternative! It >>>>>> draws a lot less power than the light bulb. >>>>> > >>>>>>> DHCP or no DHCP... what coverage area? what link layer? >>>>>>> DHCP can be very fast. >>>>>> In order to counter this statement (or, more accurately, show =20 >>>>>> why it >>>>>> is not relevant), I would have to go through the exercise -- =20 >>>>>> but you >>>>>> had relieved me of that task. >>>>> >>>>> I know why people say DHCP is slow. I've measured it. There =20 >>>>> are quirks with some implementations of the timers. It's mostly =20= >>>>> in the discovery phase. It's the same fundamental reasons why =20 >>>>> some people complain about slow WiFi link-layer handovers, and =20 >>>>> slow Mobile IP, and slow NUD, slow ND - which I've also measured. >>>>> >>>>> Basically one can't do discovery otherwise than emitting and =20 >>>>> then _waiting_ a pre-defined amount of time. It's the basics of =20= >>>>> the basics. >>>>> >>>>> What one can do is to shorten the time one waits, at the risk of =20= >>>>> not hearing some things and maybe hitting into someone, or =20 >>>>> missing the presence of some DHCP Server. >>>>> >>>>> AUTOCONF can't propose a discovery mechanism better than the =20 >>>>> discovery phases of DHCP, ND, and FastBSS. People would have =20 >>>>> already done it well before. >>>>> >>>>>> I'm not going to do that unless necessary. >>>>>> But, roughly speaking, the answer is that you can't have DHCP =20 >>>>>> unless >>>>>> you know where the server(s) and the relays are. >>>>> >>>>> Err... yes, more or less. >>>>> >>>>> The Client performs a discovery phase, sending first to a =20 >>>>> predefined multicast address and then waiting. >>>>> >>>>>> And when the nodes >>>>>> are moving, you don't know. >>>>> >>>>> Well - you do know for some time. >>>>> >>>>>> And you can't quote NUD and NA as theorems because of the =20 >>>>>> reasons I already outlined in previous >>>>>> messages. And even if you could, before long you'd have to get =20= >>>>>> some >>>>>> new relay because you need the relay to be local. And more than >>>>>> likely your DHCP server will be occasionally partitioned into =20 >>>>>> temporary isolation. But then it's back! But the relay is gone! >>>>>> And then there's something else to go wrong. But, are _all_ =20 >>>>>> nodes >>>>>> relays? But, which server has the state? Or is there just one >>>>>> server? But that won't ever work! >>>>>> Every time I think about it, I just know it's wrong. I do not =20 >>>>>> have >>>>>> any belief whatsoever in this theorem. And, with three nodes, =20 >>>>>> you'll >>>>>> never see the problem. Never! >>>>> >>>>> Well I look at it as a distributed election problem. =20 >>>>> Dynamically elect the Servers and the Relays, among them. Of =20 >>>>> course, afterwards, the elected DHCP Server needs to learn the =20 >>>>> addresses of the relays and to have routes to them. These =20 >>>>> issues can be solved by using link-local addresses. >>>>> >>>>> This entire mechanism will work during some lapse of time during =20= >>>>> which the devices are within relatively stable distance. >>>>> >>>>> When links start breaking, nodes disappear, other nodes appear - =20= >>>>> re-execute the entire election process. >>>>> >>>>> Now, don't tell me that things move so fast that there is not =20 >>>>> enough time to deal with re-election: there will always be =20 >>>>> things which move too fast for whoever and whatever mechanism to =20= >>>>> break, including whatever AUTOCONF designs. >>>>> >>>>> Alex >>>>> >>>>> _______________________________________________ >>>>> Autoconf mailing list >>>>> Autoconf@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/autoconf >>> > From alexandru.petrescu@gmail.com Sat Oct 24 03:55:53 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 69BA528C14E for ; Sat, 24 Oct 2009 03:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.87 X-Spam-Level: X-Spam-Status: No, score=-1.87 tagged_above=-999 required=5 tests=[AWL=0.379, 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 eJm1lRNDet7X for ; Sat, 24 Oct 2009 03:55:52 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 4355D28C146 for ; Sat, 24 Oct 2009 03:55:50 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id E5971D480A9; Sat, 24 Oct 2009 12:55:57 +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 ABBB9D48069; Sat, 24 Oct 2009 12:55:54 +0200 (CEST) Message-ID: <4AE2DD36.4090809@gmail.com> Date: Sat, 24 Oct 2009 12:55:50 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) 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><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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <4AE2D66B.90208@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091023-0, 23/10/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] [warning -- weeks old mail under discussion] Re: 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: Sat, 24 Oct 2009 10:55:53 -0000 Ryuji Wakikawa a écrit : > > On 2009/10/24, at 3:26, Alexandru Petrescu wrote: > >> Ryuji Wakikawa a écrit : >>> On 2009/10/22, at 11:43, Charles E. Perkins wrote: >>>> Hello Alex, >>>> Alexandru Petrescu wrote: >>>>>> First, I don't agree with the often suggested assumption that we >>>>>> can rely on MAC addresses for uniqueness. Maybe we ought to >>>>>> have a new design team or even working group for that, but I think >>>>>> such results are usually required to be clearly labeled as, for >>>>>> instance, "XXXX over IEEE 802.11" or some such. >>>>> Ok, I agree, we should label AUTOCONF as 802.11. >>>> Well, you may agree with some other people on that point, but I do >>>> not agree with it, and maybe it's time to get some clarity on this >>>> point. >>> We shouldn't assume 802.11 only. I agree with Charlie that MAC >>> addresses uniqueness is not sufficient. That's what we started the >>> discussion of LL address treatment. >>> We cannot guarantee the LL address uniqueness along the current IPv6 >>> spec. A second after DAD, the neighbors can be changed and LL address >>> can now be duplicated. >>> In some scenarios, this issue might not be applied. >> >> I agree on this point, in the scenario I need this issues does not apply. >> >>> However, unless there is a case, we cannot ignore this issue in >>> AUTOCONF. >> >> I can't see what are the implications of this, thus Ill stay silent >> about it. > > Unless there is a scenario where address uniqueness cannot be guaranteed, > we cannot ignore the address duplication issue in AUTOCONF. Yes, there are scenarios where the uniqueness use of IPv6 link-locals is guaranteed: wifi and non-MANET routers. I dont request to avoid DAD operation on them. But most of the time the uniqueness _is_ guqrqnteed. "Non-MANET" routers is also what the AUTOCONF Charter calls "ad hoc-unaware parts". I could use this term instead. Alex > > ryuji > > >> >> Alex >> >>> ryuji >>>>>> So when you quote "theorems" such as DHCP, without going to the >>>>>> trouble of verifying the requisite preconditions, you are >>>>>> investing confidence in a design that would fall apart like a >>>>>> house of cards in a windstorm. >>>>> Hmm... how else is one supposed to make logical argumentations? >>>> By making assumptions that are supportable in the area of interest. >>>>>> Ten or more neighbors, moving at any reasonable speed, and your >>>>>> design is toast -- DHCP or no DHCP. >>>>> Charles - "speed" as we tend to interpret it may have no sense when >>>>> we consider coverage areas. Node speed of 300kmph equals 0 if the >>>>> coverage is very large. >>>> This is a good point. Perhaps the proper quantity of interest is >>>> the average transition time through the range of coverage from a >>>> neighboring node. >>>>> Node speed of 300kmph going through a 50m wifi area - ok, no DHCP: >>>>> but then one wonders _why_ would a car need to communicate anything >>>>> through that 50m wifi area. >>>> I personally think this is a great idea, if for instance we had WiFi >>>> on the streetlamps and freeway dividers. At $1.00 per transceiver >>>> chip, it's a reasonable alternative! It draws a lot less power than >>>> the light bulb. >>>>> DHCP or no DHCP... what coverage area? what link layer? >>>>> DHCP can be very fast. >>>> In order to counter this statement (or, more accurately, show why it >>>> is not relevant), I would have to go through the exercise -- but >>>> you had relieved me of that task. >>>> I'm not going to do that unless necessary. >>>> But, roughly speaking, the answer is that you can't have DHCP unless >>>> you know where the server(s) and the relays are. And when the nodes >>>> are moving, you don't know. And you can't quote NUD and NA as >>>> theorems because of the reasons I already outlined in previous >>>> messages. And even if you could, before long you'd have to get some >>>> new relay because you need the relay to be local. And more than >>>> likely your DHCP server will be occasionally partitioned into >>>> temporary isolation. But then it's back! But the relay is gone! >>>> And then there's something else to go wrong. But, are _all_ >>>> nodes relays? But, which server has the state? Or is there just >>>> one server? But that won't ever work! >>>> Every time I think about it, I just know it's wrong. I do not have >>>> any belief whatsoever in this theorem. And, with three nodes, you'll >>>> never see the problem. Never! >>>> Regards, Charlie P. >>>> _______________________________________________ Autoconf mailing >>>> list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf >> > > From ryuji.wakikawa@gmail.com Sat Oct 24 04:00:34 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 C745028C117 for ; Sat, 24 Oct 2009 04:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 SVgvIitRgJ1U for ; Sat, 24 Oct 2009 04:00:33 -0700 (PDT) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 95D343A6767 for ; Sat, 24 Oct 2009 04:00:33 -0700 (PDT) Received: by pzk6 with SMTP id 6so1298731pzk.29 for ; Sat, 24 Oct 2009 04:00:41 -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=waETQCjmka5uaTsRtYE9CTGc4hx1B5c1dyhDzH4qy3M=; b=w4CMz27AYUGPSsfE+gfvg4eT/2j3ZIhf1v8fvgf06C9HXvVtBy1Egk+/p3WsekcyhY WKQBTaOBK544AgiWWWfhSb0VIqWbh3UIzMFPuaEaz51wetCm37C4b+owK8IAAM2FHSLf juaqTocmuj9dvR20rbGyq9A7Bg2PLDsCyuLlY= 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=p5jiKHP3JXfGxPYFqludgcGB6lSdxSUqFBD/geO18qHnqKZOhFfdVXPM446h4Stw+1 y9snnJDZU9O4Dne3HlV7Kp7ChcKkTXz7rocMqVlIPq3ndNbXVxlD3WObirkxgo7UG4C/ V9E1JdoBYjKll2v/GGQKMdTM/ZORXOTYMF5zg= Received: by 10.114.3.29 with SMTP id 29mr17568025wac.208.1256382040992; Sat, 24 Oct 2009 04:00:40 -0700 (PDT) Received: from ?10.0.1.2? (c-98-248-44-75.hsd1.ca.comcast.net [98.248.44.75]) by mx.google.com with ESMTPS id 21sm905461pzk.3.2009.10.24.04.00.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 24 Oct 2009 04:00:38 -0700 (PDT) From: Ryuji Wakikawa To: Alexandru Petrescu In-Reply-To: <4AE2DC52.4000306@gmail.com> 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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <4AE2D5AD.6090701@gmail.com> <4AE2DC52.4000306@gmail.com> Message-Id: <0DDB887F-ADC9-4955-8366-A630FB20DC25@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: Sat, 24 Oct 2009 04:00:35 -0700 X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] [warning -- weeks old mail under discussion] Re: 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: Sat, 24 Oct 2009 11:00:34 -0000 Hi Alex, On 2009/10/24, at 3:52, Alexandru Petrescu wrote: > Ryuji Wakikawa a =E9crit : >> Hi Alex, >> On 2009/10/24, at 3:23, Alexandru Petrescu wrote: >>> Ryuji Wakikawa a =E9crit : >>>> On 2009/10/22, at 11:43, Charles E. Perkins wrote: >>>>> >>>>> Hello Alex, >>>>> >>>>> Alexandru Petrescu wrote: >>>>>> >>>>>>> First, I don't agree with the often suggested >>>>>>> assumption that we can rely on MAC addresses >>>>>>> for uniqueness. Maybe we ought to have a new >>>>>>> design team or even working group for that, but >>>>>>> I think such results are usually required to be clearly >>>>>>> labeled as, for instance, "XXXX over IEEE 802.11" >>>>>>> or some such. >>>>>> >>>>>> Ok, I agree, we should label AUTOCONF as 802.11. >>>>> >>>>> Well, you may agree with some other people on that point, >>>>> but I do not agree with it, and maybe it's time to get some >>>>> clarity on this point. >>>> We shouldn't assume 802.11 only. >>>> I agree with Charlie that MAC addresses uniqueness is not =20 >>>> sufficient. >>>> That's what we started the discussion of LL address treatment. >>>> We cannot guarantee the LL address uniqueness along the current =20 >>>> IPv6 spec. >>> >>> Can you enumerate the problems you've seen in practice of not =20 >>> assuming this uniqueness? >>> >>> I have never seen one. I have never seen DAD reporting duplicates =20= >>> either. >> I saw many for home address of MIP at returning home because of =20 >> implementation's bugs,,, > > Was that on the link-local address or the global address? both in many times. I really had hard time to implement the returning =20= home on BSD (it was timing sensitive and my poor implementation skill!) > >> The address duplication can be occurred because of not only the MAC =20= >> address duplication, but also bugs in the implementation. >> If your observation is true, RFC4862(2462-bis) can be updated like =20= >> "DAD is an option". > > Sounds logical, but no, it is not my intention. DAD can help. > > You are against not only DAD but also against LLs. > >> But RFC4862 still mandate DAD. >> Comparing to wired network, our AUTOCONF environment is a bit =20 >> severe environment for DAD. > > Ok. > >> Anyway, you and i are too unreliable to report DAD is merely =20 >> occurred;-) > > :-) > > Well I have seen DAD in action but I haven't seen it reporting =20 > duplicated link-local MAC-derived IPv6 addresses. Thus I think I =20 > will stay silent about this, simply shrugging when facing people who =20= > may have seen it. This is not AUTOCONF specific argument, more IPv6 general matter. The point is that AUTOCONF WG cannot ignore the IPv6 required =20 functionalities specially for AUTOCONF without any reason. (well, =20 reason we haven't seen the duplication before). thanks ryuji > > Alex > >> ryuji >>> Theoretically - yes, DAD was designed in the spirit you talk about. >>> >>> Alex >>> >>>> A second after DAD, the neighbors can be changed and LL address =20 >>>> can now be duplicated. >>>> In some scenarios, this issue might not be applied. However, =20 >>>> unless there is a case, >>>> we cannot ignore this issue in AUTOCONF. >>>> ryuji >>>>> >>>>>>> >>>>>>> So when you quote "theorems" such as DHCP, >>>>>>> without going to the trouble of verifying the requisite >>>>>>> preconditions, you are investing confidence in a >>>>>>> design that would fall apart like a house of cards in >>>>>>> a windstorm. >>>>>> >>>>>> >>>>>> Hmm... how else is one supposed to make logical argumentations? >>>>> >>>>> By making assumptions that are supportable in the >>>>> area of interest. >>>>> >>>>>> >>>>>> >>>>>>> Ten or more neighbors, moving at any reasonable speed, >>>>>>> and your design is toast -- DHCP or no DHCP. >>>>>> >>>>>> Charles - "speed" as we tend to interpret it may have no sense =20= >>>>>> when we consider coverage areas. Node speed of 300kmph equals =20= >>>>>> 0 if the coverage is very large. >>>>> >>>>> This is a good point. Perhaps the proper quantity of interest >>>>> is the average transition time through the range of coverage >>>>> from a neighboring node. >>>>> >>>>>> >>>>>> Node speed of 300kmph going through a 50m wifi area - ok, no =20 >>>>>> DHCP: but then one wonders _why_ would a car need to =20 >>>>>> communicate anything through that 50m wifi area. >>>>> >>>>> I personally think this is a great idea, if for instance we had >>>>> WiFi on the streetlamps and freeway dividers. At $1.00 >>>>> per transceiver chip, it's a reasonable alternative! It draws >>>>> a lot less power than the light bulb. >>>>> >>>>>> >>>>>> DHCP or no DHCP... what coverage area? what link layer? >>>>>> >>>>>> DHCP can be very fast. >>>>> >>>>> In order to counter this statement (or, more accurately, >>>>> show why it is not relevant), I would have to go through >>>>> the exercise -- but you had relieved me of that task. >>>>> >>>>> I'm not going to do that unless necessary. >>>>> >>>>> But, roughly speaking, the answer is that you can't >>>>> have DHCP unless you know where the server(s) and >>>>> the relays are. And when the nodes are moving, you >>>>> don't know. And you can't quote NUD and NA as >>>>> theorems because of the reasons I already outlined >>>>> in previous messages. And even if you could, before >>>>> long you'd have to get some new relay because you >>>>> need the relay to be local. And more than likely your >>>>> DHCP server will be occasionally partitioned into >>>>> temporary isolation. But then it's back! But the >>>>> relay is gone! And then there's something else to >>>>> go wrong. But, are _all_ nodes relays? But, which >>>>> server has the state? Or is there just one server? >>>>> But that won't ever work! >>>>> >>>>> Every time I think about it, I just know it's wrong. >>>>> I do not have any belief whatsoever in this theorem. >>>>> And, with three nodes, you'll never see the problem. >>>>> Never! >>>>> >>>>> Regards, >>>>> Charlie P. >>>>> >>>>> _______________________________________________ >>>>> Autoconf mailing list >>>>> Autoconf@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/autoconf >>> > From alexandru.petrescu@gmail.com Sat Oct 24 04:12:56 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 9F6073A69B8 for ; Sat, 24 Oct 2009 04:12:56 -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.367, 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 kzKfcJ9IXvL8 for ; Sat, 24 Oct 2009 04:12:55 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 6EF1A3A67CF for ; Sat, 24 Oct 2009 04:12:53 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 1BFE9D48096; Sat, 24 Oct 2009 13:13:00 +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 D8435D4801C; Sat, 24 Oct 2009 13:12:57 +0200 (CEST) Message-ID: <4AE2E135.4020709@gmail.com> Date: Sat, 24 Oct 2009 13:12:53 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ryuji Wakikawa References: <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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <4AE0DB2A.7090902@gmail.com> <5AA9128C-9931-4793-A750-1916BE56E866@gmail.com> <4AE2D53F.9000208@gmail.com> <366FE0D9-6620-4E59-BF8A-14044FF79B2F@gmail.com> <4AE2DB2A.7000600@gmail.com> <373786A1-8757-42CF-9934-BBF107505B23@gmail.com> In-Reply-To: <373786A1-8757-42CF-9934-BBF107505B23@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 091023-0, 23/10/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] [warning -- weeks old mail under discussion] Re: 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: Sat, 24 Oct 2009 11:12:56 -0000 [...] :-) > However, unfortunately, AUTOCONF WG is not yet at that stage. We still > build the one generic addressing model for MANET. Dont forget to not disturb the adhoc unaware parts of the system (which AUTOCONF Charter promisses to do). Unrecommending the LLs is to disturb the adhoc unaware parts of the system, as exposed by the Carlos draft and by 4 people support of it. Do you think an adhoc unaware router attaching to the MANET network will be happy to have its DAD's requests unreplied? > Once we finish the addressing model, you should propose a WG item to > define your addressing model. > > make sense? The AUTOCONF addressing model should be finished, yes. Once it's finished I wont go against it with _my_ addressing model. I can live without publishing an experimental RFC. Alex > > regards, > ryuji > > > > > >> >> Alex >> >>> ryuji >>>> >>>> Alex >>>> >>>>> ryuji >>>>>> >>>>>>>> Node speed of 300kmph going through a 50m wifi area - ok, no DHCP: >>>>>>>> but then one wonders _why_ would a car need to communicate anything >>>>>>>> through that 50m wifi area. >>>>>>> I personally think this is a great idea, if for instance we had WiFi >>>>>>> on the streetlamps and freeway dividers. >>>>>> >>>>>> It could work for certain values of ATT, I am sure. >>>>>> >>>>>>> At $1.00 per transceiver chip, it's a reasonable alternative! It >>>>>>> draws a lot less power than the light bulb. >>>>>> > >>>>>>>> DHCP or no DHCP... what coverage area? what link layer? >>>>>>>> DHCP can be very fast. >>>>>>> In order to counter this statement (or, more accurately, show why it >>>>>>> is not relevant), I would have to go through the exercise -- but you >>>>>>> had relieved me of that task. >>>>>> >>>>>> I know why people say DHCP is slow. I've measured it. There are >>>>>> quirks with some implementations of the timers. It's mostly in >>>>>> the discovery phase. It's the same fundamental reasons why some >>>>>> people complain about slow WiFi link-layer handovers, and slow >>>>>> Mobile IP, and slow NUD, slow ND - which I've also measured. >>>>>> >>>>>> Basically one can't do discovery otherwise than emitting and then >>>>>> _waiting_ a pre-defined amount of time. It's the basics of the >>>>>> basics. >>>>>> >>>>>> What one can do is to shorten the time one waits, at the risk of >>>>>> not hearing some things and maybe hitting into someone, or missing >>>>>> the presence of some DHCP Server. >>>>>> >>>>>> AUTOCONF can't propose a discovery mechanism better than the >>>>>> discovery phases of DHCP, ND, and FastBSS. People would have >>>>>> already done it well before. >>>>>> >>>>>>> I'm not going to do that unless necessary. >>>>>>> But, roughly speaking, the answer is that you can't have DHCP unless >>>>>>> you know where the server(s) and the relays are. >>>>>> >>>>>> Err... yes, more or less. >>>>>> >>>>>> The Client performs a discovery phase, sending first to a >>>>>> predefined multicast address and then waiting. >>>>>> >>>>>>> And when the nodes >>>>>>> are moving, you don't know. >>>>>> >>>>>> Well - you do know for some time. >>>>>> >>>>>>> And you can't quote NUD and NA as theorems because of the reasons >>>>>>> I already outlined in previous >>>>>>> messages. And even if you could, before long you'd have to get some >>>>>>> new relay because you need the relay to be local. And more than >>>>>>> likely your DHCP server will be occasionally partitioned into >>>>>>> temporary isolation. But then it's back! But the relay is gone! >>>>>>> And then there's something else to go wrong. But, are _all_ nodes >>>>>>> relays? But, which server has the state? Or is there just one >>>>>>> server? But that won't ever work! >>>>>>> Every time I think about it, I just know it's wrong. I do not have >>>>>>> any belief whatsoever in this theorem. And, with three nodes, you'll >>>>>>> never see the problem. Never! >>>>>> >>>>>> Well I look at it as a distributed election problem. Dynamically >>>>>> elect the Servers and the Relays, among them. Of course, >>>>>> afterwards, the elected DHCP Server needs to learn the addresses >>>>>> of the relays and to have routes to them. These issues can be >>>>>> solved by using link-local addresses. >>>>>> >>>>>> This entire mechanism will work during some lapse of time during >>>>>> which the devices are within relatively stable distance. >>>>>> >>>>>> When links start breaking, nodes disappear, other nodes appear - >>>>>> re-execute the entire election process. >>>>>> >>>>>> Now, don't tell me that things move so fast that there is not >>>>>> enough time to deal with re-election: there will always be things >>>>>> which move too fast for whoever and whatever mechanism to break, >>>>>> including whatever AUTOCONF designs. >>>>>> >>>>>> Alex >>>>>> >>>>>> _______________________________________________ >>>>>> Autoconf mailing list >>>>>> Autoconf@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/autoconf >>>> >> > > From teco@inf-net.nl Sat Oct 24 04:46: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 D742C3A69BC for ; Sat, 24 Oct 2009 04:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.888 X-Spam-Level: X-Spam-Status: No, score=-0.888 tagged_above=-999 required=5 tests=[AWL=0.222, 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 8pjNSWNYYitt for ; Sat, 24 Oct 2009 04:46:34 -0700 (PDT) Received: from CPSMTPM-EML110.kpnxchange.com (cpsmtpm-eml110.kpnxchange.com [195.121.3.14]) by core3.amsl.com (Postfix) with ESMTP id 7804A3A690F for ; Sat, 24 Oct 2009 04:46:33 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML110.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Sat, 24 Oct 2009 13:46:44 +0200 From: "Teco Boot" To: "'Ryuji Wakikawa'" , 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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <4AE2D5AD.6090701@gmail.com> In-Reply-To: Date: Sat, 24 Oct 2009 13:46:44 +0200 Message-ID: <001501ca549f$a9015310$fb03f930$@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: AcpUlznMjPb+fmVXROSbbhF5qhddUQAAJR4A Content-Language: nl X-OriginalArrivalTime: 24 Oct 2009 11:46:44.0322 (UTC) FILETIME=[A8DF4C20:01CA549F] Subject: [Autoconf] DAD, link-locals, two drafts and making up my mind 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: Sat, 24 Oct 2009 11:46:36 -0000 >Van: Ryuji Wakikawa >If your observation is true, RFC4862(2462-bis) can be updated like >"DAD is an option". >But RFC4862 still mandate DAD. Hi Ryuji, all, I have asked some pertinent questions to this workgroup about DAD. Until now, I didn't see answers. What I see is more and more confusion. Please confirm that: 1: DAD is not for link-local addresses only =========================================== DAD MUST run for all types of unicast addresses [RFC 4862, page 12-13]. In reality, it is not a MUST but a SHOULD. I say so, because there are exceptions [RFC 4862, page 12-13]. It is explicitly mentioned that new implementations MUST NOT do an optimization for performing DAD for link-locals only [RFC 4862 page 13]. 2: DAD may be disabled, in cases overhead outweighs its benefits ================================================================ It is clearly specified that DAD may be disabled [RFC 4862 page 9]. In my opinion, this is the case where bandwidth usage is constrained and InterfaceIDs are highly unique or even guaranteed unique. This is the case in all MANETs I dealt with, and is not restricted to IEEE MAC addresses. Because there is so much misconception on DAD, we fail to make even the smallest progress. I ask the chairs to correct all postings on false statements on what Standards Track RFCs specify. I am not interested in long discussions on DAD. But what I dislike is strong opinions on DAD and link-locals that are based on false assumptions. I continue posting on DAD and link-locals, because I think it is the foundation for IPv6 Stateless Address Autoconfiguration. We need some sort of uniqueness, either for each and every address or for a piece of the address, that is used for all addresses of a box. I think the IPv6 Addressing Architecture [RFC 4291] provides what we need, that is a 64-bits InterfaceID (unicast address start with binary 000) [RFC 4291 page 8]. Having unique InterfaceIDs, we can easily add 64-bit prefixes, either ULA for MANET-local, or border router provided prefixes for attached MANETs. When I read back both proposals for the MANET address model, I see bernardos-autoconf-addressing-model is more complete (no open issues) and better aligns with current Standard Track RFCs. I DO NOT say link-local addresses MUST be used for routing protocols, but it can be very practical, as is clearly shown in running code of OSPF-MANET. Also, there is code of BRDP in simulators that run without problems. I respect other opinions on using link-locals, and I have nothing against weakening mandatory usage of them. The key point here is having unique InterfaceIDs. Using it, we are able to swap prefixes easily. We could define a protocol for detecting duplicate InterfaceIDs in the MANET, this would work for all of us, when needed. I have posted proposals for corrections on the "DT draft". There was low acceptance. I think it doesn't help to resubmit. We have an archive for it. Regards, Teco From alexandru.petrescu@gmail.com Sat Oct 24 05:24: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 47E2C3A6814 for ; Sat, 24 Oct 2009 05:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.356, 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 Lm2zq3S0l5Ou for ; Sat, 24 Oct 2009 05:24:21 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 040653A67A3 for ; Sat, 24 Oct 2009 05:24:19 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 2FA1FD480FB; Sat, 24 Oct 2009 14:24:26 +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 98FCCD48131; Sat, 24 Oct 2009 14:24:23 +0200 (CEST) Message-ID: <4AE2F1F7.6050107@gmail.com> Date: Sat, 24 Oct 2009 14:24:23 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Teco Boot 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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <4AE2D5AD.6090701@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> In-Reply-To: <001501ca549f$a9015310$fb03f930$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091023-0, 23/10/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind 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: Sat, 24 Oct 2009 12:24:22 -0000 Teco Boot a écrit : >> Van: Ryuji Wakikawa >> If your observation is true, RFC4862(2462-bis) can be updated like >> "DAD is an option". >> But RFC4862 still mandate DAD. > > > Hi Ryuji, all, > > I have asked some pertinent questions to this workgroup about DAD. > Until now, I didn't see answers. What I see is more and more confusion. > > Please confirm that: > > 1: DAD is not for link-local addresses only > =========================================== > DAD MUST run for all types of unicast addresses [RFC 4862, page 12-13]. > In reality, it is not a MUST but a SHOULD. I say so, because there are > exceptions [RFC 4862, page 12-13]. > It is explicitly mentioned that new implementations MUST NOT do an > optimization for performing DAD for link-locals only [RFC 4862 page 13]. > > 2: DAD may be disabled, in cases overhead outweighs its benefits > ================================================================ > It is clearly specified that DAD may be disabled [RFC 4862 page 9]. > In my opinion, this is the case where bandwidth usage is constrained > and InterfaceIDs are highly unique or even guaranteed unique. > This is the case in all MANETs I dealt with, and is not restricted to > IEEE MAC addresses. Teco, thanks for digging out this clarification. It's good to have it in one place. Overall, I think we should not unrecommend any stuff (be it LL or DAD) before having comments on this intention from as many people as possible, including why not the 6MAN WG. Alex > > Because there is so much misconception on DAD, we fail to make even the > smallest progress. I ask the chairs to correct all postings on false > statements on what Standards Track RFCs specify. > > > I am not interested in long discussions on DAD. But what I dislike is > strong opinions on DAD and link-locals that are based on false assumptions. > > > I continue posting on DAD and link-locals, because I think it is the > foundation for IPv6 Stateless Address Autoconfiguration. We need > some sort of uniqueness, either for each and every address or for a > piece of the address, that is used for all addresses of a box. I think > the IPv6 Addressing Architecture [RFC 4291] provides what we need, that > is a 64-bits InterfaceID (unicast address start with binary 000) > [RFC 4291 page 8]. Having unique InterfaceIDs, we can easily add 64-bit > prefixes, either ULA for MANET-local, or border router provided prefixes > for attached MANETs. > > > When I read back both proposals for the MANET address model, I see > bernardos-autoconf-addressing-model is more complete (no open issues) > and better aligns with current Standard Track RFCs. I DO NOT say > link-local addresses MUST be used for routing protocols, but it can > be very practical, as is clearly shown in running code of OSPF-MANET. > Also, there is code of BRDP in simulators that run without problems. > I respect other opinions on using link-locals, and I have nothing against > weakening mandatory usage of them. The key point here is having unique > InterfaceIDs. Using it, we are able to swap prefixes easily. We could > define a protocol for detecting duplicate InterfaceIDs in the MANET, > this would work for all of us, when needed. > > > I have posted proposals for corrections on the "DT draft". There was low > acceptance. I think it doesn't help to resubmit. We have an archive for it. > > > Regards, Teco > > > > > > > > > > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From ryuji.wakikawa@gmail.com Sat Oct 24 05:50: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 8CE8D3A6882 for ; Sat, 24 Oct 2009 05:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 IuDb+YwRwJEz for ; Sat, 24 Oct 2009 05:50:46 -0700 (PDT) Received: from mail-px0-f173.google.com (mail-px0-f173.google.com [209.85.216.173]) by core3.amsl.com (Postfix) with ESMTP id 9BEA03A6783 for ; Sat, 24 Oct 2009 05:50:46 -0700 (PDT) Received: by pxi3 with SMTP id 3so929738pxi.29 for ; Sat, 24 Oct 2009 05:50:55 -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=XdVRBTXXKj9uTib5JP/BmNyitStiZANubfAopyL0ZUc=; b=wEyWDF4wHV+0JIHZ5V6DNIDrZGE+3jD7iUk5tcJnlnVbME79Qt5rjFzaavtXGC1D6z lpRM4Ho/fnDHgtd2+LZVzXAtZTVBGBnypufYAYqubA4jxOQwVxvOFT/lE5fDVP5FTCbY 70BJgZMKDY7MApqBsnY0WllNjm6bQOxPISF1k= 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=nzKrhkCYUGr2GfFt9GZFs3hAtD/c8AfREW1X2kxxelHzFlZNSbOG/CEPMxIw0HczKB zXoPyxRdjdoTfvhp3zxcLHmgoTBCRQp4iBn1dI8Te5w9M/A+JGAAXEPYXMAKudY6hhwq WJag/oRP5K/ZyD+BWL+cWaMFwBVL3lls/Hcm4= Received: by 10.115.24.12 with SMTP id b12mr7795269waj.86.1256388655598; Sat, 24 Oct 2009 05:50:55 -0700 (PDT) Received: from ?10.0.1.2? (c-98-248-44-75.hsd1.ca.comcast.net [98.248.44.75]) by mx.google.com with ESMTPS id 23sm280301pxi.5.2009.10.24.05.50.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 24 Oct 2009 05:50:54 -0700 (PDT) From: Ryuji Wakikawa To: Teco Boot In-Reply-To: <001501ca549f$a9015310$fb03f930$@nl> 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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <4AE2D5AD.6090701@gmail.com> <001501ca549f$a9015310$fb03f930$@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: Sat, 24 Oct 2009 05:50:50 -0700 X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind 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: Sat, 24 Oct 2009 12:50:47 -0000 Hi Teco, On 2009/10/24, at 4:46, Teco Boot wrote: >> Van: Ryuji Wakikawa >> If your observation is true, RFC4862(2462-bis) can be updated like >> "DAD is an option". >> But RFC4862 still mandate DAD. > > > Hi Ryuji, all, > > I have asked some pertinent questions to this workgroup about DAD. > Until now, I didn't see answers. What I see is more and more > confusion. > > Please confirm that: > > 1: DAD is not for link-local addresses only > =========================================== > DAD MUST run for all types of unicast addresses [RFC 4862, page > 12-13]. > In reality, it is not a MUST but a SHOULD. I say so, because there are > exceptions [RFC 4862, page 12-13]. > It is explicitly mentioned that new implementations MUST NOT do an > optimization for performing DAD for link-locals only [RFC 4862 page > 13]. DAD is mandatory. The document said "MUST". The exception is for interoperability with older implementations. > 2: DAD may be disabled, in cases overhead outweighs its benefits > ================================================================ > It is clearly specified that DAD may be disabled [RFC 4862 page 9]. > In my opinion, this is the case where bandwidth usage is constrained > and InterfaceIDs are highly unique or even guaranteed unique. > This is the case in all MANETs I dealt with, and is not restricted to > IEEE MAC addresses. fine in your network, but there are other MANETs not having such condition. > Because there is so much misconception on DAD, we fail to make even > the > smallest progress. I ask the chairs to correct all postings on false > statements on what Standards Track RFCs specify. What is the misconception? We cannot fix your issue of the general IPv6 spec. in AUTOCONF WG. > I am not interested in long discussions on DAD. But what I dislike is > strong opinions on DAD and link-locals that are based on false > assumptions. Even you think it's false, that is the current agreement in IETF (according to RFCs). > I continue posting on DAD and link-locals, because I think it is the > foundation for IPv6 Stateless Address Autoconfiguration. We need > some sort of uniqueness, either for each and every address or for a > piece of the address, that is used for all addresses of a box. I think > the IPv6 Addressing Architecture [RFC 4291] provides what we need, > that > is a 64-bits InterfaceID (unicast address start with binary 000) > [RFC 4291 page 8]. Having unique InterfaceIDs, we can easily add 64- > bit > prefixes, either ULA for MANET-local, or border router provided > prefixes > for attached MANETs. > > > When I read back both proposals for the MANET address model, I see > bernardos-autoconf-addressing-model is more complete (no open issues) > and better aligns with current Standard Track RFCs. I DO NOT say > link-local addresses MUST be used for routing protocols, but it can > be very practical, as is clearly shown in running code of OSPF-MANET. AFAIK, this issue was closed at the previous consensus call. We don't open the issue again. Please respect to the consensus in WG. > Also, there is code of BRDP in simulators that run without problems. > I respect other opinions on using link-locals, and I have nothing > against > weakening mandatory usage of them. The key point here is having unique > InterfaceIDs. Using it, we are able to swap prefixes easily. We could > define a protocol for detecting duplicate InterfaceIDs in the MANET, > this would work for all of us, when needed. Your proposal is not what the current IPv6 specs said. In AUTOCONF env, we will face more chances to have address duplication due to topology changes in some scenarios. We cannot ignore these scenarios and relax the DAD for link-local. That was what we had discussed at the previous IETF meeting and conclusion at the previous consensus call. I appreciate if you can follow the WG agreement. regards, ryuji > > I have posted proposals for corrections on the "DT draft". There was > low > acceptance. I think it doesn't help to resubmit. We have an archive > for it. > > > Regards, Teco > > > > > > > > > > > From cjbc@it.uc3m.es Sat Oct 24 06:08: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 D52A43A68B5 for ; Sat, 24 Oct 2009 06:08:35 -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 DdRFKQYrxo0t for ; Sat, 24 Oct 2009 06:08:34 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 5BBA73A68AB for ; Sat, 24 Oct 2009 06:08:34 -0700 (PDT) Received: from [192.168.1.209] (82.159.18.172.dyn.user.ono.com [82.159.18.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id C379572C9D8; Sat, 24 Oct 2009 15:08:43 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Ryuji Wakikawa 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> <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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <4AE2D5AD.6090701@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-mfh77lZXyav9pMGjht5k" Organization: Universidad Carlos III de Madrid Date: Sat, 24 Oct 2009 15:08:46 +0200 Message-Id: <1256389726.5286.65.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16966.007 Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind 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: Sat, 24 Oct 2009 13:08:35 -0000 --=-mfh77lZXyav9pMGjht5k Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable On Sat, 2009-10-24 at 05:50 -0700, Ryuji Wakikawa wrote: > Hi Teco, >=20 > On 2009/10/24, at 4:46, Teco Boot wrote: >=20 > >> Van: Ryuji Wakikawa > >> If your observation is true, RFC4862(2462-bis) can be updated like > >> "DAD is an option". > >> But RFC4862 still mandate DAD. > > > > > > Hi Ryuji, all, > > > > I have asked some pertinent questions to this workgroup about DAD. > > Until now, I didn't see answers. What I see is more and more =20 > > confusion. > > > > Please confirm that: > > > > 1: DAD is not for link-local addresses only > > =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 > > DAD MUST run for all types of unicast addresses [RFC 4862, page =20 > > 12-13]. > > In reality, it is not a MUST but a SHOULD. I say so, because there are > > exceptions [RFC 4862, page 12-13]. > > It is explicitly mentioned that new implementations MUST NOT do an > > optimization for performing DAD for link-locals only [RFC 4862 page =20 > > 13]. >=20 > DAD is mandatory. The document said "MUST". > The exception is for interoperability with older implementations. Or if DupAddrDetectTransmits is set to zero, which I think it is not forbidden by RFC4862. Thanks, Carlos >=20 > > 2: DAD may be disabled, in cases overhead outweighs its benefits > > =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 > > It is clearly specified that DAD may be disabled [RFC 4862 page 9]. > > In my opinion, this is the case where bandwidth usage is constrained > > and InterfaceIDs are highly unique or even guaranteed unique. > > This is the case in all MANETs I dealt with, and is not restricted to > > IEEE MAC addresses. >=20 > fine in your network, but there are other MANETs not having such =20 > condition. >=20 >=20 > > Because there is so much misconception on DAD, we fail to make even =20 > > the > > smallest progress. I ask the chairs to correct all postings on false > > statements on what Standards Track RFCs specify. >=20 > What is the misconception? > We cannot fix your issue of the general IPv6 spec. in AUTOCONF WG. >=20 > > I am not interested in long discussions on DAD. But what I dislike is > > strong opinions on DAD and link-locals that are based on false =20 > > assumptions. >=20 > Even you think it's false, that is the current agreement in IETF =20 > (according to RFCs). >=20 > > I continue posting on DAD and link-locals, because I think it is the > > foundation for IPv6 Stateless Address Autoconfiguration. We need > > some sort of uniqueness, either for each and every address or for a > > piece of the address, that is used for all addresses of a box. I think > > the IPv6 Addressing Architecture [RFC 4291] provides what we need, =20 > > that > > is a 64-bits InterfaceID (unicast address start with binary 000) > > [RFC 4291 page 8]. Having unique InterfaceIDs, we can easily add 64-=20 > > bit > > prefixes, either ULA for MANET-local, or border router provided =20 > > prefixes > > for attached MANETs. > > > > > > When I read back both proposals for the MANET address model, I see > > bernardos-autoconf-addressing-model is more complete (no open issues) > > and better aligns with current Standard Track RFCs. I DO NOT say > > link-local addresses MUST be used for routing protocols, but it can > > be very practical, as is clearly shown in running code of OSPF-MANET. >=20 > AFAIK, this issue was closed at the previous consensus call. > We don't open the issue again. Please respect to the consensus in WG. >=20 > > Also, there is code of BRDP in simulators that run without problems. > > I respect other opinions on using link-locals, and I have nothing =20 > > against > > weakening mandatory usage of them. The key point here is having unique > > InterfaceIDs. Using it, we are able to swap prefixes easily. We could > > define a protocol for detecting duplicate InterfaceIDs in the MANET, > > this would work for all of us, when needed. >=20 > Your proposal is not what the current IPv6 specs said. > In AUTOCONF env, we will face more chances to have address duplication =20 > due to topology changes in some scenarios. > We cannot ignore these scenarios and relax the DAD for link-local. >=20 > That was what we had discussed at the previous IETF meeting and =20 > conclusion at the previous consensus call. > I appreciate if you can follow the WG agreement. >=20 > regards, > ryuji >=20 > > > > I have posted proposals for corrections on the "DT draft". There was =20 > > low > > acceptance. I think it doesn't help to resubmit. We have an archive =20 > > for it. > > > > > > Regards, Teco > > > > > > > > > > > > > > > > > > > > > > >=20 > _______________________________________________ > 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 --=-mfh77lZXyav9pMGjht5k 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) iEYEABECAAYFAkri/F4ACgkQNdy6TdFwT2cblACg0CVU8SQU2/di22rfR/wHbyqv NZ0AoJcHwTpgQbLFnsY3aIfHaQPvsRNE =2mTi -----END PGP SIGNATURE----- --=-mfh77lZXyav9pMGjht5k-- From teco@inf-net.nl Sat Oct 24 06:30:51 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 28E0B3A6831 for ; Sat, 24 Oct 2009 06:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[AWL=0.911, 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 L2yTBp7WgEvf for ; Sat, 24 Oct 2009 06:30:49 -0700 (PDT) Received: from CPSMTPM-EML103.kpnxchange.com (cpsmtpm-eml103.kpnxchange.com [195.121.3.7]) by core3.amsl.com (Postfix) with ESMTP id 0332F3A62C1 for ; Sat, 24 Oct 2009 06:30:48 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML103.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Sat, 24 Oct 2009 15:30:59 +0200 From: "Teco Boot" To: "'Ryuji Wakikawa'" 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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <4AE2D5AD.6090701@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> In-Reply-To: Date: Sat, 24 Oct 2009 15:30:58 +0200 Message-ID: <002301ca54ae$38c99c60$aa5cd520$@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: AcpUqKHX583wNiYxToi8fFhLWwKTqAAAhsQA Content-Language: nl X-OriginalArrivalTime: 24 Oct 2009 13:30:59.0160 (UTC) FILETIME=[390BD580:01CA54AE] Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind 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: Sat, 24 Oct 2009 13:30:51 -0000 Hi Ryuji, >-----Oorspronkelijk bericht----- >Van: Ryuji Wakikawa [mailto:ryuji.wakikawa@gmail.com] >Verzonden: zaterdag 24 oktober 2009 14:51 >Aan: Teco Boot >CC: autoconf@ietf.org >Onderwerp: Re: [Autoconf] DAD, link-locals, two drafts and making up my >mind > >Hi Teco, > >On 2009/10/24, at 4:46, Teco Boot wrote: > >>> Van: Ryuji Wakikawa >>> If your observation is true, RFC4862(2462-bis) can be updated like >>> "DAD is an option". >>> But RFC4862 still mandate DAD. >> >> >> Hi Ryuji, all, >> >> I have asked some pertinent questions to this workgroup about DAD. >> Until now, I didn't see answers. What I see is more and more >> confusion. >> >> Please confirm that: >> >> 1: DAD is not for link-local addresses only >> =========================================== >> DAD MUST run for all types of unicast addresses [RFC 4862, page >> 12-13]. >> In reality, it is not a MUST but a SHOULD. I say so, because there are >> exceptions [RFC 4862, page 12-13]. >> It is explicitly mentioned that new implementations MUST NOT do an >> optimization for performing DAD for link-locals only [RFC 4862 page >> 13]. > >DAD is mandatory. The document said "MUST". >The exception is for interoperability with older implementations. Please confirm that DAD has nothing to do with link-locals. >> 2: DAD may be disabled, in cases overhead outweighs its benefits >> ================================================================ >> It is clearly specified that DAD may be disabled [RFC 4862 page 9]. >> In my opinion, this is the case where bandwidth usage is constrained >> and InterfaceIDs are highly unique or even guaranteed unique. >> This is the case in all MANETs I dealt with, and is not restricted to >> IEEE MAC addresses. > >fine in your network, but there are other MANETs not having such >condition. As far as I know, MANETs struggle with scalability and high overhead. I remember Charlie on saving every bit sent out, at cost of CPU cycles. Above, you are wrong. DAD is a "MUST", but only when the DupAddrDetectTransmits variable is non-zero, not for anycast etc.. I never said I was against a MANET wide duplicate detection. I am against mandating such. >> Because there is so much misconception on DAD, we fail to make even >> the >> smallest progress. I ask the chairs to correct all postings on false >> statements on what Standards Track RFCs specify. > >What is the misconception? >We cannot fix your issue of the general IPv6 spec. in AUTOCONF WG. Sorry, you don't get my message. There are no issues in the general IPv6 specs. They just don't handle the MANET case, and this is well written in the documents itself, e.g. [RFC 4861, page 88]. >> I am not interested in long discussions on DAD. But what I dislike is >> strong opinions on DAD and link-locals that are based on false >> assumptions. > >Even you think it's false, that is the current agreement in IETF >(according to RFCs). Please come up with references. I did, and those clearly shows the opposite. >> I continue posting on DAD and link-locals, because I think it is the >> foundation for IPv6 Stateless Address Autoconfiguration. We need >> some sort of uniqueness, either for each and every address or for a >> piece of the address, that is used for all addresses of a box. I think >> the IPv6 Addressing Architecture [RFC 4291] provides what we need, >> that >> is a 64-bits InterfaceID (unicast address start with binary 000) >> [RFC 4291 page 8]. Having unique InterfaceIDs, we can easily add 64- >> bit >> prefixes, either ULA for MANET-local, or border router provided >> prefixes >> for attached MANETs. >> >> >> When I read back both proposals for the MANET address model, I see >> bernardos-autoconf-addressing-model is more complete (no open issues) >> and better aligns with current Standard Track RFCs. I DO NOT say >> link-local addresses MUST be used for routing protocols, but it can >> be very practical, as is clearly shown in running code of OSPF-MANET. > >AFAIK, this issue was closed at the previous consensus call. >We don't open the issue again. Please respect to the consensus in WG. I think there is no consensus in WG. >> Also, there is code of BRDP in simulators that run without problems. >> I respect other opinions on using link-locals, and I have nothing >> against >> weakening mandatory usage of them. The key point here is having unique >> InterfaceIDs. Using it, we are able to swap prefixes easily. We could >> define a protocol for detecting duplicate InterfaceIDs in the MANET, >> this would work for all of us, when needed. > >Your proposal is not what the current IPv6 specs said. >In AUTOCONF env, we will face more chances to have address duplication >due to topology changes in some scenarios. >We cannot ignore these scenarios and relax the DAD for link-local. I did not suggest this at all. What I say is that the baccelli draft does not address the uniqueness topic, other than put to shame link-locals and DAD. I posted a few times now this text is wrong. >That was what we had discussed at the previous IETF meeting and >conclusion at the previous consensus call. >I appreciate if you can follow the WG agreement. Sorry, but I have to stand up if we [Autoconf] make mistakes. We cannot allow another draft in the IESG wastebasket. High chance the baccelli draft ends this way. Regards, Teco > >regards, >ryuji > >> >> I have posted proposals for corrections on the "DT draft". There was >> low >> acceptance. I think it doesn't help to resubmit. We have an archive >> for it. >> >> >> Regards, Teco >> >> >> >> >> >> >> >> >> >> >> From townsley@cisco.com Sun Oct 25 02:35:10 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 039183A68A8 for ; Sun, 25 Oct 2009 02:35:10 -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 929kuIpjidcN for ; Sun, 25 Oct 2009 02:35:08 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B743A3A68F7 for ; Sun, 25 Oct 2009 02:35:08 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAO6340qrR7Hu/2dsb2JhbAC9d5c2hD8EgV4 X-IronPort-AV: E=Sophos;i="4.44,620,1249257600"; d="scan'208";a="417234920" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 25 Oct 2009 09:35:20 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9P9ZJJX017140; Sun, 25 Oct 2009 09:35:20 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Oct 2009 10:35:19 +0100 Received: from ams-townsley-8719.cisco.com ([10.55.233.234]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Oct 2009 10:35:18 +0100 Message-ID: <4AE41BC4.2050700@cisco.com> Date: Sun, 25 Oct 2009 10:35:00 +0100 From: Mark Townsley User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Alexandru Petrescu References: <4ADED440.2080403@cisco.com> <4AE05EFC.2060501@gmail.com> In-Reply-To: <4AE05EFC.2060501@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 25 Oct 2009 09:35:18.0656 (UTC) FILETIME=[770FE800:01CA5556] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16968.004 X-TM-AS-Result: No--29.810900-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: autoconf@ietf.org Subject: Re: [Autoconf] IPv4 link-locals 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: Sun, 25 Oct 2009 09:35:10 -0000 Alexandru Petrescu wrote: > Mark Townsley a écrit : >> >> Fred wrote: >>> Emmanuel, >>> >>> Section 6.1 of your draft should say the same thing about IPv4 >>> link-local addresses [RFC3927] as was said about IPv6 link-local >>> addresses in Section 6.2. The only difference being that when (or >>> rather if) an IPv4 interface configures a routable address the >>> link-local one is typically deprecated. >>> >>> Fred >> >> Fred, this is the text that ended up in -00: >> >> Note that the use of IPv4 link-local addresses [RFC3927] in this >> context should be discouraged for most applications, as the >> limitations outlined in Section 6.2 for IPv6 link-local addresses >> also concern IPv4 link-local addresses. These limitations are >> further exacerbated by the smaller pool of IPv4 link-local addresses >> to choose from and thus increased reliance on DAD. >> >> However, I think that we need to say a little more here to your >> point. Also, I think that while it is reasonable to discourage >> link-local usage in IPv6 (as hopefully we are more able to readily >> autoconfigure a ULA or Global Ipv6 address) the situation in IPv4 is >> a bit different as obtaining a unique Global or Private IPv4 address >> may be quite a bit more difficult. Therefore, usage of IPv4 >> link-locals may be necessary in some cases (I'm thinking of >> mdns-based service discovery, for example). So, I'd like to propose >> something like this: >> >> "The use of IPv4 link-local addresses [RFC3927] is discouraged for >> most applications. > > I disagree. I have an example showing otherwise. ActiveSync is run on > a large share of the current market devices pertaining to MANETs. We said "most" - one cited application does not contradict that. In fact, I'd go so far as to say that "most" applications, even on a typical wired network, should avoid IPv4 link local if possible. That's clearly what they do today (on purpose or not) as once a non-link-local is available on the interface, the link-local is deprecated. Perhaps that is all the section should say and no more, as it certainly implies that link-local is to be avoided if another address is available. This of course brings upon the additional dependency that the application be able to handle IPv4 address changes, rebinding from link-local to a different scope and perhaps back again. Again, this is certainly possible for some applications, but not all (at least not transparently to the user). > They > all do IPv4 link-local addresses for a very wide range of applications. > > One can't "discourage" that. One should first ack the widespread > deployment of IPv4 link-local address use. The question is whether autoconf should put cycles into: - Making sure IPv4 link-locals are stable and usable within a manet, or - Making sure IPv4 Private addresses stable and usable within a manet, or - Making sure IPv4 Global addresses stable and usable within a manet, or ... all of the above. Success is dependent upon the address space you have to work with, the number of addresses needed for a deployment, the scope of the deployment, etc. ... not to mention the mechanisms for assignment. I think that the confidence level of an address being stable, or at least unique, is likely higher as you move from link-local to private to global spaces in IPv4. That's a generalization, and depends on things like simply not camping out on global address space that hasn't actually been assigned, not to mention the number of and veracity of movement of devices relative to one another. It's all fairly fuzzy, and that's sort of the point... That if your application or the operator of the device knows the environment it is working in, it can use whatever address it has, link-local or otherwise. If not, then perhaps its best to wait until a more "stable" address is available. So, should autoconf focus on making Global, Private *and* link-local addresses stable and usable for "any" or even "most" applications, or should it pick a smaller subset? That's what this section is really trying to do. To scope the work for the autoconf mechanism. Certainly link-local addresses are available and can be used, the question is whether we need to go out of our way to make them even more available and usable, or if we should just focus on getting a (hopefully more stable) Private or Global address ASAP and push the link-local out of the way so that applications are not required to be resilient to their peculiarities. - Mark > >> The limitations outlined in Section 6.2 for IPv6 link-local addresses >> also concern IPv4 link-local addresses, and are further exacerbated >> by the smaller pool of IPv4 link-local addresses to choose from and >> thus increased reliance on DAD. However, given the increased >> difficulty of obtaining a Global or Private [RFC1918] IPv4 address, > > Which difficulty? I personally have the feeling it's more and more > easy to obtain public IPv4 addresses. I had to struggle in 2000 for a > class C, but a few months ago I could get one very easily. Maybe > because people rush to IPv6 deployment... > > Maybe a reference should be given here to support the statement that > public IPv4 addresses are hard to get, and for whom. > > (a fast reader would be tempted into thinking that the [RFC1918] is such > a reference, but no). > >> use of IPv4 link-locals may be the only readily available option in >> some circumstances. Applications running in an ad-hoc environment >> must be well-aware that link-connectivity is constantly in flux, and >> if link-locals are used, ensure that this is not a detrimental factor >> to proper operation. An application that may be able to use IPv4 >> link-locals effectively is one that consists of a stateless >> request-response action and no more. > > Er? What is this? My web browser on my PDA is such a "stateless > request-response action"? And my gps IP tools too? Both use IPv4 > link-local addresses. > >> An application that may not operate with IPv4 link-locals effectively >> is one that relies on nodes to have a consistent or long-lived IPv4 >> address (e.g., connection-oriented communication bound to the IP >> address). > > Why? > > An IPv4 link-local address can be very long-lived. > > Typically apps on devices with IPv4 link-local addresses live behind > NATs. These NATs may change their "CoA" address (if I can say so) and > may have problems because of that. But that is the problem of these > NATs, not of the device using hte IPv4 link-local address. > >> In the event an interface obtains a non-link-local IPv4 >> address, the link-local IPv4 address should be deprecated." > > Well, it depends for which purpose? Which protocol? Which application? > > I think there are IPv4 apps and protocols which can only use IPv4 > link-local addresses, even if there is an IPv4 global address on the > interface. I think you already say so at the beginning (mDNS). > There's also ActiveSync app. > > Alex > >> >> - Mark >> >> >> >> >> >> >> >> >> _______________________________________________ Autoconf mailing list >> Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf >> > > > From teco@inf-net.nl Sun Oct 25 06:17: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 EAD233A6783 for ; Sun, 25 Oct 2009 06:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.941 X-Spam-Level: X-Spam-Status: No, score=-0.941 tagged_above=-999 required=5 tests=[AWL=-0.201, 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 Ritt+a0+M0RG for ; Sun, 25 Oct 2009 06:17:37 -0700 (PDT) Received: from CPSMTPM-EML102.kpnxchange.com (cpsmtpm-eml102.kpnxchange.com [195.121.3.6]) by core3.amsl.com (Postfix) with ESMTP id 05D6A3A6358 for ; Sun, 25 Oct 2009 06:17:36 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML102.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Sun, 25 Oct 2009 14:17:47 +0100 From: "Teco Boot" To: "'Mark Townsley'" References: <4ADED440.2080403@cisco.com> <4AE05EFC.2060501@gmail.com> <4AE41BC4.2050700@cisco.com> In-Reply-To: <4AE41BC4.2050700@cisco.com> Date: Sun, 25 Oct 2009 14:17:48 +0100 Message-ID: <003301ca5575$8c3fb380$a4bf1a80$@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: AcpVVn06E1LAJMGFSqat0I1GnWS17wAHjv7g Content-Language: nl X-OriginalArrivalTime: 25 Oct 2009 13:17:48.0020 (UTC) FILETIME=[8BE73340:01CA5575] Cc: autoconf@ietf.org Subject: Re: [Autoconf] IPv4 link-locals 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: Sun, 25 Oct 2009 13:17:38 -0000 >Mark Townsley wrote: >The question is whether autoconf should put cycles into: > >- Making sure IPv4 link-locals are stable and usable within a manet, or >- Making sure IPv4 Private addresses stable and usable within a manet, >or >- Making sure IPv4 Global addresses stable and usable within a manet, or >... all of the above. Or none of above. I prefer a focus on IPv6. When we arrange IPv6 connectivity to a border router, it is easy to set up a DHCP connection. It requires DHCP_v4 over DHCP_v6 or alternative. Doable. Regards, Teco From alexandru.petrescu@gmail.com Sun Oct 25 07:23: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 D3D2028C0F4 for ; Sun, 25 Oct 2009 07:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=0.335, 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 oQDpsphgPOdN for ; Sun, 25 Oct 2009 07:23:28 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 40B203A6882 for ; Sun, 25 Oct 2009 07:23:26 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 028C8D48015; Sun, 25 Oct 2009 15:23:33 +0100 (CET) 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 BBF7CD4812F; Sun, 25 Oct 2009 15:23:29 +0100 (CET) Message-ID: <4AE45F61.2000800@gmail.com> Date: Sun, 25 Oct 2009 15:23:29 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Mark Townsley References: <4ADED440.2080403@cisco.com> <4AE05EFC.2060501@gmail.com> <4AE41BC4.2050700@cisco.com> In-Reply-To: <4AE41BC4.2050700@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091024-0, 24/10/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] IPv4 link-locals 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: Sun, 25 Oct 2009 14:23:29 -0000 Mark Townsley a écrit : > Alexandru Petrescu wrote: >> Mark Townsley a écrit : >>> >>> Fred wrote: >>>> Emmanuel, >>>> >>>> Section 6.1 of your draft should say the same thing about IPv4 >>>> link-local addresses [RFC3927] as was said about IPv6 link-local >>>> addresses in Section 6.2. The only difference being that when (or >>>> rather if) an IPv4 interface configures a routable address the >>>> link-local one is typically deprecated. >>>> >>>> Fred >>> >>> Fred, this is the text that ended up in -00: >>> >>> Note that the use of IPv4 link-local addresses [RFC3927] in this >>> context should be discouraged for most applications, as the >>> limitations outlined in Section 6.2 for IPv6 link-local addresses >>> also concern IPv4 link-local addresses. These limitations are >>> further exacerbated by the smaller pool of IPv4 link-local addresses >>> to choose from and thus increased reliance on DAD. >>> >>> However, I think that we need to say a little more here to your >>> point. Also, I think that while it is reasonable to discourage >>> link-local usage in IPv6 (as hopefully we are more able to readily >>> autoconfigure a ULA or Global Ipv6 address) the situation in IPv4 is >>> a bit different as obtaining a unique Global or Private IPv4 address >>> may be quite a bit more difficult. Therefore, usage of IPv4 >>> link-locals may be necessary in some cases (I'm thinking of >>> mdns-based service discovery, for example). So, I'd like to propose >>> something like this: >>> >>> "The use of IPv4 link-local addresses [RFC3927] is discouraged for >>> most applications. >> >> I disagree. I have an example showing otherwise. ActiveSync is run on >> a large share of the current market devices pertaining to MANETs. > We said "most" - one cited application does not contradict that. > > In fact, I'd go so far as to say that "most" applications, even on a > typical wired network, should avoid IPv4 link local if possible. That's > clearly what they do today (on purpose or not) as once a non-link-local > is available on the interface, the link-local is deprecated. Perhaps > that is all the section should say and no more, as it certainly implies > that link-local is to be avoided if another address is available. > > This of course brings upon the additional dependency that the > application be able to handle IPv4 address changes, rebinding from > link-local to a different scope and perhaps back again. Again, this is > certainly possible for some applications, but not all (at least not > transparently to the user). >> They >> all do IPv4 link-local addresses for a very wide range of applications. >> >> One can't "discourage" that. One should first ack the widespread >> deployment of IPv4 link-local address use. > The question is whether autoconf should put cycles into: > > - Making sure IPv4 link-locals are stable and usable within a manet, or > - Making sure IPv4 Private addresses stable and usable within a manet, or > - Making sure IPv4 Global addresses stable and usable within a manet, or > ... all of the above. Of course, put that way, one would prefer the last, "make sure the global addresses are usable and stable"... because one thinks manet needs it. But put it another way: make sure the AUTOCONF results still work with ad-hoc unaware nodes (as the Charter mentions too) - then one would prefer to simply not spend any cycles in forbidding something already deployed. > Success is dependent upon the address space you have to work with, the > number of addresses needed for a deployment, the scope of the > deployment, etc. ... not to mention the mechanisms for assignment. > > I think that the confidence level of an address being stable, or at > least unique, is likely higher as you move from link-local to private to > global spaces in IPv4. Yes, that sounds reasonable. For IPv4, one would trust more that the global publicly routable address is unique than its LL or private address. Except that the IPv4 LL is based on a pseudo-random thing and, moreover, tested for uniqueness (RFC 3927 probes), whereas the IPv4 global address is trusted unique either because adminsitratively assigned (very true for adhoc unaware nodes) or DHCP-assigned (sometimes leading to duplicates). In this sense, one trusts more the uniqueness of IPv4 LL addresses than IPv4 global addresses. Do you also intend to discard the RFC3927 probing (similar to IPv6 DAD)? > That's a generalization, and depends on things > like simply not camping out on global address space that hasn't actually > been assigned, not to mention the number of and veracity of movement of > devices relative to one another. > > It's all fairly fuzzy, and that's sort of the point... That if your > application or the operator of the device knows the environment it is > working in, it can use whatever address it has, link-local or otherwise. > If not, then perhaps its best to wait until a more "stable" address is > available. This is something that touches on the future AUTOCONF designs. Have we decided somehow that the AUTOCONF node keeps an address stable despite its movements? Or will it prefer to change its address upon each movement? I can tell about the adhoc unaware nodes. The adhoc unaware hosts prefer to change their addresses when moving, i.e. when changing attachment to a different IP subnet. For ad-hoc unaware routers, the behaviour facing changes due to physical movement depends on many factors. There are a few types of adhoc unaware routers, such as NEMO mobile routers, static routers, and more. > So, should autoconf focus on making Global, Private *and* link-local > addresses stable and usable for "any" or even "most" applications, or > should it pick a smaller subset? That's what this section is really > trying to do. To scope the work for the autoconf mechanism. Certainly > link-local addresses are available and can be used, the question is > whether we need to go out of our way to make them even more available > and usable, or if we should just focus on getting a (hopefully more > stable) Private or Global address ASAP and push the link-local out of > the way so that applications are not required to be resilient to their > peculiarities. Getting dynamically an IPv4 public address... yes, but then it should be tested for uniqueness, especially in a highly mobile environment. Are you going to design a mechanism similar to IPv4 LL probing RFC 3927 (IPv4 LLs). ? If it's not tested for uniqueness, there are risks of duplicate address use, a thing which I have seen very often on Windows screens and linux dmesg messages. Are you going to test for uniqueness of IPv4 global addresses? Alex > > - Mark > >> >>> The limitations outlined in Section 6.2 for IPv6 link-local addresses >>> also concern IPv4 link-local addresses, and are further exacerbated >>> by the smaller pool of IPv4 link-local addresses to choose from and >>> thus increased reliance on DAD. However, given the increased >>> difficulty of obtaining a Global or Private [RFC1918] IPv4 address, >> >> Which difficulty? I personally have the feeling it's more and more >> easy to obtain public IPv4 addresses. I had to struggle in 2000 for a >> class C, but a few months ago I could get one very easily. Maybe >> because people rush to IPv6 deployment... >> >> Maybe a reference should be given here to support the statement that >> public IPv4 addresses are hard to get, and for whom. >> >> (a fast reader would be tempted into thinking that the [RFC1918] is such >> a reference, but no). >> >>> use of IPv4 link-locals may be the only readily available option in >>> some circumstances. Applications running in an ad-hoc environment >>> must be well-aware that link-connectivity is constantly in flux, and >>> if link-locals are used, ensure that this is not a detrimental factor >>> to proper operation. An application that may be able to use IPv4 >>> link-locals effectively is one that consists of a stateless >>> request-response action and no more. >> >> Er? What is this? My web browser on my PDA is such a "stateless >> request-response action"? And my gps IP tools too? Both use IPv4 >> link-local addresses. >> >>> An application that may not operate with IPv4 link-locals effectively >>> is one that relies on nodes to have a consistent or long-lived IPv4 >>> address (e.g., connection-oriented communication bound to the IP >>> address). >> >> Why? >> >> An IPv4 link-local address can be very long-lived. >> >> Typically apps on devices with IPv4 link-local addresses live behind >> NATs. These NATs may change their "CoA" address (if I can say so) and >> may have problems because of that. But that is the problem of these >> NATs, not of the device using hte IPv4 link-local address. >> >>> In the event an interface obtains a non-link-local IPv4 >>> address, the link-local IPv4 address should be deprecated." >> >> Well, it depends for which purpose? Which protocol? Which application? >> >> I think there are IPv4 apps and protocols which can only use IPv4 >> link-local addresses, even if there is an IPv4 global address on the >> interface. I think you already say so at the beginning (mDNS). >> There's also ActiveSync app. >> >> Alex >> >>> >>> - Mark >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ Autoconf mailing list >>> Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf >>> >> >> >> > > > From thomas@thomasclausen.org Sun Oct 25 08:43:20 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 CA0313A6904 for ; Sun, 25 Oct 2009 08:43:20 -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 8T2eK7jNioLA for ; Sun, 25 Oct 2009 08:43:20 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 03F7D3A657C for ; Sun, 25 Oct 2009 08:43:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id B9B1932317AF; Sun, 25 Oct 2009 08:43:32 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 9287A32317AB; Sun, 25 Oct 2009 08:43:31 -0700 (PDT) Message-Id: From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE45F61.2000800@gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-35--994665350 Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 25 Oct 2009 16:43:28 +0100 References: <4ADED440.2080403@cisco.com> <4AE05EFC.2060501@gmail.com> <4AE41BC4.2050700@cisco.com> <4AE45F61.2000800@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] IPv4 link-locals 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: Sun, 25 Oct 2009 15:43:20 -0000 --Apple-Mail-35--994665350 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Oct 25, 2009, at 3:23 PM, Alexandru Petrescu wrote: >>> >> The question is whether autoconf should put cycles into: >> - Making sure IPv4 link-locals are stable and usable within a >> manet, or >> - Making sure IPv4 Private addresses stable and usable within a >> manet, or >> - Making sure IPv4 Global addresses stable and usable within a >> manet, or >> ... all of the above. > > Of course, put that way, one would prefer the last, "make sure the > global addresses are usable and stable"... because one thinks manet > needs it. > > But put it another way: make sure the AUTOCONF results still work > with ad-hoc unaware nodes (as the Charter mentions too) - then one > would prefer to simply not spend any cycles in forbidding something > already deployed. > Alex, Can you explain what in the current document will impact the behavior "ad hoc unaware nodes", and propose a way of rectifying this matter? Thanks, Thomas --Apple-Mail-35--994665350 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Oct 25, 2009, = at 3:23 PM, Alexandru Petrescu wrote:

The question is whether autoconf should put cycles = into:
- Making sure IPv4 = link-locals are stable and usable within a manet, = or
- Making sure IPv4 Private = addresses stable and usable within a manet, = or
- Making sure IPv4 Global = addresses stable and usable within a manet, = or
... all of the = above.

Of course, put that way, one would prefer the = last, "make sure the global addresses are usable and stable"... because = one thinks manet needs it.

But put it another way: make sure the = AUTOCONF results still work with ad-hoc unaware nodes (as the Charter = mentions too) - then one would prefer to simply not spend any cycles in = forbidding something already = deployed.


Alex,

Can you explain what in the current document will impact the = behavior "ad hoc unaware nodes", and propose a way of rectifying this = matter?

Thanks,

Thomas

= --Apple-Mail-35--994665350-- From alexandru.petrescu@gmail.com Sun Oct 25 09:22: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 EA6E328C103 for ; Sun, 25 Oct 2009 09:22:33 -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.316, 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 noiDoKK7TY6b for ; Sun, 25 Oct 2009 09:22:33 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id E417528C0F8 for ; Sun, 25 Oct 2009 09:22:31 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 2B8FFD48179; Sun, 25 Oct 2009 17:22:39 +0100 (CET) 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 5DEF7D480FD; Sun, 25 Oct 2009 17:22:36 +0100 (CET) Message-ID: <4AE47B4B.2020906@gmail.com> Date: Sun, 25 Oct 2009 17:22:35 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <4ADED440.2080403@cisco.com> <4AE05EFC.2060501@gmail.com> <4AE41BC4.2050700@cisco.com> <4AE45F61.2000800@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091024-0, 24/10/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] IPv4 link-locals 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: Sun, 25 Oct 2009 16:22:34 -0000 Thomas Heide Clausen a écrit : > > On Oct 25, 2009, at 3:23 PM, Alexandru Petrescu wrote: >>>> >>> The question is whether autoconf should put cycles into: >>> - Making sure IPv4 link-locals are stable and usable within a manet, or >>> - Making sure IPv4 Private addresses stable and usable within a manet, or >>> - Making sure IPv4 Global addresses stable and usable within a manet, or >>> ... all of the above. >> >> Of course, put that way, one would prefer the last, "make sure the >> global addresses are usable and stable"... because one thinks manet >> needs it. >> >> But put it another way: make sure the AUTOCONF results still work with >> ad-hoc unaware nodes (as the Charter mentions too) - then one would >> prefer to simply not spend any cycles in forbidding something already >> deployed. >> > > Alex, > > Can you explain what in the current document will impact the behavior > "ad hoc unaware nodes", and propose a way of rectifying this matter? Thomas, I have doubts with respect to the use of "discourage" in this text: draft in question says: > Note that the use of IPv4 link-local addresses [RFC3927] in this > context should be discouraged for most applications Will an AUTOCONF network discourage the IPv4 LL of an adhoc-unaware node by sending it ARP packets with its address and somebody else's MAC address? (thus making the adhoc unaware node, which implements rfc3927, believe it can't use its IPv4 LL in that network.) If yes - we have an impact problem, as per Charter. It may read as a DoS for IPv4 LLs. To address this potential problem I propose two alternative paragraphs: "When IPv4 link-local addresses are available for use in a certain node, then they may prove useful for AUTOCONF mechanisms, as they are tested for uniqueness. Future AUTOCONF mechanisms MAY use IPv4 link-local addresses, if RFC3927 implementation available, as a starting point in configuring publicly routable IPv4 addresses." XOR "Future AUTOCONF mechanims should allow the use of IPv4 LLs for adhoc unaware nodes and should not allow the use of IPv4 LLs for MANET nodes". Is this inline with the intention of that [discourage] word? Alex > > Thanks, > > Thomas > From cjbc@it.uc3m.es Sun Oct 25 10:23: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 02DE228C11F for ; Sun, 25 Oct 2009 10:23:57 -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 8GxfUWnOsgrq for ; Sun, 25 Oct 2009 10:23:55 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 5754628C118 for ; Sun, 25 Oct 2009 10:23:55 -0700 (PDT) Received: from [192.168.1.209] (82.159.18.172.dyn.user.ono.com [82.159.18.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 2A32B7F3935; Sun, 25 Oct 2009 18:24:06 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Charles E. Perkins" In-Reply-To: <4AE0AD94.7050800@earthlink.net> References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <4AE0AD94.7050800@earthlink.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-jCC6dT6/XK/oZ5q/BSui" Organization: Universidad Carlos III de Madrid Date: Sun, 25 Oct 2009 18:24:08 +0100 Message-Id: <1256491448.4766.30.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16970.000 Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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: Sun, 25 Oct 2009 17:23:57 -0000 --=-jCC6dT6/XK/oZ5q/BSui Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Charlie, Some delayed comments to your e-mail in-line below... On Thu, 2009-10-22 at 12:08 -0700, Charles E. Perkins wrote: > Hello Carlos, >=20 > Carlos Jes=FAs Bernardos Cano wrote: > > > >>> No, this would not be satisfactory. Link locals are not only mandated= by > >>> RFC 4861 but also used by some protocols, so that's why we consider > >>> important to configure them (so they can be used) in MANETs. > >>> =20 > >>> =20 > >> Can you say which protocols are of interest in this connection? > >> =20 > > > > Some routing protocols make use of link-locals, right? > > =20 >=20 > [manet] was started as a working group because OSPF and other routing > protocols were measured to consume well over 100% of the available > bandwidth (data from NRL). >=20 > Which protocols would you like to employ? Do I need to make a list? do I have to limit only to existing protocols? there may be also other protocols in the future that what to make use of link-locals. >=20 > > > > Well, for these scenarios we also propose in the draft to use some of > > the mechanisms that have been proposed in the past (such as > > draft-soto-mobileip-random-iids)to reduce the collision probability. > > =20 >=20 > This is a great idea... BUT: the solution space should not be > limited to ONLY those solutions that can make use of such > techniques. Right, for those that cannot make use of such techniques we could then develop DAD (or Duplicate Avoidance instead of Detection) mechanisms that work. Autoconf will hopefully work on solutions some point in time in the future, working on DAD solutions may be part of the work. I also want to avoid limiting the solution space of autoconf only to solutions that do not use LLs :-D >=20 > > > >>> =20 > >>> =20 > >> Using a routing protocol to insure uniqueness of > >> link-local addresses seems, on the face of it, to be > >> a serious layer violation. However, I like to keep > >> an open mind :-). > >> =20 > > > > I guess I didn't explain myself clearly... I never said that routing > > protocols should be used to insure uniqueness of link-local addresses > > (though they may be use to detect duplication, as it has been proposed > > in several passive "DAD" approaches, such as PACMAN). What I was trying > > to say is that a stronger interaction with the routing protocol might b= e > > used to detect that a neighbour is no longer reachable, instead of > > purely relying on NUD. > > =20 >=20 > That is true, but it is by no mean restricted to just routing protocols. > You could also use the lack of TCP acknowledgment for such purposes. > Some solutions make use of promiscuous-mode reception to check > whether the neighbor has relayed your packet to some more distant > destination. True, there are indeed more ways of doing this. >=20 > > > > ... I think we were talking > > about reachability of a 1-hop node, that is, the next IP hop of a > > communication (if we are using link-locals, then next IP hop =3D=3D > > destination). > > =20 >=20 > Well, on this point, we are totally on the same page :-). > But, of course, if you happen to know an address for your > neighbor that has larger scope than link-local, you are > free to make use of it. True. RFC3484 also says something about this, I guess. >=20 > > =20 > >> Please explain the relationship between the following two sentences: > >> > >> =20 > >>> "MANET interfaces MUST also be configured with > >>> IPv6 Link-local addresses" > >>> =20 > >> and > >> =20 > >>> "Besides, we do > >>> not mandate to use link-locals in the draft, we just think there are = use > >>> cases where they are useful and therefore we should not prevent their > >>> use in MANETs." > >>> =20 > > > > The relationship is the following: LLs MUST be configured, but we don't > > mandate their use. It is a MUST, because there are IPv6 specs that say > > so and because there are IPv6 protocols/applications that may want to > > use them, but this does not imply that we force protocols/applications > > to use them (it's up to the protocol/application designer to decide > > whether to use them or not). > > > > =20 >=20 > I am pretty sure (having been there) that the IPv6 mandates in > question were placed without regard to the realities of ad hoc > networks. In fact, I think it can be safely said that these mandates > are relevant only to networks where certain subnet structures are > clearly realized. Then, we should ask to update those standards to reflect this. Thanks, Carlos >=20 > And anyway I think it is really important in this context to be > clear about which protocols are to be put into service, and just > what is their reliance on link-local addresses. >=20 > Regards, > Charlie P. >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-jCC6dT6/XK/oZ5q/BSui 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) iEYEABECAAYFAkrkibgACgkQNdy6TdFwT2dkRQCbBa6qFQssazo9rulWaxoiWVbP IdwAoKET7PwFFi1CxNYD4oOENCPTAsKa =p+2t -----END PGP SIGNATURE----- --=-jCC6dT6/XK/oZ5q/BSui-- From cjbc@it.uc3m.es Sun Oct 25 10:28:51 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 000723A6840 for ; Sun, 25 Oct 2009 10:28:50 -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 jopEqJDD996O for ; Sun, 25 Oct 2009 10:28:49 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 44A373A67F0 for ; Sun, 25 Oct 2009 10:28:49 -0700 (PDT) Received: from [192.168.1.209] (82.159.18.172.dyn.user.ono.com [82.159.18.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 2747EBA7A80; Sun, 25 Oct 2009 18:29:00 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Ryuji Wakikawa In-Reply-To: <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Qt8FJHPrggWYbwCg6j7Z" Organization: Universidad Carlos III de Madrid Date: Sun, 25 Oct 2009 18:29:02 +0100 Message-Id: <1256491742.4766.35.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16970.000 Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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: Sun, 25 Oct 2009 17:28:51 -0000 --=-Qt8FJHPrggWYbwCg6j7Z Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Ryuji, On Sat, 2009-10-24 at 03:11 -0700, Ryuji Wakikawa wrote: > Hi Carlos, >=20 > On 2009/10/22, at 11:53, Carlos Jes=FAs Bernardos Cano wrote: >=20 > > Hi Charlie, > >> > >> Please explain the relationship between the following two sentences: > >> > >>> "MANET interfaces MUST also be configured with > >>> IPv6 Link-local addresses" > >> > >> and > >>> "Besides, we do > >>> not mandate to use link-locals in the draft, we just think there =20 > >>> are use > >>> cases where they are useful and therefore we should not prevent =20 > >>> their > >>> use in MANETs." > > > > The relationship is the following: LLs MUST be configured, but we =20 > > don't > > mandate their use. It is a MUST, because there are IPv6 specs that say > > so and because there are IPv6 protocols/applications that may want to > > use them, but this does not imply that we force protocols/applications > > to use them (it's up to the protocol/application designer to decide > > whether to use them or not). >=20 > The differences from the DT draft on this point are > - mandating LL address > - no warning to use it >=20 > ? >=20 > The DT document does not prohibit using LL address, but it clearly =20 > warn the possible problems (which are MANET specific). > What is your problem of the texts in the DT document? > You can still run existing protocols using the link-local with the =20 > same condition of your draft (i.e. no DAD). >=20 > We should not let this DAD functionality as an optional. > If we want to use LL, we have to provide uniqueness to LL and mandate =20 > DAD for it. > This is because we shouldn't assume any L1/L2 technology in IP. I guess we have already addressed this in some other previous e-mails, but just to avoid leaving e-mails without a reply, I'm providing my view on this here. I think there is a difference between draft-bacceli and ours regarding LL. You might say it is subtle, but I don't think so :-). One draft says: LLs are not a MUST, but you are free to use them. The other says; LLs are a MUST, but you are not forced to use them (this is exactly what IPv6 specs say, in my understanding). DAD is not mandated for LL, but strongly encouraged. There is again a -- maybe subtle, maybe not -- difference. Thanks, Carlos >=20 > regards, > ryuji >=20 >=20 > > > > Thanks, > > > > Carlos > > > >> > >> Regards, > >> Charlie P. > >> > > --=20 > > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www.ietf.org/mailman/listinfo/autoconf >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-Qt8FJHPrggWYbwCg6j7Z 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) iEYEABECAAYFAkrkit4ACgkQNdy6TdFwT2c3RQCgvspKgrr1WSwcJAjBk422P6Bt KWgAoMZazCk5ZVFOk/DKqz9kyPvDSkAt =HSZn -----END PGP SIGNATURE----- --=-Qt8FJHPrggWYbwCg6j7Z-- From thomas@thomasclausen.org Sun Oct 25 10:35: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 D61243A67F1 for ; Sun, 25 Oct 2009 10:35:39 -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=[AWL=0.001, 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 uY9CAE5YPH1e for ; Sun, 25 Oct 2009 10:35:39 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 0794E3A67E6 for ; Sun, 25 Oct 2009 10:35:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id C3D2B32317AE; Sun, 25 Oct 2009 10:35:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 9F8CB32317AB; Sun, 25 Oct 2009 10:35:49 -0700 (PDT) Message-Id: <70909CF7-8087-4284-B90E-CD56CF3CB6FE@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE47B4B.2020906@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: Sun, 25 Oct 2009 18:35:47 +0100 References: <4ADED440.2080403@cisco.com> <4AE05EFC.2060501@gmail.com> <4AE41BC4.2050700@cisco.com> <4AE45F61.2000800@gmail.com> <4AE47B4B.2020906@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] IPv4 link-locals 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: Sun, 25 Oct 2009 17:35:39 -0000 On Oct 25, 2009, at 5:22 PM, Alexandru Petrescu wrote: > Thomas Heide Clausen a =E9crit : >> On Oct 25, 2009, at 3:23 PM, Alexandru Petrescu wrote: >>>>> >>>> The question is whether autoconf should put cycles into: >>>> - Making sure IPv4 link-locals are stable and usable within a =20 >>>> manet, or >>>> - Making sure IPv4 Private addresses stable and usable within a =20 >>>> manet, or >>>> - Making sure IPv4 Global addresses stable and usable within a =20 >>>> manet, or >>>> ... all of the above. >>> >>> Of course, put that way, one would prefer the last, "make sure the =20= >>> global addresses are usable and stable"... because one thinks =20 >>> manet needs it. >>> >>> But put it another way: make sure the AUTOCONF results still work =20= >>> with ad-hoc unaware nodes (as the Charter mentions too) - then one =20= >>> would prefer to simply not spend any cycles in forbidding =20 >>> something already deployed. >>> >> Alex, >> Can you explain what in the current document will impact the =20 >> behavior "ad hoc unaware nodes", and propose a way of rectifying =20 >> this matter? > > Thomas, I have doubts with respect to the use of "discourage" in =20 > this text: > > draft in question says: >> Note that the use of IPv4 link-local addresses [RFC3927] in this >> context should be discouraged for most applications > > Will an AUTOCONF network discourage the IPv4 LL of an adhoc-unaware =20= > node by Absolutely not. I am not reading the draft as mandating anything on =20 "ad hoc unaware nodes". Rather, the draft is careful on stating that =20 (I paraphrase): "If one knows something about the topology, i.e. one =20 is not in an ad hoc network, USE THAT KNOWLEDGE" > sending it ARP packets with its address and somebody else's MAC =20 > address? (thus making the adhoc unaware node, which implements =20 > rfc3927, believe it can't use its IPv4 LL in that network.) > > If yes - we have an impact problem, as per Charter. It may read as =20= > a DoS for IPv4 LLs. My read is, that for what you call "ad hoc unaware nodes", that =20 document mandates absolutely nothing. > > To address this potential problem I propose two alternative =20 > paragraphs: > > "When IPv4 link-local addresses are available for use in a certain =20 > node, then they may prove useful for AUTOCONF mechanisms, as they =20 > are tested for uniqueness. Disagree. This i the "wrong way around": a LL address (v4 or v6) =20 cannot with existing mechanisms be tested for uniqueness and -- even =20 if they could -- due to node mobility any uniqueness would not be =20 guaranteed to exist over time. Hence, if I have a LL address, generated "the usual way" (v4 or v6), =20 then on an "ad hoc aware node" [to retake your terminology] I can not =20= be sure that it is useful as I do not know of the properties of that =20 address. IOW, IPv6 prescribes "thou shall have a LL address" -- which =20= is fine. We observe that "in an ad hoc network, thy better be wary =20 that the LL address may be of limited use". Which, I think, is also =20 fine. > Future AUTOCONF mechanisms MAY use IPv4 link-local addresses, if =20 > RFC3927 implementation available, as a starting point in configuring =20= > publicly routable IPv4 addresses." > > XOR > > "Future AUTOCONF mechanims should allow the use of IPv4 LLs for =20 > adhoc unaware nodes and should not allow the use of IPv4 LLs for =20 > MANET nodes". > > Is this inline with the intention of that [discourage] word? No, see above... Thomas > > Alex > > >> Thanks, >> Thomas > From cjbc@it.uc3m.es Sun Oct 25 10:38:38 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 C81AD28C11F for ; Sun, 25 Oct 2009 10:38:38 -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=[AWL=-0.000, 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 zSoV0onUoBGL for ; Sun, 25 Oct 2009 10:38:37 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id E8A5B28C110 for ; Sun, 25 Oct 2009 10:38:36 -0700 (PDT) Received: from [192.168.1.209] (82.159.18.172.dyn.user.ono.com [82.159.18.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 8EB25BA01FD; Sun, 25 Oct 2009 18:38:47 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Ryuji Wakikawa In-Reply-To: <0E0F03A1-EC0C-4FF9-AB17-DB2029F7363E@gmail.com> References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <0E0F03A1-EC0C-4FF9-AB17-DB2029F7363E@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-iq4bySgkYgd4QhAWE9Aw" Organization: Universidad Carlos III de Madrid Date: Sun, 25 Oct 2009 18:38:49 +0100 Message-Id: <1256492329.4766.39.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16970.000 Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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: Sun, 25 Oct 2009 17:38:38 -0000 --=-iq4bySgkYgd4QhAWE9Aw Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Ryuji, On Sat, 2009-10-24 at 03:00 -0700, Ryuji Wakikawa wrote: > Hi Carlos, >=20 > On 2009/10/21, at 17:10, Carlos Jes=FAs Bernardos Cano wrote: >=20 > > Hi Charlie, > > > > On Wed, 2009-10-21 at 16:08 -0700, Charles E. Perkins wrote: > >> Hello Carlos and Ronald, > >> > >> Intrigued by Alex's email to the [autoconf] mailing list, I read > >> your draft, which suggests the mandate: > > > > Thanks for reading the draft. We are working on a -01 version (we > > submitted -00 to meet the deadline and we hope to make some changes > > before announcing it on the ML), but I'll provide my view on your > > questions. > > > >> "MANET interfaces MUST also be configured with > >> IPv6 Link-local addresses". > >> > >> But there is no indication in the draft about why that > >> mandate might result in anything useful. > >> > >> What if [autoconf] recommended assignment of a distinguished > >> link-local address to every MANET node? We could, for > >> instance, designate the value fe80::FFFF as the distinguished > >> useless link-local address designed _solely_ for the purpose > >> of rigorous compliance with RFC 4861. Would this be > >> satisfactory for the purposes you espouse in your draft? > > > > No, this would not be satisfactory. Link locals are not only =20 > > mandated by > > RFC 4861 but also used by some protocols, so that's why we consider > > important to configure them (so they can be used) in MANETs. >=20 > We have to understand all the protocols using link-local address expect > the uniqueness of LL-address defined as RFC4861. >=20 > If LL address cannot be guaranteed uniqueness as RFC4861, > we cannot guarantee the correct behavior of other protocols. Sure, but IP is best-effort, so we also need to understand what do we mean by "guarantee uniqueness"... >=20 >=20 > >> I also note that in your draft you advocate reliance on the > >> typical (but not guaranteed) uniqueness of IEEE MAC addresses, > > > > It's true that it is not guaranteed, but the probability of =20 > > collision is > > so low, that I'm not sure it's worth arguing about the necessity of > > using DAD. >=20 > see above. > AFAIK, It's necessary to make sure the LL address uniqueness if we =20 > will use it. Sure, but ensuring address "uniqueness" (the level of guarantee that any protocol running on IP can expect) does not necessarily mean running DAD (or at least the DAD mechanism defined in IPv6 standards, we can work on protocols in autoconf). Thanks, Carlos >=20 > regards, > ryuji >=20 > > > >> and also turning off DAD or hacking the parameters. Did you > >> try to calculate the overhead of, say, beaconing NA messages > >> every 50 milliseconds, and the resulting too-frequent ND > >> operations? Do you have any comments on the N^2 nature > >> of this source of congestion? > > > > This could be certainly a scalability problem, but "hacking/=20 > > configuring" > > ND is just one proposed mechanism to tackle with fluctuating > > reachability issues. There are other ways proposed in the draft =20 > > (such a > > stronger interaction with the routing protocol) and surely there are > > more. > > > > Even if globals are used instead, we would have a fluctuating > > reachability issue, since the next IP hop used to reach a certain > > destination might move out of radio coverage (you need to detect =20 > > this by > > ND or the routing protocol). I think the same kind-of solutions that =20 > > be > > used there can also be used when link-locals are used. Besides, we do > > not mandate to use link-locals in the draft, we just think there are =20 > > use > > cases where they are useful and therefore we should not prevent their > > use in MANETs. > > > > Again, thanks for reading the draft. > > > > Regards, > > > > Carlos > > > >> > >> Regards, > >> Charlie P. > >> > >> > >> Alexandru Petrescu wrote: > >>> AUTOCONFers, > >>> > >>> I just noticed this draft just announced: > >>> > >>> Internet-Drafts@ietf.org a =E9crit : > >>>> A URL for this Internet-Draft is: > >>>> http://www.ietf.org/internet-drafts/draft-bernardos-autoconf-address= ing-model-00.txt > >>>> > >>> > >>> This draft says, among others: > >>> > >>>> MANET interfaces MUST also be configured with IPv6 Link-local > >>>> addresses (as required by RFC 4861 [RFC4861] and RFC 4291 =20 > >>>> [RFC4291]). > >>>> Two main concerns may arise when considering the use of IPv6 =20 > >>>> Link- > >>>> local addresses: > >>>> > >>>> o Address uniqueness: the event of having two duplicate =20 > >>>> addresses in > >>>> the same link has proved to be very low (EUI64 derived =20 > >>>> interface > >>>> identifiers very rarely collide, since MAC addresses are =20 > >>>> expected > >>>> to be globally unique), and even some mechanisms have been > >>>> proposed to reduce the collision probability > >>>> [I-D.soto-mobileip-random-iids]. Therefore, in most =20 > >>>> scenarios it > >>>> is safe to assume that the probability of having two or more > >>>> duplicated link-local addresses in a MANET is negiglible. For > >>>> those scenarios, in which this cannot be safely assumed, we =20 > >>>> refer > >>>> to the DAD considerations of Section 3.3. > >>>> > >>>> o Reachability: connectivity among neighbours in wireless =20 > >>>> links may > >>>> be intermittent and/or short-lived. Therefore, the use of =20 > >>>> link- > >>>> local addresses may lead to reachability issues, since two =20 > >>>> nodes > >>>> that were in direct coverage range at one moment, might not be > >>>> anymore shortly after. These problems might also arise in =20 > >>>> wired > >>>> networks (nodes going up/down), but it is not the common case. > >>>> > >>>> Having brought to attention these concerns, it is further left =20 > >>>> to the > >>>> designers of MANET routing protocols (and other protocols) to > >>>> determine whether link-local addresses can be used in an =20 > >>>> effective > >>>> way. > >>> > >>> I must say I fully agree with the above text, because it says > >>> link-locals are "MUST". It is more positive towards link-locals, I > >>> agree with it. > >>> > >>> I agree with it more than I agree with this text in > >>> draft-ietf-autoconf-adhoc-addr-model-00.txt: > >>>> Note that while link-local addresses are assumed to be "on =20 > >>>> link", the > >>>> utility of link-local addresses is limited as described in =20 > >>>> Section 6. > >>> > >>> ... which has a negative co-notation in that use of the "limited" =20 > >>> word. > >>> > >>> So - please clarify this situation. > >>> > >>> Alex > >>> > >>>> > >>> > >>> > >>>> > >>>> Internet-Drafts are also available by anonymous FTP at: > >>>> ftp://ftp.ietf.org/internet-drafts/ > >>>> > >>>> Below is the data which will enable a MIME compliant mail reader > >>>> implementation to automatically retrieve the ASCII version of the > >>>> Internet-Draft. > >>>> > >>>> > >>>> --------------------------------------------------------------------= ---- > >>>> > >>>> _______________________________________________ > >>>> I-D-Announce mailing list > >>>> I-D-Announce@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/i-d-announce > >>>> Internet-Draft directories: http://www.ietf.org/shadow.html > >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >>> > >>> _______________________________________________ > >>> 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 > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www.ietf.org/mailman/listinfo/autoconf >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-iq4bySgkYgd4QhAWE9Aw 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) iEYEABECAAYFAkrkjSkACgkQNdy6TdFwT2czKACgofmVXC6kBzHO5qAK2Wau9NR+ 3LUAoN95TALONkKxY4R8RWOcgkkkCvid =GJHk -----END PGP SIGNATURE----- --=-iq4bySgkYgd4QhAWE9Aw-- From thomas@thomasclausen.org Sun Oct 25 10:40: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 BB2F128C11F for ; Sun, 25 Oct 2009 10:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] 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 SQOPh7XSHQE2 for ; Sun, 25 Oct 2009 10:40:07 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 7FD3F28C110 for ; Sun, 25 Oct 2009 10:40:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id EEF7032317AE; Sun, 25 Oct 2009 10:40:19 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id C9BFB32317AD; Sun, 25 Oct 2009 10:40:18 -0700 (PDT) Message-Id: From: Thomas Heide Clausen To: cjbc@it.uc3m.es In-Reply-To: <1256491742.4766.35.camel@acorde.it.uc3m.es> 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: Sun, 25 Oct 2009 18:40:16 +0100 References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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: Sun, 25 Oct 2009 17:40:08 -0000 Carlos, On Oct 25, 2009, at 6:29 PM, Carlos Jes=FAs Bernardos Cano wrote: > Hi Ryuji, > > On Sat, 2009-10-24 at 03:11 -0700, Ryuji Wakikawa wrote: >> Hi Carlos, >> >> On 2009/10/22, at 11:53, Carlos Jes=FAs Bernardos Cano wrote: >> >>> Hi Charlie, >>>> >>>> Please explain the relationship between the following two =20 >>>> sentences: >>>> >>>>> "MANET interfaces MUST also be configured with >>>>> IPv6 Link-local addresses" >>>> >>>> and >>>>> "Besides, we do >>>>> not mandate to use link-locals in the draft, we just think there >>>>> are use >>>>> cases where they are useful and therefore we should not prevent >>>>> their >>>>> use in MANETs." >>> >>> The relationship is the following: LLs MUST be configured, but we >>> don't >>> mandate their use. It is a MUST, because there are IPv6 specs that =20= >>> say >>> so and because there are IPv6 protocols/applications that may want =20= >>> to >>> use them, but this does not imply that we force protocols/=20 >>> applications >>> to use them (it's up to the protocol/application designer to decide >>> whether to use them or not). >> >> The differences from the DT draft on this point are >> - mandating LL address >> - no warning to use it >> >> ? >> >> The DT document does not prohibit using LL address, but it clearly >> warn the possible problems (which are MANET specific). >> What is your problem of the texts in the DT document? >> You can still run existing protocols using the link-local with the >> same condition of your draft (i.e. no DAD). >> >> We should not let this DAD functionality as an optional. >> If we want to use LL, we have to provide uniqueness to LL and mandate >> DAD for it. >> This is because we shouldn't assume any L1/L2 technology in IP. > > I guess we have already addressed this in some other previous e-mails, > but just to avoid leaving e-mails without a reply, I'm providing my =20= > view > on this here. > > I think there is a difference between draft-bacceli and ours regarding > LL. You might say it is subtle, but I don't think so :-). One draft > says: LLs are not a MUST, but you are free to use them. The other =20 > says; > LLs are a MUST, but you are not forced to use them (this is exactly =20= > what > IPv6 specs say, in my understanding). I'd say that the truth is as follows: o If you have an LL address [generated by the usual = means], it may be useless. Use it if you like, but be wary that the = properties of =20 that address are undefined. I thought that was what the Baccelli/Townsley draft said? > DAD is not mandated for LL, but strongly encouraged. There is again =20= > a -- > maybe subtle, maybe not -- difference. But, DAD [again, the usual DAD] won't (i) get you a usefully unique LL =20= address and (ii) even if it does, with DAD being a one-shot operation =20= when an interface is brought up, won't ensure LL address uniqueness in =20= the future [node mobility would be one cause for such]. Therefore, if you get a LL address using these usual means, it's not =20 really useful. I think that's what the Baccelli/Townsley I-D states, =20 isn't it ? Thomas > > Thanks, > > Carlos > >> >> regards, >> ryuji >> >> >>> >>> Thanks, >>> >>> Carlos >>> >>>> >>>> Regards, >>>> Charlie P. >>>> >>> --=20 >>> Carlos Jes=FAs Bernardos Cano http://www.netcoms.net >>> GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 >>> _______________________________________________ >>> 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 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From cjbc@it.uc3m.es Sun Oct 25 10:52:20 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 8E2463A69A4 for ; Sun, 25 Oct 2009 10:52:20 -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 dBwSXvGBA9+7 for ; Sun, 25 Oct 2009 10:52:19 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 0B1123A659C for ; Sun, 25 Oct 2009 10:52:18 -0700 (PDT) Received: from [192.168.1.209] (82.159.18.172.dyn.user.ono.com [82.159.18.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 91B6E6C2AC1; Sun, 25 Oct 2009 18:52:29 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Thomas Heide Clausen In-Reply-To: References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-LsrwB693EmpunUqp2HS+" Organization: Universidad Carlos III de Madrid Date: Sun, 25 Oct 2009 18:52:31 +0100 Message-Id: <1256493151.4766.58.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16970.000 Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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: Sun, 25 Oct 2009 17:52:20 -0000 --=-LsrwB693EmpunUqp2HS+ Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Thomas, On Sun, 2009-10-25 at 18:40 +0100, Thomas Heide Clausen wrote: > Carlos, >=20 > On Oct 25, 2009, at 6:29 PM, Carlos Jes=FAs Bernardos Cano wrote: >=20 > > Hi Ryuji, > > > > On Sat, 2009-10-24 at 03:11 -0700, Ryuji Wakikawa wrote: > >> Hi Carlos, > >> > >> On 2009/10/22, at 11:53, Carlos Jes=FAs Bernardos Cano wrote: > >> > >>> Hi Charlie, > >>>> > >>>> Please explain the relationship between the following two =20 > >>>> sentences: > >>>> > >>>>> "MANET interfaces MUST also be configured with > >>>>> IPv6 Link-local addresses" > >>>> > >>>> and > >>>>> "Besides, we do > >>>>> not mandate to use link-locals in the draft, we just think there > >>>>> are use > >>>>> cases where they are useful and therefore we should not prevent > >>>>> their > >>>>> use in MANETs." > >>> > >>> The relationship is the following: LLs MUST be configured, but we > >>> don't > >>> mandate their use. It is a MUST, because there are IPv6 specs that =20 > >>> say > >>> so and because there are IPv6 protocols/applications that may want =20 > >>> to > >>> use them, but this does not imply that we force protocols/=20 > >>> applications > >>> to use them (it's up to the protocol/application designer to decide > >>> whether to use them or not). > >> > >> The differences from the DT draft on this point are > >> - mandating LL address > >> - no warning to use it > >> > >> ? > >> > >> The DT document does not prohibit using LL address, but it clearly > >> warn the possible problems (which are MANET specific). > >> What is your problem of the texts in the DT document? > >> You can still run existing protocols using the link-local with the > >> same condition of your draft (i.e. no DAD). > >> > >> We should not let this DAD functionality as an optional. > >> If we want to use LL, we have to provide uniqueness to LL and mandate > >> DAD for it. > >> This is because we shouldn't assume any L1/L2 technology in IP. > > > > I guess we have already addressed this in some other previous e-mails, > > but just to avoid leaving e-mails without a reply, I'm providing my =20 > > view > > on this here. > > > > I think there is a difference between draft-bacceli and ours regarding > > LL. You might say it is subtle, but I don't think so :-). One draft > > says: LLs are not a MUST, but you are free to use them. The other =20 > > says; > > LLs are a MUST, but you are not forced to use them (this is exactly =20 > > what > > IPv6 specs say, in my understanding). >=20 > I'd say that the truth is as follows: >=20 > o If you have an LL address [generated by the usual means], it may > be useless. Use it if you like, but be wary that the properties of =20 > that > address are undefined. >=20 >=20 > I thought that was what the Baccelli/Townsley draft said? Well, I think that "[generated by the usual means]" can be skipped since the draft should not go (if possible, know it's hard) into solution space. I'd make the question: IPv6 mandates LLs, do we really want to make IPv6 protocols running on MANET be special (in some way) because this feature of IPv6 is not present in MANETs (i.e. no LLs)? If we say no, if we want to keep LLs, then we can go into the debate about how to generate LLs in MANETs (solution space). >=20 >=20 > > DAD is not mandated for LL, but strongly encouraged. There is again =20 > > a -- > > maybe subtle, maybe not -- difference. >=20 > But, DAD [again, the usual DAD] won't (i) get you a usefully unique LL =20 > address and (ii) even if it does, with DAD being a one-shot operation =20 > when an interface is brought up, won't ensure LL address uniqueness in =20 > the future [node mobility would be one cause for such]. >=20 > Therefore, if you get a LL address using these usual means, it's not =20 > really useful. I think that's what the Baccelli/Townsley I-D states, =20 > isn't it ? Well, I think I disagree here (see above). Even LL addresses configured using usual means would probably work in the 99.9% of the scenarios (but this is just my personal feeling, based on my very limited experience running IP networks). Thanks, Carlos >=20 > Thomas >=20 >=20 > > > > Thanks, > > > > Carlos > > > >> > >> regards, > >> ryuji > >> > >> > >>> > >>> Thanks, > >>> > >>> Carlos > >>> > >>>> > >>>> Regards, > >>>> Charlie P. > >>>> > >>> --=20 > >>> Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > >>> GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > >>> _______________________________________________ > >>> 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 > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www.ietf.org/mailman/listinfo/autoconf >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-LsrwB693EmpunUqp2HS+ 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) iEYEABECAAYFAkrkkF8ACgkQNdy6TdFwT2dl0QCcCbRBuRaxFIx+UnrJQW/cByAy yvgAmwfa8yvsrNAO39aTdOqdDnlICocy =hHjh -----END PGP SIGNATURE----- --=-LsrwB693EmpunUqp2HS+-- From emmanuel.baccelli@gmail.com Sun Oct 25 11:02:27 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 33A443A69A6 for ; Sun, 25 Oct 2009 11:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.729 X-Spam-Level: X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[AWL=0.247, 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 KksavS7hb+gP for ; Sun, 25 Oct 2009 11:02:26 -0700 (PDT) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 4E2443A69A4 for ; Sun, 25 Oct 2009 11:02:26 -0700 (PDT) Received: by ywh13 with SMTP id 13so14550664ywh.29 for ; Sun, 25 Oct 2009 11:02:36 -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=XxyPRsy3+5wTTBEElm+Z63CbocXqwBqBryBfu6IpA4o=; b=DVp++oQNYS96bz2hEDOTqhVwXbN48onctFvFkWybjOQArA5UweNuYjuAR4yJkpgoq7 7mOkQA+UwVJfV2R/s0w8SIIOp5ZSE5YgP2Ei5a4yCA7Hc0sndMFkH4rPIAZ2gEWuZrBG oZMZ6ri3dQHzoquakkzZX4nIhAfBb817fnYcE= 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=bdLY+FBrRFvP1PabSAZegsQSITIHOXePO2DrTq2W/qtGyvyB9r2DD1TQxR8MSbWRoY nV8JrQDvlLOTQc5xyvaMyyiQZVOLPtEbLEkLgpIu6lTwVjJZ7Ub4eahMrZCKJihn/Kpv ciYtT3VJw0am4rCO+39EOXPTzepUcqp5aXNHo= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.101.183.7 with SMTP id k7mr8386069anp.164.1256493756082; Sun, 25 Oct 2009 11:02:36 -0700 (PDT) In-Reply-To: <1256491742.4766.35.camel@acorde.it.uc3m.es> References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> From: Emmanuel Baccelli Date: Sun, 25 Oct 2009 19:02:16 +0100 X-Google-Sender-Auth: d60b62ef5cb4f0ba Message-ID: To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=001636c59534fe6a6c0476c63f8e Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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: Sun, 25 Oct 2009 18:02:27 -0000 --001636c59534fe6a6c0476c63f8e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi again Carlos (sending again to the list too this time ;). See below. 2009/10/25 Carlos Jes=FAs Bernardos Cano > Hi Ryuji, > > > I guess we have already addressed this in some other previous e-mails, > but just to avoid leaving e-mails without a reply, I'm providing my view > on this here. > > I think there is a difference between draft-bacceli and ours regarding > LL. You might say it is subtle, but I don't think so :-). One draft > says: LLs are not a MUST, but you are free to use them. The other says; > LLs are a MUST, but you are not forced to use them (this is exactly what > IPv6 specs say, in my understanding). > > I have a hard time seeing which draft says what, according to you. Neither draft-ietf, nor draft-bernados I believe, say that "LLs are not a must". They both say that LLs are assigned to each interface as per [RFC4291]. So if there is a difference between the drafts on this point, it must be even more subtle than you thought ;) Emmanuel > > > --001636c59534fe6a6c0476c63f8e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi again Carlos (sending again to the list too this time ;). See below.
=
2009/10/25 Carlos Jes=FAs Bernardos Cano=A0<= span dir=3D"ltr"><cjbc@it.uc3m.es= >
Hi Ryuji,


I guess = we have already addressed this in some other previous e-mails,
but just = to avoid leaving e-mails without a reply, I'm providing my view
on t= his here.

I think there is a difference between draft-bacceli and ours regarding<= br>LL. You might say it is subtle, but I don't think so :-). One draft<= br>says: LLs are not a MUST, but you are free to use them. The other says;<= br> LLs are a MUST, but you are not forced to use them (this is exactly whatIPv6 specs say, in my understanding).


<= div> I have a hard time seeing which draft says what, according to you. Neither = draft-ietf, nor draft-bernados I believe, say that "LLs are not a must= ". They both say that LLs are assigned to each interface as per [RFC42= 91]. So if there is a difference between the drafts on this point, it must = be even more subtle than you thought ;)

Emmanuel


--001636c59534fe6a6c0476c63f8e-- From charles.perkins@earthlink.net Sun Oct 25 11:09: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 AE3343A69AE for ; Sun, 25 Oct 2009 11:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 vlu--8uRuB8I for ; Sun, 25 Oct 2009 11:09:07 -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 CDD8F3A69AB for ; Sun, 25 Oct 2009 11:09:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=LUvUXkdmcL1Ck6CwWAX/mMqP4lJKA1XXnaAx0mYtAhYaEeQ6KByO52Cnvgha1fbo; 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-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1N27Wp-0000uE-VT; Sun, 25 Oct 2009 14:09:20 -0400 Message-ID: <4AE4944F.2060508@earthlink.net> Date: Sun, 25 Oct 2009 11:09:19 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> In-Reply-To: <1256491742.4766.35.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f529e9010479b49f47282d6bbf30539abe7350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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: Sun, 25 Oct 2009 18:09:08 -0000 Hello Carlos, Carlos Jesús Bernardos Cano wrote: > > > I think there is a difference between draft-bacceli and ours regarding > LL. You might say it is subtle, but I don't think so :-). One draft > says: LLs are not a MUST, but you are free to use them. The other says; > LLs are a MUST, but you are not forced to use them (this is exactly what > IPv6 specs say, in my understanding). > The problem with your MUST is that it's silly to mandate link-locals unless you can guarantee uniqueness, and that places the bar far too high -- getting in the way of useful work. > DAD is not mandated for LL, but strongly encouraged. There is again a -- > maybe subtle, maybe not -- difference. > Ins this is where the proponents for manding link-locals lose their way? There seems to be a common belief that one can tacitly rely on uniqueness derived from MAC addresses, but when this is pointed out, then we fall back on arguing about DAD when all along the proponents don't plan on implementing DAD in the first place. Regards, Charlie P. From cjbc@it.uc3m.es Sun Oct 25 11:12:56 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 51B143A69B1 for ; Sun, 25 Oct 2009 11:12:56 -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 nuj8d1e2L3BQ for ; Sun, 25 Oct 2009 11:12:55 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 23ABD3A69B0 for ; Sun, 25 Oct 2009 11:12:54 -0700 (PDT) Received: from [192.168.1.209] (82.159.18.172.dyn.user.ono.com [82.159.18.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id B3B78BA58F5; Sun, 25 Oct 2009 19:13:04 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Emmanuel Baccelli In-Reply-To: References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-qFBwNkA2Rd75O3W2KdnT" Organization: Universidad Carlos III de Madrid Date: Sun, 25 Oct 2009 19:13:06 +0100 Message-Id: <1256494386.4766.83.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16970.000 Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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: Sun, 25 Oct 2009 18:12:56 -0000 --=-qFBwNkA2Rd75O3W2KdnT Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Emmanuel, On Sun, 2009-10-25 at 19:02 +0100, Emmanuel Baccelli wrote: > Hi again Carlos (sending again to the list too this time ;). See > below. :-D >=20 > 2009/10/25 Carlos Jes=FAs Bernardos Cano > Hi Ryuji, > =20 > =20 > =20 > =20 > I guess we have already addressed this in some other previous > e-mails, > but just to avoid leaving e-mails without a reply, I'm > providing my view > on this here. > =20 > I think there is a difference between draft-bacceli and ours > regarding > LL. You might say it is subtle, but I don't think so :-). One > draft > says: LLs are not a MUST, but you are free to use them. The > other says; > LLs are a MUST, but you are not forced to use them (this is > exactly what > IPv6 specs say, in my understanding). > =20 >=20 >=20 > I have a hard time seeing which draft says what, according to you. > Neither draft-ietf, nor draft-bernados I believe, say that "LLs are > not a must". They both say that LLs are assigned to each interface as > per [RFC4291]. So if there is a difference between the drafts on this > point, it must be even more subtle than you thought ;) Could be, yes. Well, but if I understood correctly, your draft strongly discourages the use of LLs and it is not much concerned about the use of LLs in MANETs (so you are basically putting in the draft what it is required to not formally contradict IPv6 standards), right? My point was that our draft is on the side of providing MANET routers with LLs that _may_ be used if applications/protocols want to (exactly as in the current non-MANET world). Thanks, Carlos >=20 >=20 > Emmanuel > =20 > =20 > _______________________________________________ > 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 --=-qFBwNkA2Rd75O3W2KdnT 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) iEYEABECAAYFAkrklTIACgkQNdy6TdFwT2ciNwCdHpmRoYTtUtYNZrzNgpIYPlKP xmMAn1XMRI0Y2eDPOhaMBX6zSPUw8kA3 =lJfx -----END PGP SIGNATURE----- --=-qFBwNkA2Rd75O3W2KdnT-- From alexandru.petrescu@gmail.com Sun Oct 25 11:16: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 2C76328C125 for ; Sun, 25 Oct 2009 11:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.942 X-Spam-Level: X-Spam-Status: No, score=-1.942 tagged_above=-999 required=5 tests=[AWL=0.307, 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 QSZ2sSUwRdW9 for ; Sun, 25 Oct 2009 11:15:59 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id F2F043A69B4 for ; Sun, 25 Oct 2009 11:15:57 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 4F8E7D4819D; Sun, 25 Oct 2009 19:16:05 +0100 (CET) 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 0586FD48098; Sun, 25 Oct 2009 19:16:02 +0100 (CET) Message-ID: <4AE495E2.2040800@gmail.com> Date: Sun, 25 Oct 2009 19:16:02 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <4ADED440.2080403@cisco.com> <4AE05EFC.2060501@gmail.com> <4AE41BC4.2050700@cisco.com> <4AE45F61.2000800@gmail.com> <4AE47B4B.2020906@gmail.com> <70909CF7-8087-4284-B90E-CD56CF3CB6FE@thomasclausen.org> In-Reply-To: <70909CF7-8087-4284-B90E-CD56CF3CB6FE@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091024-0, 24/10/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] adhoc unaware parts of the System, regular Internet nodes (was: IPv4 link-locals) 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: Sun, 25 Oct 2009 18:16:00 -0000 ThomasC - I suppose the draft should say something about how AUTOCONF addressing model doesnt cause problems to the adhoc unaware parts of the system, right? (it's a requirement in the Charter): Charter: > The main purpose of the AUTOCONF WG is to describe the addressing model > for ad hoc networks and how nodes in these networks configure their > addresses. It is required that such models do not cause problems for ad > hoc-unaware parts of the system, such as standard applications running > on an ad hoc node or regular Internet nodes attached to the ad hoc > nodes. Thomas Heide Clausen a écrit : > > On Oct 25, 2009, at 5:22 PM, Alexandru Petrescu wrote: > >> Thomas Heide Clausen a écrit : >>> On Oct 25, 2009, at 3:23 PM, Alexandru Petrescu wrote: >>>>>> >>>>> The question is whether autoconf should put cycles into: >>>>> - Making sure IPv4 link-locals are stable and usable within a >>>>> manet, or >>>>> - Making sure IPv4 Private addresses stable and usable within a >>>>> manet, or >>>>> - Making sure IPv4 Global addresses stable and usable within a >>>>> manet, or >>>>> ... all of the above. >>>> >>>> Of course, put that way, one would prefer the last, "make sure the >>>> global addresses are usable and stable"... because one thinks manet >>>> needs it. >>>> >>>> But put it another way: make sure the AUTOCONF results still work >>>> with ad-hoc unaware nodes (as the Charter mentions too) - then one >>>> would prefer to simply not spend any cycles in forbidding something >>>> already deployed. >>>> >>> Alex, >>> Can you explain what in the current document will impact the behavior >>> "ad hoc unaware nodes", and propose a way of rectifying this matter? >> >> Thomas, I have doubts with respect to the use of "discourage" in this >> text: >> >> draft in question says: >>> Note that the use of IPv4 link-local addresses [RFC3927] in this >>> context should be discouraged for most applications >> >> Will an AUTOCONF network discourage the IPv4 LL of an adhoc-unaware >> node by > > Absolutely not. I am not reading the draft as mandating anything on "ad > hoc unaware nodes". Ok, how about about "regular Internet dones" (from the Charter). > Rather, the draft is careful on stating that (I > paraphrase): "If one knows something about the topology, i.e. one is not > in an ad hoc network, USE THAT KNOWLEDGE" Where in the draft? Also - the important thing here (by the Charter) is to say what happens when one _is_ in the ad hoc network, and is adhoc unaware - make sure things dont break. >> sending it ARP packets with its address and somebody else's MAC >> address? (thus making the adhoc unaware node, which implements >> rfc3927, believe it can't use its IPv4 LL in that network.) >> >> If yes - we have an impact problem, as per Charter. It may read as a >> DoS for IPv4 LLs. > > My read is, that for what you call "ad hoc unaware nodes", that document > mandates absolutely nothing. That sounds ok, but the draft should say something about how it doesnt impact the adhoc unaware parts. >> To address this potential problem I propose two alternative paragraphs: >> >> "When IPv4 link-local addresses are available for use in a certain >> node, then they may prove useful for AUTOCONF mechanisms, as they are >> tested for uniqueness. > > Disagree. This i the "wrong way around": a LL address (v4 or v6) cannot > with existing mechanisms be tested for uniqueness and -- even if they > could -- due to node mobility any uniqueness would not be guaranteed to > exist over time. In a sense, I agree, but there are also times where it could be guaranteed - for adhoc unaware nodes. > Hence, if I have a LL address, generated "the usual way" (v4 or v6), > then on an "ad hoc aware node" [to retake your terminology] Ok, sorry, I meant "regular Internet nodes" - which is in the Charter too. Adhoc unaware parts regular Internet nodes > I can not be > sure that it is useful as I do not know of the properties of that > address. IOW, IPv6 prescribes "thou shall have a LL address" -- which is > fine. We observe that "in an ad hoc network, thy better be wary that the > LL address may be of limited use". Which, I think, is also fine. That interpretation is fine. But the text starts by saying how it discourages the IPv4 LLs. >> Future AUTOCONF mechanisms MAY use IPv4 link-local addresses, if >> RFC3927 implementation available, as a starting point in configuring >> publicly routable IPv4 addresses." >> >> XOR >> >> "Future AUTOCONF mechanims should allow the use of IPv4 LLs for adhoc >> unaware nodes and should not allow the use of IPv4 LLs for MANET nodes". >> >> Is this inline with the intention of that [discourage] word? > > No, see above... What does that [discourage] mean with respect to the regular Internet nodes? Let me paste again the disturbing text: >> draft in question says: >>> Note that the use of IPv4 link-local addresses [RFC3927] in this >>> context should be discouraged for most applications Does the context==MANET? If yes, I agree with the paragraph, provided it also says something about how a regular Internet node (adhoc unaware part of the System) _can_ use its IPv4 LL if it wants to. Otherwise, the MANET nodes will never talk to the other parts of the system, the adhoc unaware parts - the regular Internet nodes. Alex > > Thomas > >> >> Alex >> >> >>> Thanks, >>> Thomas >> > > From charles.perkins@earthlink.net Sun Oct 25 11:18: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 E81E728C13F for ; Sun, 25 Oct 2009 11:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 p5mwK5ljXQ-d for ; Sun, 25 Oct 2009 11:18:30 -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 E27373A69B6 for ; Sun, 25 Oct 2009 11:18:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=G7tR5ai0nCs6c5bH+f8d8G8wt3Yv2eEWEc+PSkCXs+LZhAh9SVwPQfGxV2Iqh5MR; 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-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1N27fp-0008AF-UD; Sun, 25 Oct 2009 14:18:38 -0400 Message-ID: <4AE4967E.5040604@earthlink.net> Date: Sun, 25 Oct 2009 11:18:38 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <4AE0AD94.7050800@earthlink.net> <1256491448.4766.30.camel@acorde.it.uc3m.es> In-Reply-To: <1256491448.4766.30.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f525fa6ce4cf7078a5ff6baf3e7dd171348350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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: Sun, 25 Oct 2009 18:18:31 -0000 Hello Carlos, Carlos Jesús Bernardos Cano wrote: > >> [manet] was started as a working group because OSPF and other routing >> protocols were measured to consume well over 100% of the available >> bandwidth (data from NRL). >> >> Which protocols would you like to employ? >> > > Do I need to make a list? do I have to limit only to existing protocols? > there may be also other protocols in the future that what to make use of > link-locals. > O.K. Not an exhaustive list. How about three examples? Or one? > >>> Well, for these scenarios we also propose in the draft to use some of >>> the mechanisms that have been proposed in the past (such as >>> draft-soto-mobileip-random-iids)to reduce the collision probability. >>> >>> >> This is a great idea... BUT: the solution space should not be >> limited to ONLY those solutions that can make use of such >> techniques. >> > > Right, for those that cannot make use of such techniques we could then > develop DAD (or Duplicate Avoidance instead of Detection) mechanisms > that work. Autoconf will hopefully work on solutions some point in time > in the future, working on DAD solutions may be part of the work. > This would be terrible. We can standardize something right now that works very well. The only problem is that we must await this interminable argument about something that is known to cause extraordinary difficulty. Now, even _after_ we have had consensus and a good document to promulgate. In all of the argument, I have never seen even the slightest convincing argument except that link-local is part of the wireline IPv6 addressing scheme. > I also want to avoid limiting the solution space of autoconf only to > solutions that do not use LLs :-D > This has never been at issue. If you have a scheme that uses them, it should receive consideration. If it only works for IEEE MAC addresses, perhaps the charter could be expanded to allow publication of a solution for the restricted problem. > >> I am pretty sure (having been there) that the IPv6 mandates in >> question were placed without regard to the realities of ad hoc >> networks. In fact, I think it can be safely said that these mandates >> are relevant only to networks where certain subnet structures are >> clearly realized. >> > > Then, we should ask to update those standards to reflect this. > Do you really, _really_ want to require [autoconf] to boil the ocean on this? We've already consumed years on haggling over what should have been near-trivial to decide. If you really believe we need to go back and accomplish this titanic task before even standardizing the autoconf use case, I think you should reconsider. > >> And anyway I think it is really important in this context to be >> clear about which protocols are to be put into service, and just >> what is their reliance on link-local addresses. >> ? Regards, Charlie P. From emmanuel.baccelli@gmail.com Sun Oct 25 11:22: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 8029628C135 for ; Sun, 25 Oct 2009 11:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.757 X-Spam-Level: X-Spam-Status: No, score=-1.757 tagged_above=-999 required=5 tests=[AWL=0.219, 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 QabateGaXIFe for ; Sun, 25 Oct 2009 11:22:18 -0700 (PDT) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id D2B7D28C125 for ; Sun, 25 Oct 2009 11:22:17 -0700 (PDT) Received: by ywh13 with SMTP id 13so14562036ywh.29 for ; Sun, 25 Oct 2009 11:22:26 -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=96TKan0ZrmkX+nIyKQov8YvJ1qDYVMJtxOVBxJH6RG0=; b=wdDbPlUfqh5DuyiUeLio0xCO9CDUsjBFuN1ItpzhHbZMchcRSABlqZZZ30cMsLFYwa EWQP23GXWcfVGHfbJRPyX+VLf5i8qhJVxztPt0scDlsjdIqqKdVHTaPVLMOkrhn54y48 T9hYkV/dkx5SprQE8tirYzS0awObb9Bl9axVE= 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=kGISbUWdP9eg571QgU5Ax+jPup94N/1OBHeH/OLXWIyvVXZ6nEg658xuR2P4J/0nRM k/Kea4IvBWP2zZeXrl/mAAecD2Hnzno9JcqGoJ7gbnGuauLFZwJEddBfyAtN8urr9j4E zz6bRwT7HTJRmoIrF0/k4kZb7roCDow8s5KJo= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.101.138.1 with SMTP id q1mr305762ann.44.1256494946156; Sun, 25 Oct 2009 11:22:26 -0700 (PDT) In-Reply-To: <4AE495E2.2040800@gmail.com> References: <4ADED440.2080403@cisco.com> <4AE05EFC.2060501@gmail.com> <4AE41BC4.2050700@cisco.com> <4AE45F61.2000800@gmail.com> <4AE47B4B.2020906@gmail.com> <70909CF7-8087-4284-B90E-CD56CF3CB6FE@thomasclausen.org> <4AE495E2.2040800@gmail.com> From: Emmanuel Baccelli Date: Sun, 25 Oct 2009 19:22:06 +0100 X-Google-Sender-Auth: 4598a2b0aaf5a880 Message-ID: To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=0016e68ee2bced81cb0476c6865f Subject: Re: [Autoconf] adhoc unaware parts of the System, regular Internet nodes (was: IPv4 link-locals) 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: Sun, 25 Oct 2009 18:22:19 -0000 --0016e68ee2bced81cb0476c6865f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alex, obviously, this topic is completely out of scope for the addressing model document, and even for the whole working group! Emmanuel On Sun, Oct 25, 2009 at 7:16 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > ThomasC - I suppose the draft should say something about how AUTOCONF > addressing model doesnt cause problems to the adhoc unaware parts of the > system, right? (it's a requirement in the Charter): > > Charter: > >> The main purpose of the AUTOCONF WG is to describe the addressing model >> for ad hoc networks and how nodes in these networks configure their >> addresses. It is required that such models do not cause problems for ad >> hoc-unaware parts of the system, such as standard applications running >> on an ad hoc node or regular Internet nodes attached to the ad hoc >> nodes. >> > > Thomas Heide Clausen a =E9crit : > >> >> On Oct 25, 2009, at 5:22 PM, Alexandru Petrescu wrote: >> >> Thomas Heide Clausen a =E9crit : >>> >>>> On Oct 25, 2009, at 3:23 PM, Alexandru Petrescu wrote: >>>> >>>>> >>>>>>> The question is whether autoconf should put cycles into: >>>>>> - Making sure IPv4 link-locals are stable and usable within a manet, >>>>>> or >>>>>> - Making sure IPv4 Private addresses stable and usable within a mane= t, >>>>>> or >>>>>> - Making sure IPv4 Global addresses stable and usable within a manet= , >>>>>> or >>>>>> ... all of the above. >>>>>> >>>>> >>>>> Of course, put that way, one would prefer the last, "make sure the >>>>> global addresses are usable and stable"... because one thinks manet n= eeds >>>>> it. >>>>> >>>>> But put it another way: make sure the AUTOCONF results still work wit= h >>>>> ad-hoc unaware nodes (as the Charter mentions too) - then one would p= refer >>>>> to simply not spend any cycles in forbidding something already deploy= ed. >>>>> >>>>> Alex, >>>> Can you explain what in the current document will impact the behavior >>>> "ad hoc unaware nodes", and propose a way of rectifying this matter? >>>> >>> >>> Thomas, I have doubts with respect to the use of "discourage" in this >>> text: >>> >>> draft in question says: >>> >>>> Note that the use of IPv4 link-local addresses [RFC3927] in this >>>> context should be discouraged for most applications >>>> >>> >>> Will an AUTOCONF network discourage the IPv4 LL of an adhoc-unaware nod= e >>> by >>> >> >> Absolutely not. I am not reading the draft as mandating anything on "ad >> hoc unaware nodes". >> > > Ok, how about about "regular Internet dones" (from the Charter). > > Rather, the draft is careful on stating that (I paraphrase): "If one kno= ws >> something about the topology, i.e. one is not in an ad hoc network, USE = THAT >> KNOWLEDGE" >> > > Where in the draft? > > Also - the important thing here (by the Charter) is to say what happens > when one _is_ in the ad hoc network, and is adhoc unaware - make sure thi= ngs > dont break. > > sending it ARP packets with its address and somebody else's MAC address? >>> (thus making the adhoc unaware node, which implements rfc3927, believe= it >>> can't use its IPv4 LL in that network.) >>> >>> If yes - we have an impact problem, as per Charter. It may read as a D= oS >>> for IPv4 LLs. >>> >> >> My read is, that for what you call "ad hoc unaware nodes", that document >> mandates absolutely nothing. >> > > That sounds ok, but the draft should say something about how it doesnt > impact the adhoc unaware parts. > > To address this potential problem I propose two alternative paragraphs: >>> >>> "When IPv4 link-local addresses are available for use in a certain node= , >>> then they may prove useful for AUTOCONF mechanisms, as they are tested = for >>> uniqueness. >>> >> >> Disagree. This i the "wrong way around": a LL address (v4 or v6) cannot >> with existing mechanisms be tested for uniqueness and -- even if they co= uld >> -- due to node mobility any uniqueness would not be guaranteed to exist = over >> time. >> > > In a sense, I agree, but there are also times where it could be guarantee= d > - for adhoc unaware nodes. > > Hence, if I have a LL address, generated "the usual way" (v4 or v6), the= n >> on an "ad hoc aware node" [to retake your terminology] >> > > Ok, sorry, I meant "regular Internet nodes" - which is in the Charter too= . > > Adhoc unaware parts > regular Internet nodes > > I can not be sure that it is useful as I do not know of the properties o= f >> that address. IOW, IPv6 prescribes "thou shall have a LL address" -- whi= ch >> is fine. We observe that "in an ad hoc network, thy better be wary that = the >> LL address may be of limited use". Which, I think, is also fine. >> > > That interpretation is fine. But the text starts by saying how it > discourages the IPv4 LLs. > > Future AUTOCONF mechanisms MAY use IPv4 link-local addresses, if RFC392= 7 >>> implementation available, as a starting point in configuring publicly >>> routable IPv4 addresses." >>> >>> XOR >>> >>> "Future AUTOCONF mechanims should allow the use of IPv4 LLs for adhoc >>> unaware nodes and should not allow the use of IPv4 LLs for MANET nodes"= . >>> >>> Is this inline with the intention of that [discourage] word? >>> >> >> No, see above... >> > > What does that [discourage] mean with respect to the regular Internet > nodes? > > Let me paste again the disturbing text: > > >> draft in question says: > >>> Note that the use of IPv4 link-local addresses [RFC3927] in this > >>> context should be discouraged for most applications > > Does the context=3D=3DMANET? If yes, I agree with the paragraph, provide= d it > also says something about how a regular Internet node (adhoc unaware part= of > the System) _can_ use its IPv4 LL if it wants to. > > Otherwise, the MANET nodes will never talk to the other parts of the > system, the adhoc unaware parts - the regular Internet nodes. > > Alex > > >> Thomas >> >> >>> Alex >>> >>> >>> Thanks, >>>> Thomas >>>> >>> >>> >> >> > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > --0016e68ee2bced81cb0476c6865f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alex,
obviously, this topic is completely out of scope for the addre= ssing model document, and even for the whole working group!
Emman= uel


On Sun, Oct 25,= 2009 at 7:16 PM, Alexandru Petrescu <alexandru.petrescu@gmail.com>= wrote:
ThomasC - I suppose the draft should say so= mething about how AUTOCONF addressing model doesnt cause problems to the ad= hoc unaware parts of the system, right? (it's a requirement in the Char= ter):

Charter:
The main purpose of the AUTOCONF WG is to describe the addressing model
for ad hoc networks and how nodes in these networks configure their
addresses. It is required that such models do not cause problems for ad
hoc-unaware parts of the system, such as standard applications running
on an ad hoc node or regular Internet nodes attached to the ad hoc
nodes.

Thomas Heide Clausen a =E9crit :

On Oct 25, 2009, at 5:22 PM, Alexandru Petrescu wrote:

Thomas Heide Clausen a =E9crit :
On Oct 25, 2009, at 3:23 PM, Alexandru Petrescu wrote:

The question is whether autoconf should put cycles into:
- Making sure IPv4 link-locals are stable and usable within a manet, or
- Making sure IPv4 Private addresses stable and usable within a manet, or - Making sure IPv4 Global addresses stable and usable within a manet, or ... all of the above.

Of course, put that way, one would prefer the last, "make sure the glo= bal addresses are usable and stable"... because one thinks manet needs= it.

But put it another way: make sure the AUTOCONF results still work with ad-h= oc unaware nodes (as the Charter mentions too) - then one would prefer to s= imply not spend any cycles in forbidding something already deployed.

Alex,
Can you explain what in the current document will impact the behavior "= ;ad hoc unaware nodes", and propose a way of rectifying this matter?

Thomas, I have doubts with respect to the use of "discourage" in = this text:

draft in question says:
=A0Note that the use of IPv4 link-local addresses [RFC3927] in this
=A0context should be discouraged for most applications

Will an AUTOCONF network discourage the IPv4 LL of an adhoc-unaware node by=

Absolutely not. I am not reading the draft as mandating anything on "a= d hoc unaware nodes".

Ok, how about about "regular Internet dones" (from the Charter).<= br>
Rather, the draft is careful on stating that (I paraphrase): "If one k= nows something about the topology, i.e. one is not in an ad hoc network, US= E THAT KNOWLEDGE"

Where in the draft?

Also - the important thing here (by the Charter) is to say what happens whe= n one _is_ in the ad hoc network, and is adhoc unaware - make sure things d= ont break.

sending it ARP packets with its address and somebody else's MAC address= ? (thus making the adhoc unaware node, which implements rfc3927, =A0believe= it can't use its IPv4 LL in that network.)

If yes - we have an impact problem, as per Charter. =A0It may read as a DoS= for IPv4 LLs.

My read is, that for what you call "ad hoc unaware nodes", that d= ocument mandates absolutely nothing.

That sounds ok, but the draft should say something about how it doesnt impa= ct the adhoc unaware parts.

To address this potential problem I propose two alternative paragraphs:

"When IPv4 link-local addresses are available for use in a certain nod= e, then they may prove useful for AUTOCONF mechanisms, as they are tested f= or uniqueness.

Disagree. This i the "wrong way around": a LL address (v4 or v6) = cannot with existing mechanisms be tested for uniqueness and -- even if the= y could -- due to node mobility any uniqueness would not be guaranteed to e= xist over time.

In a sense, I agree, but there are also times where it could be guaranteed = - for adhoc unaware nodes.

Hence, if I have a LL address, generated "the usual way" (v4 or v= 6), then on an "ad hoc aware node" [to retake your terminology]

Ok, sorry, I meant "regular Internet nodes" - which is in the Cha= rter too.

Adhoc unaware parts
regular Internet nodes

I can not be sure that it is useful as I do not know of the properties of t= hat address. IOW, IPv6 prescribes "thou shall have a LL address" = -- which is fine. We observe that "in an ad hoc network, thy better be= wary that the LL address may be of limited use". Which, I think, is a= lso fine.

That interpretation is fine. =A0But the text starts by saying how it discou= rages the IPv4 LLs.

=A0Future AUTOCONF mechanisms MAY use IPv4 link-local addresses, if RFC3927= implementation available, as a starting point in configuring publicly rout= able IPv4 addresses."

XOR

"Future AUTOCONF mechanims should allow the use of IPv4 LLs for adhoc = unaware nodes and should not allow the use of IPv4 LLs for MANET nodes"= ;.

Is this inline with the intention of that [discourage] word?

No, see above...

What does that [discourage] mean with respect to the regular Internet nodes= ?

Let me paste again the disturbing text:

>> draft in question says:
>>> =A0 Note that the use of IPv4 link-local addresses [RFC3927] i= n this
>>> =A0 context should be discouraged for most applications

Does the context=3D=3DMANET? =A0If yes, I agree with the paragraph, provide= d it also says something about how a regular Internet node (adhoc unaware p= art of the System) _can_ use its IPv4 LL if it wants to.

Otherwise, the MANET nodes will never talk to the other parts of the system= , the adhoc unaware parts - the regular Internet nodes.

Alex


Thomas


Alex


Thanks,
Thomas




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

--0016e68ee2bced81cb0476c6865f-- From charles.perkins@earthlink.net Sun Oct 25 11:24: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 3443A28C13F for ; Sun, 25 Oct 2009 11:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 UZqjnJ9YbinE for ; Sun, 25 Oct 2009 11:24:40 -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 6291C28C10F for ; Sun, 25 Oct 2009 11:24:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=svialTZTIREpHjhExqF4v7nMyd/Ku3zCcKf8ZqbrL/SgNQuOILhw+Oq8KCA53uJa; 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 1N27ls-0001p1-Je; Sun, 25 Oct 2009 14:24:52 -0400 Message-ID: <4AE497F4.8090007@earthlink.net> Date: Sun, 25 Oct 2009 11:24:52 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <0E0F03A1-EC0C-4FF9-AB17-DB2029F7363E@gmail.com> <1256492329.4766.39.camel@acorde.it.uc3m.es> In-Reply-To: <1256492329.4766.39.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52771d41e884d78c7168a9d2d493fe5c05350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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: Sun, 25 Oct 2009 18:24:41 -0000 Carlos Jesús Bernardos Cano wrote: > > > Sure, but IP is best-effort, so we also need to understand what do we > mean by "guarantee uniqueness"... > This argument is absolutely wrong. You should carefully consider why IP is "best-effort". It isn't about allowing address duplication. I really emphasize that you cannot allow simply any imaginable behavior and justify the result on the basis of "best-effort". That's very wrong. Did I mention that such an argument is quite erroneous and misses the whole point about why IP is described as "best-effort". Oh, and one more thing, ... >> see above. >> AFAIK, It's necessary to make sure the LL address uniqueness if we >> will use it. >> > > Sure, but ensuring address "uniqueness" (the level of guarantee that any > protocol running on IP can expect) does not necessarily mean running DAD > (or at least the DAD mechanism defined in IPv6 standards, we can work on > protocols in autoconf). > Once again you make reference to treating IP as unreliable. That is a wrong justification for relaxing uniqueness. If you want to wrangle this point, I think it should be a long-term goal, and not get in the way of standardizing some techniques already known to work. Regards, Charlie P. From alexandru.petrescu@gmail.com Sun Oct 25 11:29: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 D4FC828C149 for ; Sun, 25 Oct 2009 11:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.299, 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 b1JkP3ZaTqQv for ; Sun, 25 Oct 2009 11:29: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 7DEE83A687C for ; Sun, 25 Oct 2009 11:29:49 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 711F7D480FF; Sun, 25 Oct 2009 19:29:58 +0100 (CET) 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 536BED4809A; Sun, 25 Oct 2009 19:29:56 +0100 (CET) Message-ID: <4AE49924.90805@gmail.com> Date: Sun, 25 Oct 2009 19:29:56 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Emmanuel Baccelli References: <4ADED440.2080403@cisco.com> <4AE05EFC.2060501@gmail.com> <4AE41BC4.2050700@cisco.com> <4AE45F61.2000800@gmail.com> <4AE47B4B.2020906@gmail.com> <70909CF7-8087-4284-B90E-CD56CF3CB6FE@thomasclausen.org> <4AE495E2.2040800@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091024-0, 24/10/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] adhoc unaware parts of the System, regular Internet nodes 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: Sun, 25 Oct 2009 18:29:52 -0000 Emmanuel Baccelli a écrit : > Hi Alex, > obviously, this topic is completely out of scope for the addressing > model document, and even for the whole working group! But it's in the Charter, no? Alex > Emmanuel > > > On Sun, Oct 25, 2009 at 7:16 PM, Alexandru Petrescu > > wrote: > > ThomasC - I suppose the draft should say something about how > AUTOCONF addressing model doesnt cause problems to the adhoc unaware > parts of the system, right? (it's a requirement in the Charter): > > Charter: > > The main purpose of the AUTOCONF WG is to describe the > addressing model > for ad hoc networks and how nodes in these networks configure their > addresses. It is required that such models do not cause problems > for ad > hoc-unaware parts of the system, such as standard applications > running > on an ad hoc node or regular Internet nodes attached to the ad hoc > nodes. > > > Thomas Heide Clausen a écrit : > > > On Oct 25, 2009, at 5:22 PM, Alexandru Petrescu wrote: > > Thomas Heide Clausen a écrit : > > On Oct 25, 2009, at 3:23 PM, Alexandru Petrescu wrote: > > > The question is whether autoconf should put > cycles into: > - Making sure IPv4 link-locals are stable and > usable within a manet, or > - Making sure IPv4 Private addresses stable and > usable within a manet, or > - Making sure IPv4 Global addresses stable and > usable within a manet, or > ... all of the above. > > > Of course, put that way, one would prefer the last, > "make sure the global addresses are usable and > stable"... because one thinks manet needs it. > > But put it another way: make sure the AUTOCONF > results still work with ad-hoc unaware nodes (as the > Charter mentions too) - then one would prefer to > simply not spend any cycles in forbidding something > already deployed. > > Alex, > Can you explain what in the current document will impact > the behavior "ad hoc unaware nodes", and propose a way > of rectifying this matter? > > > Thomas, I have doubts with respect to the use of > "discourage" in this text: > > draft in question says: > > Note that the use of IPv4 link-local addresses > [RFC3927] in this > context should be discouraged for most applications > > > Will an AUTOCONF network discourage the IPv4 LL of an > adhoc-unaware node by > > > Absolutely not. I am not reading the draft as mandating anything > on "ad hoc unaware nodes". > > > Ok, how about about "regular Internet dones" (from the Charter). > > Rather, the draft is careful on stating that (I paraphrase): "If > one knows something about the topology, i.e. one is not in an ad > hoc network, USE THAT KNOWLEDGE" > > > Where in the draft? > > Also - the important thing here (by the Charter) is to say what > happens when one _is_ in the ad hoc network, and is adhoc unaware - > make sure things dont break. > > sending it ARP packets with its address and somebody else's > MAC address? (thus making the adhoc unaware node, which > implements rfc3927, believe it can't use its IPv4 LL in > that network.) > > If yes - we have an impact problem, as per Charter. It may > read as a DoS for IPv4 LLs. > > > My read is, that for what you call "ad hoc unaware nodes", that > document mandates absolutely nothing. > > > That sounds ok, but the draft should say something about how it > doesnt impact the adhoc unaware parts. > > To address this potential problem I propose two alternative > paragraphs: > > "When IPv4 link-local addresses are available for use in a > certain node, then they may prove useful for AUTOCONF > mechanisms, as they are tested for uniqueness. > > > Disagree. This i the "wrong way around": a LL address (v4 or v6) > cannot with existing mechanisms be tested for uniqueness and -- > even if they could -- due to node mobility any uniqueness would > not be guaranteed to exist over time. > > > In a sense, I agree, but there are also times where it could be > guaranteed - for adhoc unaware nodes. > > Hence, if I have a LL address, generated "the usual way" (v4 or > v6), then on an "ad hoc aware node" [to retake your terminology] > > > Ok, sorry, I meant "regular Internet nodes" - which is in the > Charter too. > > Adhoc unaware parts > regular Internet nodes > > I can not be sure that it is useful as I do not know of the > properties of that address. IOW, IPv6 prescribes "thou shall > have a LL address" -- which is fine. We observe that "in an ad > hoc network, thy better be wary that the LL address may be of > limited use". Which, I think, is also fine. > > > That interpretation is fine. But the text starts by saying how it > discourages the IPv4 LLs. > > Future AUTOCONF mechanisms MAY use IPv4 link-local > addresses, if RFC3927 implementation available, as a > starting point in configuring publicly routable IPv4 addresses." > > XOR > > "Future AUTOCONF mechanims should allow the use of IPv4 LLs > for adhoc unaware nodes and should not allow the use of IPv4 > LLs for MANET nodes". > > Is this inline with the intention of that [discourage] word? > > > No, see above... > > > What does that [discourage] mean with respect to the regular > Internet nodes? > > Let me paste again the disturbing text: > > >> draft in question says: > >>> Note that the use of IPv4 link-local addresses [RFC3927] in this > >>> context should be discouraged for most applications > > Does the context==MANET? If yes, I agree with the paragraph, > provided it also says something about how a regular Internet node > (adhoc unaware part of the System) _can_ use its IPv4 LL if it wants to. > > Otherwise, the MANET nodes will never talk to the other parts of the > system, the adhoc unaware parts - the regular Internet nodes. > > Alex > > > Thomas > > > Alex > > > Thanks, > Thomas > > > > > > _______________________________________________ > 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 charles.perkins@earthlink.net Sun Oct 25 11:31: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 4ED2C28C149 for ; Sun, 25 Oct 2009 11:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 WMX0Zxp+5ICs for ; Sun, 25 Oct 2009 11:31:14 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 7D3A43A69B6 for ; Sun, 25 Oct 2009 11:31:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=sYqukMRQ+tV95ttTmetcTCMbmEcKwT4ot1kATlClUsVfVG7Gu4WyFdh0kUCNIoLs; 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-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1N27sE-0004w6-IR; Sun, 25 Oct 2009 13:31:26 -0500 Message-ID: <4AE4997E.6090705@earthlink.net> Date: Sun, 25 Oct 2009 11:31:26 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <1256493151.4766.58.camel@acorde.it.uc3m.es> In-Reply-To: <1256493151.4766.58.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f525a17003596c8f83cf96eb51a02f5dbda350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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: Sun, 25 Oct 2009 18:31:15 -0000 Hello Carlos, Carlos Jesús Bernardos Cano wrote: > > IPv6 mandates LLs, do we really want to > make IPv6 protocols running on MANET be special (in some way) because > this feature of IPv6 is not present in MANETs (i.e. no LLs)? If we say > no, if we want to keep LLs, then we can go into the debate about how to > generate LLs in MANETs (solution space). > I believe we can safely relax the mandate for creation of link-locals. This is not a statement made lightly, but instead based on a long history of making AODV and DYMO and other protocols work on IPv6. It's not that hard to do! > ... Even LL addresses configured > using usual means would probably work in the 99.9% of the scenarios (but > this is just my personal feeling, based on my very limited experience > running IP networks). > Your statement is valid for networks with conformant hosts using IEEE MAC addresses -- but not for all network nodes within the intended sphere of applicability for IPv6 address. Regards, Charlie P. From cjbc@it.uc3m.es Sun Oct 25 11:36: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 DE70728C149 for ; Sun, 25 Oct 2009 11:36:58 -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 AY-W381DFs2p for ; Sun, 25 Oct 2009 11:36:58 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id B9FB53A6883 for ; Sun, 25 Oct 2009 11:36:57 -0700 (PDT) Received: from [192.168.1.209] (82.159.18.172.dyn.user.ono.com [82.159.18.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id B9BB46C2AE3; Sun, 25 Oct 2009 19:37:08 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Charles E. Perkins" In-Reply-To: <4AE497F4.8090007@earthlink.net> References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <0E0F03A1-EC0C-4FF9-AB17-DB2029F7363E@gmail.com> <1256492329.4766.39.camel@acorde.it.uc3m.es> <4AE497F4.8090007@earthlink.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-+zVcUXWodsLWsnhfUZ7B" Organization: Universidad Carlos III de Madrid Date: Sun, 25 Oct 2009 19:37:10 +0100 Message-Id: <1256495830.4766.97.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16970.000 Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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: Sun, 25 Oct 2009 18:36:59 -0000 --=-+zVcUXWodsLWsnhfUZ7B Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable On Sun, 2009-10-25 at 11:24 -0700, Charles E. Perkins wrote: > Carlos Jes=FAs Bernardos Cano wrote: > > > > > > Sure, but IP is best-effort, so we also need to understand what do we > > mean by "guarantee uniqueness"... > > =20 >=20 > This argument is absolutely wrong. You should carefully consider > why IP is "best-effort". It isn't about allowing address duplication. > I really emphasize that you cannot allow simply any imaginable behavior > and justify the result on the basis of "best-effort". That's very wrong. >=20 > Did I mention that such an argument is quite erroneous and misses > the whole point about why IP is described as "best-effort". Current DAD does not prevent a misbehaving/faulty node to configure a duplicated address and we have to live with that. This is what I tried to mean. I consider the probability of address duplication very low (using standard mechanisms, it may even lower if we use something slightly smarter). I guess current DAD cannot guarantee 100% that addresses on a link are always unique, this is what I tried to mean by "best-effort", maybe I didn't use the best possible term. >=20 > Oh, and one more thing, ... >=20 >=20 > >> see above. > >> AFAIK, It's necessary to make sure the LL address uniqueness if we =20 > >> will use it. > >> =20 > > > > Sure, but ensuring address "uniqueness" (the level of guarantee that an= y > > protocol running on IP can expect) does not necessarily mean running DA= D > > (or at least the DAD mechanism defined in IPv6 standards, we can work o= n > > protocols in autoconf). > > =20 >=20 > Once again you make reference to treating IP as unreliable. > That is a wrong justification for relaxing uniqueness. >=20 > If you want to wrangle this point, I think it should be a long-term > goal, and not get in the way of standardizing some techniques already > known to work. Well, I think there are ways of statistically ensure address uniqueness that would work as well. Thanks, Carlos >=20 >=20 > Regards, > Charlie P. >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-+zVcUXWodsLWsnhfUZ7B 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) iEYEABECAAYFAkrkmtYACgkQNdy6TdFwT2fptwCfURlcjpD1SgOFk62oSrG3vPe5 MGIAn3nTxsiaz8lJ7KqkQK3pSOgr9olg =tcmi -----END PGP SIGNATURE----- --=-+zVcUXWodsLWsnhfUZ7B-- From charles.perkins@earthlink.net Sun Oct 25 11:53: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 AE7B828C149 for ; Sun, 25 Oct 2009 11:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 VfRgD3jkuWYT for ; Sun, 25 Oct 2009 11:53:25 -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 C0FD53A69B8 for ; Sun, 25 Oct 2009 11:53:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=BMtV3EGxpmnl62cczC5/Ob9W6cpTLg57J83SlkjrCvOxi71rRI+ZIoXV5gg2mO+D; 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 1N28Di-0004mI-8U; Sun, 25 Oct 2009 14:53:38 -0400 Message-ID: <4AE49EB2.7010305@earthlink.net> Date: Sun, 25 Oct 2009 11:53:38 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <0E0F03A1-EC0C-4FF9-AB17-DB2029F7363E@gmail.com> <1256492329.4766.39.camel@acorde.it.uc3m.es> <4AE497F4.8090007@earthlink.net> <1256495830.4766.97.camel@acorde.it.uc3m.es> In-Reply-To: <1256495830.4766.97.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52e4f1d9f8b79a898237ba3f8ce7e77977350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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: Sun, 25 Oct 2009 18:53:26 -0000 Hello Carlos, Carlos Jesús Bernardos Cano wrote: > On Sun, 2009-10-25 at 11:24 -0700, Charles E. Perkins wrote: > > > Current DAD does not prevent a misbehaving/faulty node to configure a > duplicated address and we have to live with that. This is what I tried > to mean. I consider the probability of address duplication very low > (using standard mechanisms, it may even lower if we use something > slightly smarter). I guess current DAD cannot guarantee 100% that > addresses on a link are always unique, this is what I tried to mean by > "best-effort", maybe I didn't use the best possible term. > In my experience, "best-effort" largely refers to what might otherwise be called "lack of QoS mechanisms". Your point that we can not absolutely guarantee uniqueness is still wrong, I think. When uniqueness isn't guaranteed, the network breaks. If DAD is required, but doesn't resolve the problem, the network breaks. If DAD is required and kills the available network bandwidth, just the mandate is already responsible for killing the network. When an application misses a packet because of overflow of an input buffer on the network interface, that's very much different than when two computers are indistinguishable on the basis of their IP address. > >> Once again you make reference to treating IP as unreliable. >> That is a wrong justification for relaxing uniqueness. >> >> If you want to wrangle this point, I think it should be a long-term >> goal, and not get in the way of standardizing some techniques already >> known to work. >> > > Well, I think there are ways of statistically ensure address uniqueness > that would work as well. > That's all well and good, but unless there is a good reason to mandate these burdensome mechanisms, it would be better to work with the more natural mechanisms that are available. Regards, Charlie P. From thomas@thomasclausen.org Sun Oct 25 14:54: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 E0CBB3A68E9 for ; Sun, 25 Oct 2009 14:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 O94RWPvhseOQ for ; Sun, 25 Oct 2009 14:54:31 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id A2F443A68B3 for ; Sun, 25 Oct 2009 14:54:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id BD48E32317AB; Sun, 25 Oct 2009 14:54:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 522183228040; Sun, 25 Oct 2009 14:54:43 -0700 (PDT) Message-Id: <17800C5F-E014-4010-BF49-E30D32E66CA2@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE495E2.2040800@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: Sun, 25 Oct 2009 22:54:40 +0100 References: <4ADED440.2080403@cisco.com> <4AE05EFC.2060501@gmail.com> <4AE41BC4.2050700@cisco.com> <4AE45F61.2000800@gmail.com> <4AE47B4B.2020906@gmail.com> <70909CF7-8087-4284-B90E-CD56CF3CB6FE@thomasclausen.org> <4AE495E2.2040800@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] adhoc unaware parts of the System, regular Internet nodes (was: IPv4 link-locals) 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: Sun, 25 Oct 2009 21:54:33 -0000 On Oct 25, 2009, at 7:16 PM, Alexandru Petrescu wrote: > ThomasC - I suppose the draft should say something about how =20 > AUTOCONF addressing model doesnt cause problems to the adhoc unaware =20= > parts of the system, right? (it's a requirement in the Charter): > Not really. If I write that "all ThomasC's cars shall be blue" in a draft, do I =20 then also need to also add a note insisting that "note, this doesn't =20 apply to AlexP's cars", even thought this already was explicit that =20 the "blue" statement applied only to ThomasC's cars? Thomas > Charter: >> The main purpose of the AUTOCONF WG is to describe the addressing =20 >> model >> for ad hoc networks and how nodes in these networks configure their >> addresses. It is required that such models do not cause problems =20 >> for ad >> hoc-unaware parts of the system, such as standard applications =20 >> running >> on an ad hoc node or regular Internet nodes attached to the ad hoc >> nodes. > > Thomas Heide Clausen a =E9crit : >> On Oct 25, 2009, at 5:22 PM, Alexandru Petrescu wrote: >>> Thomas Heide Clausen a =E9crit : >>>> On Oct 25, 2009, at 3:23 PM, Alexandru Petrescu wrote: >>>>>>> >>>>>> The question is whether autoconf should put cycles into: >>>>>> - Making sure IPv4 link-locals are stable and usable within a =20 >>>>>> manet, or >>>>>> - Making sure IPv4 Private addresses stable and usable within a =20= >>>>>> manet, or >>>>>> - Making sure IPv4 Global addresses stable and usable within a =20= >>>>>> manet, or >>>>>> ... all of the above. >>>>> >>>>> Of course, put that way, one would prefer the last, "make sure =20 >>>>> the global addresses are usable and stable"... because one =20 >>>>> thinks manet needs it. >>>>> >>>>> But put it another way: make sure the AUTOCONF results still =20 >>>>> work with ad-hoc unaware nodes (as the Charter mentions too) - =20 >>>>> then one would prefer to simply not spend any cycles in =20 >>>>> forbidding something already deployed. >>>>> >>>> Alex, >>>> Can you explain what in the current document will impact the =20 >>>> behavior "ad hoc unaware nodes", and propose a way of rectifying =20= >>>> this matter? >>> >>> Thomas, I have doubts with respect to the use of "discourage" in =20 >>> this text: >>> >>> draft in question says: >>>> Note that the use of IPv4 link-local addresses [RFC3927] in this >>>> context should be discouraged for most applications >>> >>> Will an AUTOCONF network discourage the IPv4 LL of an adhoc-=20 >>> unaware node by >> Absolutely not. I am not reading the draft as mandating anything on =20= >> "ad hoc unaware nodes". > > Ok, how about about "regular Internet dones" (from the Charter). > >> Rather, the draft is careful on stating that (I paraphrase): "If =20 >> one knows something about the topology, i.e. one is not in an ad =20 >> hoc network, USE THAT KNOWLEDGE" > > Where in the draft? > > Also - the important thing here (by the Charter) is to say what =20 > happens when one _is_ in the ad hoc network, and is adhoc unaware - =20= > make sure things dont break. > >>> sending it ARP packets with its address and somebody else's MAC =20 >>> address? (thus making the adhoc unaware node, which implements =20 >>> rfc3927, believe it can't use its IPv4 LL in that network.) >>> >>> If yes - we have an impact problem, as per Charter. It may read =20 >>> as a DoS for IPv4 LLs. >> My read is, that for what you call "ad hoc unaware nodes", that =20 >> document mandates absolutely nothing. > > That sounds ok, but the draft should say something about how it =20 > doesnt impact the adhoc unaware parts. > >>> To address this potential problem I propose two alternative =20 >>> paragraphs: >>> >>> "When IPv4 link-local addresses are available for use in a certain =20= >>> node, then they may prove useful for AUTOCONF mechanisms, as they =20= >>> are tested for uniqueness. >> Disagree. This i the "wrong way around": a LL address (v4 or v6) =20 >> cannot with existing mechanisms be tested for uniqueness and -- =20 >> even if they could -- due to node mobility any uniqueness would not =20= >> be guaranteed to exist over time. > > In a sense, I agree, but there are also times where it could be =20 > guaranteed - for adhoc unaware nodes. > >> Hence, if I have a LL address, generated "the usual way" (v4 or =20 >> v6), then on an "ad hoc aware node" [to retake your terminology] > > Ok, sorry, I meant "regular Internet nodes" - which is in the =20 > Charter too. > > Adhoc unaware parts > regular Internet nodes > >> I can not be sure that it is useful as I do not know of the =20 >> properties of that address. IOW, IPv6 prescribes "thou shall have a =20= >> LL address" -- which is fine. We observe that "in an ad hoc =20 >> network, thy better be wary that the LL address may be of limited =20 >> use". Which, I think, is also fine. > > That interpretation is fine. But the text starts by saying how it =20 > discourages the IPv4 LLs. > >>> Future AUTOCONF mechanisms MAY use IPv4 link-local addresses, if =20 >>> RFC3927 implementation available, as a starting point in =20 >>> configuring publicly routable IPv4 addresses." >>> >>> XOR >>> >>> "Future AUTOCONF mechanims should allow the use of IPv4 LLs for =20 >>> adhoc unaware nodes and should not allow the use of IPv4 LLs for =20 >>> MANET nodes". >>> >>> Is this inline with the intention of that [discourage] word? >> No, see above... > > What does that [discourage] mean with respect to the regular =20 > Internet nodes? > > Let me paste again the disturbing text: > > >> draft in question says: > >>> Note that the use of IPv4 link-local addresses [RFC3927] in this > >>> context should be discouraged for most applications > > Does the context=3D=3DMANET? If yes, I agree with the paragraph, =20 > provided it also says something about how a regular Internet node =20 > (adhoc unaware part of the System) _can_ use its IPv4 LL if it wants =20= > to. > > Otherwise, the MANET nodes will never talk to the other parts of the =20= > system, the adhoc unaware parts - the regular Internet nodes. > > Alex > >> Thomas >>> >>> Alex >>> >>> >>>> Thanks, >>>> Thomas >>> > From ietf@thomasclausen.org Sun Oct 25 14:58:56 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 954843A6900 for ; Sun, 25 Oct 2009 14:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 UJfoj1y8nO8q for ; Sun, 25 Oct 2009 14:58:55 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id E0A313A6801 for ; Sun, 25 Oct 2009 14:58:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 0CA4232317AD; Sun, 25 Oct 2009 14:59:09 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 5FEB53228040; Sun, 25 Oct 2009 14:59:08 -0700 (PDT) Message-Id: <77155058-7CE3-43FC-9662-179C63E3079D@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE495E2.2040800@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 25 Oct 2009 22:59:06 +0100 References: <4ADED440.2080403@cisco.com> <4AE05EFC.2060501@gmail.com> <4AE41BC4.2050700@cisco.com> <4AE45F61.2000800@gmail.com> <4AE47B4B.2020906@gmail.com> <70909CF7-8087-4284-B90E-CD56CF3CB6FE@thomasclausen.org> <4AE495E2.2040800@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] adhoc unaware parts of the System, regular Internet nodes (was: IPv4 link-locals) 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: Sun, 25 Oct 2009 21:58:56 -0000 On Oct 25, 2009, at 7:16 PM, Alexandru Petrescu wrote: > Also - the important thing here (by the Charter) is to say what > happens when one _is_ in the ad hoc network, and is adhoc unaware - > make sure things dont break. I'm trying to see where in the RFC2740 it is specified what happens if a non-OSPFv3 aware router finds itself in an OSPFv3-network. As I can't find anything in 2740, my conjecture would be "that router wouldn't work in that network" -- which seems quite reasonable. Why should ad hoc networks be different? Thomas From ietf@thomasclausen.org Sun Oct 25 14:59:51 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 41F7F3A6900 for ; Sun, 25 Oct 2009 14:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 Dgs8p46L+tmk for ; Sun, 25 Oct 2009 14:59:50 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 2E9723A68B3 for ; Sun, 25 Oct 2009 14:59:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 4D98432317AB; Sun, 25 Oct 2009 15:00:03 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id BD6D93228040; Sun, 25 Oct 2009 15:00:01 -0700 (PDT) Message-Id: <55338E8A-3153-4378-ACC9-9C682651F911@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE49924.90805@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: Sun, 25 Oct 2009 23:00:01 +0100 References: <4ADED440.2080403@cisco.com> <4AE05EFC.2060501@gmail.com> <4AE41BC4.2050700@cisco.com> <4AE45F61.2000800@gmail.com> <4AE47B4B.2020906@gmail.com> <70909CF7-8087-4284-B90E-CD56CF3CB6FE@thomasclausen.org> <4AE495E2.2040800@gmail.com> <4AE49924.90805@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] adhoc unaware parts of the System, regular Internet nodes 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: Sun, 25 Oct 2009 21:59:51 -0000 On Oct 25, 2009, at 7:29 PM, Alexandru Petrescu wrote: > Emmanuel Baccelli a =E9crit : >> Hi Alex, >> obviously, this topic is completely out of scope for the addressing =20= >> model document, and even for the whole working group! > > But it's in the Charter, no? > No - what is in the charter is not what you're implying. Thomas > Alex > >> Emmanuel >> On Sun, Oct 25, 2009 at 7:16 PM, Alexandru Petrescu = > > wrote: >> ThomasC - I suppose the draft should say something about how >> AUTOCONF addressing model doesnt cause problems to the adhoc =20 >> unaware >> parts of the system, right? (it's a requirement in the Charter): >> Charter: >> The main purpose of the AUTOCONF WG is to describe the >> addressing model >> for ad hoc networks and how nodes in these networks =20 >> configure their >> addresses. It is required that such models do not cause =20 >> problems >> for ad >> hoc-unaware parts of the system, such as standard applications >> running >> on an ad hoc node or regular Internet nodes attached to the =20= >> ad hoc >> nodes. >> Thomas Heide Clausen a =E9crit : >> On Oct 25, 2009, at 5:22 PM, Alexandru Petrescu wrote: >> Thomas Heide Clausen a =E9crit : >> On Oct 25, 2009, at 3:23 PM, Alexandru Petrescu wrote: >> The question is whether autoconf should put >> cycles into: >> - Making sure IPv4 link-locals are stable and >> usable within a manet, or >> - Making sure IPv4 Private addresses stable =20= >> and >> usable within a manet, or >> - Making sure IPv4 Global addresses stable and >> usable within a manet, or >> ... all of the above. >> Of course, put that way, one would prefer the =20 >> last, >> "make sure the global addresses are usable and >> stable"... because one thinks manet needs it. >> But put it another way: make sure the AUTOCONF >> results still work with ad-hoc unaware nodes (as =20= >> the >> Charter mentions too) - then one would prefer to >> simply not spend any cycles in forbidding =20 >> something >> already deployed. >> Alex, >> Can you explain what in the current document will =20 >> impact >> the behavior "ad hoc unaware nodes", and propose a way >> of rectifying this matter? >> Thomas, I have doubts with respect to the use of >> "discourage" in this text: >> draft in question says: >> Note that the use of IPv4 link-local addresses >> [RFC3927] in this >> context should be discouraged for most applications >> Will an AUTOCONF network discourage the IPv4 LL of an >> adhoc-unaware node by >> Absolutely not. I am not reading the draft as mandating =20 >> anything >> on "ad hoc unaware nodes". >> Ok, how about about "regular Internet dones" (from the Charter). >> Rather, the draft is careful on stating that (I paraphrase): =20= >> "If >> one knows something about the topology, i.e. one is not in =20 >> an ad >> hoc network, USE THAT KNOWLEDGE" >> Where in the draft? >> Also - the important thing here (by the Charter) is to say what >> happens when one _is_ in the ad hoc network, and is adhoc =20 >> unaware - >> make sure things dont break. >> sending it ARP packets with its address and somebody =20 >> else's >> MAC address? (thus making the adhoc unaware node, which >> implements rfc3927, believe it can't use its IPv4 LL in >> that network.) >> If yes - we have an impact problem, as per Charter. It =20= >> may >> read as a DoS for IPv4 LLs. >> My read is, that for what you call "ad hoc unaware nodes", =20 >> that >> document mandates absolutely nothing. >> That sounds ok, but the draft should say something about how it >> doesnt impact the adhoc unaware parts. >> To address this potential problem I propose two =20 >> alternative >> paragraphs: >> "When IPv4 link-local addresses are available for use in a >> certain node, then they may prove useful for AUTOCONF >> mechanisms, as they are tested for uniqueness. >> Disagree. This i the "wrong way around": a LL address (v4 or =20= >> v6) >> cannot with existing mechanisms be tested for uniqueness and =20= >> -- >> even if they could -- due to node mobility any uniqueness =20 >> would >> not be guaranteed to exist over time. >> In a sense, I agree, but there are also times where it could be >> guaranteed - for adhoc unaware nodes. >> Hence, if I have a LL address, generated "the usual way" (v4 =20= >> or >> v6), then on an "ad hoc aware node" [to retake your =20 >> terminology] >> Ok, sorry, I meant "regular Internet nodes" - which is in the >> Charter too. >> Adhoc unaware parts >> regular Internet nodes >> I can not be sure that it is useful as I do not know of the >> properties of that address. IOW, IPv6 prescribes "thou shall >> have a LL address" -- which is fine. We observe that "in an ad >> hoc network, thy better be wary that the LL address may be of >> limited use". Which, I think, is also fine. >> That interpretation is fine. But the text starts by saying how it >> discourages the IPv4 LLs. >> Future AUTOCONF mechanisms MAY use IPv4 link-local >> addresses, if RFC3927 implementation available, as a >> starting point in configuring publicly routable IPv4 =20 >> addresses." >> XOR >> "Future AUTOCONF mechanims should allow the use of IPv4 =20= >> LLs >> for adhoc unaware nodes and should not allow the use of =20= >> IPv4 >> LLs for MANET nodes". >> Is this inline with the intention of that [discourage] =20 >> word? >> No, see above... >> What does that [discourage] mean with respect to the regular >> Internet nodes? >> Let me paste again the disturbing text: >> >> draft in question says: >> >>> Note that the use of IPv4 link-local addresses [RFC3927] =20= >> in this >> >>> context should be discouraged for most applications >> Does the context=3D=3DMANET? If yes, I agree with the paragraph, >> provided it also says something about how a regular Internet node >> (adhoc unaware part of the System) _can_ use its IPv4 LL if it =20 >> wants to. >> Otherwise, the MANET nodes will never talk to the other parts of =20= >> the >> system, the adhoc unaware parts - the regular Internet nodes. >> Alex >> Thomas >> Alex >> Thanks, >> Thomas >> _______________________________________________ >> 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 From cjbc@it.uc3m.es Sun Oct 25 16:39: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 8D7DF3A6841 for ; Sun, 25 Oct 2009 16:39:32 -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 ZK39v5o4BS3d for ; Sun, 25 Oct 2009 16:39:31 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 57B873A6963 for ; Sun, 25 Oct 2009 16:39:31 -0700 (PDT) Received: from [192.168.1.209] (82.159.18.172.dyn.user.ono.com [82.159.18.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 734AB7F417C; Mon, 26 Oct 2009 00:39:42 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Charles E. Perkins" In-Reply-To: <4AE49EB2.7010305@earthlink.net> References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <0E0F03A1-EC0C-4FF9-AB17-DB2029F7363E@gmail.com> <1256492329.4766.39.camel@acorde.it.uc3m.es> <4AE497F4.8090007@earthlink.net> <1256495830.4766.97.camel@acorde.it.uc3m.es> <4AE49EB2.7010305@earthlink.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-3JRGTerx4tWBjQwtCUKP" Organization: Universidad Carlos III de Madrid Date: Mon, 26 Oct 2009 00:39:44 +0100 Message-Id: <1256513984.4766.169.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16970.003 Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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: Sun, 25 Oct 2009 23:39:32 -0000 --=-3JRGTerx4tWBjQwtCUKP Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Charlie, On Sun, 2009-10-25 at 11:53 -0700, Charles E. Perkins wrote: > Hello Carlos, >=20 > Carlos Jes=FAs Bernardos Cano wrote: > > On Sun, 2009-10-25 at 11:24 -0700, Charles E. Perkins wrote: > > =20 > > > > Current DAD does not prevent a misbehaving/faulty node to configure a > > duplicated address and we have to live with that. This is what I tried > > to mean. I consider the probability of address duplication very low > > (using standard mechanisms, it may even lower if we use something > > slightly smarter). I guess current DAD cannot guarantee 100% that > > addresses on a link are always unique, this is what I tried to mean by > > "best-effort", maybe I didn't use the best possible term. > > =20 >=20 > In my experience, "best-effort" largely refers to what might > otherwise be called "lack of QoS mechanisms". >=20 > Your point that we can not absolutely guarantee uniqueness > is still wrong, I think. When uniqueness isn't guaranteed, the > network breaks. If DAD is required, but doesn't resolve the > problem, the network breaks. If DAD is required and kills > the available network bandwidth, just the mandate is already > responsible for killing the network. Fully agree. However, I think we can avoid duplicates (at least statistically or just react when they are detected passively) without using active DAD mechanisms that kill the network. >=20 > When an application misses a packet because of overflow > of an input buffer on the network interface, that's very much > different than when two computers are indistinguishable on > the basis of their IP address. Still, unless SEND is used, there is now guarantee that once a node is granted an IP address, the node remains being the only one that can use it. >=20 > > > >> Once again you make reference to treating IP as unreliable. > >> That is a wrong justification for relaxing uniqueness. > >> > >> If you want to wrangle this point, I think it should be a long-term > >> goal, and not get in the way of standardizing some techniques already > >> known to work. > >> =20 > > > > Well, I think there are ways of statistically ensure address uniqueness > > that would work as well. > > =20 >=20 > That's all well and good, but unless there is a good reason to > mandate these burdensome mechanisms, it would be better to > work with the more natural mechanisms that are available. Anyway, we are gonna have also similar problems ensuring address uniqueness for non-link local addresses, right? Thanks for the discussion, Carlos >=20 > Regards, > Charlie P. >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-3JRGTerx4tWBjQwtCUKP 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) iEYEABECAAYFAkrk4cAACgkQNdy6TdFwT2f2eACg2UmjOuoDtHYnKrY60xD4un04 LfMAoMXpZJlcJ2COdG7N+OYV8JKQWyEo =6oOz -----END PGP SIGNATURE----- --=-3JRGTerx4tWBjQwtCUKP-- From cjbc@it.uc3m.es Sun Oct 25 16:40: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 701383A6A05 for ; Sun, 25 Oct 2009 16:40:55 -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 yZJCfQpeBETo for ; Sun, 25 Oct 2009 16:40:54 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 3CA893A6841 for ; Sun, 25 Oct 2009 16:40:54 -0700 (PDT) Received: from [192.168.1.209] (82.159.18.172.dyn.user.ono.com [82.159.18.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id C29BEBA0222; Mon, 26 Oct 2009 00:41:05 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Charles E. Perkins" In-Reply-To: <4AE4997E.6090705@earthlink.net> References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <1256493151.4766.58.camel@acorde.it.uc3m.es> <4AE4997E.6090705@earthlink.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-uLX0v+Qb7w3Y5cYJTx07" Organization: Universidad Carlos III de Madrid Date: Mon, 26 Oct 2009 00:41:07 +0100 Message-Id: <1256514067.4766.171.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16970.003 Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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: Sun, 25 Oct 2009 23:40:56 -0000 --=-uLX0v+Qb7w3Y5cYJTx07 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Charlie, On Sun, 2009-10-25 at 11:31 -0700, Charles E. Perkins wrote: > Hello Carlos, >=20 > Carlos Jes=FAs Bernardos Cano wrote: > > > > IPv6 mandates LLs, do we really want to > > make IPv6 protocols running on MANET be special (in some way) because > > this feature of IPv6 is not present in MANETs (i.e. no LLs)? If we say > > no, if we want to keep LLs, then we can go into the debate about how to > > generate LLs in MANETs (solution space). > > =20 >=20 > I believe we can safely relax the mandate for creation > of link-locals. This is not a statement made lightly, but > instead based on a long history of making AODV and DYMO > and other protocols work on IPv6. It's not that hard to do! >=20 >=20 > > ... Even LL addresses configured > > using usual means would probably work in the 99.9% of the scenarios (bu= t > > this is just my personal feeling, based on my very limited experience > > running IP networks). > > =20 >=20 > Your statement is valid for networks with conformant hosts using > IEEE MAC addresses -- but not for all network nodes within the > intended sphere of applicability for IPv6 address. True, for those not using MAC addresses, I think using random iids will just make the work OK. Thanks, Carlos >=20 > Regards, > Charlie P. >=20 >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-uLX0v+Qb7w3Y5cYJTx07 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) iEYEABECAAYFAkrk4hMACgkQNdy6TdFwT2fznwCg5lKx/wPCRiRZ8fS/6M8Iq9r5 MjwAnieUzQSwkecOlGmLcdUKig5PmYNO =scBO -----END PGP SIGNATURE----- --=-uLX0v+Qb7w3Y5cYJTx07-- From charles.perkins@earthlink.net Sun Oct 25 17:21: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 4BB843A679F for ; Sun, 25 Oct 2009 17:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 HcVE3Xk0A4wz for ; Sun, 25 Oct 2009 17:21:28 -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 5695A3A659B for ; Sun, 25 Oct 2009 17:21:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=uGROwndQoWf+r1CsscPqlaL4YGeFpM8/1DWqNnlD0Ovhamnu02kKlRJLxav2zTVA; 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-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1N2DLA-0004kx-O4; Sun, 25 Oct 2009 20:21:40 -0400 Message-ID: <4AE4EB94.6020101@earthlink.net> Date: Sun, 25 Oct 2009 17:21:40 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <0E0F03A1-EC0C-4FF9-AB17-DB2029F7363E@gmail.com> <1256492329.4766.39.camel@acorde.it.uc3m.es> <4AE497F4.8090007@earthlink.net> <1256495830.4766.97.camel@acorde.it.uc3m.es> <4AE49EB2.7010305@earthlink.net> <1256513984.4766.169.camel@acorde.it.uc3m.es> In-Reply-To: <1256513984.4766.169.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f521993a8027cab5a3ecf541d94a009b568350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 00:21:29 -0000 Hello Carlos, Carlos Jesús Bernardos Cano wrote: > >> In my experience, "best-effort" largely refers to what might >> otherwise be called "lack of QoS mechanisms". >> >> Your point that we can not absolutely guarantee uniqueness >> is still wrong, I think. When uniqueness isn't guaranteed, the >> network breaks. If DAD is required, but doesn't resolve the >> problem, the network breaks. If DAD is required and kills >> the available network bandwidth, just the mandate is already >> responsible for killing the network. >> > > Fully agree. However, I think we can avoid duplicates (at least > statistically or just react when they are detected passively) without > using active DAD mechanisms that kill the network. > That opinion is in conflict with a very stable consensus during the design of IPv6, to the effect that that one could not depend on randomness. This point has already been discussed in [autoconf] at least a half-dozen times. > > > Still, unless SEND is used, there is now guarantee that once a node is > granted an IP address, the node remains being the only one that can use > it. > Sure, malicious nodes can break a network by masquerading as another IP address. That is really drastically different than designing such pitfalls into the basic autoconfiguration protocols in the first place. > >> That's all well and good, but unless there is a good reason to >> mandate these burdensome mechanisms, it would be better to >> work with the more natural mechanisms that are available. >> > > Anyway, we are gonna have also similar problems ensuring address > uniqueness for non-link local addresses, right? > This has also been discussed many times. It is very important to distinguish, because non-local addresses can be meaningfully carried as fields in a signaling message payload that can be forwarded. To do anything similar for link-local addresses is, to put it mildly, challenging. Unless you want to do everything at layer 2. Even so, I am remembering scatternets. Not trivial -- and much harder to really deploy than initially imagined. Did you ever see one? Regards, Charlie P. From charles.perkins@earthlink.net Sun Oct 25 17:29: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 E501E3A687D for ; Sun, 25 Oct 2009 17:29:26 -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 EitnhDh7SWSf for ; Sun, 25 Oct 2009 17:29:26 -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 18A793A67EC for ; Sun, 25 Oct 2009 17:29:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=qNP6PEC3oJ6mpDXO1Aaj+7nOndcxDpVwmnQQCAdhlKrj7sQTqxVcGNTZk+UQKNd7; 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 1N2DSs-0008Aq-Cq; Sun, 25 Oct 2009 20:29:38 -0400 Message-ID: <4AE4ED72.9000707@earthlink.net> Date: Sun, 25 Oct 2009 17:29:38 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <1256493151.4766.58.camel@acorde.it.uc3m.es> <4AE4997E.6090705@earthlink.net> <1256514067.4766.171.camel@acorde.it.uc3m.es> In-Reply-To: <1256514067.4766.171.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f528d52640de93c4ba9186aeb0c54120cca350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 00:29:27 -0000 Hello Carlos, Carlos Jesús Bernardos Cano wrote: > >> Your statement is valid for networks with conformant hosts using >> IEEE MAC addresses -- but not for all network nodes within the >> intended sphere of applicability for IPv6 address. >> > > True, for those not using MAC addresses, I think using random iids will > just make the work OK. > > Actually, not. Please see my other message. But, one more thing. This philosophy is especially bad because you will, statistically, _never_ encounter any bugs in your lab networks. Then when your bug shows up in a network with ten million nodes, you might never find it. Never. But maybe you would claim that we must then rely on the small size of ad hoc networks. At least it would be easier to find your bug, but it would be extremely tedious and difficult to trust any debugging tools or your intuition. We can't eliminate the need for address uniqueness by waving the wand of randomness. Regards, Charlie P. From teco@inf-net.nl Mon Oct 26 01:42: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 152783A6906 for ; Mon, 26 Oct 2009 01:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.015 X-Spam-Level: X-Spam-Status: No, score=-0.015 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 iEeBbZVE3ulI for ; Mon, 26 Oct 2009 01:42:07 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id BBA623A689A for ; Mon, 26 Oct 2009 01:42:06 -0700 (PDT) Received: (qmail 3218 invoked from network); 26 Oct 2009 09:42:17 +0100 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 26 Oct 2009 09:42:17 +0100 From: "Teco Boot" To: "'Thomas Heide Clausen'" References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> In-Reply-To: Date: Mon, 26 Oct 2009 09:41:45 +0100 Message-ID: <005801ca5618$38d35be0$aa7a13a0$@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: AcpVmjz83Z/TAYhrQA66OZid6hiHDwAfZKRw Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 08:42:08 -0000 >Thomas Heide Clausen wrote: > o If you have an LL address [generated by the usual means], it may > be useless. Use it if you like, but be wary that the properties of > that address are undefined. LL may be useful also. Properties of LL are well defined. Regards, Teco From thomas@thomasclausen.org Mon Oct 26 01: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 591663A6A48 for ; Mon, 26 Oct 2009 01:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 g3hbvI5wfkuj for ; Mon, 26 Oct 2009 01:48:27 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id B37863A69D2 for ; Mon, 26 Oct 2009 01:48:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 3CC1532317AD; Mon, 26 Oct 2009 01:48:41 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 8BDBA32317AB; Mon, 26 Oct 2009 01:48:40 -0700 (PDT) Message-Id: From: Thomas Heide Clausen To: "Teco Boot" In-Reply-To: <005801ca5618$38d35be0$aa7a13a0$@nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 09:48:38 +0100 References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <005801ca5618$38d35be0$aa7a13a0$@nl> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 08:48:28 -0000 On Oct 26, 2009, at 9:41 AM, Teco Boot wrote: >> Thomas Heide Clausen wrote: >> o If you have an LL address [generated by the usual means], it may >> be useless. Use it if you like, but be wary that the properties of >> that address are undefined. > > LL may be useful also. > Properties of LL are well defined. If by "Well defined [in a MANET]" you mean "unique only within a 1-hop radius and also only unique within that 1-hop radius at the very instant when DAD is testing uniqueness -- not guaranteed to be unique beyond 1-hop and nor even an instant after DAD has completed" then yes, LL properties are "well defined [in a MANET]" when using the usual means of getting LLs. I'd question if that's useful, though. Thomas From alexandru.petrescu@gmail.com Mon Oct 26 01:51: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 3D8483A6A4A for ; Mon, 26 Oct 2009 01:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=0.152, 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 c8I7WazlFvpU for ; Mon, 26 Oct 2009 01:51:24 -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 3EFFA3A6A49 for ; Mon, 26 Oct 2009 01:51:24 -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 n9Q8pZ42017086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 09:51:35 +0100 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 n9Q8pZMD021341; Mon, 26 Oct 2009 09:51:35 +0100 (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 n9Q8pYGd006724; Mon, 26 Oct 2009 09:51:35 +0100 Message-ID: <4AE56316.2080207@gmail.com> Date: Mon, 26 Oct 2009 09:51:34 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <4ADED440.2080403@cisco.com> <4AE05EFC.2060501@gmail.com> <4AE41BC4.2050700@cisco.com> <4AE45F61.2000800@gmail.com> <4AE47B4B.2020906@gmail.com> <70909CF7-8087-4284-B90E-CD56CF3CB6FE@thomasclausen.org> <4AE495E2.2040800@gmail.com> <77155058-7CE3-43FC-9662-179C63E3079D@thomasclausen.org> In-Reply-To: <77155058-7CE3-43FC-9662-179C63E3079D@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] adhoc unaware parts of the System, regular Internet nodes 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, 26 Oct 2009 08:51:25 -0000 Thomas Heide Clausen a écrit : > > On Oct 25, 2009, at 7:16 PM, Alexandru Petrescu wrote: > > >> Also - the important thing here (by the Charter) is to say what >> happens when one _is_ in the ad hoc network, and is adhoc unaware - >> make sure things dont break. > > I'm trying to see where in the RFC2740 it is specified what happens if a > non-OSPFv3 aware router finds itself in an OSPFv3-network. As I can't > find anything in 2740, my conjecture would be "that router wouldn't work > in that network" -- which seems quite reasonable. > > Why should ad hoc networks be different? Thomas, it is a req in the Charter: > The main purpose of the AUTOCONF WG is to describe the addressing model > for ad hoc networks and how nodes in these networks configure their > addresses. It is required that such models do not cause problems for ad > hoc-unaware parts of the system, such as standard applications running > on an ad hoc node or regular Internet nodes attached to the ad hoc > nodes. One way to satisfy that requirement is to write about it. Alex > Thomas > > From alexandru.petrescu@gmail.com Mon Oct 26 01:52: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 825883A6A4E for ; Mon, 26 Oct 2009 01:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=0.146, 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 DbrtM6XnAf3r for ; Mon, 26 Oct 2009 01:52:13 -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 12B8F3A6A4C for ; Mon, 26 Oct 2009 01:52:12 -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 n9Q8qOGL017481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 09:52:25 +0100 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 n9Q8qOB1021602; Mon, 26 Oct 2009 09:52:24 +0100 (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 n9Q8qO8m006989; Mon, 26 Oct 2009 09:52:24 +0100 Message-ID: <4AE56348.4050701@gmail.com> Date: Mon, 26 Oct 2009 09:52:24 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <4ADED440.2080403@cisco.com> <4AE05EFC.2060501@gmail.com> <4AE41BC4.2050700@cisco.com> <4AE45F61.2000800@gmail.com> <4AE47B4B.2020906@gmail.com> <70909CF7-8087-4284-B90E-CD56CF3CB6FE@thomasclausen.org> <4AE495E2.2040800@gmail.com> <4AE49924.90805@gmail.com> <55338E8A-3153-4378-ACC9-9C682651F911@thomasclausen.org> In-Reply-To: <55338E8A-3153-4378-ACC9-9C682651F911@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] adhoc unaware parts of the System, regular Internet nodes 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, 26 Oct 2009 08:52:14 -0000 Thomas Heide Clausen a écrit : > > On Oct 25, 2009, at 7:29 PM, Alexandru Petrescu wrote: > >> Emmanuel Baccelli a écrit : >>> Hi Alex, >>> obviously, this topic is completely out of scope for the addressing >>> model document, and even for the whole working group! >> >> But it's in the Charter, no? >> > > No - what is in the charter is not what you're implying. Please interpret this for me: > It is required that such models do not cause problems for ad > hoc-unaware parts of the system, such as standard applications running > on an ad hoc node or regular Internet nodes attached to the ad hoc > nodes. Alex > > Thomas > >> Alex >> >>> Emmanuel >>> On Sun, Oct 25, 2009 at 7:16 PM, Alexandru Petrescu >>> > >>> wrote: >>> ThomasC - I suppose the draft should say something about how >>> AUTOCONF addressing model doesnt cause problems to the adhoc unaware >>> parts of the system, right? (it's a requirement in the Charter): >>> Charter: >>> The main purpose of the AUTOCONF WG is to describe the >>> addressing model >>> for ad hoc networks and how nodes in these networks configure >>> their >>> addresses. It is required that such models do not cause problems >>> for ad >>> hoc-unaware parts of the system, such as standard applications >>> running >>> on an ad hoc node or regular Internet nodes attached to the ad >>> hoc >>> nodes. >>> Thomas Heide Clausen a écrit : >>> On Oct 25, 2009, at 5:22 PM, Alexandru Petrescu wrote: >>> Thomas Heide Clausen a écrit : >>> On Oct 25, 2009, at 3:23 PM, Alexandru Petrescu wrote: >>> The question is whether autoconf should put >>> cycles into: >>> - Making sure IPv4 link-locals are stable and >>> usable within a manet, or >>> - Making sure IPv4 Private addresses stable and >>> usable within a manet, or >>> - Making sure IPv4 Global addresses stable and >>> usable within a manet, or >>> ... all of the above. >>> Of course, put that way, one would prefer the last, >>> "make sure the global addresses are usable and >>> stable"... because one thinks manet needs it. >>> But put it another way: make sure the AUTOCONF >>> results still work with ad-hoc unaware nodes (as the >>> Charter mentions too) - then one would prefer to >>> simply not spend any cycles in forbidding something >>> already deployed. >>> Alex, >>> Can you explain what in the current document will impact >>> the behavior "ad hoc unaware nodes", and propose a way >>> of rectifying this matter? >>> Thomas, I have doubts with respect to the use of >>> "discourage" in this text: >>> draft in question says: >>> Note that the use of IPv4 link-local addresses >>> [RFC3927] in this >>> context should be discouraged for most applications >>> Will an AUTOCONF network discourage the IPv4 LL of an >>> adhoc-unaware node by >>> Absolutely not. I am not reading the draft as mandating anything >>> on "ad hoc unaware nodes". >>> Ok, how about about "regular Internet dones" (from the Charter). >>> Rather, the draft is careful on stating that (I paraphrase): "If >>> one knows something about the topology, i.e. one is not in an ad >>> hoc network, USE THAT KNOWLEDGE" >>> Where in the draft? >>> Also - the important thing here (by the Charter) is to say what >>> happens when one _is_ in the ad hoc network, and is adhoc unaware - >>> make sure things dont break. >>> sending it ARP packets with its address and somebody else's >>> MAC address? (thus making the adhoc unaware node, which >>> implements rfc3927, believe it can't use its IPv4 LL in >>> that network.) >>> If yes - we have an impact problem, as per Charter. It may >>> read as a DoS for IPv4 LLs. >>> My read is, that for what you call "ad hoc unaware nodes", that >>> document mandates absolutely nothing. >>> That sounds ok, but the draft should say something about how it >>> doesnt impact the adhoc unaware parts. >>> To address this potential problem I propose two alternative >>> paragraphs: >>> "When IPv4 link-local addresses are available for use in a >>> certain node, then they may prove useful for AUTOCONF >>> mechanisms, as they are tested for uniqueness. >>> Disagree. This i the "wrong way around": a LL address (v4 or v6) >>> cannot with existing mechanisms be tested for uniqueness and -- >>> even if they could -- due to node mobility any uniqueness would >>> not be guaranteed to exist over time. >>> In a sense, I agree, but there are also times where it could be >>> guaranteed - for adhoc unaware nodes. >>> Hence, if I have a LL address, generated "the usual way" (v4 or >>> v6), then on an "ad hoc aware node" [to retake your terminology] >>> Ok, sorry, I meant "regular Internet nodes" - which is in the >>> Charter too. >>> Adhoc unaware parts >>> regular Internet nodes >>> I can not be sure that it is useful as I do not know of the >>> properties of that address. IOW, IPv6 prescribes "thou shall >>> have a LL address" -- which is fine. We observe that "in an ad >>> hoc network, thy better be wary that the LL address may be of >>> limited use". Which, I think, is also fine. >>> That interpretation is fine. But the text starts by saying how it >>> discourages the IPv4 LLs. >>> Future AUTOCONF mechanisms MAY use IPv4 link-local >>> addresses, if RFC3927 implementation available, as a >>> starting point in configuring publicly routable IPv4 >>> addresses." >>> XOR >>> "Future AUTOCONF mechanims should allow the use of IPv4 LLs >>> for adhoc unaware nodes and should not allow the use of IPv4 >>> LLs for MANET nodes". >>> Is this inline with the intention of that [discourage] word? >>> No, see above... >>> What does that [discourage] mean with respect to the regular >>> Internet nodes? >>> Let me paste again the disturbing text: >>> >> draft in question says: >>> >>> Note that the use of IPv4 link-local addresses [RFC3927] in >>> this >>> >>> context should be discouraged for most applications >>> Does the context==MANET? If yes, I agree with the paragraph, >>> provided it also says something about how a regular Internet node >>> (adhoc unaware part of the System) _can_ use its IPv4 LL if it >>> wants to. >>> Otherwise, the MANET nodes will never talk to the other parts of the >>> system, the adhoc unaware parts - the regular Internet nodes. >>> Alex >>> Thomas >>> Alex >>> Thanks, >>> Thomas >>> _______________________________________________ >>> 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 > > From teco@inf-net.nl Mon Oct 26 01:56: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 502CD28C162 for ; Mon, 26 Oct 2009 01:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, 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 rRaTWMtv1q4i for ; Mon, 26 Oct 2009 01:56:57 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 2638528C12A for ; Mon, 26 Oct 2009 01:56:56 -0700 (PDT) Received: (qmail 17028 invoked from network); 26 Oct 2009 09:57:03 +0100 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 26 Oct 2009 09:57:03 +0100 From: "Teco Boot" To: "'Charles E. Perkins'" References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <1256493151.4766.58.camel@acorde.it.uc3m.es> <4AE4997E.6090705@earthlink.net> <1256514067.4766.171.camel@acorde.it.uc3m.es> <4AE4ED72.9000707@earthlink.net> In-Reply-To: <4AE4ED72.9000707@earthlink.net> Date: Mon, 26 Oct 2009 09:56:30 +0100 Message-ID: <005901ca561a$48e6e3b0$dab4ab10$@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: AcpV02tKDC1IKNNASNOFNt1EOG/OVAARjDVQ Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 08:56:58 -0000 Charlie, I experienced multiple times a network down in a production network = caused by=20 duplicate detection mechanism bugs. These were severity 1 problems, = because all=20 nodes were affected. A duplicate problem primary affects those who have the duplicates. There = can be=20 an increased network load or other effects, I do not deny the problem. Regards, Teco >-----Oorspronkelijk bericht----- >Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] = Namens >Charles E. Perkins >Verzonden: maandag 26 oktober 2009 1:30 >Aan: cjbc@it.uc3m.es >CC: autoconf@ietf.org >Onderwerp: Re: [Autoconf] I-D Action:draft-bernardos-autoconf- >addressing-model-00.txt > > >Hello Carlos, > >Carlos Jes=FAs Bernardos Cano wrote: >> >>> Your statement is valid for networks with conformant hosts using >>> IEEE MAC addresses -- but not for all network nodes within the >>> intended sphere of applicability for IPv6 address. >>> >> >> True, for those not using MAC addresses, I think using random iids >will >> just make the work OK. >> >> > >Actually, not. > >Please see my other message. > >But, one more thing. > >This philosophy is especially bad because you >will, statistically, _never_ encounter any bugs in >your lab networks. > >Then when your bug shows up in a network >with ten million nodes, you might never find it. > >Never. > >But maybe you would claim that we must then >rely on the small size of ad hoc networks. >At least it would be easier to find your bug, but >it would be extremely tedious and difficult to >trust any debugging tools or your intuition. > >We can't eliminate the need for address >uniqueness by waving the wand of randomness. > >Regards, >Charlie P. > >_______________________________________________ >Autoconf mailing list >Autoconf@ietf.org >https://www.ietf.org/mailman/listinfo/autoconf From teco@inf-net.nl Mon Oct 26 02:00:20 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 5A30B28C206 for ; Mon, 26 Oct 2009 02:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.132 X-Spam-Level: X-Spam-Status: No, score=-1.132 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, 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 kesNZ8xk5iuF for ; Mon, 26 Oct 2009 02:00:19 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 6D57028C201 for ; Mon, 26 Oct 2009 02:00:18 -0700 (PDT) Received: (qmail 20049 invoked from network); 26 Oct 2009 10:00:29 +0100 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 26 Oct 2009 10:00:29 +0100 From: "Teco Boot" To: "'Thomas Heide Clausen'" References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <005801ca5618$38d35be0$aa7a13a0$@nl> In-Reply-To: Date: Mon, 26 Oct 2009 09:59:56 +0100 Message-ID: <005a01ca561a$c3db0650$4b9112f0$@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: AcpWGR+6GEeRo99TRDilGienkxKNTgAASQOw Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 09:00:20 -0000 >-----Oorspronkelijk bericht----- >Van: Thomas Heide Clausen [mailto:thomas@thomasclausen.org] >Verzonden: maandag 26 oktober 2009 9:49 >Aan: Teco Boot >CC: autoconf@ietf.org >Onderwerp: Re: [Autoconf] I-D Action:draft-bernardos-autoconf- >addressing-model-00.txt > > >On Oct 26, 2009, at 9:41 AM, Teco Boot wrote: > >>> Thomas Heide Clausen wrote: >>> o If you have an LL address [generated by the usual means], it may >>> be useless. Use it if you like, but be wary that the properties of >>> that address are undefined. >> >> LL may be useful also. >> Properties of LL are well defined. > >If by "Well defined [in a MANET]" you mean "unique only within a 1-hop >radius and also only unique within that 1-hop radius at the very >instant when DAD is testing uniqueness -- not guaranteed to be unique >beyond 1-hop and nor even an instant after DAD has completed" then >yes, LL properties are "well defined [in a MANET]" when using the >usual means of getting LLs. > >I'd question if that's useful, though. Some protocols require a 1-hop scope. LLs are made for this. DAD problems in a MANET are not specific to LLs at all. Regards, Teco > >Thomas From ietf@thomasclausen.org Mon Oct 26 02:01: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 AB0AE28C182 for ; Mon, 26 Oct 2009 02:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 3guDZEmQ+Ey2 for ; Mon, 26 Oct 2009 02:01:31 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id C3B1228C103 for ; Mon, 26 Oct 2009 02:01:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 5566D32317AD; Mon, 26 Oct 2009 02:01:43 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 31DCE32317AB; Mon, 26 Oct 2009 02:01:42 -0700 (PDT) Message-Id: <7138D249-5FB8-49C6-B61C-209BC4601477@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE56348.4050701@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: Mon, 26 Oct 2009 10:01:39 +0100 References: <4ADED440.2080403@cisco.com> <4AE05EFC.2060501@gmail.com> <4AE41BC4.2050700@cisco.com> <4AE45F61.2000800@gmail.com> <4AE47B4B.2020906@gmail.com> <70909CF7-8087-4284-B90E-CD56CF3CB6FE@thomasclausen.org> <4AE495E2.2040800@gmail.com> <4AE49924.90805@gmail.com> <55338E8A-3153-4378-ACC9-9C682651F911@thomasclausen.org> <4AE56348.4050701@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] adhoc unaware parts of the System, regular Internet nodes 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, 26 Oct 2009 09:01:31 -0000 On Oct 26, 2009, at 9:52 AM, Alexandru Petrescu wrote: > Thomas Heide Clausen a =E9crit : >> On Oct 25, 2009, at 7:29 PM, Alexandru Petrescu wrote: >>> Emmanuel Baccelli a =E9crit : >>>> Hi Alex, >>>> obviously, this topic is completely out of scope for the =20 >>>> addressing model document, and even for the whole working group! >>> >>> But it's in the Charter, no? >>> >> No - what is in the charter is not what you're implying. > > Please interpret this for me: > >> It is required that such models do not cause problems for ad >> hoc-unaware parts of the system, such as standard applications =20 >> running >> on an ad hoc node or regular Internet nodes attached to the ad hoc >> nodes. > Easy, consider this example network: {a,b,c,d}-----AHR-- AHR is an Ad Hoc Router with two interfaces. One is towards {a,b,c,d} =20= and is a regular ethernet, with a, b, c and d being regular non-MANET =20= hosts or routers. The other interface is a "MANET interface" towards =20 other AHRs. Whatever [autoconf] does should not affect {a, b, c, d} at all -- but, =20= of course, will affect AHRs and their interconnect. Now, replace AHR with "OSPFv3-router" -- whatever OSPFv3-routers do =20 between them (and whatever changes are introduced to OSPFv3) on OSPFv3 =20= interfaces does not affect {a, b, c, d}. This because the "magic of an OSPFv3 routing domain" -- and the "magic =20= of a MANET routing domain" -- is isolated from the rest of the network =20= by an IP hop. All the "ad hoc unaware parts of the system" see is a =20 well-defined, unchanged, classic, legacy IP hop... Thomas = From ietf@thomasclausen.org Mon Oct 26 02:02: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 0EF8328C19C for ; Mon, 26 Oct 2009 02:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.030, 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 ZQhpgrxcBpBr for ; Mon, 26 Oct 2009 02:02:28 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 3005B28C103 for ; Mon, 26 Oct 2009 02:02:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id B752A32317AD; Mon, 26 Oct 2009 02:02:41 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 852B632317AB; Mon, 26 Oct 2009 02:02:40 -0700 (PDT) Message-Id: <622A2E59-2236-482F-8A16-27594875E284@thomasclausen.org> From: Thomas Heide Clausen To: "Teco Boot" In-Reply-To: <005a01ca561a$c3db0650$4b9112f0$@nl> Content-Type: multipart/alternative; boundary=Apple-Mail-39--932314141 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 10:02:39 +0100 References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <005801ca5618$38d35be0$aa7a13a0$@nl> <005a01ca561a$c3db0650$4b9112f0$@nl> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 09:02:29 -0000 --Apple-Mail-39--932314141 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Oct 26, 2009, at 9:59 AM, Teco Boot wrote: > > >> -----Oorspronkelijk bericht----- >> Van: Thomas Heide Clausen [mailto:thomas@thomasclausen.org] >> Verzonden: maandag 26 oktober 2009 9:49 >> Aan: Teco Boot >> CC: autoconf@ietf.org >> Onderwerp: Re: [Autoconf] I-D Action:draft-bernardos-autoconf- >> addressing-model-00.txt >> >> >> On Oct 26, 2009, at 9:41 AM, Teco Boot wrote: >> >>>> Thomas Heide Clausen wrote: >>>> o If you have an LL address [generated by the usual means], it may >>>> be useless. Use it if you like, but be wary that the properties of >>>> that address are undefined. >>> >>> LL may be useful also. >>> Properties of LL are well defined. >> >> If by "Well defined [in a MANET]" you mean "unique only within a 1- >> hop >> radius and also only unique within that 1-hop radius at the very >> instant when DAD is testing uniqueness -- not guaranteed to be unique >> beyond 1-hop and nor even an instant after DAD has completed" then >> yes, LL properties are "well defined [in a MANET]" when using the >> usual means of getting LLs. >> >> I'd question if that's useful, though. > > Some protocols require a 1-hop scope. LLs are made for this. > DAD problems in a MANET are not specific to LLs at all. Charlie posted considerations on this in a response to Carlos, I think? Thomas --Apple-Mail-39--932314141 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Oct 26, 2009, = at 9:59 AM, Teco Boot wrote:



-----Oorspronkelijk = bericht-----
Van: Thomas Heide = Clausen [mailto:thomas@thomasclausen.org]
Verzonden: maandag 26 = oktober 2009 9:49
Aan: Teco = Boot
CC: autoconf@ietf.org
Onderwerp: Re: [Autoconf] I-D = Action:draft-bernardos-autoconf-
addressing-model-00.txt


On Oct 26, = 2009, at 9:41 AM, Teco Boot wrote:

Thomas Heide Clausen = wrote:
o If you = have an LL address [generated by the usual means], it = may
be = useless. Use it if you like, but be wary that the properties = of
that = address are = undefined.

LL may be useful = also.
Properties of LL are well = defined.

If by "Well = defined [in a MANET]" you mean "unique only within a = 1-hop
radius and also only = unique within that 1-hop radius at the very
instant when DAD is testing uniqueness -- not guaranteed = to be unique
beyond 1-hop and = nor even an instant after DAD has completed" = then
yes, LL properties are = "well defined [in a MANET]" when using the
usual means of getting LLs.

I'd question if = that's useful, though.

Some protocols require a = 1-hop scope. LLs are made for this.
DAD problems in a MANET are not = specific to LLs at all.

Char= lie posted considerations on this in a response to Carlos, I = think?

Thomas
= --Apple-Mail-39--932314141-- From thomas@thomasclausen.org Mon Oct 26 02:04: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 83D7A28C179 for ; Mon, 26 Oct 2009 02:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 g0-aTKbP4yZE for ; Mon, 26 Oct 2009 02:04:07 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id B65F528C0D9 for ; Mon, 26 Oct 2009 02:04:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 49F5C32317AD; Mon, 26 Oct 2009 02:04:21 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 1F96332317AB; Mon, 26 Oct 2009 02:04:19 -0700 (PDT) Message-Id: From: Thomas Heide Clausen To: "Teco Boot" In-Reply-To: <005901ca561a$48e6e3b0$dab4ab10$@nl> 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: Mon, 26 Oct 2009 10:04:17 +0100 References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <1256493151.4766.58.camel@acorde.it.uc3m.es> <4AE4997E.6090705@earthlink.net> <1256514067.4766.171.camel@acorde.it.uc3m.es> <4AE4ED72.9000707@earthlink.net> <005901ca561a$48e6e3b0$dab4ab10$@nl> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 09:04:08 -0000 On Oct 26, 2009, at 9:56 AM, Teco Boot wrote: > Charlie, > > I experienced multiple times a network down in a production network =20= > caused > by > duplicate detection mechanism bugs. These were severity 1 problems, =20= > because > all > nodes were affected. > A duplicate problem primary affects those who have the duplicates. =20 > There can > be > an increased network load or other effects, I do not deny the problem. > If a duplicate occurs on intermediaries (routers) interfaces, this =20 certainly will also have the ability to impact other than those who =20 have duplicate addresses. Thomas > Regards, Teco > > > >> -----Oorspronkelijk bericht----- >> Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] =20 >> Namens >> Charles E. Perkins >> Verzonden: maandag 26 oktober 2009 1:30 >> Aan: cjbc@it.uc3m.es >> CC: autoconf@ietf.org >> Onderwerp: Re: [Autoconf] I-D Action:draft-bernardos-autoconf- >> addressing-model-00.txt >> >> >> Hello Carlos, >> >> Carlos Jes=FAs Bernardos Cano wrote: >>> >>>> Your statement is valid for networks with conformant hosts using >>>> IEEE MAC addresses -- but not for all network nodes within the >>>> intended sphere of applicability for IPv6 address. >>>> >>> >>> True, for those not using MAC addresses, I think using random iids >> will >>> just make the work OK. >>> >>> >> >> Actually, not. >> >> Please see my other message. >> >> But, one more thing. >> >> This philosophy is especially bad because you >> will, statistically, _never_ encounter any bugs in >> your lab networks. >> >> Then when your bug shows up in a network >> with ten million nodes, you might never find it. >> >> Never. >> >> But maybe you would claim that we must then >> rely on the small size of ad hoc networks. >> At least it would be easier to find your bug, but >> it would be extremely tedious and difficult to >> trust any debugging tools or your intuition. >> >> We can't eliminate the need for address >> uniqueness by waving the wand of randomness. >> >> Regards, >> Charlie P. >> >> _______________________________________________ >> 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 alexandru.petrescu@gmail.com Mon Oct 26 02:05: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 49B0728C1DF for ; Mon, 26 Oct 2009 02:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[AWL=0.137, 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 7goGjiIasoDg for ; Mon, 26 Oct 2009 02:05:17 -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 4F7BA3A692D for ; Mon, 26 Oct 2009 02:05:17 -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 n9Q95TJC026787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 10:05:29 +0100 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 n9Q95Sem026730; Mon, 26 Oct 2009 10:05:28 +0100 (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 n9Q95SIi015254; Mon, 26 Oct 2009 10:05:28 +0100 Message-ID: <4AE56658.2080802@gmail.com> Date: Mon, 26 Oct 2009 10:05:28 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <4ADED440.2080403@cisco.com> <4AE05EFC.2060501@gmail.com> <4AE41BC4.2050700@cisco.com> <4AE45F61.2000800@gmail.com> <4AE47B4B.2020906@gmail.com> <70909CF7-8087-4284-B90E-CD56CF3CB6FE@thomasclausen.org> <4AE495E2.2040800@gmail.com> <4AE49924.90805@gmail.com> <55338E8A-3153-4378-ACC9-9C682651F911@thomasclausen.org> <4AE56348.4050701@gmail.com> <7138D249-5FB8-49C6-B61C-209BC4601477@thomasclausen.org> In-Reply-To: <7138D249-5FB8-49C6-B61C-209BC4601477@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] adhoc unaware parts of the System, regular Internet nodes 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, 26 Oct 2009 09:05:18 -0000 Thomas Heide Clausen a écrit : > > On Oct 26, 2009, at 9:52 AM, Alexandru Petrescu wrote: > >> Thomas Heide Clausen a écrit : >>> On Oct 25, 2009, at 7:29 PM, Alexandru Petrescu wrote: >>>> Emmanuel Baccelli a écrit : >>>>> Hi Alex, >>>>> obviously, this topic is completely out of scope for the addressing >>>>> model document, and even for the whole working group! >>>> >>>> But it's in the Charter, no? >>>> >>> No - what is in the charter is not what you're implying. >> >> Please interpret this for me: >> >>> It is required that such models do not cause problems for ad >>> hoc-unaware parts of the system, such as standard applications running >>> on an ad hoc node or regular Internet nodes attached to the ad hoc >>> nodes. >> > > Easy, consider this example network: > > {a,b,c,d}-----AHR-- > > AHR is an Ad Hoc Router with two interfaces. One is towards {a,b,c,d} > and is a regular ethernet, with a, b, c and d being regular non-MANET > hosts or routers. The other interface is a "MANET interface" towards > other AHRs. > > Whatever [autoconf] does should not affect {a, b, c, d} at all -- but, > of course, will affect AHRs and their interconnect. I agree. This should be said in the document, to satisfy that Charter requirement. It currently does not address that requirement (at least not with respect to link-local addresses). Once you agree this is necessary, we can see further. Alex > > Now, replace AHR with "OSPFv3-router" -- whatever OSPFv3-routers do > between them (and whatever changes are introduced to OSPFv3) on OSPFv3 > interfaces does not affect {a, b, c, d}. > > This because the "magic of an OSPFv3 routing domain" -- and the "magic > of a MANET routing domain" -- is isolated from the rest of the network > by an IP hop. All the "ad hoc unaware parts of the system" see is a > well-defined, unchanged, classic, legacy IP hop... > > Thomas > > From ietf@thomasclausen.org Mon Oct 26 02:09: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 77B5028C205 for ; Mon, 26 Oct 2009 02:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 BB9KNcIT4GXT for ; Mon, 26 Oct 2009 02:09:05 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id AA3A428C1E5 for ; Mon, 26 Oct 2009 02:09:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 3877A32317AD; Mon, 26 Oct 2009 02:09:19 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 12CFA32317AB; Mon, 26 Oct 2009 02:09:17 -0700 (PDT) Message-Id: From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE56658.2080802@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: Mon, 26 Oct 2009 10:09:15 +0100 References: <4ADED440.2080403@cisco.com> <4AE05EFC.2060501@gmail.com> <4AE41BC4.2050700@cisco.com> <4AE45F61.2000800@gmail.com> <4AE47B4B.2020906@gmail.com> <70909CF7-8087-4284-B90E-CD56CF3CB6FE@thomasclausen.org> <4AE495E2.2040800@gmail.com> <4AE49924.90805@gmail.com> <55338E8A-3153-4378-ACC9-9C682651F911@thomasclausen.org> <4AE56348.4050701@gmail.com> <7138D249-5FB8-49C6-B61C-209BC4601477@thomasclausen.org> <4AE56658.2080802@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] adhoc unaware parts of the System, regular Internet nodes 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, 26 Oct 2009 09:09:06 -0000 On Oct 26, 2009, at 10:05 AM, Alexandru Petrescu wrote: > Thomas Heide Clausen a =E9crit : >> On Oct 26, 2009, at 9:52 AM, Alexandru Petrescu wrote: >>> Thomas Heide Clausen a =E9crit : >>>> On Oct 25, 2009, at 7:29 PM, Alexandru Petrescu wrote: >>>>> Emmanuel Baccelli a =E9crit : >>>>>> Hi Alex, >>>>>> obviously, this topic is completely out of scope for the =20 >>>>>> addressing model document, and even for the whole working group! >>>>> >>>>> But it's in the Charter, no? >>>>> >>>> No - what is in the charter is not what you're implying. >>> >>> Please interpret this for me: >>> >>>> It is required that such models do not cause problems for ad >>>> hoc-unaware parts of the system, such as standard applications =20 >>>> running >>>> on an ad hoc node or regular Internet nodes attached to the ad hoc >>>> nodes. >>> >> Easy, consider this example network: >> {a,b,c,d}-----AHR-- >> AHR is an Ad Hoc Router with two interfaces. One is towards =20 >> {a,b,c,d} and is a regular ethernet, with a, b, c and d being =20 >> regular non-MANET hosts or routers. The other interface is a "MANET =20= >> interface" towards other AHRs. >> Whatever [autoconf] does should not affect {a, b, c, d} at all -- =20 >> but, of course, will affect AHRs and their interconnect. > > I agree. > > This should be said in the document, to satisfy that Charter =20 > requirement. > > It currently does not address that requirement (at least not with =20 > respect to link-local addresses). > > Once you agree this is necessary, we can see further. > I'd be much happier if you rephrase your last sentence to: "Once the WG agrees, we can see further" ;) So I'll wait for the rest of the WG to chime in -- I just explained my =20= understanding of the charter. Thomas > Alex > >> Now, replace AHR with "OSPFv3-router" -- whatever OSPFv3-routers do =20= >> between them (and whatever changes are introduced to OSPFv3) on =20 >> OSPFv3 interfaces does not affect {a, b, c, d}. >> This because the "magic of an OSPFv3 routing domain" -- and the =20 >> "magic of a MANET routing domain" -- is isolated from the rest of =20 >> the network by an IP hop. All the "ad hoc unaware parts of the =20 >> system" see is a well-defined, unchanged, classic, legacy IP hop... >> Thomas >> > > From ulrich@herberg.name Mon Oct 26 02:19:44 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 F339A3A6801 for ; Mon, 26 Oct 2009 02:19:43 -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 0-MThpO5uztK for ; Mon, 26 Oct 2009 02:19:43 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 8A28B28C1FE for ; Mon, 26 Oct 2009 02:19:23 -0700 (PDT) Received: by fxm18 with SMTP id 18so11879889fxm.37 for ; Mon, 26 Oct 2009 02:19:33 -0700 (PDT) MIME-Version: 1.0 Sender: ulrich@herberg.name Received: by 10.204.13.210 with SMTP id d18mr1868936bka.211.1256548773061; Mon, 26 Oct 2009 02:19:33 -0700 (PDT) In-Reply-To: References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <005801ca5618$38d35be0$aa7a13a0$@nl> Date: Mon, 26 Oct 2009 10:19:32 +0100 X-Google-Sender-Auth: 968509fe1661ba88 Message-ID: <25c114b90910260219h52c74b4dha6871856afaaec23@mail.gmail.com> From: Ulrich Herberg To: Thomas Heide Clausen Content-Type: multipart/alternative; boundary=00032555a89a42e6380476d30f4e Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 09:19:44 -0000 --00032555a89a42e6380476d30f4e Content-Type: text/plain; charset=ISO-8859-1 Fully agree with Thomas here. Note that the DT draft says: "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 connnectivity to neighbors may be constantly changing." So, the draft also says that (per RFC4291) LL are configured on an interface. It just says that they are not of much use, because it is very difficult to assure uniqueness beyond 1 hop. Ulrich On Mon, Oct 26, 2009 at 9:48 AM, Thomas Heide Clausen < thomas@thomasclausen.org> wrote: > > On Oct 26, 2009, at 9:41 AM, Teco Boot wrote: > > Thomas Heide Clausen wrote: >>> o If you have an LL address [generated by the usual means], it may >>> be useless. Use it if you like, but be wary that the properties of >>> that address are undefined. >>> >> >> LL may be useful also. >> Properties of LL are well defined. >> > > If by "Well defined [in a MANET]" you mean "unique only within a 1-hop > radius and also only unique within that 1-hop radius at the very instant > when DAD is testing uniqueness -- not guaranteed to be unique beyond 1-hop > and nor even an instant after DAD has completed" then yes, LL properties are > "well defined [in a MANET]" when using the usual means of getting LLs. > > I'd question if that's useful, though. > > Thomas > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > --00032555a89a42e6380476d30f4e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fully agree with Thomas here.

Note that the DT draft says:

&q= uot;Note that while an IPv6 link-local address is assigned to each interfac= e as per [RFC4291], in general link-loca= l addresses are of limited utility on links with undetermined connectivity,= as connnectivity to neighbors may be constantly changing."

So, the draft also says that (per RFC4291) LL are configured on an inte= rface. It just says that they are not of much use, because it is very diffi= cult to assure uniqueness beyond 1 hop.

Ulrich

On Mon, Oct 26, 2009 at 9:48 AM, Thomas Heide Clausen <= ;thomas@thomasclausen.org&g= t; wrote:

On Oct 26, 2009, at 9:41 AM, Teco Boot wrote:

Thomas Heide Clausen wrote:
o =A0 =A0 =A0 If you have an LL address [generated by the usual means], it = may
=A0 =A0 =A0 =A0be useless. Use it if you like, but be wary that the proper= ties of
=A0 =A0 =A0 =A0that address are undefined.

LL may be useful also.
Properties of LL are well defined.

If by "Well defined [in a MANET]" you mean "unique only with= in a 1-hop radius and also only unique within that 1-hop radius at the very= instant when DAD is testing uniqueness -- not guaranteed to be unique beyo= nd 1-hop and nor even an instant after DAD has completed" then yes, LL= properties are "well defined [in a MANET]" when using the usual = means of getting LLs.

I'd question if that's useful, though.

Thomas

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

--00032555a89a42e6380476d30f4e-- From thomas@thomasclausen.org Mon Oct 26 02:26: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 8E35D3A67FA for ; Mon, 26 Oct 2009 02:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.042, 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 KxbRYO3ANmQT for ; Mon, 26 Oct 2009 02:26:08 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 998253A657C for ; Mon, 26 Oct 2009 02:26:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 3110632317AD; Mon, 26 Oct 2009 02:26:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id D0BD332317AB; Mon, 26 Oct 2009 02:26:20 -0700 (PDT) Message-Id: <28349458-7477-4A62-8B7F-2628BD9AFA8C@thomasclausen.org> From: Thomas Heide Clausen To: Ulrich Herberg In-Reply-To: <25c114b90910260219h52c74b4dha6871856afaaec23@mail.gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-41--930895465 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 10:26:18 +0100 References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <005801ca5618$38d35be0$aa7a13a0$@nl> <25c114b90910260219h52c74b4dha6871856afaaec23@mail.gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 09:26:09 -0000 --Apple-Mail-41--930895465 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Oct 26, 2009, at 10:19 AM, Ulrich Herberg wrote: > Fully agree with Thomas here. > > Note that the DT draft says: > > "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 > connnectivity to neighbors may be constantly changing." > > So, the draft also says that (per RFC4291) LL are configured on an > interface. It just says that they are not of much use, because it is > very difficult to assure uniqueness beyond 1 hop. > Or even within 1-hop, considering that some interface that (at the time of DAD, with DAD being a 1-hop operation) was far away due to node mobility has become a neighbor. Of course, ensuring MANET-wide uniqueness (and, I agree with Charlie's consideration on "randomness is not the answer....") of LL addresses would address this particular issue. However, in that case, our "LL addresses" are not "LL" but "MANET wide", and ULA is likely a better term (And address family) to use... Thomas > Ulrich > > On Mon, Oct 26, 2009 at 9:48 AM, Thomas Heide Clausen > wrote: > > On Oct 26, 2009, at 9:41 AM, Teco Boot wrote: > > Thomas Heide Clausen wrote: > o If you have an LL address [generated by the usual means], it > may > be useless. Use it if you like, but be wary that the > properties of > that address are undefined. > > LL may be useful also. > Properties of LL are well defined. > > If by "Well defined [in a MANET]" you mean "unique only within a 1- > hop radius and also only unique within that 1-hop radius at the very > instant when DAD is testing uniqueness -- not guaranteed to be > unique beyond 1-hop and nor even an instant after DAD has completed" > then yes, LL properties are "well defined [in a MANET]" when using > the usual means of getting LLs. > > I'd question if that's useful, though. > > Thomas > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > --Apple-Mail-41--930895465 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Oct 26, 2009, = at 10:19 AM, Ulrich Herberg wrote:

Fully = agree with Thomas here.

Note that the DT draft says:

"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 connnectivity to neighbors may be constantly = changing."

So, the draft also says that (per RFC4291) LL are = configured on an interface. It just says that they are not of much use, = because it is very difficult to assure uniqueness beyond 1 = hop.


Or even within 1-hop, = considering that some interface that (at the time of DAD, with DAD being = a 1-hop operation) was far away due to node mobility has become a = neighbor.

Of course, ensuring MANET-wide = uniqueness (and, I agree with Charlie's consideration on "randomness is = not the answer....") of LL addresses would address this particular = issue. However, in that case, our "LL addresses" are not "LL" but "MANET = wide", and ULA is likely a better term (And address family) to = use...

Thomas

Ulrich

On Mon, Oct 26, = 2009 at 9:48 AM, Thomas Heide Clausen <thomas@thomasclausen.org><= /span> wrote:

On Oct 26, 2009, at 9:41 AM, Teco Boot wrote:

=
= Thomas Heide Clausen wrote:
o       If you have an LL = address [generated by the usual means], it may
      =  be useless. Use it if you like, but be wary that the properties = of
       that address are undefined.
=

LL may be useful also.
Properties of LL are well = defined.

If by "Well defined [in a MANET]" you = mean "unique only within a 1-hop radius and also only unique within that = 1-hop radius at the very instant when DAD is testing uniqueness -- not = guaranteed to be unique beyond 1-hop and nor even an instant after DAD = has completed" then yes, LL properties are "well defined [in a MANET]" = when using the usual means of getting LLs.

I'd question if = that's useful, though.

= Thomas

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


= --Apple-Mail-41--930895465-- From alexandru.petrescu@gmail.com Mon Oct 26 02:30: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 6415E3A6927 for ; Mon, 26 Oct 2009 02:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.128 X-Spam-Level: X-Spam-Status: No, score=-2.128 tagged_above=-999 required=5 tests=[AWL=0.121, 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 YGB7KZ+tskaU for ; Mon, 26 Oct 2009 02:30:35 -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 3E1F83A68E9 for ; Mon, 26 Oct 2009 02:30:35 -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 n9Q9Ulv1016619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 10:30:47 +0100 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 n9Q9Uk0H003999; Mon, 26 Oct 2009 10:30:46 +0100 (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 n9Q9UkMo026363; Mon, 26 Oct 2009 10:30:46 +0100 Message-ID: <4AE56C46.60403@gmail.com> Date: Mon, 26 Oct 2009 10:30:46 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <4ADED440.2080403@cisco.com> <4AE05EFC.2060501@gmail.com> <4AE41BC4.2050700@cisco.com> <4AE45F61.2000800@gmail.com> <4AE47B4B.2020906@gmail.com> <70909CF7-8087-4284-B90E-CD56CF3CB6FE@thomasclausen.org> <4AE495E2.2040800@gmail.com> <4AE49924.90805@gmail.com> <55338E8A-3153-4378-ACC9-9C682651F911@thomasclausen.org> <4AE56348.4050701@gmail.com> <7138D249-5FB8-49C6-B61C-209BC4601477@thomasclausen.org> <4AE56658.2080802@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] adhoc unaware parts of the System, regular Internet nodes 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, 26 Oct 2009 09:30:36 -0000 Thomas Heide Clausen a écrit : > > On Oct 26, 2009, at 10:05 AM, Alexandru Petrescu wrote: > >> Thomas Heide Clausen a écrit : >>> On Oct 26, 2009, at 9:52 AM, Alexandru Petrescu wrote: >>>> Thomas Heide Clausen a écrit : >>>>> On Oct 25, 2009, at 7:29 PM, Alexandru Petrescu wrote: >>>>>> Emmanuel Baccelli a écrit : >>>>>>> Hi Alex, >>>>>>> obviously, this topic is completely out of scope for the >>>>>>> addressing model document, and even for the whole working group! >>>>>> >>>>>> But it's in the Charter, no? >>>>>> >>>>> No - what is in the charter is not what you're implying. >>>> >>>> Please interpret this for me: >>>> >>>>> It is required that such models do not cause problems for ad >>>>> hoc-unaware parts of the system, such as standard applications running >>>>> on an ad hoc node or regular Internet nodes attached to the ad hoc >>>>> nodes. >>>> >>> Easy, consider this example network: >>> {a,b,c,d}-----AHR-- >>> AHR is an Ad Hoc Router with two interfaces. One is towards {a,b,c,d} >>> and is a regular ethernet, with a, b, c and d being regular non-MANET >>> hosts or routers. The other interface is a "MANET interface" towards >>> other AHRs. >>> Whatever [autoconf] does should not affect {a, b, c, d} at all -- >>> but, of course, will affect AHRs and their interconnect. >> >> I agree. >> >> This should be said in the document, to satisfy that Charter requirement. >> >> It currently does not address that requirement (at least not with >> respect to link-local addresses). >> >> Once you agree this is necessary, we can see further. >> > > I'd be much happier if you rephrase your last sentence to: > > "Once the WG agrees, we can see further" > > ;) > > So I'll wait for the rest of the WG to chime in -- I just explained my > understanding of the charter. :-) You implicitely say above that the Ad Hoc Router AHR has two interfaces. Maybe we should get agreement from the WG about AHR having two interfaces? (early signs showed 1). Alex > > Thomas > >> Alex >> >>> Now, replace AHR with "OSPFv3-router" -- whatever OSPFv3-routers do >>> between them (and whatever changes are introduced to OSPFv3) on >>> OSPFv3 interfaces does not affect {a, b, c, d}. >>> This because the "magic of an OSPFv3 routing domain" -- and the >>> "magic of a MANET routing domain" -- is isolated from the rest of the >>> network by an IP hop. All the "ad hoc unaware parts of the system" >>> see is a well-defined, unchanged, classic, legacy IP hop... >>> Thomas >>> >> >> > > From ietf@thomasclausen.org Mon Oct 26 02:31: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 8F8473A6906 for ; Mon, 26 Oct 2009 02:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 lG8d70ZLIaxt for ; Mon, 26 Oct 2009 02:31:36 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id A57833A6841 for ; Mon, 26 Oct 2009 02:31:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 3B26932317AD; Mon, 26 Oct 2009 02:31:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 078A932317AB; Mon, 26 Oct 2009 02:31:48 -0700 (PDT) Message-Id: <5D2D975E-FE10-42F5-8359-A03D5379C33A@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE56C46.60403@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: Mon, 26 Oct 2009 10:31:46 +0100 References: <4ADED440.2080403@cisco.com> <4AE05EFC.2060501@gmail.com> <4AE41BC4.2050700@cisco.com> <4AE45F61.2000800@gmail.com> <4AE47B4B.2020906@gmail.com> <70909CF7-8087-4284-B90E-CD56CF3CB6FE@thomasclausen.org> <4AE495E2.2040800@gmail.com> <4AE49924.90805@gmail.com> <55338E8A-3153-4378-ACC9-9C682651F911@thomasclausen.org> <4AE56348.4050701@gmail.com> <7138D249-5FB8-49C6-B61C-209BC4601477@thomasclausen.org> <4AE56658.2080802@gmail.com> <4AE56C46.60403@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] adhoc unaware parts of the System, regular Internet nodes 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, 26 Oct 2009 09:31:37 -0000 On Oct 26, 2009, at 10:30 AM, Alexandru Petrescu wrote: > Thomas Heide Clausen a =E9crit : >> On Oct 26, 2009, at 10:05 AM, Alexandru Petrescu wrote: >>> Thomas Heide Clausen a =E9crit : >>>> On Oct 26, 2009, at 9:52 AM, Alexandru Petrescu wrote: >>>>> Thomas Heide Clausen a =E9crit : >>>>>> On Oct 25, 2009, at 7:29 PM, Alexandru Petrescu wrote: >>>>>>> Emmanuel Baccelli a =E9crit : >>>>>>>> Hi Alex, >>>>>>>> obviously, this topic is completely out of scope for the =20 >>>>>>>> addressing model document, and even for the whole working =20 >>>>>>>> group! >>>>>>> >>>>>>> But it's in the Charter, no? >>>>>>> >>>>>> No - what is in the charter is not what you're implying. >>>>> >>>>> Please interpret this for me: >>>>> >>>>>> It is required that such models do not cause problems for ad >>>>>> hoc-unaware parts of the system, such as standard applications =20= >>>>>> running >>>>>> on an ad hoc node or regular Internet nodes attached to the ad =20= >>>>>> hoc >>>>>> nodes. >>>>> >>>> Easy, consider this example network: >>>> {a,b,c,d}-----AHR-- >>>> AHR is an Ad Hoc Router with two interfaces. One is towards =20 >>>> {a,b,c,d} and is a regular ethernet, with a, b, c and d being =20 >>>> regular non-MANET hosts or routers. The other interface is a =20 >>>> "MANET interface" towards other AHRs. >>>> Whatever [autoconf] does should not affect {a, b, c, d} at all -- =20= >>>> but, of course, will affect AHRs and their interconnect. >>> >>> I agree. >>> >>> This should be said in the document, to satisfy that Charter =20 >>> requirement. >>> >>> It currently does not address that requirement (at least not with =20= >>> respect to link-local addresses). >>> >>> Once you agree this is necessary, we can see further. >>> >> I'd be much happier if you rephrase your last sentence to: >> "Once the WG agrees, we can see further" >> ;) >> So I'll wait for the rest of the WG to chime in -- I just explained =20= >> my understanding of the charter. > > :-) > > You implicitely say above that the Ad Hoc Router AHR has two =20 > interfaces. No, I was saying that my example has one interface. > Maybe we should get agreement from the WG about AHR having two =20 > interfaces? (early signs showed 1). No. An AHR may have 1, 2 or many many more interfaces.... Thomas > Alex > >> Thomas >>> Alex >>> >>>> Now, replace AHR with "OSPFv3-router" -- whatever OSPFv3-routers =20= >>>> do between them (and whatever changes are introduced to OSPFv3) =20 >>>> on OSPFv3 interfaces does not affect {a, b, c, d}. >>>> This because the "magic of an OSPFv3 routing domain" -- and the =20 >>>> "magic of a MANET routing domain" -- is isolated from the rest of =20= >>>> the network by an IP hop. All the "ad hoc unaware parts of the =20 >>>> system" see is a well-defined, unchanged, classic, legacy IP hop... >>>> Thomas >>>> >>> >>> > > From alexandru.petrescu@gmail.com Mon Oct 26 02:35: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 9B78B3A682A for ; Mon, 26 Oct 2009 02:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.115, 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 DHMHTNTSecvM for ; Mon, 26 Oct 2009 02:34:59 -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 6EAC13A6801 for ; Mon, 26 Oct 2009 02:34:59 -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 n9Q9ZAks020955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 10:35:10 +0100 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 n9Q9ZA9c005776; Mon, 26 Oct 2009 10:35:10 +0100 (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 n9Q9ZA3Y028933; Mon, 26 Oct 2009 10:35:10 +0100 Message-ID: <4AE56D4E.9010709@gmail.com> Date: Mon, 26 Oct 2009 10:35:10 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <4ADED440.2080403@cisco.com> <4AE05EFC.2060501@gmail.com> <4AE41BC4.2050700@cisco.com> <4AE45F61.2000800@gmail.com> <4AE47B4B.2020906@gmail.com> <70909CF7-8087-4284-B90E-CD56CF3CB6FE@thomasclausen.org> <4AE495E2.2040800@gmail.com> <4AE49924.90805@gmail.com> <55338E8A-3153-4378-ACC9-9C682651F911@thomasclausen.org> <4AE56348.4050701@gmail.com> <7138D249-5FB8-49C6-B61C-209BC4601477@thomasclausen.org> <4AE56658.2080802@gmail.com> <4AE56C46.60403@gmail.com> <5D2D975E-FE10-42F5-8359-A03D5379C33A@thomasclausen.org> In-Reply-To: <5D2D975E-FE10-42F5-8359-A03D5379C33A@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] adhoc unaware parts of the System, regular Internet nodes 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, 26 Oct 2009 09:35:00 -0000 Thomas Heide Clausen a écrit : > > On Oct 26, 2009, at 10:30 AM, Alexandru Petrescu wrote: > >> Thomas Heide Clausen a écrit : >>> On Oct 26, 2009, at 10:05 AM, Alexandru Petrescu wrote: >>>> Thomas Heide Clausen a écrit : >>>>> On Oct 26, 2009, at 9:52 AM, Alexandru Petrescu wrote: >>>>>> Thomas Heide Clausen a écrit : >>>>>>> On Oct 25, 2009, at 7:29 PM, Alexandru Petrescu wrote: >>>>>>>> Emmanuel Baccelli a écrit : >>>>>>>>> Hi Alex, >>>>>>>>> obviously, this topic is completely out of scope for the >>>>>>>>> addressing model document, and even for the whole working group! >>>>>>>> >>>>>>>> But it's in the Charter, no? >>>>>>>> >>>>>>> No - what is in the charter is not what you're implying. >>>>>> >>>>>> Please interpret this for me: >>>>>> >>>>>>> It is required that such models do not cause problems for ad >>>>>>> hoc-unaware parts of the system, such as standard applications >>>>>>> running >>>>>>> on an ad hoc node or regular Internet nodes attached to the ad hoc >>>>>>> nodes. >>>>>> >>>>> Easy, consider this example network: >>>>> {a,b,c,d}-----AHR-- >>>>> AHR is an Ad Hoc Router with two interfaces. One is towards >>>>> {a,b,c,d} and is a regular ethernet, with a, b, c and d being >>>>> regular non-MANET hosts or routers. The other interface is a "MANET >>>>> interface" towards other AHRs. >>>>> Whatever [autoconf] does should not affect {a, b, c, d} at all -- >>>>> but, of course, will affect AHRs and their interconnect. >>>> >>>> I agree. >>>> >>>> This should be said in the document, to satisfy that Charter >>>> requirement. >>>> >>>> It currently does not address that requirement (at least not with >>>> respect to link-local addresses). >>>> >>>> Once you agree this is necessary, we can see further. >>>> >>> I'd be much happier if you rephrase your last sentence to: >>> "Once the WG agrees, we can see further" >>> ;) >>> So I'll wait for the rest of the WG to chime in -- I just explained >>> my understanding of the charter. >> >> :-) >> >> You implicitely say above that the Ad Hoc Router AHR has two interfaces. > > No, I was saying that my example has one interface. But you pictured two ifaces on AHR! You even say so. >> Maybe we should get agreement from the WG about AHR having two >> interfaces? (early signs showed 1). > > No. An AHR may have 1, 2 or many many more interfaces.... I dont think you have agreement from the WG about this particular point. Although I do agree with you on this particular point. Alex > > Thomas > > >> Alex >> >>> Thomas >>>> Alex >>>> >>>>> Now, replace AHR with "OSPFv3-router" -- whatever OSPFv3-routers do >>>>> between them (and whatever changes are introduced to OSPFv3) on >>>>> OSPFv3 interfaces does not affect {a, b, c, d}. >>>>> This because the "magic of an OSPFv3 routing domain" -- and the >>>>> "magic of a MANET routing domain" -- is isolated from the rest of >>>>> the network by an IP hop. All the "ad hoc unaware parts of the >>>>> system" see is a well-defined, unchanged, classic, legacy IP hop... >>>>> Thomas >>>>> >>>> >>>> >> >> > > From alexandru.petrescu@gmail.com Mon Oct 26 02:36: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 B4B0528C184 for ; Mon, 26 Oct 2009 02:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.837 X-Spam-Level: X-Spam-Status: No, score=-0.837 tagged_above=-999 required=5 tests=[AWL=-1.188, 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 Zjt7wNVzAiqw for ; Mon, 26 Oct 2009 02:36:25 -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 CA7F028C11F for ; Mon, 26 Oct 2009 02:36:24 -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 n9Q9aaAB022152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 26 Oct 2009 10:36:37 +0100 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 n9Q9aaiV006416 for ; Mon, 26 Oct 2009 10:36:36 +0100 (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 n9Q9aaTv029738 for ; Mon, 26 Oct 2009 10:36:36 +0100 Message-ID: <4AE56DA4.9010606@gmail.com> Date: Mon, 26 Oct 2009 10:36:36 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "autoconf@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Autoconf] How many interfaces does an AUTOCONF node have? 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, 26 Oct 2009 09:36:25 -0000 How many physical interfaces does an AUTOCONF node have? 0..n ? or 1..n ? or 2..n ? Alex From ietf@thomasclausen.org Mon Oct 26 02:39: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 33AA43A68E6 for ; Mon, 26 Oct 2009 02:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 JQxSWtVGxYEn for ; Mon, 26 Oct 2009 02:39:01 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 5EC433A68E0 for ; Mon, 26 Oct 2009 02:39:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id EA3DE32317AD; Mon, 26 Oct 2009 02:39:14 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id B1ABF32317AB; Mon, 26 Oct 2009 02:39:13 -0700 (PDT) Message-Id: <1BA26508-61D8-49BE-865D-180167A12C8F@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE56D4E.9010709@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: Mon, 26 Oct 2009 10:39:11 +0100 References: <4ADED440.2080403@cisco.com> <4AE05EFC.2060501@gmail.com> <4AE41BC4.2050700@cisco.com> <4AE45F61.2000800@gmail.com> <4AE47B4B.2020906@gmail.com> <70909CF7-8087-4284-B90E-CD56CF3CB6FE@thomasclausen.org> <4AE495E2.2040800@gmail.com> <4AE49924.90805@gmail.com> <55338E8A-3153-4378-ACC9-9C682651F911@thomasclausen.org> <4AE56348.4050701@gmail.com> <7138D249-5FB8-49C6-B61C-209BC4601477@thomasclausen.org> <4AE56658.2080802@gmail.com> <4AE56C46.60403@gmail.com> <5D2D975E-FE10-42F5-8359-A03D5379C33A@thomasclausen.org> <4AE56D4E.9010709@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] adhoc unaware parts of the System, regular Internet nodes 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, 26 Oct 2009 09:39:02 -0000 On Oct 26, 2009, at 10:35 AM, Alexandru Petrescu wrote: > Thomas Heide Clausen a =E9crit : >> On Oct 26, 2009, at 10:30 AM, Alexandru Petrescu wrote: >>> Thomas Heide Clausen a =E9crit : >>>> On Oct 26, 2009, at 10:05 AM, Alexandru Petrescu wrote: >>>>> Thomas Heide Clausen a =E9crit : >>>>>> On Oct 26, 2009, at 9:52 AM, Alexandru Petrescu wrote: >>>>>>> Thomas Heide Clausen a =E9crit : >>>>>>>> On Oct 25, 2009, at 7:29 PM, Alexandru Petrescu wrote: >>>>>>>>> Emmanuel Baccelli a =E9crit : >>>>>>>>>> Hi Alex, >>>>>>>>>> obviously, this topic is completely out of scope for the =20 >>>>>>>>>> addressing model document, and even for the whole working =20 >>>>>>>>>> group! >>>>>>>>> >>>>>>>>> But it's in the Charter, no? >>>>>>>>> >>>>>>>> No - what is in the charter is not what you're implying. >>>>>>> >>>>>>> Please interpret this for me: >>>>>>> >>>>>>>> It is required that such models do not cause problems for ad >>>>>>>> hoc-unaware parts of the system, such as standard =20 >>>>>>>> applications running >>>>>>>> on an ad hoc node or regular Internet nodes attached to the =20 >>>>>>>> ad hoc >>>>>>>> nodes. >>>>>>> >>>>>> Easy, consider this example network: >>>>>> {a,b,c,d}-----AHR-- >>>>>> AHR is an Ad Hoc Router with two interfaces. One is towards =20 >>>>>> {a,b,c,d} and is a regular ethernet, with a, b, c and d being =20 >>>>>> regular non-MANET hosts or routers. The other interface is a =20 >>>>>> "MANET interface" towards other AHRs. >>>>>> Whatever [autoconf] does should not affect {a, b, c, d} at all =20= >>>>>> -- but, of course, will affect AHRs and their interconnect. >>>>> >>>>> I agree. >>>>> >>>>> This should be said in the document, to satisfy that Charter =20 >>>>> requirement. >>>>> >>>>> It currently does not address that requirement (at least not =20 >>>>> with respect to link-local addresses). >>>>> >>>>> Once you agree this is necessary, we can see further. >>>>> >>>> I'd be much happier if you rephrase your last sentence to: >>>> "Once the WG agrees, we can see further" >>>> ;) >>>> So I'll wait for the rest of the WG to chime in -- I just =20 >>>> explained my understanding of the charter. >>> >>> :-) >>> >>> You implicitely say above that the Ad Hoc Router AHR has two =20 >>> interfaces. >> No, I was saying that my example has one interface. > > But you pictured two ifaces on AHR! You even say so. > Yes, in this *example* that is very true, for the purpose of =20 illustrating that point. >>> Maybe we should get agreement from the WG about AHR having two =20 >>> interfaces? (early signs showed 1). >> No. An AHR may have 1, 2 or many many more interfaces.... > > I dont think you have agreement from the WG about this particular =20 > point. Hum, for 10+ years, we've been building MANETs with MANET routers =20 (AHRs) having a single interface. Some have multiple interfaces too. =20 That too has been supported for that long. I don't think that anybody who's been building MANETs would be able to =20= disagree on this particular point? Thomas > Although I do agree with you on this particular point. > > Alex > >> Thomas >>> Alex >>> >>>> Thomas >>>>> Alex >>>>> >>>>>> Now, replace AHR with "OSPFv3-router" -- whatever OSPFv3-=20 >>>>>> routers do between them (and whatever changes are introduced to =20= >>>>>> OSPFv3) on OSPFv3 interfaces does not affect {a, b, c, d}. >>>>>> This because the "magic of an OSPFv3 routing domain" -- and the =20= >>>>>> "magic of a MANET routing domain" -- is isolated from the rest =20= >>>>>> of the network by an IP hop. All the "ad hoc unaware parts of =20 >>>>>> the system" see is a well-defined, unchanged, classic, legacy =20 >>>>>> IP hop... >>>>>> Thomas >>>>>> >>>>> >>>>> >>> >>> > > From thomas@thomasclausen.org Mon Oct 26 02:40: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 A7FD53A681D for ; Mon, 26 Oct 2009 02:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 LJF3zUFgAL6e for ; Mon, 26 Oct 2009 02:40:37 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 47C523A67AF for ; Mon, 26 Oct 2009 02:40:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id D4FE732317AF; Mon, 26 Oct 2009 02:40:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 30FA732317AE; Mon, 26 Oct 2009 02:40:50 -0700 (PDT) Message-Id: <36EE5525-28E0-47D6-8FFF-C9CF94398F57@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE56DA4.9010606@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 10:40:48 +0100 References: <4AE56DA4.9010606@gmail.com> X-Mailer: Apple Mail (2.936) Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] How many interfaces does an AUTOCONF node have? 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, 26 Oct 2009 09:40:39 -0000 On Oct 26, 2009, at 10:36 AM, Alexandru Petrescu wrote: > How many physical interfaces does an AUTOCONF node have? > > 0..n ? A router with 0 interfaces? You can't be serious. > or > 1..n ? 1..n is the only valid answer. Just look at *running* MANETs and MANET routing protocols. There's really no question about that matter. Thomas > or > 2..n ? > > Alex > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From cjbc@it.uc3m.es Mon Oct 26 02:41: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 A567F3A68E9 for ; Mon, 26 Oct 2009 02:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.499 X-Spam-Level: X-Spam-Status: No, score=-5.499 tagged_above=-999 required=5 tests=[AWL=0.200, 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 Y+AQkboh2cKy for ; Mon, 26 Oct 2009 02:40:59 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id CC9F13A681D for ; Mon, 26 Oct 2009 02:40:58 -0700 (PDT) Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id BB8186C2D8B; Mon, 26 Oct 2009 10:41:10 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Alexandru Petrescu In-Reply-To: <4AE56DA4.9010606@gmail.com> References: <4AE56DA4.9010606@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-TatHvSH/8AqkZwtq2npp" Organization: Universidad Carlos III de Madrid Date: Mon, 26 Oct 2009 10:39:09 +0100 Message-Id: <1256549949.7742.11.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16970.006 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] How many interfaces does an AUTOCONF node have? 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: Mon, 26 Oct 2009 09:41:00 -0000 --=-TatHvSH/8AqkZwtq2npp Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable As I see it, 1..n Carlos On Mon, 2009-10-26 at 10:36 +0100, Alexandru Petrescu wrote: > How many physical interfaces does an AUTOCONF node have? >=20 > 0..n ? > or > 1..n ? > or > 2..n ? >=20 > Alex >=20 > _______________________________________________ > 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 --=-TatHvSH/8AqkZwtq2npp 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) iEYEABECAAYFAkrlbj0ACgkQNdy6TdFwT2dzeACfX1ukNzqs004FLKlUB6PNH09c r/MAoM7grz+rrHfw+Cceavj7knGcIoeD =CM94 -----END PGP SIGNATURE----- --=-TatHvSH/8AqkZwtq2npp-- From henning.rogge@fkie.fraunhofer.de Mon Oct 26 02:43:21 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 705F23A6909 for ; Mon, 26 Oct 2009 02:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.949 X-Spam-Level: X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=-1.300, 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 vwOs0zb8YbiJ for ; Mon, 26 Oct 2009 02:43:20 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 46D5E3A681D for ; Mon, 26 Oct 2009 02:43:20 -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 1N2M6t-0007CO-R7; Mon, 26 Oct 2009 10:43:31 +0100 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 1N2M6t-0001XT-I4; Mon, 26 Oct 2009 10:43:31 +0100 From: Henning Rogge To: autoconf@ietf.org Date: Mon, 26 Oct 2009 10:43:21 +0100 User-Agent: KMail/1.11.2 (Linux/2.6.30-10-generic; KDE/4.2.2; i686; ; ) References: <4AE56DA4.9010606@gmail.com> In-Reply-To: <4AE56DA4.9010606@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1617006.JG4E4Uu3WT"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910261043.26487.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/9940/Mon Oct 26 02:47:14 2009) by mailguard.fgan.de X-Scan-Signature: 03aa31d695fb3eb984fab57667d62e5a Subject: Re: [Autoconf] How many interfaces does an AUTOCONF node have? 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, 26 Oct 2009 09:43:21 -0000 --nextPart1617006.JG4E4Uu3WT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Mon October 26 2009 10:36:36 schrieb Alexandru Petrescu: > 0..n ? > or > 1..n ? > or > 2..n ? 1..n without interfaces there is nothing to do for autoconfig (or manet routing). 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 --nextPart1617006.JG4E4Uu3WT 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) iEYEABECAAYFAkrlbzkACgkQRIfGfFXsz+BWGgCfczBJYnyPWpMRvkfJ5PgbJbYu xCQAn0njIxhf/nY9HtVAp5RCF+itq98+ =5RYX -----END PGP SIGNATURE----- --nextPart1617006.JG4E4Uu3WT-- From ulrich@herberg.name Mon Oct 26 02:47:44 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 0C5A428C19C for ; Mon, 26 Oct 2009 02:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[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 myakyeKEs6kI for ; Mon, 26 Oct 2009 02:47:43 -0700 (PDT) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 0653328C13A for ; Mon, 26 Oct 2009 02:47:42 -0700 (PDT) Received: by bwz23 with SMTP id 23so1995099bwz.29 for ; Mon, 26 Oct 2009 02:47:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.157.16 with SMTP id z16mr8699310bkw.103.1256550470597; Mon, 26 Oct 2009 02:47:50 -0700 (PDT) In-Reply-To: <200910261043.26487.henning.rogge@fkie.fraunhofer.de> References: <4AE56DA4.9010606@gmail.com> <200910261043.26487.henning.rogge@fkie.fraunhofer.de> Date: Mon, 26 Oct 2009 10:47:50 +0100 Message-ID: <25c114b90910260247m7a0efe03w3bc6cf4e718be020@mail.gmail.com> From: Ulrich Herberg To: Henning Rogge Content-Type: multipart/alternative; boundary=0015175ccf5c713c8e0476d37409 Cc: autoconf@ietf.org Subject: Re: [Autoconf] How many interfaces does an AUTOCONF node have? 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, 26 Oct 2009 09:47:44 -0000 --0015175ccf5c713c8e0476d37409 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable of course 1..n Ulrich On Mon, Oct 26, 2009 at 10:43 AM, Henning Rogge < henning.rogge@fkie.fraunhofer.de> wrote: > Am Mon October 26 2009 10:36:36 schrieb Alexandru Petrescu: > > 0..n ? > > or > > 1..n ? > > or > > 2..n ? > > 1..n > > without interfaces there is nothing to do for autoconfig (or manet > routing). > > Henning Rogge > > -- > 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 > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > > --0015175ccf5c713c8e0476d37409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable of course 1..n

Ulrich

On Mon, Oct = 26, 2009 at 10:43 AM, Henning Rogge <henning.rogge@fkie.fraunhofer.de>= wrote:
Am Mon October 26= 2009 10:36:36 schrieb Alexandru Petrescu:
> 0..n ?
> or
> 1..n ?
> or
> 2..n ?

1..n

without interfaces there is nothing to do for autoconfig (or manet routing)= .

Henning Rogge

--
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, =A0 Fax +49 228 9435 685
mailto:henning.rogge@fk= ie.fraunhofer.de http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0


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


--0015175ccf5c713c8e0476d37409-- From alexandru.petrescu@gmail.com Mon Oct 26 02:52: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 77DBB3A6A49 for ; Mon, 26 Oct 2009 02:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.114 X-Spam-Level: X-Spam-Status: No, score=-2.114 tagged_above=-999 required=5 tests=[AWL=0.135, 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 B5nDB106zpms for ; Mon, 26 Oct 2009 02:52:39 -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 5587C3A6A4D for ; Mon, 26 Oct 2009 02:52:39 -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 n9Q9qodQ030762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 10:52:51 +0100 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 n9Q9qokf013063; Mon, 26 Oct 2009 10:52:50 +0100 (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 n9Q9qohb004973; Mon, 26 Oct 2009 10:52:50 +0100 Message-ID: <4AE57172.3010301@gmail.com> Date: Mon, 26 Oct 2009 10:52:50 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <4ADED440.2080403@cisco.com> <4AE05EFC.2060501@gmail.com> <4AE41BC4.2050700@cisco.com> <4AE45F61.2000800@gmail.com> <4AE47B4B.2020906@gmail.com> <70909CF7-8087-4284-B90E-CD56CF3CB6FE@thomasclausen.org> <4AE495E2.2040800@gmail.com> <4AE49924.90805@gmail.com> <55338E8A-3153-4378-ACC9-9C682651F911@thomasclausen.org> <4AE56348.4050701@gmail.com> <7138D249-5FB8-49C6-B61C-209BC4601477@thomasclausen.org> <4AE56658.2080802@gmail.com> <4AE56C46.60403@gmail.com> <5D2D975E-FE10-42F5-8359-A03D5379C33A@thomasclausen.org> <4AE56D4E.9010709@gmail.com> <1BA26508-61D8-49BE-865D-180167A12C8F@thomasclausen.org> In-Reply-To: <1BA26508-61D8-49BE-865D-180167A12C8F@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] adhoc unaware parts of the System, regular Internet nodes 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, 26 Oct 2009 09:52:40 -0000 Thomas Heide Clausen a écrit : > > On Oct 26, 2009, at 10:35 AM, Alexandru Petrescu wrote: > >> Thomas Heide Clausen a écrit : >>> On Oct 26, 2009, at 10:30 AM, Alexandru Petrescu wrote: >>>> Thomas Heide Clausen a écrit : >>>>> On Oct 26, 2009, at 10:05 AM, Alexandru Petrescu wrote: >>>>>> Thomas Heide Clausen a écrit : >>>>>>> On Oct 26, 2009, at 9:52 AM, Alexandru Petrescu wrote: >>>>>>>> Thomas Heide Clausen a écrit : >>>>>>>>> On Oct 25, 2009, at 7:29 PM, Alexandru Petrescu wrote: >>>>>>>>>> Emmanuel Baccelli a écrit : >>>>>>>>>>> Hi Alex, >>>>>>>>>>> obviously, this topic is completely out of scope for the >>>>>>>>>>> addressing model document, and even for the whole working group! >>>>>>>>>> >>>>>>>>>> But it's in the Charter, no? >>>>>>>>>> >>>>>>>>> No - what is in the charter is not what you're implying. >>>>>>>> >>>>>>>> Please interpret this for me: >>>>>>>> >>>>>>>>> It is required that such models do not cause problems for ad >>>>>>>>> hoc-unaware parts of the system, such as standard applications >>>>>>>>> running >>>>>>>>> on an ad hoc node or regular Internet nodes attached to the ad hoc >>>>>>>>> nodes. >>>>>>>> >>>>>>> Easy, consider this example network: >>>>>>> {a,b,c,d}-----AHR-- >>>>>>> AHR is an Ad Hoc Router with two interfaces. One is towards >>>>>>> {a,b,c,d} and is a regular ethernet, with a, b, c and d being >>>>>>> regular non-MANET hosts or routers. The other interface is a >>>>>>> "MANET interface" towards other AHRs. >>>>>>> Whatever [autoconf] does should not affect {a, b, c, d} at all -- >>>>>>> but, of course, will affect AHRs and their interconnect. >>>>>> >>>>>> I agree. >>>>>> >>>>>> This should be said in the document, to satisfy that Charter >>>>>> requirement. >>>>>> >>>>>> It currently does not address that requirement (at least not with >>>>>> respect to link-local addresses). >>>>>> >>>>>> Once you agree this is necessary, we can see further. >>>>>> >>>>> I'd be much happier if you rephrase your last sentence to: >>>>> "Once the WG agrees, we can see further" >>>>> ;) >>>>> So I'll wait for the rest of the WG to chime in -- I just explained >>>>> my understanding of the charter. >>>> >>>> :-) >>>> >>>> You implicitely say above that the Ad Hoc Router AHR has two >>>> interfaces. >>> No, I was saying that my example has one interface. >> >> But you pictured two ifaces on AHR! You even say so. >> > > Yes, in this *example* that is very true, for the purpose of > illustrating that point. One of the most particular points in AUTOCONF drafts is that A-B-C problem where B is claimed to have only one interface. It is one of the most important building blocks of the problem in AUTOCONF. If it had 2 interfaces, then we had no such problem. Alex > >>>> Maybe we should get agreement from the WG about AHR having two >>>> interfaces? (early signs showed 1). >>> No. An AHR may have 1, 2 or many many more interfaces.... >> >> I dont think you have agreement from the WG about this particular point. > > Hum, for 10+ years, we've been building MANETs with MANET routers (AHRs) > having a single interface. Some have multiple interfaces too. That too > has been supported for that long. > > I don't think that anybody who's been building MANETs would be able to > disagree on this particular point? > > Thomas > > >> Although I do agree with you on this particular point. >> >> Alex >> >>> Thomas >>>> Alex >>>> >>>>> Thomas >>>>>> Alex >>>>>> >>>>>>> Now, replace AHR with "OSPFv3-router" -- whatever OSPFv3-routers >>>>>>> do between them (and whatever changes are introduced to OSPFv3) >>>>>>> on OSPFv3 interfaces does not affect {a, b, c, d}. >>>>>>> This because the "magic of an OSPFv3 routing domain" -- and the >>>>>>> "magic of a MANET routing domain" -- is isolated from the rest of >>>>>>> the network by an IP hop. All the "ad hoc unaware parts of the >>>>>>> system" see is a well-defined, unchanged, classic, legacy IP hop... >>>>>>> Thomas >>>>>>> >>>>>> >>>>>> >>>> >>>> >> >> > > From ulrich@herberg.name Mon Oct 26 02:58: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 A94B628C118 for ; Mon, 26 Oct 2009 02:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[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 u9wu0linW373 for ; Mon, 26 Oct 2009 02:58:18 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id B41C428C10D for ; Mon, 26 Oct 2009 02:58:17 -0700 (PDT) Received: by fxm18 with SMTP id 18so11903176fxm.37 for ; Mon, 26 Oct 2009 02:58:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.152.27 with SMTP id e27mr3999467bkw.192.1256551107729; Mon, 26 Oct 2009 02:58:27 -0700 (PDT) In-Reply-To: <4AE57172.3010301@gmail.com> References: <4ADED440.2080403@cisco.com> <4AE56348.4050701@gmail.com> <7138D249-5FB8-49C6-B61C-209BC4601477@thomasclausen.org> <4AE56658.2080802@gmail.com> <4AE56C46.60403@gmail.com> <5D2D975E-FE10-42F5-8359-A03D5379C33A@thomasclausen.org> <4AE56D4E.9010709@gmail.com> <1BA26508-61D8-49BE-865D-180167A12C8F@thomasclausen.org> <4AE57172.3010301@gmail.com> Date: Mon, 26 Oct 2009 10:58:27 +0100 Message-ID: <25c114b90910260258h17247de9n63c1837c0961eba1@mail.gmail.com> From: Ulrich Herberg To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=0015175d03a66b1c190476d39a4c Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] adhoc unaware parts of the System, regular Internet nodes 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, 26 Oct 2009 09:58:18 -0000 --0015175d03a66b1c190476d39a4c Content-Type: text/plain; charset=ISO-8859-1 Alex, On Mon, Oct 26, 2009 at 10:52 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > [...] > One of the most particular points in AUTOCONF drafts is that A-B-C problem > where B is claimed to have only one interface. It is one of the most > important building blocks of the problem in AUTOCONF. > What is a building block? > > If it had 2 interfaces, then we had no such problem. > As such, this sentence is wrong. B could have two (or more interfaces), and still reach A and C over the same interface. Autoconf will have to support multiple interfaces. And -- as Thomas showed in the example -- should not have any effect on non-MANET interfaces. Ulrich --0015175d03a66b1c190476d39a4c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alex,

On Mon, Oct 26, 2009 at 10:52 AM, A= lexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
[...]
=A0
One of the most particular points in AUTOCONF drafts is that= A-B-C problem where B is claimed to have only one interface. =A0It is one = of the most important building blocks of the problem in AUTOCONF.

What is a building block?

If it had 2 interfaces, then we had no such problem.
<= br>As such, this sentence is wrong. B could have two (or more interfaces), = and still reach A and C over the same interface. Autoconf will have to supp= ort multiple interfaces. And -- as Thomas showed in the example -- should n= ot have any effect on non-MANET interfaces.

Ulrich
--0015175d03a66b1c190476d39a4c-- From ietf@thomasclausen.org Mon Oct 26 03:00: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 270283A68FF for ; Mon, 26 Oct 2009 03:00:45 -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 FNNjHlS5dHsg for ; Mon, 26 Oct 2009 03:00:44 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 20D033A68E9 for ; Mon, 26 Oct 2009 03:00:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id AFD3E32317AE; Mon, 26 Oct 2009 03:00:57 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 4FAC932317AB; Mon, 26 Oct 2009 03:00:56 -0700 (PDT) Message-Id: <80003250-7F99-439B-927B-B2CC70F95CB5@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE57172.3010301@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: Mon, 26 Oct 2009 11:00:53 +0100 References: <4ADED440.2080403@cisco.com> <4AE05EFC.2060501@gmail.com> <4AE41BC4.2050700@cisco.com> <4AE45F61.2000800@gmail.com> <4AE47B4B.2020906@gmail.com> <70909CF7-8087-4284-B90E-CD56CF3CB6FE@thomasclausen.org> <4AE495E2.2040800@gmail.com> <4AE49924.90805@gmail.com> <55338E8A-3153-4378-ACC9-9C682651F911@thomasclausen.org> <4AE56348.4050701@gmail.com> <7138D249-5FB8-49C6-B61C-209BC4601477@thomasclausen.org> <4AE56658.2080802@gmail.com> <4AE56C46.60403@gmail.com> <5D2D975E-FE10-42F5-8359-A03D5379C33A@thomasclausen.org> <4AE56D4E.9010709@gmail.com> <1BA26508-61D8-49BE-865D-180167A12C8F@thomasclausen.org> <4AE57172.3010301@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] adhoc unaware parts of the System, regular Internet nodes 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, 26 Oct 2009 10:00:45 -0000 On Oct 26, 2009, at 10:52 AM, Alexandru Petrescu wrote: > Thomas Heide Clausen a =E9crit : >> On Oct 26, 2009, at 10:35 AM, Alexandru Petrescu wrote: >>> Thomas Heide Clausen a =E9crit : >>>> On Oct 26, 2009, at 10:30 AM, Alexandru Petrescu wrote: >>>>> Thomas Heide Clausen a =E9crit : >>>>>> On Oct 26, 2009, at 10:05 AM, Alexandru Petrescu wrote: >>>>>>> Thomas Heide Clausen a =E9crit : >>>>>>>> On Oct 26, 2009, at 9:52 AM, Alexandru Petrescu wrote: >>>>>>>>> Thomas Heide Clausen a =E9crit : >>>>>>>>>> On Oct 25, 2009, at 7:29 PM, Alexandru Petrescu wrote: >>>>>>>>>>> Emmanuel Baccelli a =E9crit : >>>>>>>>>>>> Hi Alex, >>>>>>>>>>>> obviously, this topic is completely out of scope for the =20= >>>>>>>>>>>> addressing model document, and even for the whole working =20= >>>>>>>>>>>> group! >>>>>>>>>>> >>>>>>>>>>> But it's in the Charter, no? >>>>>>>>>>> >>>>>>>>>> No - what is in the charter is not what you're implying. >>>>>>>>> >>>>>>>>> Please interpret this for me: >>>>>>>>> >>>>>>>>>> It is required that such models do not cause problems for ad >>>>>>>>>> hoc-unaware parts of the system, such as standard =20 >>>>>>>>>> applications running >>>>>>>>>> on an ad hoc node or regular Internet nodes attached to the =20= >>>>>>>>>> ad hoc >>>>>>>>>> nodes. >>>>>>>>> >>>>>>>> Easy, consider this example network: >>>>>>>> {a,b,c,d}-----AHR-- >>>>>>>> AHR is an Ad Hoc Router with two interfaces. One is towards =20 >>>>>>>> {a,b,c,d} and is a regular ethernet, with a, b, c and d being =20= >>>>>>>> regular non-MANET hosts or routers. The other interface is a =20= >>>>>>>> "MANET interface" towards other AHRs. >>>>>>>> Whatever [autoconf] does should not affect {a, b, c, d} at =20 >>>>>>>> all -- but, of course, will affect AHRs and their interconnect. >>>>>>> >>>>>>> I agree. >>>>>>> >>>>>>> This should be said in the document, to satisfy that Charter =20 >>>>>>> requirement. >>>>>>> >>>>>>> It currently does not address that requirement (at least not =20 >>>>>>> with respect to link-local addresses). >>>>>>> >>>>>>> Once you agree this is necessary, we can see further. >>>>>>> >>>>>> I'd be much happier if you rephrase your last sentence to: >>>>>> "Once the WG agrees, we can see further" >>>>>> ;) >>>>>> So I'll wait for the rest of the WG to chime in -- I just =20 >>>>>> explained my understanding of the charter. >>>>> >>>>> :-) >>>>> >>>>> You implicitely say above that the Ad Hoc Router AHR has two =20 >>>>> interfaces. >>>> No, I was saying that my example has one interface. >>> >>> But you pictured two ifaces on AHR! You even say so. >>> >> Yes, in this *example* that is very true, for the purpose of =20 >> illustrating that point. > > One of the most particular points in AUTOCONF drafts is that A-B-C =20 > problem where B is claimed to have only one interface. It is one of =20= > the most important building blocks of the problem in AUTOCONF. An A, B, C are MANET routers in your example? If yes, then A, B, C =20 (with whatever many interfaces they have) are aware of their MANET =20 capabilities (just as an OSPFv3 router is aware of its OSPFv3 =20 capabilities) The "single-MANET-interface-router" configuration is quite common in =20 MANETs. I'd even go as far as saying that it's probably the most =20 common configuration. Duly note that we're only *interested* in MANET interfaces -- non-=20 MANET-interfaces we've already agreed to not touch, they should =20 operate as they always have. > If it had 2 interfaces, then we had no such problem. Oh yes, we still would. Thomas > > Alex > >>>>> Maybe we should get agreement from the WG about AHR having two =20 >>>>> interfaces? (early signs showed 1). >>>> No. An AHR may have 1, 2 or many many more interfaces.... >>> >>> I dont think you have agreement from the WG about this particular =20= >>> point. >> Hum, for 10+ years, we've been building MANETs with MANET routers =20 >> (AHRs) having a single interface. Some have multiple interfaces =20 >> too. That too has been supported for that long. >> I don't think that anybody who's been building MANETs would be able =20= >> to disagree on this particular point? >> Thomas >>> Although I do agree with you on this particular point. >>> >>> Alex >>> >>>> Thomas >>>>> Alex >>>>> >>>>>> Thomas >>>>>>> Alex >>>>>>> >>>>>>>> Now, replace AHR with "OSPFv3-router" -- whatever OSPFv3-=20 >>>>>>>> routers do between them (and whatever changes are introduced =20= >>>>>>>> to OSPFv3) on OSPFv3 interfaces does not affect {a, b, c, d}. >>>>>>>> This because the "magic of an OSPFv3 routing domain" -- and =20 >>>>>>>> the "magic of a MANET routing domain" -- is isolated from the =20= >>>>>>>> rest of the network by an IP hop. All the "ad hoc unaware =20 >>>>>>>> parts of the system" see is a well-defined, unchanged, =20 >>>>>>>> classic, legacy IP hop... >>>>>>>> Thomas >>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > From alexandru.petrescu@gmail.com Mon Oct 26 03:08: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 A3AA53A68E9 for ; Mon, 26 Oct 2009 03:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[AWL=0.132, 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 xrm8Pbq3ER8Z for ; Mon, 26 Oct 2009 03:08:27 -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 979333A69B2 for ; Mon, 26 Oct 2009 03:08:27 -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 n9QA8cxQ017651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 11:08:38 +0100 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 n9QA8cNH018958; Mon, 26 Oct 2009 11:08:38 +0100 (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 n9QA8cRC008906; Mon, 26 Oct 2009 11:08:38 +0100 Message-ID: <4AE57525.8010405@gmail.com> Date: Mon, 26 Oct 2009 11:08:37 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ulrich Herberg References: <4ADED440.2080403@cisco.com> <4AE56348.4050701@gmail.com> <7138D249-5FB8-49C6-B61C-209BC4601477@thomasclausen.org> <4AE56658.2080802@gmail.com> <4AE56C46.60403@gmail.com> <5D2D975E-FE10-42F5-8359-A03D5379C33A@thomasclausen.org> <4AE56D4E.9010709@gmail.com> <1BA26508-61D8-49BE-865D-180167A12C8F@thomasclausen.org> <4AE57172.3010301@gmail.com> <25c114b90910260258h17247de9n63c1837c0961eba1@mail.gmail.com> In-Reply-To: <25c114b90910260258h17247de9n63c1837c0961eba1@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] adhoc unaware parts of the System, regular Internet nodes 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, 26 Oct 2009 10:08:28 -0000 Ulrich Herberg a écrit : > Alex, > > On Mon, Oct 26, 2009 at 10:52 AM, Alexandru Petrescu > > wrote: > > [...] > > > > One of the most particular points in AUTOCONF drafts is that A-B-C > problem where B is claimed to have only one interface. It is one of > the most important building blocks of the problem in AUTOCONF. > > > What is a building block? Ok, it is a recurrent aspect motivating the AUTOCONF work, appearing several times in the AUTOCONF drafts. > If it had 2 interfaces, then we had no such problem. > > > As such, this sentence is wrong. B could have two (or more interfaces), > and still reach A and C over the same interface. :-) > Autoconf will have to > support multiple interfaces. And -- as Thomas showed in the example -- > should not have any effect on non-MANET interfaces. Ok - what happens if a non-MANET node connects to a MANET interface of a MANET router? Do you forbid this case? Do you care about this case? If you do - then you should not discourage the IPv4 LLs of the non-MANET node. You could discourage the IPv4 LLs of the MANET interface of a MANET node. Or - this distinction is not made in the draft. It is only made in our discussions. Alex > > Ulrich From henning.rogge@fkie.fraunhofer.de Mon Oct 26 03:08: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 02C3A3A69B0 for ; Mon, 26 Oct 2009 03:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.063 X-Spam-Level: X-Spam-Status: No, score=-6.063 tagged_above=-999 required=5 tests=[AWL=0.186, 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 UUo0NuXUT4AP for ; Mon, 26 Oct 2009 03:08:46 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id B70F13A6912 for ; Mon, 26 Oct 2009 03:08:46 -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 1N2MVU-00053F-6w; Mon, 26 Oct 2009 11:08:56 +0100 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 1N2MVT-0001g0-UO; Mon, 26 Oct 2009 11:08:55 +0100 From: Henning Rogge To: autoconf@ietf.org Date: Mon, 26 Oct 2009 11:08:42 +0100 User-Agent: KMail/1.11.2 (Linux/2.6.30-10-generic; KDE/4.2.2; i686; ; ) References: <4ADED440.2080403@cisco.com> <4AE57172.3010301@gmail.com> <80003250-7F99-439B-927B-B2CC70F95CB5@thomasclausen.org> In-Reply-To: <80003250-7F99-439B-927B-B2CC70F95CB5@thomasclausen.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2177941.lYrzxZxhSZ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910261108.48024.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/9940/Mon Oct 26 02:47:14 2009) by mailguard.fgan.de X-Scan-Signature: 093a4d18fb20d26714c728ddf8a13ad0 Cc: Emmanuel Baccelli Subject: Re: [Autoconf] adhoc unaware parts of the System, regular Internet nodes 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, 26 Oct 2009 10:08:48 -0000 --nextPart2177941.lYrzxZxhSZ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Mon October 26 2009 11:00:53 schrieb Thomas Heide Clausen: > An A, B, C are MANET routers in your example? If yes, then A, B, C > (with whatever many interfaces they have) are aware of their MANET > capabilities (just as an OSPFv3 router is aware of its OSPFv3 > capabilities) > > The "single-MANET-interface-router" configuration is quite common in > MANETs. I'd even go as far as saying that it's probably the most > common configuration. Devices with more than one interface are much more expensive, so they are n= ot=20 as common as one-interface routers. > > If it had 2 interfaces, then we had no such problem. > > Oh yes, we still would. If we had only interfaces with "closed" broadcast domains life would be muc= h=20 easier... ;) 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 --nextPart2177941.lYrzxZxhSZ 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) iEYEABECAAYFAkrldSsACgkQRIfGfFXsz+CRdgCfR0HD22YQbaadK/WHNxdOLITQ OQsAoJew1QbtNhbtZhmx6PLjeN3cPir8 =V6Pl -----END PGP SIGNATURE----- --nextPart2177941.lYrzxZxhSZ-- From alexandru.petrescu@gmail.com Mon Oct 26 03:11: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 469183A68F6 for ; Mon, 26 Oct 2009 03:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[AWL=0.129, 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 rX3YrFSc9rsn for ; Mon, 26 Oct 2009 03:11:36 -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 E310C3A659C for ; Mon, 26 Oct 2009 03:11:35 -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 n9QABlJD019969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 11:11:47 +0100 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 n9QABlNt020312; Mon, 26 Oct 2009 11:11:47 +0100 (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 n9QABlPv010471; Mon, 26 Oct 2009 11:11:47 +0100 Message-ID: <4AE575E3.2070806@gmail.com> Date: Mon, 26 Oct 2009 11:11:47 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <4ADED440.2080403@cisco.com> <4AE05EFC.2060501@gmail.com> <4AE41BC4.2050700@cisco.com> <4AE45F61.2000800@gmail.com> <4AE47B4B.2020906@gmail.com> <70909CF7-8087-4284-B90E-CD56CF3CB6FE@thomasclausen.org> <4AE495E2.2040800@gmail.com> <4AE49924.90805@gmail.com> <55338E8A-3153-4378-ACC9-9C682651F911@thomasclausen.org> <4AE56348.4050701@gmail.com> <7138D249-5FB8-49C6-B61C-209BC4601477@thomasclausen.org> <4AE56658.2080802@gmail.com> <4AE56C46.60403@gmail.com> <5D2D975E-FE10-42F5-8359-A03D5379C33A@thomasclausen.org> <4AE56D4E.9010709@gmail.com> <1BA26508-61D8-49BE-865D-180167A12C8F@thomasclausen.org> <4AE57172.3010301@gmail.com> <80003250-7F99-439B-927B-B2CC70F95CB5@thomasclausen.org> In-Reply-To: <80003250-7F99-439B-927B-B2CC70F95CB5@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] adhoc unaware parts of the System, regular Internet nodes 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, 26 Oct 2009 10:11:37 -0000 Thomas Heide Clausen a écrit : > > On Oct 26, 2009, at 10:52 AM, Alexandru Petrescu wrote: > >> Thomas Heide Clausen a écrit : >>> On Oct 26, 2009, at 10:35 AM, Alexandru Petrescu wrote: >>>> Thomas Heide Clausen a écrit : >>>>> On Oct 26, 2009, at 10:30 AM, Alexandru Petrescu wrote: >>>>>> Thomas Heide Clausen a écrit : >>>>>>> On Oct 26, 2009, at 10:05 AM, Alexandru Petrescu wrote: >>>>>>>> Thomas Heide Clausen a écrit : >>>>>>>>> On Oct 26, 2009, at 9:52 AM, Alexandru Petrescu wrote: >>>>>>>>>> Thomas Heide Clausen a écrit : >>>>>>>>>>> On Oct 25, 2009, at 7:29 PM, Alexandru Petrescu wrote: >>>>>>>>>>>> Emmanuel Baccelli a écrit : >>>>>>>>>>>>> Hi Alex, >>>>>>>>>>>>> obviously, this topic is completely out of scope for the >>>>>>>>>>>>> addressing model document, and even for the whole working >>>>>>>>>>>>> group! >>>>>>>>>>>> >>>>>>>>>>>> But it's in the Charter, no? >>>>>>>>>>>> >>>>>>>>>>> No - what is in the charter is not what you're implying. >>>>>>>>>> >>>>>>>>>> Please interpret this for me: >>>>>>>>>> >>>>>>>>>>> It is required that such models do not cause problems for ad >>>>>>>>>>> hoc-unaware parts of the system, such as standard >>>>>>>>>>> applications running >>>>>>>>>>> on an ad hoc node or regular Internet nodes attached to the >>>>>>>>>>> ad hoc >>>>>>>>>>> nodes. >>>>>>>>>> >>>>>>>>> Easy, consider this example network: >>>>>>>>> {a,b,c,d}-----AHR-- >>>>>>>>> AHR is an Ad Hoc Router with two interfaces. One is towards >>>>>>>>> {a,b,c,d} and is a regular ethernet, with a, b, c and d being >>>>>>>>> regular non-MANET hosts or routers. The other interface is a >>>>>>>>> "MANET interface" towards other AHRs. >>>>>>>>> Whatever [autoconf] does should not affect {a, b, c, d} at all >>>>>>>>> -- but, of course, will affect AHRs and their interconnect. >>>>>>>> >>>>>>>> I agree. >>>>>>>> >>>>>>>> This should be said in the document, to satisfy that Charter >>>>>>>> requirement. >>>>>>>> >>>>>>>> It currently does not address that requirement (at least not >>>>>>>> with respect to link-local addresses). >>>>>>>> >>>>>>>> Once you agree this is necessary, we can see further. >>>>>>>> >>>>>>> I'd be much happier if you rephrase your last sentence to: >>>>>>> "Once the WG agrees, we can see further" >>>>>>> ;) >>>>>>> So I'll wait for the rest of the WG to chime in -- I just >>>>>>> explained my understanding of the charter. >>>>>> >>>>>> :-) >>>>>> >>>>>> You implicitely say above that the Ad Hoc Router AHR has two >>>>>> interfaces. >>>>> No, I was saying that my example has one interface. >>>> >>>> But you pictured two ifaces on AHR! You even say so. >>>> >>> Yes, in this *example* that is very true, for the purpose of >>> illustrating that point. >> >> One of the most particular points in AUTOCONF drafts is that A-B-C >> problem where B is claimed to have only one interface. It is one of >> the most important building blocks of the problem in AUTOCONF. > > An A, B, C are MANET routers in your example? If yes, then A, B, C (with > whatever many interfaces they have) are aware of their MANET > capabilities (just as an OSPFv3 router is aware of its OSPFv3 capabilities) > > The "single-MANET-interface-router" configuration is quite common in > MANETs. I'd even go as far as saying that it's probably the most common > configuration. > > Duly note that we're only *interested* in MANET interfaces -- > non-MANET-interfaces we've already agreed to not touch, they should > operate as they always have. Thomas - are you interested about what happens when a non-MANET node connects to a MANET interface of a MANET node? If yes - then you should not forbid the IPv4 LLs on the non-MANET nodes. You could discourage them on the MANET interfaces of the MANET nodes. This distinction should be made in the draft. >> If it had 2 interfaces, then we had no such problem. > > Oh yes, we still would. Ok - the solution would be to route between the two interfaces. Alex > > Thomas > >> >> Alex >> >>>>>> Maybe we should get agreement from the WG about AHR having two >>>>>> interfaces? (early signs showed 1). >>>>> No. An AHR may have 1, 2 or many many more interfaces.... >>>> >>>> I dont think you have agreement from the WG about this particular >>>> point. >>> Hum, for 10+ years, we've been building MANETs with MANET routers >>> (AHRs) having a single interface. Some have multiple interfaces too. >>> That too has been supported for that long. >>> I don't think that anybody who's been building MANETs would be able >>> to disagree on this particular point? >>> Thomas >>>> Although I do agree with you on this particular point. >>>> >>>> Alex >>>> >>>>> Thomas >>>>>> Alex >>>>>> >>>>>>> Thomas >>>>>>>> Alex >>>>>>>> >>>>>>>>> Now, replace AHR with "OSPFv3-router" -- whatever >>>>>>>>> OSPFv3-routers do between them (and whatever changes are >>>>>>>>> introduced to OSPFv3) on OSPFv3 interfaces does not affect {a, >>>>>>>>> b, c, d}. >>>>>>>>> This because the "magic of an OSPFv3 routing domain" -- and the >>>>>>>>> "magic of a MANET routing domain" -- is isolated from the rest >>>>>>>>> of the network by an IP hop. All the "ad hoc unaware parts of >>>>>>>>> the system" see is a well-defined, unchanged, classic, legacy >>>>>>>>> IP hop... >>>>>>>>> Thomas >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >> >> > > From ietf@thomasclausen.org Mon Oct 26 03: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 5481428C13A for ; Mon, 26 Oct 2009 03:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 I16LE69BQyPi for ; Mon, 26 Oct 2009 03:14:14 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 84E3428C125 for ; Mon, 26 Oct 2009 03:14:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 22FAC32317AD; Mon, 26 Oct 2009 03:14:26 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id C6FD732317AB; Mon, 26 Oct 2009 03:14:24 -0700 (PDT) Message-Id: <494563A5-573D-4565-B6EA-45454129A57F@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE57525.8010405@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: Mon, 26 Oct 2009 11:14:22 +0100 References: <4ADED440.2080403@cisco.com> <4AE56348.4050701@gmail.com> <7138D249-5FB8-49C6-B61C-209BC4601477@thomasclausen.org> <4AE56658.2080802@gmail.com> <4AE56C46.60403@gmail.com> <5D2D975E-FE10-42F5-8359-A03D5379C33A@thomasclausen.org> <4AE56D4E.9010709@gmail.com> <1BA26508-61D8-49BE-865D-180167A12C8F@thomasclausen.org> <4AE57172.3010301@gmail.com> <25c114b90910260258h17247de9n63c1837c0961eba1@mail.gmail.com> <4AE57525.8010405@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] adhoc unaware parts of the System, regular Internet nodes 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, 26 Oct 2009 10:14:15 -0000 On Oct 26, 2009, at 11:08 AM, Alexandru Petrescu wrote: > Ulrich Herberg a =E9crit : >> Alex, >> On Mon, Oct 26, 2009 at 10:52 AM, Alexandru Petrescu = > > wrote: >> [...] >> One of the most particular points in AUTOCONF drafts is that A-=20= >> B-C >> problem where B is claimed to have only one interface. It is =20 >> one of >> the most important building blocks of the problem in AUTOCONF. >> What is a building block? > > Ok, it is a recurrent aspect motivating the AUTOCONF work, appearing =20= > several times in the AUTOCONF drafts. > >> If it had 2 interfaces, then we had no such problem. >> As such, this sentence is wrong. B could have two (or more =20 >> interfaces), and still reach A and C over the same interface. > > :-) > >> Autoconf will have to support multiple interfaces. And -- as Thomas =20= >> showed in the example -- should not have any effect on non-MANET =20 >> interfaces. > > Ok - what happens if a non-MANET node connects to a MANET interface =20= > of a MANET router? > What happens if a non-OSPFv3 router connects to an OSPFv3 interface of =20= an OSPFv3 router? > Do you forbid this case? In my networks, yes, I do not see the use of it. Furthermore, I see it =20= as somewhat harmful as that means that an application bound to that =20 "non-MANET node" would be exposed to the characteristics of a MANET, =20 and may not be able to handle it. Thomas > Do you care about this case? > > If you do - then you should not discourage the IPv4 LLs of the non-=20 > MANET node. You could discourage the IPv4 LLs of the MANET =20 > interface of a MANET node. > > Or - this distinction is not made in the draft. It is only made in =20= > our discussions. > > Alex > >> Ulrich > > From ietf@thomasclausen.org Mon Oct 26 03:14: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 6031C3A6927 for ; Mon, 26 Oct 2009 03:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 urXZek7zcGrn for ; Mon, 26 Oct 2009 03:14:36 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 78CE03A6912 for ; Mon, 26 Oct 2009 03:14:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 1731132317AE; Mon, 26 Oct 2009 03:14:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id A745532317AB; Mon, 26 Oct 2009 03:14:48 -0700 (PDT) Message-Id: From: Thomas Heide Clausen To: Henning Rogge In-Reply-To: <200910261108.48024.henning.rogge@fkie.fraunhofer.de> 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: Mon, 26 Oct 2009 11:14:48 +0100 References: <4ADED440.2080403@cisco.com> <4AE57172.3010301@gmail.com> <80003250-7F99-439B-927B-B2CC70F95CB5@thomasclausen.org> <200910261108.48024.henning.rogge@fkie.fraunhofer.de> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] adhoc unaware parts of the System, regular Internet nodes 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, 26 Oct 2009 10:14:37 -0000 On Oct 26, 2009, at 11:08 AM, Henning Rogge wrote: > Am Mon October 26 2009 11:00:53 schrieb Thomas Heide Clausen: >> An A, B, C are MANET routers in your example? If yes, then A, B, C >> (with whatever many interfaces they have) are aware of their MANET >> capabilities (just as an OSPFv3 router is aware of its OSPFv3 >> capabilities) >> >> The "single-MANET-interface-router" configuration is quite common in >> MANETs. I'd even go as far as saying that it's probably the most >> common configuration. > Devices with more than one interface are much more expensive, so =20 > they are not > as common as one-interface routers. > >>> If it had 2 interfaces, then we had no such problem. >> >> Oh yes, we still would. > If we had only interfaces with "closed" broadcast domains life would =20= > be much > easier... ;) > Yes, if only the world looked like an Ethernet..... Thomas > 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 ietf@thomasclausen.org Mon Oct 26 03:16: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 8C07328C13A for ; Mon, 26 Oct 2009 03:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 wCnhGsLFK4UZ for ; Mon, 26 Oct 2009 03:16:23 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 8AC943A682E for ; Mon, 26 Oct 2009 03:16:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 2A1D432317AF; Mon, 26 Oct 2009 03:16:37 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id B337D32317AB; Mon, 26 Oct 2009 03:16:35 -0700 (PDT) Message-Id: <925AFA16-6FFB-4DD2-A9C9-0F2B30D2E82F@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE575E3.2070806@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: Mon, 26 Oct 2009 11:16:33 +0100 References: <4ADED440.2080403@cisco.com> <4AE05EFC.2060501@gmail.com> <4AE41BC4.2050700@cisco.com> <4AE45F61.2000800@gmail.com> <4AE47B4B.2020906@gmail.com> <70909CF7-8087-4284-B90E-CD56CF3CB6FE@thomasclausen.org> <4AE495E2.2040800@gmail.com> <4AE49924.90805@gmail.com> <55338E8A-3153-4378-ACC9-9C682651F911@thomasclausen.org> <4AE56348.4050701@gmail.com> <7138D249-5FB8-49C6-B61C-209BC4601477@thomasclausen.org> <4AE56658.2080802@gmail.com> <4AE56C46.60403@gmail.com> <5D2D975E-FE10-42F5-8359-A03D5379C33A@thomasclausen.org> <4AE56D4E.9010709@gmail.com> <1BA26508-61D8-49BE-865D-180167A12C8F@thomasclausen.org> <4AE57172.3010301@gmail.com> <80003250-7F99-439B-927B-B2CC70F95CB5@thomasclausen.org> <4AE575E3.2070806@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] adhoc unaware parts of the System, regular Internet nodes 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, 26 Oct 2009 10:16:24 -0000 On Oct 26, 2009, at 11:11 AM, Alexandru Petrescu wrote: > Thomas Heide Clausen a =E9crit : >> On Oct 26, 2009, at 10:52 AM, Alexandru Petrescu wrote: >>> Thomas Heide Clausen a =E9crit : >>>> On Oct 26, 2009, at 10:35 AM, Alexandru Petrescu wrote: >>>>> Thomas Heide Clausen a =E9crit : >>>>>> On Oct 26, 2009, at 10:30 AM, Alexandru Petrescu wrote: >>>>>>> Thomas Heide Clausen a =E9crit : >>>>>>>> On Oct 26, 2009, at 10:05 AM, Alexandru Petrescu wrote: >>>>>>>>> Thomas Heide Clausen a =E9crit : >>>>>>>>>> On Oct 26, 2009, at 9:52 AM, Alexandru Petrescu wrote: >>>>>>>>>>> Thomas Heide Clausen a =E9crit : >>>>>>>>>>>> On Oct 25, 2009, at 7:29 PM, Alexandru Petrescu wrote: >>>>>>>>>>>>> Emmanuel Baccelli a =E9crit : >>>>>>>>>>>>>> Hi Alex, >>>>>>>>>>>>>> obviously, this topic is completely out of scope for =20 >>>>>>>>>>>>>> the addressing model document, and even for the whole =20 >>>>>>>>>>>>>> working group! >>>>>>>>>>>>> >>>>>>>>>>>>> But it's in the Charter, no? >>>>>>>>>>>>> >>>>>>>>>>>> No - what is in the charter is not what you're implying. >>>>>>>>>>> >>>>>>>>>>> Please interpret this for me: >>>>>>>>>>> >>>>>>>>>>>> It is required that such models do not cause problems for =20= >>>>>>>>>>>> ad >>>>>>>>>>>> hoc-unaware parts of the system, such as standard =20 >>>>>>>>>>>> applications running >>>>>>>>>>>> on an ad hoc node or regular Internet nodes attached to =20 >>>>>>>>>>>> the ad hoc >>>>>>>>>>>> nodes. >>>>>>>>>>> >>>>>>>>>> Easy, consider this example network: >>>>>>>>>> {a,b,c,d}-----AHR-- >>>>>>>>>> AHR is an Ad Hoc Router with two interfaces. One is towards =20= >>>>>>>>>> {a,b,c,d} and is a regular ethernet, with a, b, c and d =20 >>>>>>>>>> being regular non-MANET hosts or routers. The other =20 >>>>>>>>>> interface is a "MANET interface" towards other AHRs. >>>>>>>>>> Whatever [autoconf] does should not affect {a, b, c, d} at =20= >>>>>>>>>> all -- but, of course, will affect AHRs and their =20 >>>>>>>>>> interconnect. >>>>>>>>> >>>>>>>>> I agree. >>>>>>>>> >>>>>>>>> This should be said in the document, to satisfy that Charter =20= >>>>>>>>> requirement. >>>>>>>>> >>>>>>>>> It currently does not address that requirement (at least not =20= >>>>>>>>> with respect to link-local addresses). >>>>>>>>> >>>>>>>>> Once you agree this is necessary, we can see further. >>>>>>>>> >>>>>>>> I'd be much happier if you rephrase your last sentence to: >>>>>>>> "Once the WG agrees, we can see further" >>>>>>>> ;) >>>>>>>> So I'll wait for the rest of the WG to chime in -- I just =20 >>>>>>>> explained my understanding of the charter. >>>>>>> >>>>>>> :-) >>>>>>> >>>>>>> You implicitely say above that the Ad Hoc Router AHR has two =20 >>>>>>> interfaces. >>>>>> No, I was saying that my example has one interface. >>>>> >>>>> But you pictured two ifaces on AHR! You even say so. >>>>> >>>> Yes, in this *example* that is very true, for the purpose of =20 >>>> illustrating that point. >>> >>> One of the most particular points in AUTOCONF drafts is that A-B-C =20= >>> problem where B is claimed to have only one interface. It is one =20= >>> of the most important building blocks of the problem in AUTOCONF. >> An A, B, C are MANET routers in your example? If yes, then A, B, C =20= >> (with whatever many interfaces they have) are aware of their MANET =20= >> capabilities (just as an OSPFv3 router is aware of its OSPFv3 =20 >> capabilities) >> The "single-MANET-interface-router" configuration is quite common =20 >> in MANETs. I'd even go as far as saying that it's probably the most =20= >> common configuration. >> Duly note that we're only *interested* in MANET interfaces -- non-=20 >> MANET-interfaces we've already agreed to not touch, they should =20 >> operate as they always have. > > Thomas - are you interested about what happens when a non-MANET node =20= > connects to a MANET interface of a MANET node? > No. Just as I'm not interested in what happens if an Ethernet =20 interface plugs into a Token Ring network..... > If yes - then you should not forbid the IPv4 LLs on the non-MANET =20 > nodes. You could discourage them on the MANET interfaces of the =20 > MANET nodes. > > This distinction should be made in the draft. > >>> If it had 2 interfaces, then we had no such problem. >> Oh yes, we still would. > > Ok - the solution would be to route between the two interfaces. No, Ulrich explained well the issue - what you propose as "solution" =20 has nothing to do with the problem. Thomas > > Alex > >> Thomas >>> >>> Alex >>> >>>>>>> Maybe we should get agreement from the WG about AHR having two =20= >>>>>>> interfaces? (early signs showed 1). >>>>>> No. An AHR may have 1, 2 or many many more interfaces.... >>>>> >>>>> I dont think you have agreement from the WG about this =20 >>>>> particular point. >>>> Hum, for 10+ years, we've been building MANETs with MANET routers =20= >>>> (AHRs) having a single interface. Some have multiple interfaces =20 >>>> too. That too has been supported for that long. >>>> I don't think that anybody who's been building MANETs would be =20 >>>> able to disagree on this particular point? >>>> Thomas >>>>> Although I do agree with you on this particular point. >>>>> >>>>> Alex >>>>> >>>>>> Thomas >>>>>>> Alex >>>>>>> >>>>>>>> Thomas >>>>>>>>> Alex >>>>>>>>> >>>>>>>>>> Now, replace AHR with "OSPFv3-router" -- whatever OSPFv3-=20 >>>>>>>>>> routers do between them (and whatever changes are =20 >>>>>>>>>> introduced to OSPFv3) on OSPFv3 interfaces does not affect =20= >>>>>>>>>> {a, b, c, d}. >>>>>>>>>> This because the "magic of an OSPFv3 routing domain" -- and =20= >>>>>>>>>> the "magic of a MANET routing domain" -- is isolated from =20 >>>>>>>>>> the rest of the network by an IP hop. All the "ad hoc =20 >>>>>>>>>> unaware parts of the system" see is a well-defined, =20 >>>>>>>>>> unchanged, classic, legacy IP hop... >>>>>>>>>> Thomas >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > From alexandru.petrescu@gmail.com Mon Oct 26 03:48:34 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 4C3EC3A696F for ; Mon, 26 Oct 2009 03:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=0.118, 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 OEXup+8Ot22H for ; Mon, 26 Oct 2009 03:48:33 -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 3BA683A694E for ; Mon, 26 Oct 2009 03:48:33 -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 n9QAmibD031068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 11:48:44 +0100 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 n9QAmhXT031575; Mon, 26 Oct 2009 11:48:44 +0100 (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 n9QAmh1b024352; Mon, 26 Oct 2009 11:48:43 +0100 Message-ID: <4AE57E8B.6070803@gmail.com> Date: Mon, 26 Oct 2009 11:48:43 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <4ADED440.2080403@cisco.com> <4AE56348.4050701@gmail.com> <7138D249-5FB8-49C6-B61C-209BC4601477@thomasclausen.org> <4AE56658.2080802@gmail.com> <4AE56C46.60403@gmail.com> <5D2D975E-FE10-42F5-8359-A03D5379C33A@thomasclausen.org> <4AE56D4E.9010709@gmail.com> <1BA26508-61D8-49BE-865D-180167A12C8F@thomasclausen.org> <4AE57172.3010301@gmail.com> <25c114b90910260258h17247de9n63c1837c0961eba1@mail.gmail.com> <4AE57525.8010405@gmail.com> <494563A5-573D-4565-B6EA-45454129A57F@thomasclausen.org> In-Reply-To: <494563A5-573D-4565-B6EA-45454129A57F@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] adhoc unaware parts of the System, regular Internet nodes 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, 26 Oct 2009 10:48:34 -0000 Thomas Heide Clausen a écrit : > > On Oct 26, 2009, at 11:08 AM, Alexandru Petrescu wrote: > >> Ulrich Herberg a écrit : >>> Alex, >>> On Mon, Oct 26, 2009 at 10:52 AM, Alexandru Petrescu >>> > >>> wrote: >>> [...] >>> One of the most particular points in AUTOCONF drafts is that A-B-C >>> problem where B is claimed to have only one interface. It is one of >>> the most important building blocks of the problem in AUTOCONF. >>> What is a building block? >> >> Ok, it is a recurrent aspect motivating the AUTOCONF work, appearing >> several times in the AUTOCONF drafts. >> >>> If it had 2 interfaces, then we had no such problem. >>> As such, this sentence is wrong. B could have two (or more >>> interfaces), and still reach A and C over the same interface. >> >> :-) >> >>> Autoconf will have to support multiple interfaces. And -- as Thomas >>> showed in the example -- should not have any effect on non-MANET >>> interfaces. >> >> Ok - what happens if a non-MANET node connects to a MANET interface of >> a MANET router? >> > > What happens if a non-OSPFv3 router connects to an OSPFv3 interface of > an OSPFv3 router? Err..., right, then the non-OSPFv3 router can not talk OSPFv3 to the OSPFv3 router. This is a good example, because there is a way by which the non-OSPFv3 router is not disturbed by the OSPFv3 messaging - it doesnt join the respective multicast group. This avoidance by use of multicast is possible because both OSPFv3 and non-OSPFv3 routers follow the same rules about addressing. If, e.g., the OSPFv3 router were to be specified to broadcast messages (ff02::1 instead of the ospf group), then the non-OSPFv3 router would be disturbed. In the same way, the non-MANET nodes and the MANET nodes should follow the same addressing mechanisms, in order to not disturb each other. Discouraging the use of link-local addresses is a significant departure from the current addressing scheme. >> Do you forbid this case? > > In my networks, yes, I do not see the use of it. Furthermore, I see it > as somewhat harmful as that means that an application bound to that > "non-MANET node" would be exposed to the characteristics of a MANET, and > may not be able to handle it. Well, I think your network - if you want to connect it to non-MANET nodes - should follow same addressing rules as the non-MANET nodes. It should not discourage the use of LLs. It could develop other ways of assigning global addresses, but don't discourage the existing ways. If your new AUTOCONF mechanism uses a new link-local multicast group (as the MANET WG IANA document implies: link-local multicast group address ff02::6d) then I am not sure how are you going to forbid the link-local addresses, which have the same scope. But that is another point about which I will write separately. Alex > > Thomas > >> Do you care about this case? >> >> If you do - then you should not discourage the IPv4 LLs of the >> non-MANET node. You could discourage the IPv4 LLs of the MANET >> interface of a MANET node. >> >> Or - this distinction is not made in the draft. It is only made in >> our discussions. >> >> Alex >> >>> Ulrich >> >> > > From teco@inf-net.nl Mon Oct 26 03:56: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 1EAB33A6A51 for ; Mon, 26 Oct 2009 03:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.255 X-Spam-Level: X-Spam-Status: No, score=-1.255 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, 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 Bu0MMLJp77T4 for ; Mon, 26 Oct 2009 03:56:51 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 9F23E3A6A59 for ; Mon, 26 Oct 2009 03:56:50 -0700 (PDT) Received: (qmail 5589 invoked from network); 26 Oct 2009 11:57:00 +0100 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 26 Oct 2009 11:57:00 +0100 From: "Teco Boot" To: "'Ulrich Herberg'" , "'Thomas Heide Clausen'" References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <005801ca5618$38d35be0$aa7a13a0$@nl> <25c114b90910260219h52c74b4dha6871856afaaec23@mail.gmail.com> In-Reply-To: <25c114b90910260219h52c74b4dha6871856afaaec23@mail.gmail.com> Date: Mon, 26 Oct 2009 11:56:29 +0100 Message-ID: <00b601ca562b$0afa2ab0$20ee8010$@nl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B7_01CA5633.6CBE92B0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpWHW+bHcT6KKV8RzqA/wrPbSE9gwADXkOA Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 10:56:52 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00B7_01CA5633.6CBE92B0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Van: ulrich@herberg.name [mailto:ulrich@herberg.name] Namens Ulrich Herberg Verzonden: maandag 26 oktober 2009 10:20 Aan: Thomas Heide Clausen CC: Teco Boot; autoconf@ietf.org Onderwerp: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt Fully agree with Thomas here. Note that the DT draft says: "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 connnectivity to neighbors may be constantly changing." So, the draft also says that (per RFC4291) LL are configured on an interface. It just says that they are not of much use, because it is very difficult to assure uniqueness beyond 1 hop. Same for ULAs and globals to! Teco. Ulrich On Mon, Oct 26, 2009 at 9:48 AM, Thomas Heide Clausen wrote: On Oct 26, 2009, at 9:41 AM, Teco Boot wrote: Thomas Heide Clausen wrote: o If you have an LL address [generated by the usual means], it may be useless. Use it if you like, but be wary that the properties of that address are undefined. LL may be useful also. Properties of LL are well defined. If by "Well defined [in a MANET]" you mean "unique only within a 1-hop radius and also only unique within that 1-hop radius at the very instant when DAD is testing uniqueness -- not guaranteed to be unique beyond 1-hop and nor even an instant after DAD has completed" then yes, LL properties are "well defined [in a MANET]" when using the usual means of getting LLs. I'd question if that's useful, though. Thomas _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf ------=_NextPart_000_00B7_01CA5633.6CBE92B0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

 

 

Van:<= /b> = ulrich@herberg.name [mailto:ulrich@herberg.name] Namens Ulrich Herberg
Verzonden: maandag 26 oktober 2009 10:20
Aan: Thomas Heide Clausen
CC: Teco Boot; autoconf@ietf.org
Onderwerp: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt=

 

Fully agree with = Thomas here.

Note that the DT draft says:

"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 connnectivity to neighbors may be constantly = changing."

So, the draft also says that (per RFC4291) LL are configured on an = interface. It just says that they are not of much use, because it is very difficult = to assure uniqueness beyond 1 hop.

Same for ULAs and globals to!

Teco.

 

 


Ulrich

On Mon, Oct 26, 2009 at 9:48 AM, Thomas Heide = Clausen <thomas@thomasclausen.org>= wrote:


On Oct 26, 2009, at 9:41 AM, Teco Boot wrote:

Thomas Heide Clausen wrote:
o       If you have an LL address [generated by the usual means], it may
       be useless. Use it if you like, but be wary = that the properties of
       that address are undefined.


LL may be useful also.
Properties of LL are well defined.


If by "Well defined [in a MANET]" you mean "unique only = within a 1-hop radius and also only unique within that 1-hop radius at the very = instant when DAD is testing uniqueness -- not guaranteed to be unique beyond = 1-hop and nor even an instant after DAD has completed" then yes, LL = properties are "well defined [in a MANET]" when using the usual means of = getting LLs.

I'd question if that's useful, though.

Thomas


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

 

------=_NextPart_000_00B7_01CA5633.6CBE92B0-- From alexandru.petrescu@gmail.com Mon Oct 26 03:56: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 C87773A6A5A for ; Mon, 26 Oct 2009 03:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.116, 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 BODetgtKRRyI for ; Mon, 26 Oct 2009 03:56:57 -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 D703B3A694E for ; Mon, 26 Oct 2009 03:56:56 -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 n9QAv9Uk004434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 26 Oct 2009 11:57:09 +0100 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 n9QAv8Jw002589 for ; Mon, 26 Oct 2009 11:57:08 +0100 (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 n9QAv8sd032296 for ; Mon, 26 Oct 2009 11:57:08 +0100 Message-ID: <4AE58084.8080702@gmail.com> Date: Mon, 26 Oct 2009 11:57:08 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "autoconf@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Autoconf] Link-local addresses and MANET link-local multicast groups 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, 26 Oct 2009 10:56:57 -0000 AUTOCONFers, Do you plan the MANET router to join a link-local multicast group by using an address which is not a link-local address? MANET IANA RFC5498 uses IPv4 and IPv6 link-local multicast addresses, for LL-MANET-Routers (224.0.0.109, FF02:0:0:0:0:0:0:6D). When discouraging the use of IP link-local addresses - how to you plan the MANET router to join a link-local multicast group? (I doubt it is feasible to join a group a certain scope by using an address of a different scope). Alex From sratliff@cisco.com Mon Oct 26 07:04: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 E5EA83A6783 for ; Mon, 26 Oct 2009 07:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 jaXIYDJGM-sn for ; Mon, 26 Oct 2009 07:04:48 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 0EAFB28C242 for ; Mon, 26 Oct 2009 07:04:33 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EALFJ5UqtJV2Y/2dsb2JhbACbG6YNlnWEPwSBXg X-IronPort-AV: E=Sophos;i="4.44,626,1249257600"; d="scan'208";a="64909226" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-1.cisco.com with ESMTP; 26 Oct 2009 14:04:46 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id n9QE4j7U013893; Mon, 26 Oct 2009 14:04:46 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 10:04:46 -0400 Received: from 64.102.54.119 ([64.102.54.119]) by xmb-rtp-208.amer.cisco.com ([64.102.31.43]) with Microsoft Exchange Server HTTP-DAV ; Mon, 26 Oct 2009 14:04:45 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 26 Oct 2009 10:04:48 -0400 From: sratliff To: Thomas Heide Clausen , Alexandru Petrescu Message-ID: Thread-Topic: [Autoconf] adhoc unaware parts of the System, regular Internet nodes Thread-Index: AcpWRUcnoLHUQ+wx30+S2xVi+sgqBQ== In-Reply-To: <494563A5-573D-4565-B6EA-45454129A57F@thomasclausen.org> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 26 Oct 2009 14:04:46.0098 (UTC) FILETIME=[46058720:01CA5645] Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] adhoc unaware parts of the System, regular Internet nodes 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, 26 Oct 2009 14:04:49 -0000 On 10/26/09 6:14 AM, "Thomas Heide Clausen" wrote: >=20 > On Oct 26, 2009, at 11:08 AM, Alexandru Petrescu wrote: >=20 >> Ulrich Herberg a =E9crit : >>> Alex, >>> On Mon, Oct 26, 2009 at 10:52 AM, Alexandru Petrescu >>> >> > wrote: >>> [...] >>> One of the most particular points in AUTOCONF drafts is that A- >>> B-C >>> problem where B is claimed to have only one interface. It is >>> one of >>> the most important building blocks of the problem in AUTOCONF. >>> What is a building block? >>=20 >> Ok, it is a recurrent aspect motivating the AUTOCONF work, appearing >> several times in the AUTOCONF drafts. >>=20 >>> If it had 2 interfaces, then we had no such problem. >>> As such, this sentence is wrong. B could have two (or more >>> interfaces), and still reach A and C over the same interface. >>=20 >> :-) >>=20 >>> Autoconf will have to support multiple interfaces. And -- as Thomas >>> showed in the example -- should not have any effect on non-MANET >>> interfaces. >>=20 >> Ok - what happens if a non-MANET node connects to a MANET interface >> of a MANET router? >>=20 >=20 > What happens if a non-OSPFv3 router connects to an OSPFv3 interface of > an OSPFv3 router? >=20 >> Do you forbid this case? >=20 > In my networks, yes, I do not see the use of it. Furthermore, I see it > as somewhat harmful as that means that an application bound to that > "non-MANET node" would be exposed to the characteristics of a MANET, > and may not be able to handle it. >=20 Thomas is correct. In fact, AFAIK, such a configuration won't work, as all of the OSPFv3 MANET flooding optimizations won't interoperate with standard flooding.=20 Regards, Stan > Thomas >=20 >> Do you care about this case? >>=20 >> If you do - then you should not discourage the IPv4 LLs of the non- >> MANET node. You could discourage the IPv4 LLs of the MANET >> interface of a MANET node. >>=20 >> Or - this distinction is not made in the draft. It is only made in >> our discussions. >>=20 >> Alex >>=20 >>> Ulrich >>=20 >>=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From alexandru.petrescu@gmail.com Mon Oct 26 07:07: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 2C84F28C291 for ; Mon, 26 Oct 2009 07:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=0.113, 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 EpnesyZyv9NZ for ; Mon, 26 Oct 2009 07:07:34 -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 0ECB728C285 for ; Mon, 26 Oct 2009 07:07:33 -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 n9QE7N8f023856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 15:07:23 +0100 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 n9QE7M4C018791; Mon, 26 Oct 2009 15:07:23 +0100 (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 n9QE7MnE025195; Mon, 26 Oct 2009 15:07:22 +0100 Message-ID: <4AE5AD1A.8020002@gmail.com> Date: Mon, 26 Oct 2009 15:07:22 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: sratliff References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] adhoc unaware parts of the System, regular Internet nodes 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, 26 Oct 2009 14:07:35 -0000 sratliff a écrit : > > > On 10/26/09 6:14 AM, "Thomas Heide Clausen" wrote: > >> On Oct 26, 2009, at 11:08 AM, Alexandru Petrescu wrote: >> >>> Ulrich Herberg a écrit : >>>> Alex, >>>> On Mon, Oct 26, 2009 at 10:52 AM, Alexandru Petrescu >>>> >>> > wrote: >>>> [...] >>>> One of the most particular points in AUTOCONF drafts is that A- >>>> B-C >>>> problem where B is claimed to have only one interface. It is >>>> one of >>>> the most important building blocks of the problem in AUTOCONF. >>>> What is a building block? >>> Ok, it is a recurrent aspect motivating the AUTOCONF work, appearing >>> several times in the AUTOCONF drafts. >>> >>>> If it had 2 interfaces, then we had no such problem. >>>> As such, this sentence is wrong. B could have two (or more >>>> interfaces), and still reach A and C over the same interface. >>> :-) >>> >>>> Autoconf will have to support multiple interfaces. And -- as Thomas >>>> showed in the example -- should not have any effect on non-MANET >>>> interfaces. >>> Ok - what happens if a non-MANET node connects to a MANET interface >>> of a MANET router? >>> >> What happens if a non-OSPFv3 router connects to an OSPFv3 interface of >> an OSPFv3 router? >> >>> Do you forbid this case? >> In my networks, yes, I do not see the use of it. Furthermore, I see it >> as somewhat harmful as that means that an application bound to that >> "non-MANET node" would be exposed to the characteristics of a MANET, >> and may not be able to handle it. >> > > Thomas is correct. In fact, AFAIK, such a configuration won't work, as all > of the OSPFv3 MANET flooding optimizations won't interoperate with standard > flooding. I agree. The way this works is that the non-OSPFv3 node is not impacted by the OSPFv3 messages because there exist multicast groups to which the non-OSPFv3 node has not subscribed. In the same way, we should do about MANET routers and non-MANET routers. Alex > > Regards, > Stan > > >> Thomas >> >>> Do you care about this case? >>> >>> If you do - then you should not discourage the IPv4 LLs of the non- >>> MANET node. You could discourage the IPv4 LLs of the MANET >>> interface of a MANET node. >>> >>> Or - this distinction is not made in the draft. It is only made in >>> our discussions. >>> >>> Alex >>> >>>> Ulrich >>> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > From emmanuel.baccelli@gmail.com Mon Oct 26 07:08: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 6AB1D28C2A8 for ; Mon, 26 Oct 2009 07:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.779 X-Spam-Level: X-Spam-Status: No, score=-1.779 tagged_above=-999 required=5 tests=[AWL=0.197, 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 Bdc+katyai0X for ; Mon, 26 Oct 2009 07:08:40 -0700 (PDT) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 33E5628C2AA for ; Mon, 26 Oct 2009 07:08:39 -0700 (PDT) Received: by yxe30 with SMTP id 30so14880268yxe.29 for ; Mon, 26 Oct 2009 07:08:48 -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=xaEEIGVvwT7izFh/MuQqcKxbtpVpmvWDLGFomiJ0DUg=; b=p/EUxbgsiYZnzd4/C1AJi9T3P8iWMZTC56ZG4WHDOj4genzVMphADsk1Yz3mXXfGBw YuQ0Fxmeii14Fk4lZCZHGYV9RpqcDozVjIhEqsbpQqABMEHSVfYI8S30Am97TYkRjomj Hh80GsUT6Vx69yjgaJx3BFslVUzl1wZNbS99U= 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=uXtGhHW/xUi8kLIaP+5TTSInW/0OJ0U6XIQCAXaWz9pzeJm6PFFxiDi9hmEMpL1pao MH/M1eJjFLwfTfiIDN3XE6meIkQmqHMih4UElo6XA6QPPC51r2lmB2YyTgBW0M6ttuIz 9V0V5ITrcLcZ8+7masUTnYGqOjiACk94B4Qg8= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.91.20.28 with SMTP id x28mr674923agi.23.1256566128125; Mon, 26 Oct 2009 07:08:48 -0700 (PDT) In-Reply-To: <00b601ca562b$0afa2ab0$20ee8010$@nl> References: <20091019233002.15F4328C164@core3.amsl.com> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <005801ca5618$38d35be0$aa7a13a0$@nl> <25c114b90910260219h52c74b4dha6871856afaaec23@mail.gmail.com> <00b601ca562b$0afa2ab0$20ee8010$@nl> From: Emmanuel Baccelli Date: Mon, 26 Oct 2009 15:08:28 +0100 X-Google-Sender-Auth: 80f6de540365a75a Message-ID: To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=0016e640cc72b430580476d719c9 Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 14:08:41 -0000 --0016e640cc72b430580476d719c9 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 26, 2009 at 11:56 AM, Teco Boot wrote: > > > > > *Van:* ulrich@herberg.name [mailto:ulrich@herberg.name] *Namens *Ulrich > Herberg > *Verzonden:* maandag 26 oktober 2009 10:20 > *Aan:* Thomas Heide Clausen > *CC:* Teco Boot; autoconf@ietf.org > *Onderwerp:* Re: [Autoconf] I-D > Action:draft-bernardos-autoconf-addressing-model-00.txt > > > > Fully agree with Thomas here. > > Note that the DT draft says: > > "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 connnectivity to neighbors may be constantly changing." > > So, the draft also says that (per RFC4291) LL are configured on an > interface. It just says that they are not of much use, because it is very > difficult to assure uniqueness beyond 1 hop. > > Same for ULAs and globals to! > > Teco. > > > ULAs and globals are meant to be managed by mechanisms that are fundamentally different from the LL mechanisms. ULAs and globals are naturally unambiguous in a MANET context, contrary to LL addresses. Could this whole discussion prove once and for all (for the few still not convinced) that link local addresses are AMBIGUOUS in the context that we want to address in this working group? Why do we have to discuss this again and again? Nobody wants ambiguous standards. So let's keep the boat away from such rocks, and let's move on! Emmanuel --0016e640cc72b430580476d719c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Oct 26, 2009 at 11:56 AM, Teco B= oot <teco@inf-net.nl> wrote:

=A0

=A0

Van:<= span style=3D"font-size:10.0pt"> ulrich@herberg.name [mailto:ulrich@her= berg.name] Namens Ulrich Herberg
Verzonden: maandag 26 oktober 2009 10:20
Aan: Thomas Heide Clausen
CC: Teco Boot; autoconf@ietf.org
Onderwerp: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt

=A0

Fully agree with Thom= as here.

Note that the DT draft says:

"Note that while an IPv6 link-local address is assigned to each interf= ace as per [RFC4291], in general link-local addresses are of limited utility on links with undetermi= ned connectivity, as connnectivity to neighbors may be constantly changing.&quo= t;

So, the draft also says that (per RFC4291) LL are configured on an interfac= e. It just says that they are not of much use, because it is very difficult to assure uniqueness beyond 1 hop.

Same for ULAs and globals to!

Teco.

=A0


ULAs and globals are meant to be managed by mechanisms = that are fundamentally different from the LL mechanisms.=A0ULAs and globals= are naturally unambiguous in a MANET context, contrary to LL addresses.=A0=

Could this whole discussion prove once and for all (for= the few still not convinced) that link local addresses are AMBIGUOUS in th= e context that we want to address in this working group?=A0Why do we have t= o discuss this again and again?

Nobody wants ambiguous standards. So let's keep the= boat away from such rocks, and let's move on!

Emmanuel

=A0
--0016e640cc72b430580476d719c9-- From sratliff@cisco.com Mon Oct 26 07: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 A18D728C27A for ; Mon, 26 Oct 2009 07:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.612 X-Spam-Level: X-Spam-Status: No, score=-3.612 tagged_above=-999 required=5 tests=[AWL=-0.477, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 KCPcvWQONHWG for ; Mon, 26 Oct 2009 07:09:59 -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 CD4103A67E2 for ; Mon, 26 Oct 2009 07:09:56 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEAClK5UpAZnwN/2dsb2JhbACCJS6XO4ENphSWdYQ/BA X-IronPort-AV: E=Sophos;i="4.44,626,1249257600"; d="scan'208,217";a="64943801" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 26 Oct 2009 14:10:09 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9QEA97Q010298; Mon, 26 Oct 2009 14:10:09 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 10:10:09 -0400 Received: from 64.102.54.119 ([64.102.54.119]) by xmb-rtp-208.amer.cisco.com ([64.102.31.43]) with Microsoft Exchange Server HTTP-DAV ; Mon, 26 Oct 2009 14:10:09 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 26 Oct 2009 10:10:12 -0400 From: sratliff To: Ulrich Herberg , Alexandru Petrescu Message-ID: Thread-Topic: [Autoconf] adhoc unaware parts of the System, regular Internet nodes Thread-Index: AcpWRghG6QY4HgznX0aRE/CB9uk7GQ== In-Reply-To: <25c114b90910260258h17247de9n63c1837c0961eba1@mail.gmail.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3339396612_17664727" X-OriginalArrivalTime: 26 Oct 2009 14:10:09.0633 (UTC) FILETIME=[06DD0D10:01CA5646] Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] adhoc unaware parts of the System, regular Internet nodes 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, 26 Oct 2009 14:10:01 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3339396612_17664727 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Sigh....=20 Simply =B3enabling another interface=B2, or =B3hanging another radio on the router=B2 won=B9t work in my deployments. My customers don=B9t want 802.11; they use other, proprietary technology. The radios are ridiculously expensive (i= n excess of $100,000 each). So can we please move on, and keep this from being a =B3WiFi-only=B2 discussion= ? Regards, Stan On 10/26/09 5:58 AM, "Ulrich Herberg" wrote: > Alex, >=20 > On Mon, Oct 26, 2009 at 10:52 AM, Alexandru Petrescu > wrote: >> [...] > =A0 >> One of the most particular points in AUTOCONF drafts is that A-B-C probl= em >> where B is claimed to have only one interface. =A0It is one of the most >> important building blocks of the problem in AUTOCONF. >=20 > What is a building block? >>=20 >> If it had 2 interfaces, then we had no such problem. >=20 > As such, this sentence is wrong. B could have two (or more interfaces), a= nd > still reach A and C over the same interface. Autoconf will have to suppor= t > multiple interfaces. And -- as Thomas showed in the example -- should not= have > any effect on non-MANET interfaces. >=20 > Ulrich >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf --B_3339396612_17664727 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Autoconf] adhoc unaware parts of the System, regular Internet &= nbsp;nodes Sigh....

Simply “enabling another interface”, or “hanging another = radio on the router” won’t work in my deployments. My customers = don’t want 802.11; they use other, proprietary technology. The radios = are ridiculously expensive (in excess of $100,000 each).

So can we please move on, and keep this from being a “WiFi-only”= ; discussion?

Regards,
Stan


On 10/26/09 5:58 AM, "Ulrich Herberg" <ulrich@herberg.name> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Alex,

On Mon, Oct 26, 2009 at 10:52 AM, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
<= SPAN STYLE=3D'font-size:11pt'>[...]
= =A0
<= SPAN STYLE=3D'font-size:11pt'>One of the most particular points in AUTOCONF dr= afts is that A-B-C problem where B is claimed to have only one interface. =A0I= t is one of the most important building blocks of the problem in AUTOCONF.
=
What is a building block?
<= SPAN STYLE=3D'font-size:11pt'>
If it had 2 interfaces, then we had no such problem.
=
As such, this sentence is wrong. B could have two (or more interfaces), and= still reach A and C over the same interface. Autoconf will have to support = multiple interfaces. And -- as Thomas showed in the example -- should not ha= ve any effect on non-MANET interfaces.

Ulrich

___________= ____________________________________
Autoconf mailing list
Autoconf@ietf.org
https://www.ietf.o= rg/mailman/listinfo/autoconf
--B_3339396612_17664727-- From alexandru.petrescu@gmail.com Mon Oct 26 07:11: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 291D73A68AB for ; Mon, 26 Oct 2009 07:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.138 X-Spam-Level: X-Spam-Status: No, score=-2.138 tagged_above=-999 required=5 tests=[AWL=0.111, 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 CiVOFh0ouheX for ; Mon, 26 Oct 2009 07:11:53 -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 23CAF3A6885 for ; Mon, 26 Oct 2009 07:11:52 -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 n9QEC51N013578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 15:12:05 +0100 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 n9QEC516020359; Mon, 26 Oct 2009 15:12:05 +0100 (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 n9QEC42P001176; Mon, 26 Oct 2009 15:12:04 +0100 Message-ID: <4AE5AE34.3090409@gmail.com> Date: Mon, 26 Oct 2009 15:12:04 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Emmanuel Baccelli References: <20091019233002.15F4328C164@core3.amsl.com> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <005801ca5618$38d35be0$aa7a13a0$@nl> <25c114b90910260219h52c74b4dha6871856afaaec23@mail.gmail.com> <00b601ca562b$0afa2ab0$20ee8010$@nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 14:11:54 -0000 Emmanuel Baccelli a écrit : > > > On Mon, Oct 26, 2009 at 11:56 AM, Teco Boot > wrote: > > > > > > *Van:* ulrich@herberg.name > [mailto:ulrich@herberg.name ] *Namens > *Ulrich Herberg > *Verzonden:* maandag 26 oktober 2009 10:20 > *Aan:* Thomas Heide Clausen > *CC:* Teco Boot; autoconf@ietf.org > *Onderwerp:* Re: [Autoconf] I-D > Action:draft-bernardos-autoconf-addressing-model-00.txt > > > > Fully agree with Thomas here. > > Note that the DT draft says: > > "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 connnectivity to neighbors may be > constantly changing." > > So, the draft also says that (per RFC4291) LL are configured on an > interface. It just says that they are not of much use, because it is > very difficult to assure uniqueness beyond 1 hop. > > Same for ULAs and globals to! > > Teco. > > > > > ULAs and globals are meant to be managed by mechanisms that are > fundamentally different from the LL mechanisms. ULAs and globals are > naturally unambiguous in a MANET context, contrary to LL addresses. > > Could this whole discussion prove once and for all (for the few still > not convinced) that link local addresses are AMBIGUOUS in the context > that we want to address in this working group? Why do we have to discuss > this again and again? > > Nobody wants ambiguous standards. So let's keep the boat away from such > rocks, and let's move on! Emmanuel - how about the LL-MANET-Routers and the link-local multicast group RFC5498? Will the AUTOCONF router join this group at all? Will it use an ULA to join this link-local group? I'd rather say it would use its link-local address to join that group. But if you discourage it... Alex > > Emmanuel > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From thomas@thomasclausen.org Mon Oct 26 07:16: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 B6F2228C2C4 for ; Mon, 26 Oct 2009 07:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 VL+GECK4JapK for ; Mon, 26 Oct 2009 07:16:07 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id E689628C251 for ; Mon, 26 Oct 2009 07:16:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id A77B032317B0; Mon, 26 Oct 2009 07:16:21 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 654C332317B4; Mon, 26 Oct 2009 07:16:20 -0700 (PDT) Message-Id: <7FAD52C4-20F4-4C18-BF31-FE0FBBC76E97@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE5AE34.3090409@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: Mon, 26 Oct 2009 15:16:18 +0100 References: <20091019233002.15F4328C164@core3.amsl.com> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <005801ca5618$38d35be0$aa7a13a0$@nl> <25c114b90910260219h52c74b4dha6871856afaaec23@mail.gmail.com> <00b601ca562b$0afa2ab0$20ee8010$@nl> <4AE5AE34.3090409@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 14:16:08 -0000 On Oct 26, 2009, at 3:12 PM, Alexandru Petrescu wrote: > Emmanuel Baccelli a =E9crit : >> On Mon, Oct 26, 2009 at 11:56 AM, Teco Boot > >> wrote: >> *Van:* ulrich@herberg.name >> [mailto:ulrich@herberg.name ] *Namens >> *Ulrich Herberg >> *Verzonden:* maandag 26 oktober 2009 10:20 >> *Aan:* Thomas Heide Clausen >> *CC:* Teco Boot; autoconf@ietf.org >> *Onderwerp:* Re: [Autoconf] I-D >> Action:draft-bernardos-autoconf-addressing-model-00.txt >> Fully agree with Thomas here. >> Note that the DT draft says: >> "Note that while an IPv6 link-local address is assigned to each >> interface as per [RFC4291 ], =20= >> in >> general link-local addresses are of limited utility on links with >> undetermined connectivity, as connnectivity to neighbors may be >> constantly changing." >> So, the draft also says that (per RFC4291) LL are configured on an >> interface. It just says that they are not of much use, because =20 >> it is >> very difficult to assure uniqueness beyond 1 hop. >> Same for ULAs and globals to! >> Teco. >> ULAs and globals are meant to be managed by mechanisms that are =20= >> fundamentally different from the LL mechanisms. ULAs and globals =20 >> are naturally unambiguous in a MANET context, contrary to LL =20 >> addresses. Could this whole discussion prove once and for all (for =20= >> the few still not convinced) that link local addresses are =20 >> AMBIGUOUS in the context that we want to address in this working =20 >> group? Why do we have to discuss this again and again? >> Nobody wants ambiguous standards. So let's keep the boat away from =20= >> such rocks, and let's move on! > > Emmanuel - how about the LL-MANET-Routers and the link-local =20 > multicast group RFC5498? > > Will the AUTOCONF router join this group at all? Will it use an ULA =20= > to join this link-local group? I'd rather say it would use its link-=20= > local address to join that group. But if you discourage it... > When you say "join this link-local group", what do you imagine happen? =20= Other than that you tell the kernel in your OS "hey, if you get =20 something destined for group XXXX on this interface, hand me a copy", =20= of course? Thomas > Alex > >> Emmanuel >> = ------------------------------------------------------------------------ >> _______________________________________________ >> 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 emmanuel.baccelli@gmail.com Mon Oct 26 07:20:56 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 AB31B28C251 for ; Mon, 26 Oct 2009 07:20:56 -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 Iq0bPrSzUfEG for ; Mon, 26 Oct 2009 07:20:55 -0700 (PDT) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 8595C28C26F for ; Mon, 26 Oct 2009 07:20:55 -0700 (PDT) Received: by gxk28 with SMTP id 28so9975469gxk.9 for ; Mon, 26 Oct 2009 07:21:06 -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:cc :content-type; bh=ZEJ8FiB+lwrKhu7tWCGoD4iwJEHkGFZtVHRrH4PlHxc=; b=qTKMzOR48meSfHIrcn9vuxvsNe5Bg4PGsmcAEtAk3bfnKcUWDHpttgBDQKwdwlqn/c 069p25Q0Vhjgb64ZnbtU29mKoDmnvwwLvLWsZm6QXoEYrZyMZudN/latGgQKMU6bvSP4 fmFpdRPqttth4hWAraAXSAHnadcCy44W0JGb4= 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:cc:content-type; b=RllyfcWsViqJc3DQ/N5c7CAjOF4WOX93KNeOnH2pqzrHy4O6n3vvmv35mWecmNJXR8 tDapUE52KlJgA8c59TyRPAHZeBjWlqFeMN0WtXCLgb+PHat9er6sFd/DfM9RMg8W3Ihn hb97Eg7I8qf4zGbJUPkJ1h88ARPM1FepSurUU= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.91.161.28 with SMTP id n28mr4761433ago.36.1256566866114; Mon, 26 Oct 2009 07:21:06 -0700 (PDT) In-Reply-To: <4AE5AE34.3090409@gmail.com> References: <20091019233002.15F4328C164@core3.amsl.com> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <005801ca5618$38d35be0$aa7a13a0$@nl> <25c114b90910260219h52c74b4dha6871856afaaec23@mail.gmail.com> <00b601ca562b$0afa2ab0$20ee8010$@nl> <4AE5AE34.3090409@gmail.com> From: Emmanuel Baccelli Date: Mon, 26 Oct 2009 15:20:46 +0100 X-Google-Sender-Auth: 1c79f57978889b85 Message-ID: To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=0016e640d408b0fbbe0476d745af Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 14:20:56 -0000 --0016e640d408b0fbbe0476d745af Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 26, 2009 at 3:12 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Emmanuel Baccelli a =E9crit : > >> >> >> On Mon, Oct 26, 2009 at 11:56 AM, Teco Boot > teco@inf-net.nl>> wrote: >> >> >> >> *Van:* ulrich@herberg.name >> [mailto:ulrich@herberg.name ] *Namens >> >> *Ulrich Herberg >> *Verzonden:* maandag 26 oktober 2009 10:20 >> *Aan:* Thomas Heide Clausen >> *CC:* Teco Boot; autoconf@ietf.org >> >> *Onderwerp:* Re: [Autoconf] I-D >> Action:draft-bernardos-autoconf-addressing-model-00.txt >> >> >> Fully agree with Thomas here. >> >> Note that the DT draft says: >> >> "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 connnectivity to neighbors may be >> constantly changing." >> >> So, the draft also says that (per RFC4291) LL are configured on an >> interface. It just says that they are not of much use, because it is >> very difficult to assure uniqueness beyond 1 hop. >> >> Same for ULAs and globals to! >> >> Teco. >> >> >> >> ULAs and globals are meant to be managed by mechanisms that are >> fundamentally different from the LL mechanisms. ULAs and globals are >> naturally unambiguous in a MANET context, contrary to LL addresses. >> Could this whole discussion prove once and for all (for the few still no= t >> convinced) that link local addresses are AMBIGUOUS in the context that w= e >> want to address in this working group? Why do we have to discuss this ag= ain >> and again? >> >> Nobody wants ambiguous standards. So let's keep the boat away from such >> rocks, and let's move on! >> > > Emmanuel - how about the LL-MANET-Routers and the link-local multicast > group RFC5498? > > Will the AUTOCONF router join this group at all? Will it use an ULA to > join this link-local group? I'd rather say it would use its link-local > address to join that group. But if you discourage it... > > Alex > These are well known send/listen to addresses. You typically do not "join" anything, so there is no problem at all. Emmanuel > > >> Emmanuel >> >> >> >> ------------------------------------------------------------------------ >> >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >> > > > --0016e640d408b0fbbe0476d745af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Oct 26, 2009 at 3:12 PM, Alexand= ru Petrescu <alexandru.petrescu@gmail.com> wrote:
Emmanuel Baccelli a =E9crit :


On Mon, Oct 26, 2009 at 11:56 AM, Teco Boot <teco@inf-net.nl <mailto:teco@inf-net.nl>> wrote:

=A0 =A0
=A0 =A0
=A0 =A0*Van:* ulr= ich@herberg.name <mailto:ulrich@herberg.name>
=A0 =A0[mailto:ul= rich@herberg.name <mailto:ulrich@herberg.name>] *Namens

=A0 =A0*Ulrich Herberg
=A0 =A0*Verzonden:* maandag 26 oktober 2009 10:20
=A0 =A0*Aan:* Thomas Heide Clausen
=A0 =A0*CC:* Teco Boot; autoconf@ietf.org <mailto:autoconf@ietf.org>

=A0 =A0*Onderwerp:* Re: [Autoconf] I-D
=A0 =A0Action:draft-bernardos-autoconf-addressing-model-00.txt

=A0 =A0
=A0 =A0Fully agree with Thomas here.

=A0 =A0Note that the DT draft says:

=A0 =A0"Note that while an IPv6 link-local address is assigned to eac= h
=A0 =A0interface as per [RFC4291 <http://tools.ietf.org/html/rfc4291>], in=

=A0 =A0general link-local addresses are of limited utility on links with =A0 =A0undetermined connectivity, as connnectivity to neighbors may be
=A0 =A0constantly changing."

=A0 =A0So, the draft also says that (per RFC4291) LL are configured on an<= br> =A0 =A0interface. It just says that they are not of much use, because it i= s
=A0 =A0very difficult to assure uniqueness beyond 1 hop.

=A0 =A0Same for ULAs and globals to!

=A0 =A0Teco.

=A0 =A0

ULAs and globals are meant to be managed by mechanisms that are fundamental= ly different from the LL mechanisms. ULAs and globals are naturally unambig= uous in a MANET context, contrary to LL addresses.
Could this whole discussion prove once and for all (for the few still not c= onvinced) that link local addresses are AMBIGUOUS in the context that we wa= nt to address in this working group? Why do we have to discuss this again a= nd again?

Nobody wants ambiguous standards. So let's keep the boat away from such= rocks, and let's move on!

Emmanuel - how about the LL-MANET-Routers and the link-local multicast grou= p RFC5498?

Will the AUTOCONF router join this group at all? =A0Will it use an ULA to j= oin this link-local group? =A0I'd rather say it would use its link-loca= l address to join that group. =A0But if you discourage it...

Alex


These are well know= n send/listen to addresses. You typically do not "join" anything,= so there is no problem at all.
Emmanuel
=A0


Emmanuel

=A0

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

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



--0016e640d408b0fbbe0476d745af-- From alexandru.petrescu@gmail.com Mon Oct 26 07:22: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 DD64028C2AC for ; Mon, 26 Oct 2009 07:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=0.109, 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 JBnQMTb-FjPH for ; Mon, 26 Oct 2009 07:22:21 -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 874C828C29E for ; Mon, 26 Oct 2009 07:22:21 -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 n9QEMXrK006883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 15:22:33 +0100 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 n9QEMXpF023701; Mon, 26 Oct 2009 15:22:33 +0100 (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 n9QEMXp4031771; Mon, 26 Oct 2009 15:22:33 +0100 Message-ID: <4AE5B0A9.2090908@gmail.com> Date: Mon, 26 Oct 2009 15:22:33 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <20091019233002.15F4328C164@core3.amsl.com> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <005801ca5618$38d35be0$aa7a13a0$@nl> <25c114b90910260219h52c74b4dha6871856afaaec23@mail.gmail.com> <00b601ca562b$0afa2ab0$20ee8010$@nl> <4AE5AE34.3090409@gmail.com> <7FAD52C4-20F4-4C18-BF31-FE0FBBC76E97@thomasclausen.org> In-Reply-To: <7FAD52C4-20F4-4C18-BF31-FE0FBBC76E97@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 14:22:22 -0000 Thomas Heide Clausen a écrit : > > On Oct 26, 2009, at 3:12 PM, Alexandru Petrescu wrote: > >> Emmanuel Baccelli a écrit : >>> On Mon, Oct 26, 2009 at 11:56 AM, Teco Boot >> > wrote: >>> *Van:* ulrich@herberg.name >>> [mailto:ulrich@herberg.name ] *Namens >>> *Ulrich Herberg >>> *Verzonden:* maandag 26 oktober 2009 10:20 >>> *Aan:* Thomas Heide Clausen >>> *CC:* Teco Boot; autoconf@ietf.org >>> *Onderwerp:* Re: [Autoconf] I-D >>> Action:draft-bernardos-autoconf-addressing-model-00.txt >>> Fully agree with Thomas here. >>> Note that the DT draft says: >>> "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 connnectivity to neighbors may be >>> constantly changing." >>> So, the draft also says that (per RFC4291) LL are configured on an >>> interface. It just says that they are not of much use, because it is >>> very difficult to assure uniqueness beyond 1 hop. >>> Same for ULAs and globals to! >>> Teco. >>> ULAs and globals are meant to be managed by mechanisms that are >>> fundamentally different from the LL mechanisms. ULAs and globals are >>> naturally unambiguous in a MANET context, contrary to LL addresses. >>> Could this whole discussion prove once and for all (for the few still >>> not convinced) that link local addresses are AMBIGUOUS in the context >>> that we want to address in this working group? Why do we have to >>> discuss this again and again? >>> Nobody wants ambiguous standards. So let's keep the boat away from >>> such rocks, and let's move on! >> >> Emmanuel - how about the LL-MANET-Routers and the link-local multicast >> group RFC5498? >> >> Will the AUTOCONF router join this group at all? Will it use an ULA >> to join this link-local group? I'd rather say it would use its >> link-local address to join that group. But if you discourage it... >> > > When you say "join this link-local group", what do you imagine happen? > Other than that you tell the kernel in your OS "hey, if you get > something destined for group XXXX on this interface, hand me a copy", of > course? Well, there is also MLD - a more advanced operation than simply setting local filters. With MLD, a node expresses interest in receiving a certain group by sending an MLD message. Do you also discourage MLD? MLD is what most machines do. Do you discourage scopes as well? (and yes, there are implementations and implementations of joing groups, sometimes filters - which you imply, work too as you say). Alex > > Thomas > >> Alex >> >>> Emmanuel >>> ------------------------------------------------------------------------ >>> _______________________________________________ >>> 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 alexandru.petrescu@gmail.com Mon Oct 26 07:31: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 250573A677C for ; Mon, 26 Oct 2009 07:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=0.107, 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 nc1rIrbL8Wn8 for ; Mon, 26 Oct 2009 07:31:15 -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 0C78F28C276 for ; Mon, 26 Oct 2009 07:31:14 -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 n9QEVRpg014125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 15:31:27 +0100 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 n9QEVRNd026415; Mon, 26 Oct 2009 15:31:27 +0100 (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 n9QEVQ98008751; Mon, 26 Oct 2009 15:31:27 +0100 Message-ID: <4AE5B2BE.6040006@gmail.com> Date: Mon, 26 Oct 2009 15:31:26 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Emmanuel Baccelli References: <20091019233002.15F4328C164@core3.amsl.com> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <005801ca5618$38d35be0$aa7a13a0$@nl> <25c114b90910260219h52c74b4dha6871856afaaec23@mail.gmail.com> <00b601ca562b$0afa2ab0$20ee8010$@nl> <4AE5AE34.3090409@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] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 14:31:16 -0000 Emmanuel Baccelli a écrit : > > > On Mon, Oct 26, 2009 at 3:12 PM, Alexandru Petrescu > > wrote: > > Emmanuel Baccelli a écrit : > > > > On Mon, Oct 26, 2009 at 11:56 AM, Teco Boot >> wrote: > > > > *Van:* ulrich@herberg.name > > > [mailto:ulrich@herberg.name > >] *Namens > > *Ulrich Herberg > *Verzonden:* maandag 26 oktober 2009 10:20 > *Aan:* Thomas Heide Clausen > *CC:* Teco Boot; autoconf@ietf.org > > > > *Onderwerp:* Re: [Autoconf] I-D > Action:draft-bernardos-autoconf-addressing-model-00.txt > > > Fully agree with Thomas here. > > Note that the DT draft says: > > "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 connnectivity to neighbors may be > constantly changing." > > So, the draft also says that (per RFC4291) LL are configured > on an > interface. It just says that they are not of much use, > because it is > very difficult to assure uniqueness beyond 1 hop. > > Same for ULAs and globals to! > > Teco. > > > > ULAs and globals are meant to be managed by mechanisms that are > fundamentally different from the LL mechanisms. ULAs and globals > are naturally unambiguous in a MANET context, contrary to LL > addresses. > Could this whole discussion prove once and for all (for the few > still not convinced) that link local addresses are AMBIGUOUS in > the context that we want to address in this working group? Why > do we have to discuss this again and again? > > Nobody wants ambiguous standards. So let's keep the boat away > from such rocks, and let's move on! > > > Emmanuel - how about the LL-MANET-Routers and the link-local > multicast group RFC5498? > > Will the AUTOCONF router join this group at all? Will it use an ULA > to join this link-local group? I'd rather say it would use its > link-local address to join that group. But if you discourage it... > > Alex > > > > These are well known send/listen to addresses. You typically do not > "join" anything, so there is no problem at all. Typically, a node does join groups of various scopes, link-local scope included, by sending MLD Reports. Recent linux kernels do so. Setting up local filters is an old fashioned way which does not protect a node from noise - its driver is still solicited (the discarding happens at the kernel level - too late). For example, rfc4861 ND says "a node must join" at several places and then "Joining the solicited-node multicast address is done using a Multicast Listener Discovery such as [MLD] or [MLDv2] protocols." Do you also discourage this use of groups, scopes and MLD? Alex > > > > > Emmanuel > > > > ------------------------------------------------------------------------ > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > > > > From ulrich@herberg.name Mon Oct 26 07:45: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 EDDBE3A67F1 for ; Mon, 26 Oct 2009 07:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[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 1ziGwgHB94LV for ; Mon, 26 Oct 2009 07:45:55 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 8AC9E3A6359 for ; Mon, 26 Oct 2009 07:45:54 -0700 (PDT) Received: by fxm18 with SMTP id 18so12116789fxm.37 for ; Mon, 26 Oct 2009 07:46:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.162.204 with SMTP id w12mr14333282bkx.18.1256568364363; Mon, 26 Oct 2009 07:46:04 -0700 (PDT) In-Reply-To: <4AE5B2BE.6040006@gmail.com> References: <20091019233002.15F4328C164@core3.amsl.com> <005801ca5618$38d35be0$aa7a13a0$@nl> <25c114b90910260219h52c74b4dha6871856afaaec23@mail.gmail.com> <00b601ca562b$0afa2ab0$20ee8010$@nl> <4AE5AE34.3090409@gmail.com> <4AE5B2BE.6040006@gmail.com> Date: Mon, 26 Oct 2009 15:46:04 +0100 Message-ID: <25c114b90910260746i30d489fbm4a48c151c842ef25@mail.gmail.com> From: Ulrich Herberg To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=00032555a496fe733c0476d79ecb Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 14:45:59 -0000 --00032555a496fe733c0476d79ecb Content-Type: text/plain; charset=ISO-8859-1 IMO, Alex is right here. Routers have to join multicast groups (although there might be some exceptions like ff02::1). The RFC that specifies MLDv2 is RFC3810. The Multicast listening state is stored per socket as well as per interface. I did not find, however, a restriction of scope for a multicast group based on the unicast address of the interface. There is even an example in RFC4291 (the mentioned Solicited-Node multicast address) which creates a link-local multicast group out of a global unicast address: "For example, the Solicited-Node multicast address corresponding to the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C." Please correct me if I am wrong here.... Ulrich On Mon, Oct 26, 2009 at 3:31 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > [...] > Typically, a node does join groups of various scopes, link-local scope > included, by sending MLD Reports. Recent linux kernels do so. Setting up > local filters is an old fashioned way which does not protect a node from > noise - its driver is still solicited (the discarding happens at the kernel > level - too late). > > For example, rfc4861 ND says "a node must join" at several places and then > "Joining the solicited-node multicast address is done using a Multicast > Listener Discovery such as [MLD] or [MLDv2] protocols." > > Do you also discourage this use of groups, scopes and MLD? > > Alex > > > >> >> >> Emmanuel >> >> >> >> ------------------------------------------------------------------------ >> >> >> _______________________________________________ >> 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 > --00032555a496fe733c0476d79ecb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable IMO, Alex is right here. Routers have to join multicast groups (although th= ere might be some exceptions like ff02::1). The RFC that specifies MLDv2 is= RFC3810. The Multicast listening state is stored per socket as well as per= interface. I did not find, however, a restriction of scope for a multicast= group based on the unicast address of the interface. There is even an exam= ple in RFC4291 (the mentioned Solicited-Node multicast address) which creat= es a link-local multicast group out of a global unicast address:

"For example, the Solicited-Node multicast address corresponding to=
 the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C."

Please correct me if I am wrong here....

Ulrich
=A0

=
On Mon, Oct 26, 2009 at 3:31 PM, Alexandru P= etrescu <alexandru.petrescu@gmail.com> wrote:
[...]
Typically, a node does join groups of various scopes, link-local scope incl= uded, by sending MLD Reports. =A0Recent linux kernels do so. =A0Setting up = local filters is an old fashioned way =A0which does not protect a node from= noise - its driver is still solicited (the discarding happens at the kerne= l level - too late).

For example, rfc4861 ND says "a node must join" at several places= and then "Joining the solicited-node multicast address is done using = a Multicast Listener Discovery such as [MLD] or [MLDv2] protocols."
Do you also discourage this use of groups, scopes and MLD?

Alex


=A0


=A0 =A0 =A0 =A0Emmanuel

=A0 =A0 =A0 =A0
=A0 =A0 =A0 =A0-----------------------------------------------------------= -------------


=A0 =A0 =A0 =A0_______________________________________________
=A0 =A0 =A0 =A0Autoconf mailing list
=A0 =A0 =A0 =A0Auto= conf@ietf.org <mailto:Autoconf@ietf.org>

=A0 =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/autoconf






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

--00032555a496fe733c0476d79ecb-- From thomas@thomasclausen.org Mon Oct 26 07:48: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 2550928C116 for ; Mon, 26 Oct 2009 07:48:58 -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.025, 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 gaGWHHzNKiza for ; Mon, 26 Oct 2009 07:48:57 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 149483A67F1 for ; Mon, 26 Oct 2009 07:48:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id CF4B332317AD; Mon, 26 Oct 2009 07:49:10 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 3951A32317AF; Mon, 26 Oct 2009 07:49:09 -0700 (PDT) Message-Id: From: Thomas Heide Clausen To: Ulrich Herberg In-Reply-To: <25c114b90910260746i30d489fbm4a48c151c842ef25@mail.gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-46--911527513 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 15:49:06 +0100 References: <20091019233002.15F4328C164@core3.amsl.com> <005801ca5618$38d35be0$aa7a13a0$@nl> <25c114b90910260219h52c74b4dha6871856afaaec23@mail.gmail.com> <00b601ca562b$0afa2ab0$20ee8010$@nl> <4AE5AE34.3090409@gmail.com> <4AE5B2BE.6040006@gmail.com> <25c114b90910260746i30d489fbm4a48c151c842ef25@mail.gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 14:48:58 -0000 --Apple-Mail-46--911527513 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Oct 26, 2009, at 3:46 PM, Ulrich Herberg wrote: > IMO, Alex is right here. Routers have to join multicast groups > (although there might be some exceptions like ff02::1). The RFC that > specifies MLDv2 is RFC3810. The Multicast listening state is stored > per socket as well as per interface. I did not find, however, a > restriction of scope for a multicast group based on the unicast > address of the interface. There is even an example in RFC4291 (the > mentioned Solicited-Node multicast address) which creates a link- > local multicast group out of a global unicast address: > As far as I know, you are right -- I do not see a conflict with MLD, though. I also note that 4861 and friends are sending to various multicast addresses with the undefined address as source.... So I guess I don't grasp the problem that Alex is bringing up? Thomas > "For example, the Solicited-Node multicast address corresponding to > the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C." > > > Please correct me if I am wrong here.... > > Ulrich > > > > On Mon, Oct 26, 2009 at 3:31 PM, Alexandru Petrescu > wrote: > [...] > Typically, a node does join groups of various scopes, link-local > scope included, by sending MLD Reports. Recent linux kernels do > so. Setting up local filters is an old fashioned way which does > not protect a node from noise - its driver is still solicited (the > discarding happens at the kernel level - too late). > > For example, rfc4861 ND says "a node must join" at several places > and then "Joining the solicited-node multicast address is done using > a Multicast Listener Discovery such as [MLD] or [MLDv2] protocols." > > Do you also discourage this use of groups, scopes and MLD? > > Alex > > > > > > Emmanuel > > > > ------------------------------------------------------------------------ > > > _______________________________________________ > 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-46--911527513 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Oct 26, 2009, = at 3:46 PM, Ulrich Herberg wrote:

IMO, Alex = is right here. Routers have to join multicast groups (although there = might be some exceptions like ff02::1). The RFC that specifies MLDv2 is = RFC3810. The Multicast listening state is stored per socket as well as = per interface. I did not find, however, a restriction of scope for a = multicast group based on the unicast address of the interface. There is = even an example in RFC4291 (the mentioned Solicited-Node multicast = address) which creates a link-local multicast group out of a global = unicast address:


As far as I know, = you are right -- I do not see a conflict with MLD, though. I also note = that 4861 and friends are sending to various multicast addresses with = the undefined address as source....

So I guess = I don't grasp the problem that Alex is bringing = up?

Thomas
"For =
example, the Solicited-Node multicast address corresponding to the IPv6 =
address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C."


Please correct me if I am wrong =
here....

Ulrich
 


On Mon, Oct 26, 2009 at 3:31 PM, Alexandru = Petrescu <alexandru.petrescu@gmail.com<= /a>> wrote:
[...]
Typically, a node does join groups = of various scopes, link-local scope included, by sending MLD Reports. =  Recent linux kernels do so.  Setting up local filters is an = old fashioned way  which does not protect a node from noise - its = driver is still solicited (the discarding happens at the kernel level - = too late).

For example, rfc4861 ND says "a node must join" at = several places and then "Joining the solicited-node multicast address is = done using a Multicast Listener Discovery such as [MLD] or [MLDv2] = protocols."

Do you also discourage this use of groups, scopes = and MLD?

Alex


 


      =  Emmanuel

       
    =   =  --------------------------------------------------------------------= ----


      =  _______________________________________________
    =    Autoconf mailing list
       Autoconf@ietf.org = <mailto: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-46--911527513-- From Ronald.intVelt@tno.nl Mon Oct 26 07:49: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 5D1F63A68D4 for ; Mon, 26 Oct 2009 07:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[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 Tfc78V-RZLrG for ; Mon, 26 Oct 2009 07:49:34 -0700 (PDT) Received: from mailoutb.tno.nl (mailoutb.tno.nl [134.221.1.17]) by core3.amsl.com (Postfix) with ESMTP id 06BA23A67F1 for ; Mon, 26 Oct 2009 07:49:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,626,1249250400"; d="scan'208";a="6267389" Received: from ms-dt01thalia.tno.nl (HELO ms-dt01thalia.tsn.tno.nl) ([134.221.225.157]) by mailhost1b.tno.nl with ESMTP; 26 Oct 2009 15:49:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 Oct 2009 15:49:42 +0100 Message-ID: <7877C5C0B5CC894AB26113CF06CF886302C20E09@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <7FAD52C4-20F4-4C18-BF31-FE0FBBC76E97@thomasclausen.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf]I-D Action:draft-bernardos-autoconf-addressing-model-00.txt thread-index: AcpWSAyFhKTA4kWgQAODI9JTS/hjJQAAjXUg References: <20091019233002.15F4328C164@core3.amsl.com> <4AE090FE.3000001@earthlink.net><1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com><1256491742.4766.35.camel@acorde.it.uc3m.es> <005801ca5618$38d35be0$aa7a13a0$@nl> <25c114b90910260219h52c74b4dha6871856afaaec23@mail.gmail.com><00b601ca562b$0afa2ab0$20ee8010$@nl><4AE5AE34.3090409@gmail.com> <7FAD52C4-20F4-4C18-BF31-FE0FBBC76E97@thomasclausen.org> From: "Velt, R. (Ronald) in 't" To: "Thomas Heide Clausen" , "Alexandru Petrescu" Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 14:49:35 -0000 Hi Thomas, Alex, all=20 >-----Original Message----- >From: autoconf-bounces@ietf.org=20 >[mailto:autoconf-bounces@ietf.org] On Behalf Of Thomas Heide Clausen >Sent: maandag 26 oktober 2009 15:16 >To: Alexandru Petrescu >Cc: autoconf@ietf.org; Emmanuel Baccelli >Subject: Re: [Autoconf]I-D=20 >Action:draft-bernardos-autoconf-addressing-model-00.txt > > >On Oct 26, 2009, at 3:12 PM, Alexandru Petrescu wrote: > >> Emmanuel Baccelli a =E9crit : >>> On Mon, Oct 26, 2009 at 11:56 AM, Teco Boot >> >> >> wrote: >>> *Van:* ulrich@herberg.name >>> [mailto:ulrich@herberg.name ] *Namens >>> *Ulrich Herberg >>> *Verzonden:* maandag 26 oktober 2009 10:20 >>> *Aan:* Thomas Heide Clausen >>> *CC:* Teco Boot; autoconf@ietf.org >>> *Onderwerp:* Re: [Autoconf] I-D >>> Action:draft-bernardos-autoconf-addressing-model-00.txt >>> Fully agree with Thomas here. >>> Note that the DT draft says: >>> "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 connnectivity to neighbors may be >>> constantly changing." >>> So, the draft also says that (per RFC4291) LL are=20 >configured on an >>> interface. It just says that they are not of much use,=20 >because it=20 >>> is >>> very difficult to assure uniqueness beyond 1 hop. >>> Same for ULAs and globals to! >>> Teco. >>> ULAs and globals are meant to be managed by mechanisms that are=20 >>> fundamentally different from the LL mechanisms. ULAs and=20 >globals are=20 >>> naturally unambiguous in a MANET context, contrary to LL addresses.=20 >>> Could this whole discussion prove once and for all (for the=20 >few still=20 >>> not convinced) that link local addresses are AMBIGUOUS in=20 >the context=20 >>> that we want to address in this working group? Why do we have to=20 >>> discuss this again and again? >>> Nobody wants ambiguous standards. So let's keep the boat away from=20 >>> such rocks, and let's move on! >> >> Emmanuel - how about the LL-MANET-Routers and the link-local=20 >multicast=20 >> group RFC5498? >> >> Will the AUTOCONF router join this group at all? Will it use an ULA=20 >> to join this link-local group? I'd rather say it would use=20 >its link-=20 >> local address to join that group. But if you discourage it... >> > >When you say "join this link-local group", what do you imagine=20 >happen? =20 >Other than that you tell the kernel in your OS "hey, if you get =20 >something destined for group XXXX on this interface, hand me a copy", =20 >of course? But what about the transmitting side? I have just seen it happen in the lab: NRLOLSRD sends out Hello's to an IPv6 multicast destination address, with a= n IPv6 link-local source address. I think this is RFC3484, Source Address s= election rule #2 ("Prefer appropriate scope") in action. Regards, Ronald > >Thomas > >> Alex >> >>> Emmanuel >>>=20 >--------------------------------------------------------------- >--------- >>> _______________________________________________ >>> 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 > This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/disclaimer/email.html From ulrich@herberg.name Mon Oct 26 07:51: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 6586B28C23A for ; Mon, 26 Oct 2009 07:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[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 gA+Xire8wDr2 for ; Mon, 26 Oct 2009 07:51:28 -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 6827E28C1E9 for ; Mon, 26 Oct 2009 07:51:28 -0700 (PDT) Received: by bwz19 with SMTP id 19so2167706bwz.28 for ; Mon, 26 Oct 2009 07:51:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.3.211 with SMTP id 19mr164998bko.36.1256568698067; Mon, 26 Oct 2009 07:51:38 -0700 (PDT) In-Reply-To: References: <20091019233002.15F4328C164@core3.amsl.com> <25c114b90910260219h52c74b4dha6871856afaaec23@mail.gmail.com> <00b601ca562b$0afa2ab0$20ee8010$@nl> <4AE5AE34.3090409@gmail.com> <4AE5B2BE.6040006@gmail.com> <25c114b90910260746i30d489fbm4a48c151c842ef25@mail.gmail.com> Date: Mon, 26 Oct 2009 15:51:37 +0100 Message-ID: <25c114b90910260751l794b026bjd8f96652ba08fdb6@mail.gmail.com> From: Ulrich Herberg To: Thomas Heide Clausen Content-Type: multipart/alternative; boundary=0015174be73ce25c4e0476d7b283 Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 14:51:29 -0000 --0015174be73ce25c4e0476d7b283 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 26, 2009 at 3:49 PM, Thomas Heide Clausen < thomas@thomasclausen.org> wrote: > > On Oct 26, 2009, at 3:46 PM, Ulrich Herberg wrote: > > IMO, Alex is right here. Routers have to join multicast groups (although > there might be some exceptions like ff02::1). The RFC that specifies MLDv2 > is RFC3810. The Multicast listening state is stored per socket as well as > per interface. I did not find, however, a restriction of scope for a > multicast group based on the unicast address of the interface. There is even > an example in RFC4291 (the mentioned Solicited-Node multicast address) which > creates a link-local multicast group out of a global unicast address: > > > As far as I know, you are right -- I do not see a conflict with MLD, > though. I also note that 4861 and friends are sending to various multicast > addresses with the undefined address as source.... > > "Multicast addresses must not be used as source addresses in IPv6 packets or appear in any Routing header." [RFC4291] Ulrich --0015174be73ce25c4e0476d7b283 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Oct 26, 2009 at 3:49 PM, Thomas = Heide Clausen <thomas@thomasclausen.org> wrote:

On Oc= t 26, 2009, at 3:46 PM, Ulrich Herberg wrote:

IMO, Alex is right here. Routers have to join multicast groups (altho= ugh there might be some exceptions like ff02::1). The RFC that specifies ML= Dv2 is RFC3810. The Multicast listening state is stored per socket as well = as per interface. I did not find, however, a restriction of scope for a mul= ticast group based on the unicast address of the interface. There is even a= n example in RFC4291 (the mentioned Solicited-Node multicast address) which= creates a link-local multicast group out of a global unicast address:


As far as I know, you are right -- I= do not see a conflict with MLD, though. I also note that 4861 and friends = are sending to various multicast addresses with the undefined address as so= urce....

"Multicast ad=
dresses must not be used as source addresses in IPv6
   packets or appea=
r in any Routing header." [RFC4291]



Ulrich
=A0


=A0
--0015174be73ce25c4e0476d7b283-- From thomas@thomasclausen.org Mon Oct 26 07:54: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 0BB203A6A7D for ; Mon, 26 Oct 2009 07:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.275 X-Spam-Level: X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6] 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 u9XrqFw9y2IC for ; Mon, 26 Oct 2009 07:54:31 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id F04FA3A6A77 for ; Mon, 26 Oct 2009 07:54:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id BAC2A32317B6; Mon, 26 Oct 2009 07:54:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 7F5EF32317AF; Mon, 26 Oct 2009 07:54:43 -0700 (PDT) Message-Id: <1FBD7817-1A74-4968-BEA6-57BB592335EC@thomasclausen.org> From: Thomas Heide Clausen To: Ulrich Herberg In-Reply-To: <25c114b90910260751l794b026bjd8f96652ba08fdb6@mail.gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-48--911192944 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 15:54:41 +0100 References: <20091019233002.15F4328C164@core3.amsl.com> <25c114b90910260219h52c74b4dha6871856afaaec23@mail.gmail.com> <00b601ca562b$0afa2ab0$20ee8010$@nl> <4AE5AE34.3090409@gmail.com> <4AE5B2BE.6040006@gmail.com> <25c114b90910260746i30d489fbm4a48c151c842ef25@mail.gmail.com> <25c114b90910260751l794b026bjd8f96652ba08fdb6@mail.gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 14:54:32 -0000 --Apple-Mail-48--911192944 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Oct 26, 2009, at 3:51 PM, Ulrich Herberg wrote: > > > On Mon, Oct 26, 2009 at 3:49 PM, Thomas Heide Clausen > wrote: > > On Oct 26, 2009, at 3:46 PM, Ulrich Herberg wrote: > >> IMO, Alex is right here. Routers have to join multicast groups >> (although there might be some exceptions like ff02::1). The RFC >> that specifies MLDv2 is RFC3810. The Multicast listening state is >> stored per socket as well as per interface. I did not find, >> however, a restriction of scope for a multicast group based on the >> unicast address of the interface. There is even an example in >> RFC4291 (the mentioned Solicited-Node multicast address) which >> creates a link-local multicast group out of a global unicast address: >> > > As far as I know, you are right -- I do not see a conflict with MLD, > though. I also note that 4861 and friends are sending to various > multicast addresses with the undefined address as source.... > > "Multicast addresses must not be used as source addresses in IPv6 > packets or appear in any Routing header." [RFC4291] > Right - that would be just silly to do ;) But undefined is, apparently, quite OK (as per 4861)? And, there're even groups that one "joins" even before having an LL address for 4861 to work.... Thomas --Apple-Mail-48--911192944 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Oct 26, 2009, = at 3:51 PM, Ulrich Herberg wrote:



On Mon, Oct 26, 2009 at 3:49 PM, Thomas Heide = Clausen <thomas@thomasclausen.org><= /span> wrote:

On Oct 26, 2009, at 3:46 PM, Ulrich Herberg = wrote:

IMO, Alex is right here. = Routers have to join multicast groups (although there might be some = exceptions like ff02::1). The RFC that specifies MLDv2 is RFC3810. The = Multicast listening state is stored per socket as well as per interface. = I did not find, however, a restriction of scope for a multicast group = based on the unicast address of the interface. There is even an example = in RFC4291 (the mentioned Solicited-Node multicast address) which = creates a link-local multicast group out of a global unicast = address:


As far as I know, you = are right -- I do not see a conflict with MLD, though. I also note that = 4861 and friends are sending to various multicast addresses with the = undefined address as source....
= 

"Multicast =
addresses must not be used as source addresses in IPv6
   packets or =
appear in any Routing header." [RFC4291]
Right - that would be just = silly to do ;) But undefined is, apparently, quite OK (as per 4861)? = And, there're even groups that one "joins" even before having an LL = address for 4861 to = work....

Thomas
= --Apple-Mail-48--911192944-- From ulrich@herberg.name Mon Oct 26 07:57:07 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 D2AF428C0F8 for ; Mon, 26 Oct 2009 07:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[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 CxfJpnWTGGxo for ; Mon, 26 Oct 2009 07:57:07 -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 D7C0C3A67CF for ; Mon, 26 Oct 2009 07:57:06 -0700 (PDT) Received: by bwz19 with SMTP id 19so2173419bwz.28 for ; Mon, 26 Oct 2009 07:57:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.5.75 with SMTP id 11mr6058780bku.20.1256569035022; Mon, 26 Oct 2009 07:57:15 -0700 (PDT) In-Reply-To: <7877C5C0B5CC894AB26113CF06CF886302C20E09@ms-dt01thalia.tsn.tno.nl> References: <20091019233002.15F4328C164@core3.amsl.com> <005801ca5618$38d35be0$aa7a13a0$@nl> <25c114b90910260219h52c74b4dha6871856afaaec23@mail.gmail.com> <00b601ca562b$0afa2ab0$20ee8010$@nl> <4AE5AE34.3090409@gmail.com> <7FAD52C4-20F4-4C18-BF31-FE0FBBC76E97@thomasclausen.org> <7877C5C0B5CC894AB26113CF06CF886302C20E09@ms-dt01thalia.tsn.tno.nl> Date: Mon, 26 Oct 2009 15:57:14 +0100 Message-ID: <25c114b90910260757w33de940dv618aa93783795f26@mail.gmail.com> From: Ulrich Herberg To: "Velt, R. (Ronald) in 't" Content-Type: multipart/alternative; boundary=00151743f754f7e11f0476d7c624 Cc: autoconf@ietf.org, Thomas Heide Clausen , Emmanuel Baccelli Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 14:57:07 -0000 --00151743f754f7e11f0476d7c624 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 26, 2009 at 3:49 PM, Velt, R. (Ronald) in 't < Ronald.intVelt@tno.nl> wrote: > [...] > > But what about the transmitting side? I have just seen it happen in the > lab: > NRLOLSRD sends out Hello's to an IPv6 multicast destination address, with > an IPv6 link-local source address. I think this is RFC3484, Source Address > selection rule #2 ("Prefer appropriate scope") in action. > > That's possible. However, might not be a good idea. In my OLSRv2 implementation, I set the source address to a global IPv6 address, if such is available. (if no such address is possible, I think that my implementation will kill itself... have to check ;-) Ulrich --00151743f754f7e11f0476d7c624 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Oct 26, 2009 at 3:49 PM, Velt, R= . (Ronald) in 't <Ronald.intVelt@tno.nl> wrote:
[...]

But what about the transmitting side? I have just seen it happen in t= he lab:
NRLOLSRD sends out Hello's to an IPv6 multicast destination address, wi= th an IPv6 link-local source address. I think this is RFC3484, Source Addre= ss selection rule #2 ("Prefer appropriate scope") in action.


That's possible. However, might not be a good= idea. In my OLSRv2 implementation, I set the source address to a global IP= v6 address, if such is available. (if no such address is possible, I think = that my implementation will kill itself... have to check ;-)

Ulrich
--00151743f754f7e11f0476d7c624-- From alexandru.petrescu@gmail.com Mon Oct 26 08:07: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 440893A6AB2 for ; Mon, 26 Oct 2009 08:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=0.105, 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 KtZG7RvLRF2n for ; Mon, 26 Oct 2009 08:07:39 -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 4A0103A6AB1 for ; Mon, 26 Oct 2009 08:07:39 -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 n9QF7oXx019586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 16:07:50 +0100 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 n9QF7ods005647; Mon, 26 Oct 2009 16:07:50 +0100 (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 n9QF7nKW023714; Mon, 26 Oct 2009 16:07:49 +0100 Message-ID: <4AE5BB45.7090303@gmail.com> Date: Mon, 26 Oct 2009 16:07:49 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ulrich Herberg References: <20091019233002.15F4328C164@core3.amsl.com> <005801ca5618$38d35be0$aa7a13a0$@nl> <25c114b90910260219h52c74b4dha6871856afaaec23@mail.gmail.com> <00b601ca562b$0afa2ab0$20ee8010$@nl> <4AE5AE34.3090409@gmail.com> <4AE5B2BE.6040006@gmail.com> <25c114b90910260746i30d489fbm4a48c151c842ef25@mail.gmail.com> In-Reply-To: <25c114b90910260746i30d489fbm4a48c151c842ef25@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 15:07:41 -0000 Ulrich Herberg a écrit : > IMO, Alex is right here. Routers have to join multicast groups > (although there might be some exceptions like ff02::1). The RFC that > specifies MLDv2 is RFC3810. The Multicast listening state is stored > per socket as well as per interface. I did not find, however, a > restriction of scope for a multicast group based on the unicast > address of the interface. There is even an example in RFC4291 (the > mentioned Solicited-Node multicast address) which creates a > link-local multicast group out of a global unicast address: > > "For example, the Solicited-Node multicast address corresponding to > the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C." Right, the solicited-node multicast group derived from the IID of an IPv6 global address - that is ok. It is a local derivation. It is ok. I meant this: when node A joins froun ff02::2 by putting its link-local address in the MLD src address: > An MLDv2 Report MUST be sent with a valid IPv6 link-local source > address, or the unspecified address (::), if the sending interface > has not acquired a valid link-local address yet. I think that if AUTOCONF discourages the link-local addresses then automatically MLD will use "::" (unspecified address) in its src. I don't think this is an MLD problem. I think these things are so much intertwinned that it's hard to simply discourage the use of link-local addresses. Alex > > > Please correct me if I am wrong here.... > > Ulrich > > > > > On Mon, Oct 26, 2009 at 3:31 PM, Alexandru Petrescu > > > wrote: > > [...] Typically, a node does join groups of various scopes, > link-local scope included, by sending MLD Reports. Recent linux > kernels do so. Setting up local filters is an old fashioned way > which does not protect a node from noise - its driver is still > solicited (the discarding happens at the kernel level - too late). > > For example, rfc4861 ND says "a node must join" at several places and > then "Joining the solicited-node multicast address is done using a > Multicast Listener Discovery such as [MLD] or [MLDv2] protocols." > > Do you also discourage this use of groups, scopes and MLD? > > Alex > > > > > > Emmanuel > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ 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 alexandru.petrescu@gmail.com Mon Oct 26 08:09: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 0982E28C0F1 for ; Mon, 26 Oct 2009 08:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[AWL=0.103, 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 C6M+Kx1viQEJ for ; Mon, 26 Oct 2009 08:09:54 -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 7CFF428C185 for ; Mon, 26 Oct 2009 08:09:37 -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 n9QF9mJI016623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 16:09:48 +0100 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 n9QF9mfE006332; Mon, 26 Oct 2009 16:09:48 +0100 (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 n9QF9mTj024578; Mon, 26 Oct 2009 16:09:48 +0100 Message-ID: <4AE5BBBC.6010207@gmail.com> Date: Mon, 26 Oct 2009 16:09:48 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <20091019233002.15F4328C164@core3.amsl.com> <005801ca5618$38d35be0$aa7a13a0$@nl> <25c114b90910260219h52c74b4dha6871856afaaec23@mail.gmail.com> <00b601ca562b$0afa2ab0$20ee8010$@nl> <4AE5AE34.3090409@gmail.com> <4AE5B2BE.6040006@gmail.com> <25c114b90910260746i30d489fbm4a48c151c842ef25@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 15:09:55 -0000 Thomas Heide Clausen a écrit : > > On Oct 26, 2009, at 3:46 PM, Ulrich Herberg wrote: > >> IMO, Alex is right here. Routers have to join multicast groups >> (although there might be some exceptions like ff02::1). The RFC that >> specifies MLDv2 is RFC3810. The Multicast listening state is stored >> per socket as well as per interface. I did not find, however, a >> restriction of scope for a multicast group based on the unicast >> address of the interface. There is even an example in RFC4291 (the >> mentioned Solicited-Node multicast address) which creates a link-local >> multicast group out of a global unicast address: >> > > As far as I know, you are right -- I do not see a conflict with MLD, > though. I also note that 4861 and friends are sending to various > multicast addresses with the undefined address as source.... YEs, these are exceptions. When no LL address available, use the "::" unspecified address. I think it i smore advantageous to use the LL address is used. > So I guess I don't grasp the problem that Alex is bringing up? WEll yes, no problem; as long as you discourage the LL addresses let's use the "::" address, and not some AUTOCONF configured address - is this ok? Alex > > Thomas >> "For example, the Solicited-Node multicast address corresponding to the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C." >> >> >> Please correct me if I am wrong here.... >> >> Ulrich >> >> >> >> On Mon, Oct 26, 2009 at 3:31 PM, Alexandru Petrescu >> > >> wrote: >> >> [...] >> Typically, a node does join groups of various scopes, link-local >> scope included, by sending MLD Reports. Recent linux kernels do >> so. Setting up local filters is an old fashioned way which does >> not protect a node from noise - its driver is still solicited (the >> discarding happens at the kernel level - too late). >> >> For example, rfc4861 ND says "a node must join" at several places >> and then "Joining the solicited-node multicast address is done >> using a Multicast Listener Discovery such as [MLD] or [MLDv2] >> protocols." >> >> Do you also discourage this use of groups, scopes and MLD? >> >> Alex >> >> >> >> >> >> Emmanuel >> >> >> >> ------------------------------------------------------------------------ >> >> >> _______________________________________________ >> 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 > From alexandru.petrescu@gmail.com Mon Oct 26 08:12:04 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 96BBD3A6A9B for ; Mon, 26 Oct 2009 08:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_52=0.6] 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 aYxEZv2WhvlR for ; Mon, 26 Oct 2009 08:12:03 -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 9AFD03A6A79 for ; Mon, 26 Oct 2009 08:12:03 -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 n9QFCENc031670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 16:12:15 +0100 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 n9QFCEO4007292; Mon, 26 Oct 2009 16:12:14 +0100 (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 n9QFCES6019572; Mon, 26 Oct 2009 16:12:14 +0100 Message-ID: <4AE5BC4E.5020507@gmail.com> Date: Mon, 26 Oct 2009 16:12:14 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <20091019233002.15F4328C164@core3.amsl.com> <25c114b90910260219h52c74b4dha6871856afaaec23@mail.gmail.com> <00b601ca562b$0afa2ab0$20ee8010$@nl> <4AE5AE34.3090409@gmail.com> <4AE5B2BE.6040006@gmail.com> <25c114b90910260746i30d489fbm4a48c151c842ef25@mail.gmail.com> <25c114b90910260751l794b026bjd8f96652ba08fdb6@mail.gmail.com> <1FBD7817-1A74-4968-BEA6-57BB592335EC@thomasclausen.org> In-Reply-To: <1FBD7817-1A74-4968-BEA6-57BB592335EC@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 15:12:04 -0000 Thomas Heide Clausen a écrit : > > On Oct 26, 2009, at 3:51 PM, Ulrich Herberg wrote: > >> >> >> On Mon, Oct 26, 2009 at 3:49 PM, Thomas Heide Clausen >> > wrote: >> >> >> On Oct 26, 2009, at 3:46 PM, Ulrich Herberg wrote: >> >>> IMO, Alex is right here. Routers have to join multicast groups >>> (although there might be some exceptions like ff02::1). The RFC >>> that specifies MLDv2 is RFC3810. The Multicast listening state is >>> stored per socket as well as per interface. I did not find, >>> however, a restriction of scope for a multicast group based on >>> the unicast address of the interface. There is even an example in >>> RFC4291 (the mentioned Solicited-Node multicast address) which >>> creates a link-local multicast group out of a global unicast address: >>> >> >> As far as I know, you are right -- I do not see a conflict with >> MLD, though. I also note that 4861 and friends are sending to >> various multicast addresses with the undefined address as source.... >> >> "Multicast addresses must not be used as source addresses in IPv6 >> packets or appear in any Routing header." [RFC4291] >> > Right - that would be just silly to do ;) But undefined is, apparently, > quite OK (as per 4861)? And, there're even groups that one "joins" even > before having an LL address for 4861 to work.... Yes, that is right. But when having that LL address - use it. DO you see it like: -if not having an LL then use "::" unspecified address instead, and if you then obtain an LL address then don't use it. Alex > > Thomas > > > ------------------------------------------------------------------------ > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From thomas@thomasclausen.org Mon Oct 26 08:20: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 4F2663A691D for ; Mon, 26 Oct 2009 08:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 yWjKrMRAySt6 for ; Mon, 26 Oct 2009 08:20:42 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id E2C033A67CF for ; Mon, 26 Oct 2009 08:20:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id AD8FB32317B6; Mon, 26 Oct 2009 08:20:47 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 5CAC332317B0; Mon, 26 Oct 2009 08:20:46 -0700 (PDT) Message-Id: <620DE5EE-C3B2-4162-AEE4-018F7AC1BF5C@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE5BB45.7090303@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: Mon, 26 Oct 2009 16:20:43 +0100 References: <20091019233002.15F4328C164@core3.amsl.com> <005801ca5618$38d35be0$aa7a13a0$@nl> <25c114b90910260219h52c74b4dha6871856afaaec23@mail.gmail.com> <00b601ca562b$0afa2ab0$20ee8010$@nl> <4AE5AE34.3090409@gmail.com> <4AE5B2BE.6040006@gmail.com> <25c114b90910260746i30d489fbm4a48c151c842ef25@mail.gmail.com> <4AE5BB45.7090303@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 15:20:43 -0000 On Oct 26, 2009, at 4:07 PM, Alexandru Petrescu wrote: > Ulrich Herberg a =E9crit : >> IMO, Alex is right here. Routers have to join multicast groups >> (although there might be some exceptions like ff02::1). The RFC that >> specifies MLDv2 is RFC3810. The Multicast listening state is stored >> per socket as well as per interface. I did not find, however, a >> restriction of scope for a multicast group based on the unicast >> address of the interface. There is even an example in RFC4291 (the >> mentioned Solicited-Node multicast address) which creates a >> link-local multicast group out of a global unicast address: >> "For example, the Solicited-Node multicast address corresponding to >> the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C." > > Right, the solicited-node multicast group derived from the IID of an =20= > IPv6 global address - that is ok. It is a local derivation. It is =20= > ok. > > I meant this: when node A joins froun ff02::2 by putting its link-=20 > local address in the MLD src address: >> An MLDv2 Report MUST be sent with a valid IPv6 link-local source >> address, or the unspecified address (::), if the sending interface >> has not acquired a valid link-local address yet. > > I think that if AUTOCONF discourages the link-local addresses then =20 > automatically MLD will use "::" (unspecified address) in its src. > > I don't think this is an MLD problem. > > I think these things are so much intertwinned that it's hard to =20 > simply discourage the use of link-local addresses. > So what you propose is, that LL addresses MUST be globally (or, at =20 least, MANET-wide) unique? I.e. that LL addresses MUST be verified in =20= a scope beyond 1 hop? =09 From alexandru.petrescu@gmail.com Mon Oct 26 08:22: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 EF4713A6858 for ; Mon, 26 Oct 2009 08:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[AWL=0.103, 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 V0XwQSQ2bAnI for ; Mon, 26 Oct 2009 08:22:01 -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 EFD163A67E7 for ; Mon, 26 Oct 2009 08:22:00 -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 n9QFMCf2026957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 16:22:12 +0100 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 n9QFMCD2010596; Mon, 26 Oct 2009 16:22:12 +0100 (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 n9QFMBlk023880; Mon, 26 Oct 2009 16:22:12 +0100 Message-ID: <4AE5BEA3.7010007@gmail.com> Date: Mon, 26 Oct 2009 16:22:11 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <20091019233002.15F4328C164@core3.amsl.com> <005801ca5618$38d35be0$aa7a13a0$@nl> <25c114b90910260219h52c74b4dha6871856afaaec23@mail.gmail.com> <00b601ca562b$0afa2ab0$20ee8010$@nl> <4AE5AE34.3090409@gmail.com> <4AE5B2BE.6040006@gmail.com> <25c114b90910260746i30d489fbm4a48c151c842ef25@mail.gmail.com> <4AE5BB45.7090303@gmail.com> <620DE5EE-C3B2-4162-AEE4-018F7AC1BF5C@thomasclausen.org> In-Reply-To: <620DE5EE-C3B2-4162-AEE4-018F7AC1BF5C@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 15:22:02 -0000 Thomas Heide Clausen a écrit : > > On Oct 26, 2009, at 4:07 PM, Alexandru Petrescu wrote: > >> Ulrich Herberg a écrit : >>> IMO, Alex is right here. Routers have to join multicast groups >>> (although there might be some exceptions like ff02::1). The RFC that >>> specifies MLDv2 is RFC3810. The Multicast listening state is stored >>> per socket as well as per interface. I did not find, however, a >>> restriction of scope for a multicast group based on the unicast >>> address of the interface. There is even an example in RFC4291 (the >>> mentioned Solicited-Node multicast address) which creates a >>> link-local multicast group out of a global unicast address: >>> "For example, the Solicited-Node multicast address corresponding to >>> the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C." >> >> Right, the solicited-node multicast group derived from the IID of an >> IPv6 global address - that is ok. It is a local derivation. It is ok. >> >> I meant this: when node A joins froun ff02::2 by putting its >> link-local address in the MLD src address: >>> An MLDv2 Report MUST be sent with a valid IPv6 link-local source >>> address, or the unspecified address (::), if the sending interface >>> has not acquired a valid link-local address yet. >> >> I think that if AUTOCONF discourages the link-local addresses then >> automatically MLD will use "::" (unspecified address) in its src. >> >> I don't think this is an MLD problem. >> >> I think these things are so much intertwinned that it's hard to simply >> discourage the use of link-local addresses. >> > > So what you propose is, that LL addresses MUST be globally (or, at > least, MANET-wide) unique? I.e. that LL addresses MUST be verified in a > scope beyond 1 hop? Not really, I propose to use the LL addresses as they are originally planned to, and not to discourage them. Alex > > > > From ulrich@herberg.name Mon Oct 26 08:25: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 E94643A6A87 for ; Mon, 26 Oct 2009 08:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 4-is9S+7Ohg3 for ; Mon, 26 Oct 2009 08:25:30 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id EBFC53A67FC for ; Mon, 26 Oct 2009 08:25:29 -0700 (PDT) Received: by fxm18 with SMTP id 18so12156486fxm.37 for ; Mon, 26 Oct 2009 08:25:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.157.16 with SMTP id z16mr9070999bkw.103.1256570739833; Mon, 26 Oct 2009 08:25:39 -0700 (PDT) In-Reply-To: <4AE5BEA3.7010007@gmail.com> References: <20091019233002.15F4328C164@core3.amsl.com> <00b601ca562b$0afa2ab0$20ee8010$@nl> <4AE5AE34.3090409@gmail.com> <4AE5B2BE.6040006@gmail.com> <25c114b90910260746i30d489fbm4a48c151c842ef25@mail.gmail.com> <4AE5BB45.7090303@gmail.com> <620DE5EE-C3B2-4162-AEE4-018F7AC1BF5C@thomasclausen.org> <4AE5BEA3.7010007@gmail.com> Date: Mon, 26 Oct 2009 16:25:39 +0100 Message-ID: <25c114b90910260825n2702eed9kc4483ba73f214cdd@mail.gmail.com> From: Ulrich Herberg To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=0015175ccf5c953c840476d82c42 Cc: autoconf@ietf.org, Emmanuel Baccelli , Thomas Heide Clausen Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 15:25:31 -0000 --0015175ccf5c953c840476d82c42 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 26, 2009 at 4:22 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Thomas Heide Clausen a =E9crit : > >> [...] >> >>> >>> >> So what you propose is, that LL addresses MUST be globally (or, at least= , >> MANET-wide) unique? I.e. that LL addresses MUST be verified in a scope >> beyond 1 hop? >> >> > Not really, I propose to use the LL addresses as they are originally > planned to, and not to discourage them. > Originally, they have been planned to wired networks, so with very differen= t assumptions. So it is not possible to use them as originally planned. If yo= u want to use them as originally planned, you have the whole lot of problems that are mentioned in the DT draft. If you plan to use them, you have to assure exactly what Thomas asked as a question. Ulrich --0015175ccf5c953c840476d82c42 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Oct 26, 2009 at 4:22 PM, Alexand= ru Petrescu <alexandru.petrescu@gmail.com> wrote:
Thomas Heide Clausen a =E9crit :
[...]
<= div class=3D"h5">


So what you propose is, that LL addresses MUST be globally (or, at least, M= ANET-wide) unique? =A0I.e. that LL addresses MUST be verified in a scope be= yond 1 hop?


Not really, I propose to use the LL addresses as they are originally planne= d to, and not to discourage them.

Originally, they= have been planned to wired networks, so with very different assumptions. S= o it is not possible to use them as originally planned. If you want to use = them as originally planned, you have the whole lot of problems that are men= tioned in the DT draft.
If you plan to use them, you have to assure exactly what Thomas asked as a = question.

Ulrich
--0015175ccf5c953c840476d82c42-- From thomas@thomasclausen.org Mon Oct 26 08:30: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 3D3083A6905 for ; Mon, 26 Oct 2009 08:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 cBc8h7negZsV for ; Mon, 26 Oct 2009 08:30:53 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 3D9803A67FC for ; Mon, 26 Oct 2009 08:30:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 0C3F132317AB; Mon, 26 Oct 2009 08:31:07 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 9EDC332317B4; Mon, 26 Oct 2009 08:31:05 -0700 (PDT) Message-Id: <55FAFA43-D8DE-4EAE-89C0-817CDE22F65B@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE5BEA3.7010007@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: Mon, 26 Oct 2009 16:31:03 +0100 References: <20091019233002.15F4328C164@core3.amsl.com> <005801ca5618$38d35be0$aa7a13a0$@nl> <25c114b90910260219h52c74b4dha6871856afaaec23@mail.gmail.com> <00b601ca562b$0afa2ab0$20ee8010$@nl> <4AE5AE34.3090409@gmail.com> <4AE5B2BE.6040006@gmail.com> <25c114b90910260746i30d489fbm4a48c151c842ef25@mail.gmail.com> <4AE5BB45.7090303@gmail.com> <620DE5EE-C3B2-4162-AEE4-018F7AC1BF5C@thomasclausen.org> <4AE5BEA3.7010007@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 15:30:54 -0000 On Oct 26, 2009, at 4:22 PM, Alexandru Petrescu wrote: > Thomas Heide Clausen a =E9crit : >> On Oct 26, 2009, at 4:07 PM, Alexandru Petrescu wrote: >>> Ulrich Herberg a =E9crit : >>>> IMO, Alex is right here. Routers have to join multicast groups >>>> (although there might be some exceptions like ff02::1). The RFC =20 >>>> that >>>> specifies MLDv2 is RFC3810. The Multicast listening state is stored >>>> per socket as well as per interface. I did not find, however, a >>>> restriction of scope for a multicast group based on the unicast >>>> address of the interface. There is even an example in RFC4291 (the >>>> mentioned Solicited-Node multicast address) which creates a >>>> link-local multicast group out of a global unicast address: >>>> "For example, the Solicited-Node multicast address corresponding to >>>> the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C." >>> >>> Right, the solicited-node multicast group derived from the IID of =20= >>> an IPv6 global address - that is ok. It is a local derivation. =20 >>> It is ok. >>> >>> I meant this: when node A joins froun ff02::2 by putting its link-=20= >>> local address in the MLD src address: >>>> An MLDv2 Report MUST be sent with a valid IPv6 link-local source >>>> address, or the unspecified address (::), if the sending interface >>>> has not acquired a valid link-local address yet. >>> >>> I think that if AUTOCONF discourages the link-local addresses then =20= >>> automatically MLD will use "::" (unspecified address) in its src. >>> >>> I don't think this is an MLD problem. >>> >>> I think these things are so much intertwinned that it's hard to =20 >>> simply discourage the use of link-local addresses. >>> >> So what you propose is, that LL addresses MUST be globally (or, at =20= >> least, MANET-wide) unique? I.e. that LL addresses MUST be verified =20= >> in a scope beyond 1 hop? > > Not really, I propose to use the LL addresses as they are originally =20= > planned to, and not to discourage them. > Either: o you render the addresses useful in the MANET context; o or, you discourage their use. As they are, LL addresses are - for reasons that have been listed, =20 enumerated and discussed ad infinitum on this list and in [autoconf] =20 in general - not suitable for much in a MANET. I think that the two =20 addressing architecture Baccelli/Townsley and Carlos/Ronald (sorry =20 guys, your last names are too hard to type ;) ) I-Ds both make that =20 clear. Propose something that will *work*, and is experimentally and =20 deployment-wise supported, and I'm sure that we all will be listening. =20= Until then, I'm afraid that we're running in circles. Thomas > Alex > >> > > From thomas@thomasclausen.org Mon Oct 26 08:31: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 8DDAA3A6ABD for ; Mon, 26 Oct 2009 08:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.037, 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 VcTLuxDLYxXp for ; Mon, 26 Oct 2009 08:31:22 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id B83C53A67FC for ; Mon, 26 Oct 2009 08:31:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 8793432317AD; Mon, 26 Oct 2009 08:31:36 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 1C80D32317AB; Mon, 26 Oct 2009 08:31:34 -0700 (PDT) Message-Id: From: Thomas Heide Clausen To: Ulrich Herberg In-Reply-To: <25c114b90910260825n2702eed9kc4483ba73f214cdd@mail.gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-50--908979392 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 16:31:34 +0100 References: <20091019233002.15F4328C164@core3.amsl.com> <00b601ca562b$0afa2ab0$20ee8010$@nl> <4AE5AE34.3090409@gmail.com> <4AE5B2BE.6040006@gmail.com> <25c114b90910260746i30d489fbm4a48c151c842ef25@mail.gmail.com> <4AE5BB45.7090303@gmail.com> <620DE5EE-C3B2-4162-AEE4-018F7AC1BF5C@thomasclausen.org> <4AE5BEA3.7010007@gmail.com> <25c114b90910260825n2702eed9kc4483ba73f214cdd@mail.gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 15:31:23 -0000 --Apple-Mail-50--908979392 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Oct 26, 2009, at 4:25 PM, Ulrich Herberg wrote: > > > On Mon, Oct 26, 2009 at 4:22 PM, Alexandru Petrescu = > wrote: > Thomas Heide Clausen a =E9crit : > [...] > > > So what you propose is, that LL addresses MUST be globally (or, at =20 > least, MANET-wide) unique? I.e. that LL addresses MUST be verified =20= > in a scope beyond 1 hop? > > > Not really, I propose to use the LL addresses as they are originally =20= > planned to, and not to discourage them. > > Originally, they have been planned to wired networks, so with very =20 > different assumptions. So it is not possible to use them as =20 > originally planned. If you want to use them as originally planned, =20 > you have the whole lot of problems that are mentioned in the DT draft. > If you plan to use them, you have to assure exactly what Thomas =20 > asked as a question. > Or, you have to use them on an Ethernet ;) Which is, then, not =20 [autoconf]. Thomas > Ulrich --Apple-Mail-50--908979392 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Oct 26, 2009, = at 4:25 PM, Ulrich Herberg wrote:



On Mon, Oct 26, 2009 at 4:22 PM, Alexandru = Petrescu <alexandru.petrescu@gmail.com<= /a>> wrote:
Thomas Heide Clausen a = =E9crit :
[...]

=
So what you propose is, that LL addresses MUST be globally (or, at = least, MANET-wide) unique?  I.e. that LL addresses MUST be verified = in a scope beyond 1 hop?


Not = really, I propose to use the LL addresses as they are originally planned = to, and not to discourage them.

Originally, = they have been planned to wired networks, so with very different = assumptions. So it is not possible to use them as originally planned. If = you want to use them as originally planned, you have the whole lot of = problems that are mentioned in the DT draft.
If you plan to use = them, you have to assure exactly what Thomas asked as a = question.


Or, you have to = use them on an Ethernet ;) Which is, then, not = [autoconf].


= --Apple-Mail-50--908979392-- From alexandru.petrescu@gmail.com Mon Oct 26 08:32:21 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 238083A6ABD for ; Mon, 26 Oct 2009 08:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=0.101, 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 QgERSRG9rvmN for ; Mon, 26 Oct 2009 08:32:20 -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 E0FDD3A6AB3 for ; Mon, 26 Oct 2009 08:32: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 n9QFWVX3002594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 16:32:31 +0100 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 n9QFWUrJ013863; Mon, 26 Oct 2009 16:32:30 +0100 (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 n9QFWUUQ001524; Mon, 26 Oct 2009 16:32:30 +0100 Message-ID: <4AE5C10E.1010208@gmail.com> Date: Mon, 26 Oct 2009 16:32:30 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ulrich Herberg References: <20091019233002.15F4328C164@core3.amsl.com> <00b601ca562b$0afa2ab0$20ee8010$@nl> <4AE5AE34.3090409@gmail.com> <4AE5B2BE.6040006@gmail.com> <25c114b90910260746i30d489fbm4a48c151c842ef25@mail.gmail.com> <4AE5BB45.7090303@gmail.com> <620DE5EE-C3B2-4162-AEE4-018F7AC1BF5C@thomasclausen.org> <4AE5BEA3.7010007@gmail.com> <25c114b90910260825n2702eed9kc4483ba73f214cdd@mail.gmail.com> In-Reply-To: <25c114b90910260825n2702eed9kc4483ba73f214cdd@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, Thomas Heide Clausen , Emmanuel Baccelli Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 15:32:21 -0000 Ulrich Herberg a écrit : > > > On Mon, Oct 26, 2009 at 4:22 PM, Alexandru Petrescu > > wrote: > > Thomas Heide Clausen a écrit : > > [...] > > > > So what you propose is, that LL addresses MUST be globally (or, > at least, MANET-wide) unique? I.e. that LL addresses MUST be > verified in a scope beyond 1 hop? > > > Not really, I propose to use the LL addresses as they are originally > planned to, and not to discourage them. > > > Originally, they have been planned to wired networks, I doubt this. I will not tell the contrary to you. I think IPv6 LLs were designed at a time (1996?) when "Packet Radio" had already happened. I wasn't there, I can't say, but I feel that IPv6 LLs were there to work with the "future" Internet ("future" at that time) which planned for many small wireless devices moving around. This is speculation from my part - I wasn't there. > so with very > different assumptions. So it is not possible to use them as originally > planned. If you want to use them as originally planned, you have the > whole lot of problems that are mentioned in the DT draft. > If you plan to use them, you have to assure exactly what Thomas asked as > a question. Well ok. Let's at least make sure that some node using LLs is not disturbed when connecting to an adhoc node which is discouraged from using LLs; as the Charter requires. In this sense, it may be that we discourage the adhoc router from running OSPF/MLD/DHCP (see list posting); i.e. adhoc router and non adhoc aware router can't talk to each other using these protocols. I think we should write this down. Alex > > Ulrich From alexandru.petrescu@gmail.com Mon Oct 26 08:33: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 DB5383A6AB7 for ; Mon, 26 Oct 2009 08:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=0.099, 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 993zIBQSaj8a for ; Mon, 26 Oct 2009 08:33:27 -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 232F83A6AB3 for ; Mon, 26 Oct 2009 08:33:25 -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 n9QFXcO2029749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 26 Oct 2009 16:33:38 +0100 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 n9QFXcuL014132 for ; Mon, 26 Oct 2009 16:33:38 +0100 (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 n9QFXbZi001946 for ; Mon, 26 Oct 2009 16:33:38 +0100 Message-ID: <4AE5C151.6000800@gmail.com> Date: Mon, 26 Oct 2009 16:33:37 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "autoconf@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Autoconf] Protocols involving link-local addresses 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, 26 Oct 2009 15:33:29 -0000 In several earlier discussions question was raised about which protocols use link-local addresses. IPv4 ---- mDNS ARP (the parts in IPv4 LL RFC) IPv6 ---- DHCP OSPF RIPng MLD OLSR (a particular implementation) If you know any other, feel free to add. I think it may be useful to add to the AUTOCONF addressing model draft(s). (I think Teco may have already written such a list but I have hard time finding it). Alex From alexandru.petrescu@gmail.com Mon Oct 26 08:39: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 A94FE3A6A9A for ; Mon, 26 Oct 2009 08:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=0.097, 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 1PcpbxIw11mp for ; Mon, 26 Oct 2009 08:39:34 -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 874073A6A88 for ; Mon, 26 Oct 2009 08:39:34 -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 n9QFdjhn008136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 16:39:45 +0100 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 n9QFdjBY015859; Mon, 26 Oct 2009 16:39:45 +0100 (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 n9QFdidh030202; Mon, 26 Oct 2009 16:39:45 +0100 Message-ID: <4AE5C2C0.5090904@gmail.com> Date: Mon, 26 Oct 2009 16:39:44 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <20091019233002.15F4328C164@core3.amsl.com> <005801ca5618$38d35be0$aa7a13a0$@nl> <25c114b90910260219h52c74b4dha6871856afaaec23@mail.gmail.com> <00b601ca562b$0afa2ab0$20ee8010$@nl> <4AE5AE34.3090409@gmail.com> <4AE5B2BE.6040006@gmail.com> <25c114b90910260746i30d489fbm4a48c151c842ef25@mail.gmail.com> <4AE5BB45.7090303@gmail.com> <620DE5EE-C3B2-4162-AEE4-018F7AC1BF5C@thomasclausen.org> <4AE5BEA3.7010007@gmail.com> <55FAFA43-D8DE-4EAE-89C0-817CDE22F65B@thomasclausen.org> In-Reply-To: <55FAFA43-D8DE-4EAE-89C0-817CDE22F65B@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 15:39:35 -0000 Thomas Heide Clausen a écrit : > > On Oct 26, 2009, at 4:22 PM, Alexandru Petrescu wrote: > >> Thomas Heide Clausen a écrit : >>> On Oct 26, 2009, at 4:07 PM, Alexandru Petrescu wrote: >>>> Ulrich Herberg a écrit : >>>>> IMO, Alex is right here. Routers have to join multicast groups >>>>> (although there might be some exceptions like ff02::1). The RFC that >>>>> specifies MLDv2 is RFC3810. The Multicast listening state is stored >>>>> per socket as well as per interface. I did not find, however, a >>>>> restriction of scope for a multicast group based on the unicast >>>>> address of the interface. There is even an example in RFC4291 (the >>>>> mentioned Solicited-Node multicast address) which creates a >>>>> link-local multicast group out of a global unicast address: >>>>> "For example, the Solicited-Node multicast address corresponding to >>>>> the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C." >>>> >>>> Right, the solicited-node multicast group derived from the IID of an >>>> IPv6 global address - that is ok. It is a local derivation. It is ok. >>>> >>>> I meant this: when node A joins froun ff02::2 by putting its >>>> link-local address in the MLD src address: >>>>> An MLDv2 Report MUST be sent with a valid IPv6 link-local source >>>>> address, or the unspecified address (::), if the sending interface >>>>> has not acquired a valid link-local address yet. >>>> >>>> I think that if AUTOCONF discourages the link-local addresses then >>>> automatically MLD will use "::" (unspecified address) in its src. >>>> >>>> I don't think this is an MLD problem. >>>> >>>> I think these things are so much intertwinned that it's hard to >>>> simply discourage the use of link-local addresses. >>>> >>> So what you propose is, that LL addresses MUST be globally (or, at >>> least, MANET-wide) unique? I.e. that LL addresses MUST be verified >>> in a scope beyond 1 hop? >> >> Not really, I propose to use the LL addresses as they are originally >> planned to, and not to discourage them. >> > > Either: > > o you render the addresses useful in the MANET context; I agree on this point - render LL addresses useful for MANET contexts. Start with some OLSR implementations. > o or, you discourage their use. > > As they are, LL addresses are - for reasons that have been listed, > enumerated and discussed ad infinitum on this list and in [autoconf] in > general - not suitable for much in a MANET. I think that the two > addressing architecture Baccelli/Townsley and Carlos/Ronald (sorry guys, > your last names are too hard to type ;) ) I-Ds both make that clear. Well - one of them isn't discouraging the LL addresses. Alex From thomas@thomasclausen.org Mon Oct 26 08:40: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 E8FE63A6A03 for ; Mon, 26 Oct 2009 08:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 WyUwXpx6b3pI for ; Mon, 26 Oct 2009 08:40:58 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 8EB0E3A694A for ; Mon, 26 Oct 2009 08:40:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 5711F32317AF; Mon, 26 Oct 2009 08:41:12 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 042F332317AD; Mon, 26 Oct 2009 08:41:10 -0700 (PDT) Message-Id: <672EB726-45DC-4352-827E-D7AF6A3AF2D8@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE5C10E.1010208@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: Mon, 26 Oct 2009 16:41:08 +0100 References: <20091019233002.15F4328C164@core3.amsl.com> <00b601ca562b$0afa2ab0$20ee8010$@nl> <4AE5AE34.3090409@gmail.com> <4AE5B2BE.6040006@gmail.com> <25c114b90910260746i30d489fbm4a48c151c842ef25@mail.gmail.com> <4AE5BB45.7090303@gmail.com> <620DE5EE-C3B2-4162-AEE4-018F7AC1BF5C@thomasclausen.org> <4AE5BEA3.7010007@gmail.com> <25c114b90910260825n2702eed9kc4483ba73f214cdd@mail.gmail.com> <4AE5C10E.1010208@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 15:41:00 -0000 On Oct 26, 2009, at 4:32 PM, Alexandru Petrescu wrote: > Ulrich Herberg a =E9crit : >> On Mon, Oct 26, 2009 at 4:22 PM, Alexandru Petrescu = > > wrote: >> Thomas Heide Clausen a =E9crit : >> [...] >> So what you propose is, that LL addresses MUST be globally =20 >> (or, >> at least, MANET-wide) unique? I.e. that LL addresses MUST be >> verified in a scope beyond 1 hop? >> Not really, I propose to use the LL addresses as they are =20 >> originally >> planned to, and not to discourage them. >> Originally, they have been planned to wired networks, > > I doubt this. I will not tell the contrary to you. > > I think IPv6 LLs were designed at a time (1996?) when "Packet Radio" =20= > had already happened. I wasn't there, I can't say, but I feel that =20= > IPv6 LLs were there to work with the "future" Internet ("future" at =20= > that time) which planned for many small wireless devices moving =20 > around. > > This is speculation from my part - I wasn't there. > >> so with very different assumptions. So it is not possible to use =20 >> them as originally planned. If you want to use them as originally =20 >> planned, you have the whole lot of problems that are mentioned in =20 >> the DT draft. >> If you plan to use them, you have to assure exactly what Thomas =20 >> asked as a question. > > Well ok. > > Let's at least make sure that some node using LLs is not disturbed =20 > when connecting to an adhoc node which is discouraged from using =20 > LLs; as the Charter requires. > And, if you return to my message from this morning....as long as that =20= "node using LLs" connects as it should, it'll be working just fine. > In this sense, it may be that we discourage the adhoc router from =20 > running OSPF/MLD/DHCP (see list posting); i.e. adhoc router and non =20= > adhoc aware router can't talk to each other using these protocols. SighS....did you read my example from this morning? Thomas > I think we should write this down. > > Alex > > >> Ulrich > > From thomas@thomasclausen.org Mon Oct 26 08:44: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 8BFE93A6AB0 for ; Mon, 26 Oct 2009 08:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 1RHpwDHYZM1q for ; Mon, 26 Oct 2009 08:44:15 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 9A5893A694A for ; Mon, 26 Oct 2009 08:44:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 6BCB332317B4; Mon, 26 Oct 2009 08:44:29 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 1495E32317B6; Mon, 26 Oct 2009 08:44:27 -0700 (PDT) Message-Id: <055447F6-E2E2-4328-A5E0-40EE8A7DB163@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE5C2C0.5090904@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: Mon, 26 Oct 2009 16:44:25 +0100 References: <20091019233002.15F4328C164@core3.amsl.com> <005801ca5618$38d35be0$aa7a13a0$@nl> <25c114b90910260219h52c74b4dha6871856afaaec23@mail.gmail.com> <00b601ca562b$0afa2ab0$20ee8010$@nl> <4AE5AE34.3090409@gmail.com> <4AE5B2BE.6040006@gmail.com> <25c114b90910260746i30d489fbm4a48c151c842ef25@mail.gmail.com> <4AE5BB45.7090303@gmail.com> <620DE5EE-C3B2-4162-AEE4-018F7AC1BF5C@thomasclausen.org> <4AE5BEA3.7010007@gmail.com> <55FAFA43-D8DE-4EAE-89C0-817CDE22F65B@thomasclausen.org> <4AE5C2C0.5090904@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 15:44:16 -0000 On Oct 26, 2009, at 4:39 PM, Alexandru Petrescu wrote: > Thomas Heide Clausen a =E9crit : >> On Oct 26, 2009, at 4:22 PM, Alexandru Petrescu wrote: >>> Thomas Heide Clausen a =E9crit : >>>> On Oct 26, 2009, at 4:07 PM, Alexandru Petrescu wrote: >>>>> Ulrich Herberg a =E9crit : >>>>>> IMO, Alex is right here. Routers have to join multicast groups >>>>>> (although there might be some exceptions like ff02::1). The RFC =20= >>>>>> that >>>>>> specifies MLDv2 is RFC3810. The Multicast listening state is =20 >>>>>> stored >>>>>> per socket as well as per interface. I did not find, however, a >>>>>> restriction of scope for a multicast group based on the unicast >>>>>> address of the interface. There is even an example in RFC4291 =20 >>>>>> (the >>>>>> mentioned Solicited-Node multicast address) which creates a >>>>>> link-local multicast group out of a global unicast address: >>>>>> "For example, the Solicited-Node multicast address =20 >>>>>> corresponding to >>>>>> the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C." >>>>> >>>>> Right, the solicited-node multicast group derived from the IID =20 >>>>> of an IPv6 global address - that is ok. It is a local =20 >>>>> derivation. It is ok. >>>>> >>>>> I meant this: when node A joins froun ff02::2 by putting its =20 >>>>> link-local address in the MLD src address: >>>>>> An MLDv2 Report MUST be sent with a valid IPv6 link-local source >>>>>> address, or the unspecified address (::), if the sending =20 >>>>>> interface >>>>>> has not acquired a valid link-local address yet. >>>>> >>>>> I think that if AUTOCONF discourages the link-local addresses =20 >>>>> then automatically MLD will use "::" (unspecified address) in =20 >>>>> its src. >>>>> >>>>> I don't think this is an MLD problem. >>>>> >>>>> I think these things are so much intertwinned that it's hard to =20= >>>>> simply discourage the use of link-local addresses. >>>>> >>>> So what you propose is, that LL addresses MUST be globally (or, =20 >>>> at least, MANET-wide) unique? I.e. that LL addresses MUST be =20 >>>> verified in a scope beyond 1 hop? >>> >>> Not really, I propose to use the LL addresses as they are =20 >>> originally planned to, and not to discourage them. >>> >> Either: >> o you render the addresses useful in the MANET context; > > I agree on this point - render LL addresses useful for MANET =20 > contexts. Start with some OLSR implementations. Fine, provide me with MANET-wide unique LL addresses, i.e. verify =20 uniqueness across the entire MANET (i.e. beyond 1 hop). But you didn't =20= want that.... > >> o or, you discourage their use. >> As they are, LL addresses are - for reasons that have been listed, =20= >> enumerated and discussed ad infinitum on this list and in =20 >> [autoconf] in general - not suitable for much in a MANET. I think =20 >> that the two addressing architecture Baccelli/Townsley and Carlos/=20 >> Ronald (sorry guys, your last names are too hard to type ;) ) I-Ds =20= >> both make that clear. > > Well - one of them isn't discouraging the LL addresses. One of them says "discourage" the other says "Two main concerns may =20 arise....Having brought to attention these concerns, it is further =20 left to the designers of MANET routing protocols (and other protocols) =20= to determine whether link-local addresses can be used in an effective =20= way." Same difference.....except that one is taking a honest look at what is =20= currently *operational*..... Thomas > > Alex > > From alexandru.petrescu@gmail.com Mon Oct 26 08:46: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 2E94028C17A for ; Mon, 26 Oct 2009 08:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.096, 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 AAqqkkdeVsfB for ; Mon, 26 Oct 2009 08:46:36 -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 1FBCC28C124 for ; Mon, 26 Oct 2009 08:46:35 -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 n9QFklZQ014473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 16:46:47 +0100 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 n9QFklAg017600; Mon, 26 Oct 2009 16:46:47 +0100 (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 n9QFkkDO006331; Mon, 26 Oct 2009 16:46:47 +0100 Message-ID: <4AE5C466.5090501@gmail.com> Date: Mon, 26 Oct 2009 16:46:46 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <20091019233002.15F4328C164@core3.amsl.com> <00b601ca562b$0afa2ab0$20ee8010$@nl> <4AE5AE34.3090409@gmail.com> <4AE5B2BE.6040006@gmail.com> <25c114b90910260746i30d489fbm4a48c151c842ef25@mail.gmail.com> <4AE5BB45.7090303@gmail.com> <620DE5EE-C3B2-4162-AEE4-018F7AC1BF5C@thomasclausen.org> <4AE5BEA3.7010007@gmail.com> <25c114b90910260825n2702eed9kc4483ba73f214cdd@mail.gmail.com> <4AE5C10E.1010208@gmail.com> <672EB726-45DC-4352-827E-D7AF6A3AF2D8@thomasclausen.org> In-Reply-To: <672EB726-45DC-4352-827E-D7AF6A3AF2D8@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 15:46:37 -0000 Thomas Heide Clausen a écrit : > > On Oct 26, 2009, at 4:32 PM, Alexandru Petrescu wrote: > >> Ulrich Herberg a écrit : >>> On Mon, Oct 26, 2009 at 4:22 PM, Alexandru Petrescu >>> > >>> wrote: >>> Thomas Heide Clausen a écrit : >>> [...] >>> So what you propose is, that LL addresses MUST be globally (or, >>> at least, MANET-wide) unique? I.e. that LL addresses MUST be >>> verified in a scope beyond 1 hop? >>> Not really, I propose to use the LL addresses as they are originally >>> planned to, and not to discourage them. >>> Originally, they have been planned to wired networks, >> >> I doubt this. I will not tell the contrary to you. >> >> I think IPv6 LLs were designed at a time (1996?) when "Packet Radio" >> had already happened. I wasn't there, I can't say, but I feel that >> IPv6 LLs were there to work with the "future" Internet ("future" at >> that time) which planned for many small wireless devices moving around. >> >> This is speculation from my part - I wasn't there. >> >>> so with very different assumptions. So it is not possible to use them >>> as originally planned. If you want to use them as originally planned, >>> you have the whole lot of problems that are mentioned in the DT draft. >>> If you plan to use them, you have to assure exactly what Thomas asked >>> as a question. >> >> Well ok. >> >> Let's at least make sure that some node using LLs is not disturbed >> when connecting to an adhoc node which is discouraged from using LLs; >> as the Charter requires. >> > > And, if you return to my message from this morning....as long as that > "node using LLs" connects as it should, it'll be working just fine. What do you mean by "as it should"? Is it by _not_ using its LL address? It is very hard to impose a non-MANET node to not use its LL address, when it has one. Or do you still allow the non-MANET node to use its LL address when connecting to a MANET node? >> In this sense, it may be that we discourage the adhoc router from >> running OSPF/MLD/DHCP (see list posting); i.e. adhoc router and non >> adhoc aware router can't talk to each other using these protocols. > > SighS....did you read my example from this morning? The OSPF example? I said that a non-OSPF router connecting to an OSPF router is not disturbed by the latter's HELLOs because both use the same addressing mechanisms (multicast groups and joins). Did you read my reply? :-) Alex > > Thomas > >> I think we should write this down. > >> >> Alex >> >> >>> Ulrich >> >> > > From alexandru.petrescu@gmail.com Mon Oct 26 08:50: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 B81BD3A6933 for ; Mon, 26 Oct 2009 08:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.094, 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 pnGB+WIiIyqY for ; Mon, 26 Oct 2009 08:50: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 F016A28C2C6 for ; Mon, 26 Oct 2009 08:50:09 -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 n9QFoIWI014151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 16:50:18 +0100 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 n9QFoHll018447; Mon, 26 Oct 2009 16:50:18 +0100 (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 n9QFoH0O001367; Mon, 26 Oct 2009 16:50:17 +0100 Message-ID: <4AE5C539.3020803@gmail.com> Date: Mon, 26 Oct 2009 16:50:17 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <20091019233002.15F4328C164@core3.amsl.com> <005801ca5618$38d35be0$aa7a13a0$@nl> <25c114b90910260219h52c74b4dha6871856afaaec23@mail.gmail.com> <00b601ca562b$0afa2ab0$20ee8010$@nl> <4AE5AE34.3090409@gmail.com> <4AE5B2BE.6040006@gmail.com> <25c114b90910260746i30d489fbm4a48c151c842ef25@mail.gmail.com> <4AE5BB45.7090303@gmail.com> <620DE5EE-C3B2-4162-AEE4-018F7AC1BF5C@thomasclausen.org> <4AE5BEA3.7010007@gmail.com> <55FAFA43-D8DE-4EAE-89C0-817CDE22F65B@thomasclausen.org> <4AE5C2C0.5090904@gmail.com> <055447F6-E2E2-4328-A5E0-40EE8A7DB163@thomasclausen.org> In-Reply-To: <055447F6-E2E2-4328-A5E0-40EE8A7DB163@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 15:50:58 -0000 Thomas Heide Clausen a écrit : > > On Oct 26, 2009, at 4:39 PM, Alexandru Petrescu wrote: > >> Thomas Heide Clausen a écrit : >>> On Oct 26, 2009, at 4:22 PM, Alexandru Petrescu wrote: >>>> Thomas Heide Clausen a écrit : >>>>> On Oct 26, 2009, at 4:07 PM, Alexandru Petrescu wrote: >>>>>> Ulrich Herberg a écrit : >>>>>>> IMO, Alex is right here. Routers have to join multicast groups >>>>>>> (although there might be some exceptions like ff02::1). The RFC that >>>>>>> specifies MLDv2 is RFC3810. The Multicast listening state is stored >>>>>>> per socket as well as per interface. I did not find, however, a >>>>>>> restriction of scope for a multicast group based on the unicast >>>>>>> address of the interface. There is even an example in RFC4291 (the >>>>>>> mentioned Solicited-Node multicast address) which creates a >>>>>>> link-local multicast group out of a global unicast address: >>>>>>> "For example, the Solicited-Node multicast address corresponding to >>>>>>> the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C." >>>>>> >>>>>> Right, the solicited-node multicast group derived from the IID of >>>>>> an IPv6 global address - that is ok. It is a local derivation. >>>>>> It is ok. >>>>>> >>>>>> I meant this: when node A joins froun ff02::2 by putting its >>>>>> link-local address in the MLD src address: >>>>>>> An MLDv2 Report MUST be sent with a valid IPv6 link-local source >>>>>>> address, or the unspecified address (::), if the sending interface >>>>>>> has not acquired a valid link-local address yet. >>>>>> >>>>>> I think that if AUTOCONF discourages the link-local addresses then >>>>>> automatically MLD will use "::" (unspecified address) in its src. >>>>>> >>>>>> I don't think this is an MLD problem. >>>>>> >>>>>> I think these things are so much intertwinned that it's hard to >>>>>> simply discourage the use of link-local addresses. >>>>>> >>>>> So what you propose is, that LL addresses MUST be globally (or, at >>>>> least, MANET-wide) unique? I.e. that LL addresses MUST be verified >>>>> in a scope beyond 1 hop? >>>> >>>> Not really, I propose to use the LL addresses as they are originally >>>> planned to, and not to discourage them. >>>> >>> Either: >>> o you render the addresses useful in the MANET context; >> >> I agree on this point - render LL addresses useful for MANET contexts. >> Start with some OLSR implementations. > > Fine, provide me with MANET-wide unique LL addresses, i.e. verify > uniqueness across the entire MANET (i.e. beyond 1 hop). But you didn't > want that.... Right, that is not needed. LL addresses should stay unique within their scope and packets with src or dst an LL address should not be forwarded beyond 1 hop. If LLs act this way - is it enough for you to not discourage their use? >>> o or, you discourage their use. >>> As they are, LL addresses are - for reasons that have been listed, >>> enumerated and discussed ad infinitum on this list and in [autoconf] >>> in general - not suitable for much in a MANET. I think that the two >>> addressing architecture Baccelli/Townsley and Carlos/Ronald (sorry >>> guys, your last names are too hard to type ;) ) I-Ds both make that >>> clear. >> >> Well - one of them isn't discouraging the LL addresses. > > One of them says "discourage" the other says "Two main concerns may > arise....Having brought to attention these concerns, it is further left > to the designers of MANET routing protocols (and other protocols) to > determine whether link-local addresses can be used in an effective way." > > Same difference.....except that one is taking a honest look at what is > currently *operational*..... So change the order: put the "discourage LL" part at the end, as an optional aspect. Put the concerns in a list of advantages and disadvantages of LLs: LL advantages: X, Y and Z. LL disadvantages: concern A-B-C. Alex > > Thomas > >> >> Alex >> >> > > From thomas@thomasclausen.org Mon Oct 26 08:52: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 3090E3A68DD for ; Mon, 26 Oct 2009 08:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 pEaAvQ4Z4rky for ; Mon, 26 Oct 2009 08:52:48 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 58DE33A6877 for ; Mon, 26 Oct 2009 08:52:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 21F3532317B3; Mon, 26 Oct 2009 08:53:02 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id C02E032317AE; Mon, 26 Oct 2009 08:53:00 -0700 (PDT) Message-Id: <7534DC17-087E-4F04-B6A5-6C0CE1094F7B@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE5C466.5090501@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: Mon, 26 Oct 2009 16:52:57 +0100 References: <20091019233002.15F4328C164@core3.amsl.com> <00b601ca562b$0afa2ab0$20ee8010$@nl> <4AE5AE34.3090409@gmail.com> <4AE5B2BE.6040006@gmail.com> <25c114b90910260746i30d489fbm4a48c151c842ef25@mail.gmail.com> <4AE5BB45.7090303@gmail.com> <620DE5EE-C3B2-4162-AEE4-018F7AC1BF5C@thomasclausen.org> <4AE5BEA3.7010007@gmail.com> <25c114b90910260825n2702eed9kc4483ba73f214cdd@mail.gmail.com> <4AE5C10E.1010208@gmail.com> <672EB726-45DC-4352-827E-D7AF6A3AF2D8@thomasclausen.org> <4AE5C466.5090501@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 15:52:49 -0000 On Oct 26, 2009, at 4:46 PM, Alexandru Petrescu wrote: > Thomas Heide Clausen a =E9crit : >> On Oct 26, 2009, at 4:32 PM, Alexandru Petrescu wrote: >>> Ulrich Herberg a =E9crit : >>>> On Mon, Oct 26, 2009 at 4:22 PM, Alexandru Petrescu = >>> > wrote: >>>> Thomas Heide Clausen a =E9crit : >>>> [...] >>>> So what you propose is, that LL addresses MUST be globally =20= >>>> (or, >>>> at least, MANET-wide) unique? I.e. that LL addresses MUST be >>>> verified in a scope beyond 1 hop? >>>> Not really, I propose to use the LL addresses as they are =20 >>>> originally >>>> planned to, and not to discourage them. >>>> Originally, they have been planned to wired networks, >>> >>> I doubt this. I will not tell the contrary to you. >>> >>> I think IPv6 LLs were designed at a time (1996?) when "Packet =20 >>> Radio" had already happened. I wasn't there, I can't say, but I =20 >>> feel that IPv6 LLs were there to work with the "future" Internet =20 >>> ("future" at that time) which planned for many small wireless =20 >>> devices moving around. >>> >>> This is speculation from my part - I wasn't there. >>> >>>> so with very different assumptions. So it is not possible to use =20= >>>> them as originally planned. If you want to use them as originally =20= >>>> planned, you have the whole lot of problems that are mentioned in =20= >>>> the DT draft. >>>> If you plan to use them, you have to assure exactly what Thomas =20 >>>> asked as a question. >>> >>> Well ok. >>> >>> Let's at least make sure that some node using LLs is not disturbed =20= >>> when connecting to an adhoc node which is discouraged from using =20 >>> LLs; as the Charter requires. >>> >> And, if you return to my message from this morning....as long as =20 >> that "node using LLs" connects as it should, it'll be working just =20= >> fine. > > What do you mean by "as it should"? Is it by _not_ using its LL =20 > address? It is very hard to impose a non-MANET node to not use its =20= > LL address, when it has one. > > Or do you still allow the non-MANET node to use its LL address when =20= > connecting to a MANET node? Of course. Do you still allow a non-OSPFv3 node to connect to an =20 OSPFv3 router? >>> In this sense, it may be that we discourage the adhoc router from =20= >>> running OSPF/MLD/DHCP (see list posting); i.e. adhoc router and =20 >>> non adhoc aware router can't talk to each other using these =20 >>> protocols. >> SighS....did you read my example from this morning? > > The OSPF example? I said that a non-OSPF router connecting to an =20 > OSPF router is not disturbed by the latter's HELLOs because both use =20= > the same addressing mechanisms (multicast groups and joins). > No, that was not the one. > Did you read my reply? :-) I saw a message from you, yes. I even read it. But it didn't address =20 the issue we're discussing. Thomas > Alex > >> Thomas >>> I think we should write this down. >>> >>> Alex >>> >>> >>>> Ulrich >>> >>> > > From alexandru.petrescu@gmail.com Mon Oct 26 08:56:34 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 91F1A3A685D for ; Mon, 26 Oct 2009 08:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[AWL=-0.553, BAYES_00=-2.599, HELO_EQ_FR=0.35, MISSING_HEADERS=1.292] 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 0oqPsskXbbOG for ; Mon, 26 Oct 2009 08:56:33 -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 94EF63A683E for ; Mon, 26 Oct 2009 08:56:33 -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 n9QFujWB018261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 26 Oct 2009 16:56:46 +0100 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 n9QFujJi020116 for ; Mon, 26 Oct 2009 16:56:45 +0100 (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 n9QFujH2009557 for ; Mon, 26 Oct 2009 16:56:45 +0100 Message-ID: <4AE5C6BD.2030501@gmail.com> Date: Mon, 26 Oct 2009 16:56:45 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 CC: "autoconf@ietf.org" References: <4AE5C151.6000800@gmail.com> In-Reply-To: <4AE5C151.6000800@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Autoconf] Protocols involving link-local addresses 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, 26 Oct 2009 15:56:34 -0000 Updated list: added PPP IPv6, ND, ICMPv6, MIPv6 family. IPv4 ---- mDNS ARP (the parts in IPv4 LL RFC) IPv6 ---- DHCP OSPF RIPng MLD OLSR (a particular implementation) ND PPP IPv6 ICMPv6 SLAAC FMIPv6 MIPv6/NEMOv6/PMIPv6 Alex Alexandru Petrescu a écrit : > In several earlier discussions question was raised about which protocols > use link-local addresses. > > IPv4 > ---- > mDNS > ARP (the parts in IPv4 LL RFC) > > IPv6 > ---- > DHCP > OSPF > RIPng > MLD > OLSR (a particular implementation) > > If you know any other, feel free to add. I think it may be useful to > add to the AUTOCONF addressing model draft(s). > > (I think Teco may have already written such a list but I have hard time > finding it). > > Alex > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From thomas@thomasclausen.org Mon Oct 26 09:04:10 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 1B91828C2FB for ; Mon, 26 Oct 2009 09:04:10 -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 fX-lci5mIrKH for ; Mon, 26 Oct 2009 09:04:09 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 44AA228C2EE for ; Mon, 26 Oct 2009 09:04:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 1981432317AF; Mon, 26 Oct 2009 09:04:23 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 62B9532317AD; Mon, 26 Oct 2009 09:04:22 -0700 (PDT) Message-Id: From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE5C6BD.2030501@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: Mon, 26 Oct 2009 17:04:20 +0100 References: <4AE5C151.6000800@gmail.com> <4AE5C6BD.2030501@gmail.com> X-Mailer: Apple Mail (2.936) Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Protocols involving link-local addresses 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, 26 Oct 2009 16:04:10 -0000 That's great and these all run fine across a MANET. That's the beauty =20= of end-to-end, you see, as long as the routers present "just an IP =20 hop", then applications on end systems are happy. Thomas On Oct 26, 2009, at 4:56 PM, Alexandru Petrescu wrote: > Updated list: added PPP IPv6, ND, ICMPv6, MIPv6 family. > > IPv4 > ---- > mDNS > ARP (the parts in IPv4 LL RFC) > > IPv6 > ---- > DHCP > OSPF > RIPng > MLD > OLSR (a particular implementation) > ND > PPP IPv6 > ICMPv6 > SLAAC > FMIPv6 > MIPv6/NEMOv6/PMIPv6 > > Alex > > Alexandru Petrescu a =E9crit : >> In several earlier discussions question was raised about which =20 >> protocols use link-local addresses. >> IPv4 >> ---- >> mDNS >> ARP (the parts in IPv4 LL RFC) >> IPv6 >> ---- >> DHCP >> OSPF >> RIPng >> MLD >> OLSR (a particular implementation) >> If you know any other, feel free to add. I think it may be useful =20= >> to add to the AUTOCONF addressing model draft(s). >> (I think Teco may have already written such a list but I have hard =20= >> time >> finding it). >> Alex >> _______________________________________________ >> 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 alexandru.petrescu@gmail.com Mon Oct 26 09:05:20 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 F34333A68DD for ; Mon, 26 Oct 2009 09:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=0.101, 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 hHWekrdA12FR for ; Mon, 26 Oct 2009 09:05:19 -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 9167E28C17A for ; Mon, 26 Oct 2009 09:05:03 -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 n9QG5Eiw027352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 17:05:14 +0100 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 n9QG5DWH022249; Mon, 26 Oct 2009 17:05:13 +0100 (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 n9QG5DiJ012516; Mon, 26 Oct 2009 17:05:13 +0100 Message-ID: <4AE5C8B9.7060505@gmail.com> Date: Mon, 26 Oct 2009 17:05:13 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <20091019233002.15F4328C164@core3.amsl.com> <00b601ca562b$0afa2ab0$20ee8010$@nl> <4AE5AE34.3090409@gmail.com> <4AE5B2BE.6040006@gmail.com> <25c114b90910260746i30d489fbm4a48c151c842ef25@mail.gmail.com> <4AE5BB45.7090303@gmail.com> <620DE5EE-C3B2-4162-AEE4-018F7AC1BF5C@thomasclausen.org> <4AE5BEA3.7010007@gmail.com> <25c114b90910260825n2702eed9kc4483ba73f214cdd@mail.gmail.com> <4AE5C10E.1010208@gmail.com> <672EB726-45DC-4352-827E-D7AF6A3AF2D8@thomasclausen.org> <4AE5C466.5090501@gmail.com> <7534DC17-087E-4F04-B6A5-6C0CE1094F7B@thomasclausen.org> In-Reply-To: <7534DC17-087E-4F04-B6A5-6C0CE1094F7B@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 16:05:20 -0000 Thomas Heide Clausen a écrit : > > On Oct 26, 2009, at 4:46 PM, Alexandru Petrescu wrote: > >> Thomas Heide Clausen a écrit : >>> On Oct 26, 2009, at 4:32 PM, Alexandru Petrescu wrote: >>>> Ulrich Herberg a écrit : >>>>> On Mon, Oct 26, 2009 at 4:22 PM, Alexandru Petrescu >>>>> > >>>>> wrote: >>>>> Thomas Heide Clausen a écrit : >>>>> [...] >>>>> So what you propose is, that LL addresses MUST be globally (or, >>>>> at least, MANET-wide) unique? I.e. that LL addresses MUST be >>>>> verified in a scope beyond 1 hop? >>>>> Not really, I propose to use the LL addresses as they are originally >>>>> planned to, and not to discourage them. >>>>> Originally, they have been planned to wired networks, >>>> >>>> I doubt this. I will not tell the contrary to you. >>>> >>>> I think IPv6 LLs were designed at a time (1996?) when "Packet Radio" >>>> had already happened. I wasn't there, I can't say, but I feel that >>>> IPv6 LLs were there to work with the "future" Internet ("future" at >>>> that time) which planned for many small wireless devices moving around. >>>> >>>> This is speculation from my part - I wasn't there. >>>> >>>>> so with very different assumptions. So it is not possible to use >>>>> them as originally planned. If you want to use them as originally >>>>> planned, you have the whole lot of problems that are mentioned in >>>>> the DT draft. >>>>> If you plan to use them, you have to assure exactly what Thomas >>>>> asked as a question. >>>> >>>> Well ok. >>>> >>>> Let's at least make sure that some node using LLs is not disturbed >>>> when connecting to an adhoc node which is discouraged from using >>>> LLs; as the Charter requires. >>>> >>> And, if you return to my message from this morning....as long as that >>> "node using LLs" connects as it should, it'll be working just fine. >> >> What do you mean by "as it should"? Is it by _not_ using its LL >> address? It is very hard to impose a non-MANET node to not use its LL >> address, when it has one. >> >> Or do you still allow the non-MANET node to use its LL address when >> connecting to a MANET node? > > Of course. Do you still allow a non-OSPFv3 node to connect to an OSPFv3 > router? Ok, in this case, I think the disturbing aspect is when you say "in this context, discourage LLs", because it is not clear that context==MANET. An idea is to reformulate and say: "Non-MANET nodes connecting to MANET nodes are free to use their LLs as specified in RFCs like "IPv6 addressing architecture". The behaviour of MANET nodes will not cause problems to any non-MANET node running protocols using LLs, see list of these protocols in Appendix A. Also see list of potential problems caused by MANET nodes not using LLs, connected to non-MANET nodes using LLs, in Appendix B. MANET nodes are discouraged from using LLs, because concerns X and Y, see Appendix C." Does this sound ok? I can write the Appendices A and B. >>>> In this sense, it may be that we discourage the adhoc router from >>>> running OSPF/MLD/DHCP (see list posting); i.e. adhoc router and non >>>> adhoc aware router can't talk to each other using these protocols. >>> SighS....did you read my example from this morning? >> >> The OSPF example? I said that a non-OSPF router connecting to an OSPF >> router is not disturbed by the latter's HELLOs because both use the >> same addressing mechanisms (multicast groups and joins). >> > > No, that was not the one. > >> Did you read my reply? :-) > > I saw a message from you, yes. I even read it. But it didn't address the > issue we're discussing. Re-post then. Alex > > Thomas > > >> Alex >> >>> Thomas >>>> I think we should write this down. >>>> >>>> Alex >>>> >>>> >>>>> Ulrich >>>> >>>> >> >> > > From alexandru.petrescu@gmail.com Mon Oct 26 09:09:38 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 487CE3A685D for ; Mon, 26 Oct 2009 09:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.100, 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 FXU21+8B65n5 for ; Mon, 26 Oct 2009 09:09:37 -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 3885A3A6767 for ; Mon, 26 Oct 2009 09:09:37 -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 n9QG9mEK008585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 17:09:48 +0100 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 n9QG9mJh023134; Mon, 26 Oct 2009 17:09:48 +0100 (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 n9QG9lVL013773; Mon, 26 Oct 2009 17:09:47 +0100 Message-ID: <4AE5C9CB.5030807@gmail.com> Date: Mon, 26 Oct 2009 17:09:47 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <4AE5C151.6000800@gmail.com> <4AE5C6BD.2030501@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] Protocols involving link-local addresses 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, 26 Oct 2009 16:09:38 -0000 Thomas Heide Clausen a écrit : > That's great and these all run fine across a MANET. That's the beauty of > end-to-end, you see, as long as the routers present "just an IP hop", > then applications on end systems are happy. I don't understand you. Please add a protocol to my list; that is the goal of the list. Presenting "just an IP" hop is like routers acting at L2. Is this some sort of a layer violation? Alex > > Thomas > > On Oct 26, 2009, at 4:56 PM, Alexandru Petrescu wrote: > >> Updated list: added PPP IPv6, ND, ICMPv6, MIPv6 family. >> >> IPv4 >> ---- >> mDNS >> ARP (the parts in IPv4 LL RFC) >> >> IPv6 >> ---- >> DHCP >> OSPF >> RIPng >> MLD >> OLSR (a particular implementation) >> ND >> PPP IPv6 >> ICMPv6 >> SLAAC >> FMIPv6 >> MIPv6/NEMOv6/PMIPv6 >> >> Alex >> >> Alexandru Petrescu a écrit : >>> In several earlier discussions question was raised about which >>> protocols use link-local addresses. >>> IPv4 >>> ---- >>> mDNS >>> ARP (the parts in IPv4 LL RFC) >>> IPv6 >>> ---- >>> DHCP >>> OSPF >>> RIPng >>> MLD >>> OLSR (a particular implementation) >>> If you know any other, feel free to add. I think it may be useful to >>> add to the AUTOCONF addressing model draft(s). >>> (I think Teco may have already written such a list but I have hard time >>> finding it). >>> Alex >>> _______________________________________________ >>> 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 thomas@thomasclausen.org Mon Oct 26 09:10: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 0AA113A685D for ; Mon, 26 Oct 2009 09:10:13 -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 udi6ZwRKOmrc for ; Mon, 26 Oct 2009 09:10:12 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 2D0F43A6A79 for ; Mon, 26 Oct 2009 09:10:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id F24B432317AD; Mon, 26 Oct 2009 09:10:25 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 0F684322806E; Mon, 26 Oct 2009 09:10:24 -0700 (PDT) Message-Id: From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE5C9CB.5030807@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: Mon, 26 Oct 2009 17:10:22 +0100 References: <4AE5C151.6000800@gmail.com> <4AE5C6BD.2030501@gmail.com> <4AE5C9CB.5030807@gmail.com> X-Mailer: Apple Mail (2.936) Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Protocols involving link-local addresses 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, 26 Oct 2009 16:10:13 -0000 On Oct 26, 2009, at 5:09 PM, Alexandru Petrescu wrote: > Thomas Heide Clausen a =E9crit : >> That's great and these all run fine across a MANET. That's the =20 >> beauty of end-to-end, you see, as long as the routers present "just =20= >> an IP hop", then applications on end systems are happy. > > I don't understand you. Please add a protocol to my list; that is =20 > the goal of the list. > > Presenting "just an IP" hop is like routers acting at L2. Is this =20 > some sort of a layer violation? > No, it's actually exactly what a router is supposed to do. Thomas > Alex > >> Thomas >> On Oct 26, 2009, at 4:56 PM, Alexandru Petrescu wrote: >>> Updated list: added PPP IPv6, ND, ICMPv6, MIPv6 family. >>> >>> IPv4 >>> ---- >>> mDNS >>> ARP (the parts in IPv4 LL RFC) >>> >>> IPv6 >>> ---- >>> DHCP >>> OSPF >>> RIPng >>> MLD >>> OLSR (a particular implementation) >>> ND >>> PPP IPv6 >>> ICMPv6 >>> SLAAC >>> FMIPv6 >>> MIPv6/NEMOv6/PMIPv6 >>> >>> Alex >>> >>> Alexandru Petrescu a =E9crit : >>>> In several earlier discussions question was raised about which =20 >>>> protocols use link-local addresses. >>>> IPv4 >>>> ---- >>>> mDNS >>>> ARP (the parts in IPv4 LL RFC) >>>> IPv6 >>>> ---- >>>> DHCP >>>> OSPF >>>> RIPng >>>> MLD >>>> OLSR (a particular implementation) >>>> If you know any other, feel free to add. I think it may be =20 >>>> useful to add to the AUTOCONF addressing model draft(s). >>>> (I think Teco may have already written such a list but I have =20 >>>> hard time >>>> finding it). >>>> Alex >>>> _______________________________________________ >>>> 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 thomas@thomasclausen.org Mon Oct 26 09:12: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 3121628C2D0 for ; Mon, 26 Oct 2009 09:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 JoTjGsY-45Nb for ; Mon, 26 Oct 2009 09:12:29 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 4052F28C2C1 for ; Mon, 26 Oct 2009 09:12:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 16A0532317AE; Mon, 26 Oct 2009 09:12:43 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 0EE09322806E; Mon, 26 Oct 2009 09:12:41 -0700 (PDT) Message-Id: <5A0019AD-0BB0-4EAF-969E-73E3F1DAF1DE@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE5C9CB.5030807@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: Mon, 26 Oct 2009 17:12:39 +0100 References: <4AE5C151.6000800@gmail.com> <4AE5C6BD.2030501@gmail.com> <4AE5C9CB.5030807@gmail.com> X-Mailer: Apple Mail (2.936) Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Protocols involving link-local addresses 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, 26 Oct 2009 16:12:30 -0000 On Oct 26, 2009, at 5:09 PM, Alexandru Petrescu wrote: > Thomas Heide Clausen a =E9crit : >> That's great and these all run fine across a MANET. That's the =20 >> beauty of end-to-end, you see, as long as the routers present "just =20= >> an IP hop", then applications on end systems are happy. > > I don't understand you. Please add a protocol to my list; that is =20 > the goal of the list. > Ok, I'll try: http I am not sure I understand the game, shall it just be any odd protocol =20= that works fine across a MANET? Then, it'll be a long list ;) Thomas > Presenting "just an IP" hop is like routers acting at L2. Is this =20 > some sort of a layer violation? > > Alex > >> Thomas >> On Oct 26, 2009, at 4:56 PM, Alexandru Petrescu wrote: >>> Updated list: added PPP IPv6, ND, ICMPv6, MIPv6 family. >>> >>> IPv4 >>> ---- >>> mDNS >>> ARP (the parts in IPv4 LL RFC) >>> >>> IPv6 >>> ---- >>> DHCP >>> OSPF >>> RIPng >>> MLD >>> OLSR (a particular implementation) >>> ND >>> PPP IPv6 >>> ICMPv6 >>> SLAAC >>> FMIPv6 >>> MIPv6/NEMOv6/PMIPv6 >>> >>> Alex >>> >>> Alexandru Petrescu a =E9crit : >>>> In several earlier discussions question was raised about which =20 >>>> protocols use link-local addresses. >>>> IPv4 >>>> ---- >>>> mDNS >>>> ARP (the parts in IPv4 LL RFC) >>>> IPv6 >>>> ---- >>>> DHCP >>>> OSPF >>>> RIPng >>>> MLD >>>> OLSR (a particular implementation) >>>> If you know any other, feel free to add. I think it may be =20 >>>> useful to add to the AUTOCONF addressing model draft(s). >>>> (I think Teco may have already written such a list but I have =20 >>>> hard time >>>> finding it). >>>> Alex >>>> _______________________________________________ >>>> 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 alexandru.petrescu@gmail.com Mon Oct 26 09:19: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 EB0EA3A685D for ; Mon, 26 Oct 2009 09:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=0.098, 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 LcWNquaAMHUY for ; Mon, 26 Oct 2009 09:19:39 -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 C87393A67F8 for ; Mon, 26 Oct 2009 09:19:38 -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 n9QGJmLP019905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 17:19:48 +0100 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 n9QGJlJS025322; Mon, 26 Oct 2009 17:19:47 +0100 (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 n9QGJlbL016922; Mon, 26 Oct 2009 17:19:47 +0100 Message-ID: <4AE5CC23.1090105@gmail.com> Date: Mon, 26 Oct 2009 17:19:47 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <4AE5C151.6000800@gmail.com> <4AE5C6BD.2030501@gmail.com> <4AE5C9CB.5030807@gmail.com> <5A0019AD-0BB0-4EAF-969E-73E3F1DAF1DE@thomasclausen.org> In-Reply-To: <5A0019AD-0BB0-4EAF-969E-73E3F1DAF1DE@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Protocols involving link-local addresses 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, 26 Oct 2009 16:19:40 -0000 Thomas Heide Clausen a écrit : > > On Oct 26, 2009, at 5:09 PM, Alexandru Petrescu wrote: > >> Thomas Heide Clausen a écrit : >>> That's great and these all run fine across a MANET. That's the beauty >>> of end-to-end, you see, as long as the routers present "just an IP >>> hop", then applications on end systems are happy. >> >> I don't understand you. Please add a protocol to my list; that is the >> goal of the list. >> > > Ok, I'll try: > > http Well thanks, let me just make sure: does http use link-local addresses? Some times? IPv6 LL? IPv4 LL? > I am not sure I understand the game, shall it just be any odd protocol > that works fine across a MANET? Then, it'll be a long list ;) Protocols working fine across MANET and using link-local addresses? Er? So why do you discourage the LLs then? My goal is not a game, is to build a list by AUTOCONF members of protocols using IPv6 link-local addresses which risk be affected if the recommendation is to discourage LLs. Alex > > Thomas > >> Presenting "just an IP" hop is like routers acting at L2. Is this >> some sort of a layer violation? >> >> Alex >> >>> Thomas >>> On Oct 26, 2009, at 4:56 PM, Alexandru Petrescu wrote: >>>> Updated list: added PPP IPv6, ND, ICMPv6, MIPv6 family. >>>> >>>> IPv4 >>>> ---- >>>> mDNS >>>> ARP (the parts in IPv4 LL RFC) >>>> >>>> IPv6 >>>> ---- >>>> DHCP >>>> OSPF >>>> RIPng >>>> MLD >>>> OLSR (a particular implementation) >>>> ND >>>> PPP IPv6 >>>> ICMPv6 >>>> SLAAC >>>> FMIPv6 >>>> MIPv6/NEMOv6/PMIPv6 >>>> >>>> Alex >>>> >>>> Alexandru Petrescu a écrit : >>>>> In several earlier discussions question was raised about which >>>>> protocols use link-local addresses. >>>>> IPv4 >>>>> ---- >>>>> mDNS >>>>> ARP (the parts in IPv4 LL RFC) >>>>> IPv6 >>>>> ---- >>>>> DHCP >>>>> OSPF >>>>> RIPng >>>>> MLD >>>>> OLSR (a particular implementation) >>>>> If you know any other, feel free to add. I think it may be useful >>>>> to add to the AUTOCONF addressing model draft(s). >>>>> (I think Teco may have already written such a list but I have hard >>>>> time >>>>> finding it). >>>>> Alex >>>>> _______________________________________________ >>>>> 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 alexandru.petrescu@gmail.com Mon Oct 26 09:23: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 42EF03A6A03 for ; Mon, 26 Oct 2009 09:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=0.097, 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 ms0pH85kYhQF for ; Mon, 26 Oct 2009 09:23:10 -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 3AEED3A685D for ; Mon, 26 Oct 2009 09:23:10 -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 n9QGNMV9001538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 17:23:22 +0100 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 n9QGNL30025938; Mon, 26 Oct 2009 17:23:22 +0100 (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 n9QGNLrE012171; Mon, 26 Oct 2009 17:23:21 +0100 Message-ID: <4AE5CCF9.3060505@gmail.com> Date: Mon, 26 Oct 2009 17:23:21 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <4AE5C151.6000800@gmail.com> <4AE5C6BD.2030501@gmail.com> <4AE5C9CB.5030807@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] Protocols involving link-local addresses 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, 26 Oct 2009 16:23:11 -0000 Thomas Heide Clausen a écrit : > > On Oct 26, 2009, at 5:09 PM, Alexandru Petrescu wrote: > >> Thomas Heide Clausen a écrit : >>> That's great and these all run fine across a MANET. That's the beauty >>> of end-to-end, you see, as long as the routers present "just an IP >>> hop", then applications on end systems are happy. >> >> I don't understand you. Please add a protocol to my list; that is the >> goal of the list. >> >> Presenting "just an IP" hop is like routers acting at L2. Is this >> some sort of a layer violation? >> > > No, it's actually exactly what a router is supposed to do. Hmm... no doubt we are in contradiction. Two routers --R1--R2-- don't present an IP hop, there are three subnets and two IP hops. I think you don't agree with this model at all and you propose ---|----|--- R1 R2 where R1 and R2 IP forward with host-based routes. I know. I just don't see it that way. I believe both views should be accepted. Alex > > Thomas > >> Alex >> >>> Thomas >>> On Oct 26, 2009, at 4:56 PM, Alexandru Petrescu wrote: >>>> Updated list: added PPP IPv6, ND, ICMPv6, MIPv6 family. >>>> >>>> IPv4 >>>> ---- >>>> mDNS >>>> ARP (the parts in IPv4 LL RFC) >>>> >>>> IPv6 >>>> ---- >>>> DHCP >>>> OSPF >>>> RIPng >>>> MLD >>>> OLSR (a particular implementation) >>>> ND >>>> PPP IPv6 >>>> ICMPv6 >>>> SLAAC >>>> FMIPv6 >>>> MIPv6/NEMOv6/PMIPv6 >>>> >>>> Alex >>>> >>>> Alexandru Petrescu a écrit : >>>>> In several earlier discussions question was raised about which >>>>> protocols use link-local addresses. >>>>> IPv4 >>>>> ---- >>>>> mDNS >>>>> ARP (the parts in IPv4 LL RFC) >>>>> IPv6 >>>>> ---- >>>>> DHCP >>>>> OSPF >>>>> RIPng >>>>> MLD >>>>> OLSR (a particular implementation) >>>>> If you know any other, feel free to add. I think it may be useful >>>>> to add to the AUTOCONF addressing model draft(s). >>>>> (I think Teco may have already written such a list but I have hard >>>>> time >>>>> finding it). >>>>> Alex >>>>> _______________________________________________ >>>>> 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 teco@inf-net.nl Mon Oct 26 09:24:38 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 007E13A67F8 for ; Mon, 26 Oct 2009 09:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, 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 pDQf3YdgNFnw for ; Mon, 26 Oct 2009 09:24:37 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id DE5CE3A6A83 for ; Mon, 26 Oct 2009 09:24:23 -0700 (PDT) Received: (qmail 9246 invoked from network); 26 Oct 2009 17:24:34 +0100 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 26 Oct 2009 17:24:34 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" , References: <4AE5C151.6000800@gmail.com> In-Reply-To: <4AE5C151.6000800@gmail.com> Date: Mon, 26 Oct 2009 17:24:03 +0100 Message-ID: <014f01ca5658$cd6130d0$68239270$@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: AcpWUbmelTYEcGBJTjapwfeIeq2FLwABecFw Content-Language: nl Subject: Re: [Autoconf] Protocols involving link-local addresses 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, 26 Oct 2009 16:24:38 -0000 I would limit the list to protocols that are applicable to MANETs. This is a non-empty list. For IPv6: OSPF-MANET NDP RA MLD And I have my own middleware products that use LL for Peer discovery or 1-hop message disctribution (I could use hop-limit=1). Teco. >-----Oorspronkelijk bericht----- >Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens >Alexandru Petrescu >Verzonden: maandag 26 oktober 2009 16:34 >Aan: autoconf@ietf.org >Onderwerp: [Autoconf] Protocols involving link-local addresses > >In several earlier discussions question was raised about which protocols >use link-local addresses. > >IPv4 >---- >mDNS >ARP (the parts in IPv4 LL RFC) > >IPv6 >---- >DHCP >OSPF >RIPng >MLD >OLSR (a particular implementation) > >If you know any other, feel free to add. I think it may be useful to >add to the AUTOCONF addressing model draft(s). > >(I think Teco may have already written such a list but I have hard time > finding it). I would limit the list to protocols that are applicable to MANETs. This is a non-empty list. For IPv6: OSPF-MANET NDP RA MLD And I have my own middleware products that use LL for Peer discovery or 1-hop message disctribution (I could use hop-limit=1). I would prefer LLs for OLSR also. Teco. > >Alex > >_______________________________________________ >Autoconf mailing list >Autoconf@ietf.org >https://www.ietf.org/mailman/listinfo/autoconf From thomas@thomasclausen.org Mon Oct 26 09:26:04 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 E0AE43A6AED for ; Mon, 26 Oct 2009 09:26:04 -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 2cTIW3V51fmb for ; Mon, 26 Oct 2009 09:26:04 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 0FEF03A6AE3 for ; Mon, 26 Oct 2009 09:26:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id D2ED5322806E; Mon, 26 Oct 2009 09:26:17 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 3DFED32317AD; Mon, 26 Oct 2009 09:26:16 -0700 (PDT) Message-Id: From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE5CC23.1090105@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: Mon, 26 Oct 2009 17:26:13 +0100 References: <4AE5C151.6000800@gmail.com> <4AE5C6BD.2030501@gmail.com> <4AE5C9CB.5030807@gmail.com> <5A0019AD-0BB0-4EAF-969E-73E3F1DAF1DE@thomasclausen.org> <4AE5CC23.1090105@gmail.com> X-Mailer: Apple Mail (2.936) Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Protocols involving link-local addresses 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, 26 Oct 2009 16:26:05 -0000 On Oct 26, 2009, at 5:19 PM, Alexandru Petrescu wrote: > Thomas Heide Clausen a =E9crit : >> On Oct 26, 2009, at 5:09 PM, Alexandru Petrescu wrote: >>> Thomas Heide Clausen a =E9crit : >>>> That's great and these all run fine across a MANET. That's the =20 >>>> beauty of end-to-end, you see, as long as the routers present =20 >>>> "just an IP hop", then applications on end systems are happy. >>> >>> I don't understand you. Please add a protocol to my list; that is =20= >>> the goal of the list. >>> >> Ok, I'll try: >> http > > Well thanks, let me just make sure: does http use link-local =20 > addresses? Some times? IPv6 LL? IPv4 LL? > >> I am not sure I understand the game, shall it just be any odd =20 >> protocol that works fine across a MANET? Then, it'll be a long =20 >> list ;) > > Protocols working fine across MANET and using link-local addresses? =20= > Er? So why do you discourage the LLs then? Stuff that uses "link-local addresses" usually work across a *link* =20 not across a *network*, correct? > My goal is not a game, is to build a list by AUTOCONF members of =20 > protocols using IPv6 link-local addresses which risk be affected if =20= > the recommendation is to discourage LLs. But it just doesn't make sense what you write. Most of what you list runs on end-systems, not between routers. If your "router cloud" is a MANET or an IS-IS or an OSPF system =20 doesn't make an iota of difference. The end-systems (hosts) have no =20 idea of what's happening inside that cloud, how the links between =20 routers look etc. All they care about is the link between themselves =20 and the router -- which.....is just a good-ol' IP-link. All the end-=20 systems see is an IP-link to the router. Just as in OSPF. Just as in =20 IS-IS.....just as in.....the rest of the Internet. Are you sure you did see my example-email from this morning? Thomas > > Alex > >> Thomas >>> Presenting "just an IP" hop is like routers acting at L2. Is this =20= >>> some sort of a layer violation? >>> >>> Alex >>> >>>> Thomas >>>> On Oct 26, 2009, at 4:56 PM, Alexandru Petrescu wrote: >>>>> Updated list: added PPP IPv6, ND, ICMPv6, MIPv6 family. >>>>> >>>>> IPv4 >>>>> ---- >>>>> mDNS >>>>> ARP (the parts in IPv4 LL RFC) >>>>> >>>>> IPv6 >>>>> ---- >>>>> DHCP >>>>> OSPF >>>>> RIPng >>>>> MLD >>>>> OLSR (a particular implementation) >>>>> ND >>>>> PPP IPv6 >>>>> ICMPv6 >>>>> SLAAC >>>>> FMIPv6 >>>>> MIPv6/NEMOv6/PMIPv6 >>>>> >>>>> Alex >>>>> >>>>> Alexandru Petrescu a =E9crit : >>>>>> In several earlier discussions question was raised about which =20= >>>>>> protocols use link-local addresses. >>>>>> IPv4 >>>>>> ---- >>>>>> mDNS >>>>>> ARP (the parts in IPv4 LL RFC) >>>>>> IPv6 >>>>>> ---- >>>>>> DHCP >>>>>> OSPF >>>>>> RIPng >>>>>> MLD >>>>>> OLSR (a particular implementation) >>>>>> If you know any other, feel free to add. I think it may be =20 >>>>>> useful to add to the AUTOCONF addressing model draft(s). >>>>>> (I think Teco may have already written such a list but I have =20 >>>>>> hard time >>>>>> finding it). >>>>>> Alex >>>>>> _______________________________________________ >>>>>> 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 alexandru.petrescu@gmail.com Mon Oct 26 09: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 C37263A6B09 for ; Mon, 26 Oct 2009 09:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=0.095, 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 kgPTWDsx8A9L for ; Mon, 26 Oct 2009 09:30:05 -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 98B3A3A6AFD for ; Mon, 26 Oct 2009 09:30:05 -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 n9QGUHQ2031658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 17:30:17 +0100 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 n9QGUHYT027198; Mon, 26 Oct 2009 17:30:17 +0100 (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 n9QGUGwP014468; Mon, 26 Oct 2009 17:30:17 +0100 Message-ID: <4AE5CE98.5030809@gmail.com> Date: Mon, 26 Oct 2009 17:30:16 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Teco Boot References: <4AE5C151.6000800@gmail.com> <014f01ca5658$cd6130d0$68239270$@nl> In-Reply-To: <014f01ca5658$cd6130d0$68239270$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Protocols involving link-local addresses 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, 26 Oct 2009 16:30:06 -0000 Updated: limit to protocols relevant to MANET which use IPv6 link-local addresses. Protocols applicable to MANET which use IPv6 LLs ------------------------------------------------ OSPF-MANET NDP RA MLD ------------------------------------------------- IPv4 optional protocols using LLs --------------------------------- mDNS ARP (the parts in IPv4 LL RFC) IPv6 optional protocols using LLs --------------------------------- DHCP OSPF RIPng MLD OLSR (a particular implementation) ND PPP IPv6 ICMPv6 SLAAC FMIPv6 MIPv6/NEMOv6/PMIPv6 Alex Teco Boot a écrit : > I would limit the list to protocols that are applicable to MANETs. > This is a non-empty list. For IPv6: > OSPF-MANET > NDP RA > MLD > And I have my own middleware products that use LL for Peer discovery > or 1-hop message disctribution (I could use hop-limit=1). > > Teco. > >> -----Oorspronkelijk bericht----- >> Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens >> Alexandru Petrescu >> Verzonden: maandag 26 oktober 2009 16:34 >> Aan: autoconf@ietf.org >> Onderwerp: [Autoconf] Protocols involving link-local addresses >> >> In several earlier discussions question was raised about which protocols >> use link-local addresses. >> >> IPv4 >> ---- >> mDNS >> ARP (the parts in IPv4 LL RFC) >> >> IPv6 >> ---- >> DHCP >> OSPF >> RIPng >> MLD >> OLSR (a particular implementation) >> >> If you know any other, feel free to add. I think it may be useful to >> add to the AUTOCONF addressing model draft(s). >> >> (I think Teco may have already written such a list but I have hard time >> finding it). > > > I would limit the list to protocols that are applicable to MANETs. > This is a non-empty list. For IPv6: > OSPF-MANET > NDP RA > MLD > And I have my own middleware products that use LL for Peer discovery > or 1-hop message disctribution (I could use hop-limit=1). > I would prefer LLs for OLSR also. > > Teco. > > >> Alex >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > From teco@inf-net.nl Mon Oct 26 09:33: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 E0BD228C0F5 for ; Mon, 26 Oct 2009 09:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.355 X-Spam-Level: X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, 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 jfoGsKc2jdFI for ; Mon, 26 Oct 2009 09:33:23 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id C04AC3A6AFB for ; Mon, 26 Oct 2009 09:33:22 -0700 (PDT) Received: (qmail 18339 invoked from network); 26 Oct 2009 17:33:34 +0100 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 26 Oct 2009 17:33:34 +0100 From: "Teco Boot" To: "'Emmanuel Baccelli'" , References: <20091019233002.15F4328C164@core3.amsl.com> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <005801ca5618$38d35be0$aa7a13a0$@nl> <25c114b90910260219h52c74b4dha6871856afaaec23@mail.gmail.com> <00b601ca562b$0afa2ab0$20ee8010$@nl> In-Reply-To: Date: Mon, 26 Oct 2009 17:33:02 +0100 Message-ID: <015001ca565a$0ebbbb30$2c333190$@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: AcpWRd1brum9JacZQ3yT28Ivq7P2FQAE5fhw Content-Language: nl Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 26 Oct 2009 16:33:24 -0000 Emmanuel Baccelli wrote: > ULAs and globals are meant to be managed by mechanisms that are=20 > fundamentally different from the LL mechanisms.=A0ULAs and globals > are naturally unambiguous in a MANET context, contrary to LL = addresses.=A0 ?????? Maybe you have a different version of IPv6 than I have. My = implementations supports IPv6 Stateless Address Autoconfiguration [RFC 4862]. Regards, Teco =A0 From alexandru.petrescu@gmail.com Mon Oct 26 09:33:44 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 A958A28C10A for ; Mon, 26 Oct 2009 09:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.094, 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 HjjcYpVqR-13 for ; Mon, 26 Oct 2009 09:33:43 -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 8490C28C0CE for ; Mon, 26 Oct 2009 09:33:43 -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 n9QGXtnD008413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 17:33:55 +0100 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 n9QGXtBL027757; Mon, 26 Oct 2009 17:33:55 +0100 (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 n9QGXsnq015570; Mon, 26 Oct 2009 17:33:55 +0100 Message-ID: <4AE5CF72.9070700@gmail.com> Date: Mon, 26 Oct 2009 17:33:54 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <4AE5C151.6000800@gmail.com> <4AE5C6BD.2030501@gmail.com> <4AE5C9CB.5030807@gmail.com> <5A0019AD-0BB0-4EAF-969E-73E3F1DAF1DE@thomasclausen.org> <4AE5CC23.1090105@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] Protocols involving link-local addresses 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, 26 Oct 2009 16:33:44 -0000 Thomas Heide Clausen a écrit : > > On Oct 26, 2009, at 5:19 PM, Alexandru Petrescu wrote: > >> Thomas Heide Clausen a écrit : >>> On Oct 26, 2009, at 5:09 PM, Alexandru Petrescu wrote: >>>> Thomas Heide Clausen a écrit : >>>>> That's great and these all run fine across a MANET. That's the >>>>> beauty of end-to-end, you see, as long as the routers present "just >>>>> an IP hop", then applications on end systems are happy. >>>> >>>> I don't understand you. Please add a protocol to my list; that is >>>> the goal of the list. >>>> >>> Ok, I'll try: >>> http >> >> Well thanks, let me just make sure: does http use link-local >> addresses? Some times? IPv6 LL? IPv4 LL? >> >>> I am not sure I understand the game, shall it just be any odd >>> protocol that works fine across a MANET? Then, it'll be a long list ;) >> >> Protocols working fine across MANET and using link-local addresses? >> Er? So why do you discourage the LLs then? > > Stuff that uses "link-local addresses" usually work across a *link* not > across a *network*, correct? Right. There are ways of expressing this (stay on link, don't move out); they shouldn't simply be "discouraged". >> My goal is not a game, is to build a list by AUTOCONF members of >> protocols using IPv6 link-local addresses which risk be affected if >> the recommendation is to discourage LLs. > > But it just doesn't make sense what you write. Thomas. You have now three people: you, myself and Teco who contributed to the list. That sounds as a good candidate for inclusion. Or are you going to ignore this too? > Most of what you list runs on end-systems, not between routers. Well, talk to PMIP/OSPF/MIP/NEMO people and you'll be convinced differently. > If your "router cloud" is a MANET or an IS-IS or an OSPF system doesn't > make an iota of difference. The end-systems (hosts) have no idea of > what's happening inside that cloud, how the links between routers look > etc. LLs are not for end-systems only (hosts) they are for routers too. > All they care about is the link between themselves and the router > -- which.....is just a good-ol' IP-link. All the end-systems see is an > IP-link to the router. Just as in OSPF. Just as in IS-IS.....just as > in.....the rest of the Internet. > > Are you sure you did see my example-email from this morning? Did you reply to Ronald in 't Velt about OLSR using link-local addresses? Alex > > Thomas > > >> >> Alex >> >>> Thomas >>>> Presenting "just an IP" hop is like routers acting at L2. Is this >>>> some sort of a layer violation? >>>> >>>> Alex >>>> >>>>> Thomas >>>>> On Oct 26, 2009, at 4:56 PM, Alexandru Petrescu wrote: >>>>>> Updated list: added PPP IPv6, ND, ICMPv6, MIPv6 family. >>>>>> >>>>>> IPv4 >>>>>> ---- >>>>>> mDNS >>>>>> ARP (the parts in IPv4 LL RFC) >>>>>> >>>>>> IPv6 >>>>>> ---- >>>>>> DHCP >>>>>> OSPF >>>>>> RIPng >>>>>> MLD >>>>>> OLSR (a particular implementation) >>>>>> ND >>>>>> PPP IPv6 >>>>>> ICMPv6 >>>>>> SLAAC >>>>>> FMIPv6 >>>>>> MIPv6/NEMOv6/PMIPv6 >>>>>> >>>>>> Alex >>>>>> >>>>>> Alexandru Petrescu a écrit : >>>>>>> In several earlier discussions question was raised about which >>>>>>> protocols use link-local addresses. >>>>>>> IPv4 >>>>>>> ---- >>>>>>> mDNS >>>>>>> ARP (the parts in IPv4 LL RFC) >>>>>>> IPv6 >>>>>>> ---- >>>>>>> DHCP >>>>>>> OSPF >>>>>>> RIPng >>>>>>> MLD >>>>>>> OLSR (a particular implementation) >>>>>>> If you know any other, feel free to add. I think it may be >>>>>>> useful to add to the AUTOCONF addressing model draft(s). >>>>>>> (I think Teco may have already written such a list but I have >>>>>>> hard time >>>>>>> finding it). >>>>>>> Alex >>>>>>> _______________________________________________ >>>>>>> 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 thomas@thomasclausen.org Mon Oct 26 09:35: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 4CC973A6A9A for ; Mon, 26 Oct 2009 09:35:58 -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 FscKaWeIKpeb for ; Mon, 26 Oct 2009 09:35:54 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 5120528C0CE for ; Mon, 26 Oct 2009 09:35:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 2B849322806E; Mon, 26 Oct 2009 09:36:08 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 22B6432317B6; Mon, 26 Oct 2009 09:36:06 -0700 (PDT) Message-Id: From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE5CCF9.3060505@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: Mon, 26 Oct 2009 17:36:04 +0100 References: <4AE5C151.6000800@gmail.com> <4AE5C6BD.2030501@gmail.com> <4AE5C9CB.5030807@gmail.com> <4AE5CCF9.3060505@gmail.com> X-Mailer: Apple Mail (2.936) Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Protocols involving link-local addresses 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, 26 Oct 2009 16:35:58 -0000 On Oct 26, 2009, at 5:23 PM, Alexandru Petrescu wrote: > Thomas Heide Clausen a =E9crit : >> On Oct 26, 2009, at 5:09 PM, Alexandru Petrescu wrote: >>> Thomas Heide Clausen a =E9crit : >>>> That's great and these all run fine across a MANET. That's the =20 >>>> beauty of end-to-end, you see, as long as the routers present =20 >>>> "just an IP hop", then applications on end systems are happy. >>> >>> I don't understand you. Please add a protocol to my list; that is =20= >>> the goal of the list. >>> >>> Presenting "just an IP" hop is like routers acting at L2. Is this =20= >>> some sort of a layer violation? >>> >> No, it's actually exactly what a router is supposed to do. > > Hmm... no doubt we are in contradiction. > > Two routers --R1--R2-- don't present an IP hop, there are three =20 > subnets and two IP hops. > > I think you don't agree with this model at all and you propose > > ---|----|--- > R1 R2 > > where R1 and R2 IP forward with host-based routes. I know. I just =20= > don't see it that way. > > I believe both views should be accepted. > No, Alex, that's neither how it is. Nor is it how I see matters. h1----R1--- ........ --Rn----h2 Presents the host (h1) with one IP hop towards the router (R1). =20 Whatever happens between R1 and Rn is purely transparent to h1. It can =20= be avian carries, for all that h1 cares. The link between h1 and R1 is whatever we usually have on the edge. =20 You can run NDP, mdns, ... over it, you can define subnets on that =20 link -- the link h1--R1. It's just a classic IP link. All works well Between R1 and Rn there may be a lot of "magic" going on. Strange =20 links, complicated routing protocols. It's a "routing domain" -- =20 almost like magic ;) h1 won't know. h1 shouldn't know -- because the interface of h1 to the =20= rest of the world is....an IP hop to R1. h1 will use R1 to connect "to =20= the rest of the world". R1 should (on the interface towards the other routers) be aware of =20 that "magic", including those advanced algorithms working on =20 complicated data structures to find paths towards (in this case) h2. =20 That's alright, R1 is build for that purpose - to do exactly that =20 magic ;) In the Internet, R1 and all the other R's would run OSPF or ISIS, =20 usually. In a MANET, it'd run a MANET protocol such as AODV, DYMO, =20 OLSR, .... If you disagree with that then -- I'm sorry to say -- you disagree =20 with the Internet. I'm not sure how much clearer I can make it, so I'll jump out of this =20= discussion now. Thomas > Alex > > >> Thomas >>> Alex >>> >>>> Thomas >>>> On Oct 26, 2009, at 4:56 PM, Alexandru Petrescu wrote: >>>>> Updated list: added PPP IPv6, ND, ICMPv6, MIPv6 family. >>>>> >>>>> IPv4 >>>>> ---- >>>>> mDNS >>>>> ARP (the parts in IPv4 LL RFC) >>>>> >>>>> IPv6 >>>>> ---- >>>>> DHCP >>>>> OSPF >>>>> RIPng >>>>> MLD >>>>> OLSR (a particular implementation) >>>>> ND >>>>> PPP IPv6 >>>>> ICMPv6 >>>>> SLAAC >>>>> FMIPv6 >>>>> MIPv6/NEMOv6/PMIPv6 >>>>> >>>>> Alex >>>>> >>>>> Alexandru Petrescu a =E9crit : >>>>>> In several earlier discussions question was raised about which =20= >>>>>> protocols use link-local addresses. >>>>>> IPv4 >>>>>> ---- >>>>>> mDNS >>>>>> ARP (the parts in IPv4 LL RFC) >>>>>> IPv6 >>>>>> ---- >>>>>> DHCP >>>>>> OSPF >>>>>> RIPng >>>>>> MLD >>>>>> OLSR (a particular implementation) >>>>>> If you know any other, feel free to add. I think it may be =20 >>>>>> useful to add to the AUTOCONF addressing model draft(s). >>>>>> (I think Teco may have already written such a list but I have =20 >>>>>> hard time >>>>>> finding it). >>>>>> Alex >>>>>> _______________________________________________ >>>>>> 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 From alexandru.petrescu@gmail.com Mon Oct 26 09:36: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 8DE0828C106 for ; Mon, 26 Oct 2009 09:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.156 X-Spam-Level: X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=0.093, 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 gB2eUPg9KAxw for ; Mon, 26 Oct 2009 09:36:48 -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 9224528C0F5 for ; Mon, 26 Oct 2009 09:36:48 -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 n9QGb0wM007036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 17:37:00 +0100 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 n9QGb097028190; Mon, 26 Oct 2009 17:37:00 +0100 (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 n9QGb0aa022061; Mon, 26 Oct 2009 17:37:00 +0100 Message-ID: <4AE5D02B.8070809@gmail.com> Date: Mon, 26 Oct 2009 17:36:59 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Teco Boot References: <4AE5C151.6000800@gmail.com> <014f01ca5658$cd6130d0$68239270$@nl> In-Reply-To: <014f01ca5658$cd6130d0$68239270$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Adding list of LL protocols for-against (was: Protocols involving link-local addresses) 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, 26 Oct 2009 16:36:49 -0000 Teco, AUTOCONFers, Do you agree with adding a list of IP protocols using link-local addresses, in the AUTOCONF addressing model, and which may be pertinent to MANET? -yes -no Thanks, Alex Teco Boot a écrit : > I would limit the list to protocols that are applicable to MANETs. > This is a non-empty list. For IPv6: > OSPF-MANET > NDP RA > MLD > And I have my own middleware products that use LL for Peer discovery > or 1-hop message disctribution (I could use hop-limit=1). > > Teco. > >> -----Oorspronkelijk bericht----- >> Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens >> Alexandru Petrescu >> Verzonden: maandag 26 oktober 2009 16:34 >> Aan: autoconf@ietf.org >> Onderwerp: [Autoconf] Protocols involving link-local addresses >> >> In several earlier discussions question was raised about which protocols >> use link-local addresses. >> >> IPv4 >> ---- >> mDNS >> ARP (the parts in IPv4 LL RFC) >> >> IPv6 >> ---- >> DHCP >> OSPF >> RIPng >> MLD >> OLSR (a particular implementation) >> >> If you know any other, feel free to add. I think it may be useful to >> add to the AUTOCONF addressing model draft(s). >> >> (I think Teco may have already written such a list but I have hard time >> finding it). > > > I would limit the list to protocols that are applicable to MANETs. > This is a non-empty list. For IPv6: > OSPF-MANET > NDP RA > MLD > And I have my own middleware products that use LL for Peer discovery > or 1-hop message disctribution (I could use hop-limit=1). > I would prefer LLs for OLSR also. > > Teco. > > >> Alex >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > From alexandru.petrescu@gmail.com Mon Oct 26 09:41: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 3BD0128C0EC for ; Mon, 26 Oct 2009 09:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.158 X-Spam-Level: X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[AWL=0.091, 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 OWqTB1+-mLO5 for ; Mon, 26 Oct 2009 09:41:07 -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 E02B528C250 for ; Mon, 26 Oct 2009 09:41:06 -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 n9QGfIjL013382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 17:41:19 +0100 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 n9QGfIMG028922; Mon, 26 Oct 2009 17:41:18 +0100 (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 n9QGfIwJ023187; Mon, 26 Oct 2009 17:41:18 +0100 Message-ID: <4AE5D12D.6090605@gmail.com> Date: Mon, 26 Oct 2009 17:41:17 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <4AE5C151.6000800@gmail.com> <4AE5C6BD.2030501@gmail.com> <4AE5C9CB.5030807@gmail.com> <4AE5CCF9.3060505@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] Protocols involving link-local addresses 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, 26 Oct 2009 16:41:08 -0000 Thomas Heide Clausen a écrit : > > On Oct 26, 2009, at 5:23 PM, Alexandru Petrescu wrote: > >> Thomas Heide Clausen a écrit : >>> On Oct 26, 2009, at 5:09 PM, Alexandru Petrescu wrote: >>>> Thomas Heide Clausen a écrit : >>>>> That's great and these all run fine across a MANET. That's the >>>>> beauty of end-to-end, you see, as long as the routers present "just >>>>> an IP hop", then applications on end systems are happy. >>>> >>>> I don't understand you. Please add a protocol to my list; that is >>>> the goal of the list. >>>> >>>> Presenting "just an IP" hop is like routers acting at L2. Is this >>>> some sort of a layer violation? >>>> >>> No, it's actually exactly what a router is supposed to do. >> >> Hmm... no doubt we are in contradiction. >> >> Two routers --R1--R2-- don't present an IP hop, there are three >> subnets and two IP hops. >> >> I think you don't agree with this model at all and you propose >> >> ---|----|--- >> R1 R2 >> >> where R1 and R2 IP forward with host-based routes. I know. I just >> don't see it that way. >> >> I believe both views should be accepted. >> > > No, Alex, that's neither how it is. Nor is it how I see matters. > > > h1----R1--- ........ --Rn----h2 > > Presents the host (h1) with one IP hop towards the router (R1). On which side of R1 do you discourage LLs? > Whatever > happens between R1 and Rn is purely transparent to h1. It can be avian > carries, for all that h1 cares. > > The link between h1 and R1 is whatever we usually have on the edge. You > can run NDP, mdns, ... over it, you can define subnets on that link -- > the link h1--R1. It's just a classic IP link. Ok! Say so in the addressing model draft. > All works well > > Between R1 and Rn there may be a lot of "magic" going on. Strange links, > complicated routing protocols. DO you discourage LLs on this "magic"? Say so in the draft. > It's a "routing domain" -- almost like > magic ;) > > h1 won't know. h1 shouldn't know -- because the interface of h1 to the > rest of the world is....an IP hop to R1. h1 will use R1 to connect "to > the rest of the world". > > R1 should (on the interface towards the other routers) be aware of that > "magic", including those advanced algorithms working on complicated data > structures to find paths towards (in this case) h2. That's alright, R1 > is build for that purpose - to do exactly that magic ;) > > In the Internet, R1 and all the other R's would run OSPF or ISIS, > usually. In a MANET, it'd run a MANET protocol such as AODV, DYMO, OLSR, But some OLSR does use LLs - do you discourage that? > .... > > If you disagree with that then -- I'm sorry to say -- you disagree with > the Internet. No, I agree with Internet. > > I'm not sure how much clearer I can make it, so I'll jump out of this > discussion now. But we were on the point to converge! Alex > > Thomas > > > > >> Alex >> >> >>> Thomas >>>> Alex >>>> >>>>> Thomas >>>>> On Oct 26, 2009, at 4:56 PM, Alexandru Petrescu wrote: >>>>>> Updated list: added PPP IPv6, ND, ICMPv6, MIPv6 family. >>>>>> >>>>>> IPv4 >>>>>> ---- >>>>>> mDNS >>>>>> ARP (the parts in IPv4 LL RFC) >>>>>> >>>>>> IPv6 >>>>>> ---- >>>>>> DHCP >>>>>> OSPF >>>>>> RIPng >>>>>> MLD >>>>>> OLSR (a particular implementation) >>>>>> ND >>>>>> PPP IPv6 >>>>>> ICMPv6 >>>>>> SLAAC >>>>>> FMIPv6 >>>>>> MIPv6/NEMOv6/PMIPv6 >>>>>> >>>>>> Alex >>>>>> >>>>>> Alexandru Petrescu a écrit : >>>>>>> In several earlier discussions question was raised about which >>>>>>> protocols use link-local addresses. >>>>>>> IPv4 >>>>>>> ---- >>>>>>> mDNS >>>>>>> ARP (the parts in IPv4 LL RFC) >>>>>>> IPv6 >>>>>>> ---- >>>>>>> DHCP >>>>>>> OSPF >>>>>>> RIPng >>>>>>> MLD >>>>>>> OLSR (a particular implementation) >>>>>>> If you know any other, feel free to add. I think it may be >>>>>>> useful to add to the AUTOCONF addressing model draft(s). >>>>>>> (I think Teco may have already written such a list but I have >>>>>>> hard time >>>>>>> finding it). >>>>>>> Alex >>>>>>> _______________________________________________ >>>>>>> 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 > > From thomas@thomasclausen.org Mon Oct 26 09:44: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 5E77A3A6921 for ; Mon, 26 Oct 2009 09:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 VzUr+8ut1RRM for ; Mon, 26 Oct 2009 09:44:29 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id E8DA33A68D7 for ; Mon, 26 Oct 2009 09:44:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id C4C3632317B6; Mon, 26 Oct 2009 09:44:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 786BC32317AF; Mon, 26 Oct 2009 09:44:30 -0700 (PDT) Message-Id: <1AE426A5-A60D-4551-AE6B-AE2E9E63646B@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE5D12D.6090605@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: Mon, 26 Oct 2009 17:44:27 +0100 References: <4AE5C151.6000800@gmail.com> <4AE5C6BD.2030501@gmail.com> <4AE5C9CB.5030807@gmail.com> <4AE5CCF9.3060505@gmail.com> <4AE5D12D.6090605@gmail.com> X-Mailer: Apple Mail (2.936) Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Protocols involving link-local addresses 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, 26 Oct 2009 16:44:30 -0000 On Oct 26, 2009, at 5:41 PM, Alexandru Petrescu wrote: > Thomas Heide Clausen a =E9crit : >> On Oct 26, 2009, at 5:23 PM, Alexandru Petrescu wrote: >>> Thomas Heide Clausen a =E9crit : >>>> On Oct 26, 2009, at 5:09 PM, Alexandru Petrescu wrote: >>>>> Thomas Heide Clausen a =E9crit : >>>>>> That's great and these all run fine across a MANET. That's the =20= >>>>>> beauty of end-to-end, you see, as long as the routers present =20 >>>>>> "just an IP hop", then applications on end systems are happy. >>>>> >>>>> I don't understand you. Please add a protocol to my list; that =20= >>>>> is the goal of the list. >>>>> >>>>> Presenting "just an IP" hop is like routers acting at L2. Is =20 >>>>> this some sort of a layer violation? >>>>> >>>> No, it's actually exactly what a router is supposed to do. >>> >>> Hmm... no doubt we are in contradiction. >>> >>> Two routers --R1--R2-- don't present an IP hop, there are three =20 >>> subnets and two IP hops. >>> >>> I think you don't agree with this model at all and you propose >>> >>> ---|----|--- >>> R1 R2 >>> >>> where R1 and R2 IP forward with host-based routes. I know. I =20 >>> just don't see it that way. >>> >>> I believe both views should be accepted. >>> >> No, Alex, that's neither how it is. Nor is it how I see matters. >> h1----R1--- ........ --Rn----h2 >> Presents the host (h1) with one IP hop towards the router (R1). > > On which side of R1 do you discourage LLs? > I'll let you take a wild guess.....no, actually, I won't. The links =20 between R's... >> Whatever happens between R1 and Rn is purely transparent to h1. It =20= >> can be avian carries, for all that h1 cares. >> The link between h1 and R1 is whatever we usually have on the edge. =20= >> You can run NDP, mdns, ... over it, you can define subnets on that =20= >> link -- the link h1--R1. It's just a classic IP link. > > Ok! Say so in the addressing model draft. No, this document is not about defining the properties of a classic IP =20= link. That's done before (and better than this WG could) elsewhere by =20= other people. > >> All works well >> Between R1 and Rn there may be a lot of "magic" going on. Strange =20 >> links, complicated routing protocols. > > DO you discourage LLs on this "magic"? Say so in the draft. That's what the draft says already, and which you have been disputing =20= for days now...... EOD. Thomas > >> It's a "routing domain" -- almost like magic ;) >> h1 won't know. h1 shouldn't know -- because the interface of h1 to =20= >> the rest of the world is....an IP hop to R1. h1 will use R1 to =20 >> connect "to the rest of the world". >> R1 should (on the interface towards the other routers) be aware of =20= >> that "magic", including those advanced algorithms working on =20 >> complicated data structures to find paths towards (in this case) =20 >> h2. That's alright, R1 is build for that purpose - to do exactly =20 >> that magic ;) >> In the Internet, R1 and all the other R's would run OSPF or ISIS, =20 >> usually. In a MANET, it'd run a MANET protocol such as AODV, DYMO, =20= >> OLSR, > > But some OLSR does use LLs - do you discourage that? > >> .... >> If you disagree with that then -- I'm sorry to say -- you disagree =20= >> with the Internet. > > No, I agree with Internet. > >> I'm not sure how much clearer I can make it, so I'll jump out of =20 >> this discussion now. > > But we were on the point to converge! > > Alex > >> Thomas >>> Alex >>> >>> >>>> Thomas >>>>> Alex >>>>> >>>>>> Thomas >>>>>> On Oct 26, 2009, at 4:56 PM, Alexandru Petrescu wrote: >>>>>>> Updated list: added PPP IPv6, ND, ICMPv6, MIPv6 family. >>>>>>> >>>>>>> IPv4 >>>>>>> ---- >>>>>>> mDNS >>>>>>> ARP (the parts in IPv4 LL RFC) >>>>>>> >>>>>>> IPv6 >>>>>>> ---- >>>>>>> DHCP >>>>>>> OSPF >>>>>>> RIPng >>>>>>> MLD >>>>>>> OLSR (a particular implementation) >>>>>>> ND >>>>>>> PPP IPv6 >>>>>>> ICMPv6 >>>>>>> SLAAC >>>>>>> FMIPv6 >>>>>>> MIPv6/NEMOv6/PMIPv6 >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>> Alexandru Petrescu a =E9crit : >>>>>>>> In several earlier discussions question was raised about =20 >>>>>>>> which protocols use link-local addresses. >>>>>>>> IPv4 >>>>>>>> ---- >>>>>>>> mDNS >>>>>>>> ARP (the parts in IPv4 LL RFC) >>>>>>>> IPv6 >>>>>>>> ---- >>>>>>>> DHCP >>>>>>>> OSPF >>>>>>>> RIPng >>>>>>>> MLD >>>>>>>> OLSR (a particular implementation) >>>>>>>> If you know any other, feel free to add. I think it may be =20 >>>>>>>> useful to add to the AUTOCONF addressing model draft(s). >>>>>>>> (I think Teco may have already written such a list but I have =20= >>>>>>>> hard time >>>>>>>> finding it). >>>>>>>> Alex >>>>>>>> _______________________________________________ >>>>>>>> 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 > > From alexandru.petrescu@gmail.com Mon Oct 26 09:46: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 02D793A6A9A for ; Mon, 26 Oct 2009 09:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.159 X-Spam-Level: X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=0.090, 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 FNqvii4A8n7U for ; Mon, 26 Oct 2009 09:46:48 -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 1DE9C3A6A79 for ; Mon, 26 Oct 2009 09:46:44 -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 n9QGkvwH019079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 17:46:57 +0100 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 n9QGkuJr030145; Mon, 26 Oct 2009 17:46:57 +0100 (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 n9QGkuUA024889; Mon, 26 Oct 2009 17:46:56 +0100 Message-ID: <4AE5D280.3070206@gmail.com> Date: Mon, 26 Oct 2009 17:46:56 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <4AE5C151.6000800@gmail.com> <4AE5C6BD.2030501@gmail.com> <4AE5C9CB.5030807@gmail.com> <4AE5CCF9.3060505@gmail.com> <4AE5D12D.6090605@gmail.com> <1AE426A5-A60D-4551-AE6B-AE2E9E63646B@thomasclausen.org> In-Reply-To: <1AE426A5-A60D-4551-AE6B-AE2E9E63646B@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Protocols involving link-local addresses 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, 26 Oct 2009 16:46:49 -0000 Thomas, it is not clear your first occurence of "discourage LL". If I insist, it is for that reason. Were you to put it last, maybe it would have been ok. You seem ready to spend hours of discussion but don't touch that document. Why? Why does that OLSR implementation use LLs? Alex Thomas Heide Clausen a écrit : > > On Oct 26, 2009, at 5:41 PM, Alexandru Petrescu wrote: > >> Thomas Heide Clausen a écrit : >>> On Oct 26, 2009, at 5:23 PM, Alexandru Petrescu wrote: >>>> Thomas Heide Clausen a écrit : >>>>> On Oct 26, 2009, at 5:09 PM, Alexandru Petrescu wrote: >>>>>> Thomas Heide Clausen a écrit : >>>>>>> That's great and these all run fine across a MANET. That's the >>>>>>> beauty of end-to-end, you see, as long as the routers present >>>>>>> "just an IP hop", then applications on end systems are happy. >>>>>> >>>>>> I don't understand you. Please add a protocol to my list; that is >>>>>> the goal of the list. >>>>>> >>>>>> Presenting "just an IP" hop is like routers acting at L2. Is this >>>>>> some sort of a layer violation? >>>>>> >>>>> No, it's actually exactly what a router is supposed to do. >>>> >>>> Hmm... no doubt we are in contradiction. >>>> >>>> Two routers --R1--R2-- don't present an IP hop, there are three >>>> subnets and two IP hops. >>>> >>>> I think you don't agree with this model at all and you propose >>>> >>>> ---|----|--- >>>> R1 R2 >>>> >>>> where R1 and R2 IP forward with host-based routes. I know. I just >>>> don't see it that way. >>>> >>>> I believe both views should be accepted. >>>> >>> No, Alex, that's neither how it is. Nor is it how I see matters. >>> h1----R1--- ........ --Rn----h2 >>> Presents the host (h1) with one IP hop towards the router (R1). >> >> On which side of R1 do you discourage LLs? >> > > I'll let you take a wild guess.....no, actually, I won't. The links > between R's... > >>> Whatever happens between R1 and Rn is purely transparent to h1. It >>> can be avian carries, for all that h1 cares. >>> The link between h1 and R1 is whatever we usually have on the edge. >>> You can run NDP, mdns, ... over it, you can define subnets on that >>> link -- the link h1--R1. It's just a classic IP link. >> >> Ok! Say so in the addressing model draft. > > No, this document is not about defining the properties of a classic IP > link. That's done before (and better than this WG could) elsewhere by > other people. > >> >>> All works well >>> Between R1 and Rn there may be a lot of "magic" going on. Strange >>> links, complicated routing protocols. >> >> DO you discourage LLs on this "magic"? Say so in the draft. > > That's what the draft says already, and which you have been disputing > for days now...... > > EOD. > > Thomas > >> >>> It's a "routing domain" -- almost like magic ;) >>> h1 won't know. h1 shouldn't know -- because the interface of h1 to >>> the rest of the world is....an IP hop to R1. h1 will use R1 to >>> connect "to the rest of the world". >>> R1 should (on the interface towards the other routers) be aware of >>> that "magic", including those advanced algorithms working on >>> complicated data structures to find paths towards (in this case) h2. >>> That's alright, R1 is build for that purpose - to do exactly that >>> magic ;) >>> In the Internet, R1 and all the other R's would run OSPF or ISIS, >>> usually. In a MANET, it'd run a MANET protocol such as AODV, DYMO, OLSR, >> >> But some OLSR does use LLs - do you discourage that? >> >>> .... >>> If you disagree with that then -- I'm sorry to say -- you disagree >>> with the Internet. >> >> No, I agree with Internet. >> >>> I'm not sure how much clearer I can make it, so I'll jump out of this >>> discussion now. >> >> But we were on the point to converge! >> >> Alex >> >>> Thomas >>>> Alex >>>> >>>> >>>>> Thomas >>>>>> Alex >>>>>> >>>>>>> Thomas >>>>>>> On Oct 26, 2009, at 4:56 PM, Alexandru Petrescu wrote: >>>>>>>> Updated list: added PPP IPv6, ND, ICMPv6, MIPv6 family. >>>>>>>> >>>>>>>> IPv4 >>>>>>>> ---- >>>>>>>> mDNS >>>>>>>> ARP (the parts in IPv4 LL RFC) >>>>>>>> >>>>>>>> IPv6 >>>>>>>> ---- >>>>>>>> DHCP >>>>>>>> OSPF >>>>>>>> RIPng >>>>>>>> MLD >>>>>>>> OLSR (a particular implementation) >>>>>>>> ND >>>>>>>> PPP IPv6 >>>>>>>> ICMPv6 >>>>>>>> SLAAC >>>>>>>> FMIPv6 >>>>>>>> MIPv6/NEMOv6/PMIPv6 >>>>>>>> >>>>>>>> Alex >>>>>>>> >>>>>>>> Alexandru Petrescu a écrit : >>>>>>>>> In several earlier discussions question was raised about which >>>>>>>>> protocols use link-local addresses. >>>>>>>>> IPv4 >>>>>>>>> ---- >>>>>>>>> mDNS >>>>>>>>> ARP (the parts in IPv4 LL RFC) >>>>>>>>> IPv6 >>>>>>>>> ---- >>>>>>>>> DHCP >>>>>>>>> OSPF >>>>>>>>> RIPng >>>>>>>>> MLD >>>>>>>>> OLSR (a particular implementation) >>>>>>>>> If you know any other, feel free to add. I think it may be >>>>>>>>> useful to add to the AUTOCONF addressing model draft(s). >>>>>>>>> (I think Teco may have already written such a list but I have >>>>>>>>> hard time >>>>>>>>> finding it). >>>>>>>>> Alex >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >> >> > > From thomas@thomasclausen.org Mon Oct 26 09:49: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 05E6B3A6921 for ; Mon, 26 Oct 2009 09:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 vkOPfMfTn0vY for ; Mon, 26 Oct 2009 09:49:04 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 8F2D73A68D7 for ; Mon, 26 Oct 2009 09:49:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 6D02232317BA; Mon, 26 Oct 2009 09:49:15 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 39DE932317AE; Mon, 26 Oct 2009 09:49:14 -0700 (PDT) Message-Id: <080FCBF6-2D48-4D8A-91EA-8BF8B0BA51B8@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE5D280.3070206@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: Mon, 26 Oct 2009 17:49:12 +0100 References: <4AE5C151.6000800@gmail.com> <4AE5C6BD.2030501@gmail.com> <4AE5C9CB.5030807@gmail.com> <4AE5CCF9.3060505@gmail.com> <4AE5D12D.6090605@gmail.com> <1AE426A5-A60D-4551-AE6B-AE2E9E63646B@thomasclausen.org> <4AE5D280.3070206@gmail.com> X-Mailer: Apple Mail (2.936) Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Protocols involving link-local addresses 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, 26 Oct 2009 16:49:06 -0000 On Oct 26, 2009, at 5:46 PM, Alexandru Petrescu wrote: > Thomas, it is not clear your first occurence of "discourage LL". > > If I insist, it is for that reason. Were you to put it last, maybe =20= > it would have been ok. > The above makes no sense? > You seem ready to spend hours of discussion but don't touch that =20 > document. Why? I'm not an author. But, I agree with the document content. > > Why does that OLSR implementation use LLs? Not my code, I do not know which implementation you're talking about =20 -- I don't know. But this time, EOD for real from my side. Thomas > Alex > > Thomas Heide Clausen a =E9crit : >> On Oct 26, 2009, at 5:41 PM, Alexandru Petrescu wrote: >>> Thomas Heide Clausen a =E9crit : >>>> On Oct 26, 2009, at 5:23 PM, Alexandru Petrescu wrote: >>>>> Thomas Heide Clausen a =E9crit : >>>>>> On Oct 26, 2009, at 5:09 PM, Alexandru Petrescu wrote: >>>>>>> Thomas Heide Clausen a =E9crit : >>>>>>>> That's great and these all run fine across a MANET. That's =20 >>>>>>>> the beauty of end-to-end, you see, as long as the routers =20 >>>>>>>> present "just an IP hop", then applications on end systems =20 >>>>>>>> are happy. >>>>>>> >>>>>>> I don't understand you. Please add a protocol to my list; =20 >>>>>>> that is the goal of the list. >>>>>>> >>>>>>> Presenting "just an IP" hop is like routers acting at L2. Is =20= >>>>>>> this some sort of a layer violation? >>>>>>> >>>>>> No, it's actually exactly what a router is supposed to do. >>>>> >>>>> Hmm... no doubt we are in contradiction. >>>>> >>>>> Two routers --R1--R2-- don't present an IP hop, there are three =20= >>>>> subnets and two IP hops. >>>>> >>>>> I think you don't agree with this model at all and you propose >>>>> >>>>> ---|----|--- >>>>> R1 R2 >>>>> >>>>> where R1 and R2 IP forward with host-based routes. I know. I =20 >>>>> just don't see it that way. >>>>> >>>>> I believe both views should be accepted. >>>>> >>>> No, Alex, that's neither how it is. Nor is it how I see matters. >>>> h1----R1--- ........ --Rn----h2 >>>> Presents the host (h1) with one IP hop towards the router (R1). >>> >>> On which side of R1 do you discourage LLs? >>> >> I'll let you take a wild guess.....no, actually, I won't. The links =20= >> between R's... >>>> Whatever happens between R1 and Rn is purely transparent to h1. =20 >>>> It can be avian carries, for all that h1 cares. >>>> The link between h1 and R1 is whatever we usually have on the =20 >>>> edge. You can run NDP, mdns, ... over it, you can define subnets =20= >>>> on that link -- the link h1--R1. It's just a classic IP link. >>> >>> Ok! Say so in the addressing model draft. >> No, this document is not about defining the properties of a classic =20= >> IP link. That's done before (and better than this WG could) =20 >> elsewhere by other people. >>> >>>> All works well >>>> Between R1 and Rn there may be a lot of "magic" going on. Strange =20= >>>> links, complicated routing protocols. >>> >>> DO you discourage LLs on this "magic"? Say so in the draft. >> That's what the draft says already, and which you have been =20 >> disputing for days now...... >> EOD. >> Thomas >>> >>>> It's a "routing domain" -- almost like magic ;) >>>> h1 won't know. h1 shouldn't know -- because the interface of h1 =20 >>>> to the rest of the world is....an IP hop to R1. h1 will use R1 to =20= >>>> connect "to the rest of the world". >>>> R1 should (on the interface towards the other routers) be aware =20 >>>> of that "magic", including those advanced algorithms working on =20 >>>> complicated data structures to find paths towards (in this case) =20= >>>> h2. That's alright, R1 is build for that purpose - to do exactly =20= >>>> that magic ;) >>>> In the Internet, R1 and all the other R's would run OSPF or ISIS, =20= >>>> usually. In a MANET, it'd run a MANET protocol such as AODV, =20 >>>> DYMO, OLSR, >>> >>> But some OLSR does use LLs - do you discourage that? >>> >>>> .... >>>> If you disagree with that then -- I'm sorry to say -- you =20 >>>> disagree with the Internet. >>> >>> No, I agree with Internet. >>> >>>> I'm not sure how much clearer I can make it, so I'll jump out of =20= >>>> this discussion now. >>> >>> But we were on the point to converge! >>> >>> Alex >>> >>>> Thomas >>>>> Alex >>>>> >>>>> >>>>>> Thomas >>>>>>> Alex >>>>>>> >>>>>>>> Thomas >>>>>>>> On Oct 26, 2009, at 4:56 PM, Alexandru Petrescu wrote: >>>>>>>>> Updated list: added PPP IPv6, ND, ICMPv6, MIPv6 family. >>>>>>>>> >>>>>>>>> IPv4 >>>>>>>>> ---- >>>>>>>>> mDNS >>>>>>>>> ARP (the parts in IPv4 LL RFC) >>>>>>>>> >>>>>>>>> IPv6 >>>>>>>>> ---- >>>>>>>>> DHCP >>>>>>>>> OSPF >>>>>>>>> RIPng >>>>>>>>> MLD >>>>>>>>> OLSR (a particular implementation) >>>>>>>>> ND >>>>>>>>> PPP IPv6 >>>>>>>>> ICMPv6 >>>>>>>>> SLAAC >>>>>>>>> FMIPv6 >>>>>>>>> MIPv6/NEMOv6/PMIPv6 >>>>>>>>> >>>>>>>>> Alex >>>>>>>>> >>>>>>>>> Alexandru Petrescu a =E9crit : >>>>>>>>>> In several earlier discussions question was raised about =20 >>>>>>>>>> which protocols use link-local addresses. >>>>>>>>>> IPv4 >>>>>>>>>> ---- >>>>>>>>>> mDNS >>>>>>>>>> ARP (the parts in IPv4 LL RFC) >>>>>>>>>> IPv6 >>>>>>>>>> ---- >>>>>>>>>> DHCP >>>>>>>>>> OSPF >>>>>>>>>> RIPng >>>>>>>>>> MLD >>>>>>>>>> OLSR (a particular implementation) >>>>>>>>>> If you know any other, feel free to add. I think it may be =20= >>>>>>>>>> useful to add to the AUTOCONF addressing model draft(s). >>>>>>>>>> (I think Teco may have already written such a list but I =20 >>>>>>>>>> have hard time >>>>>>>>>> finding it). >>>>>>>>>> Alex >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>> >>> > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From sratliff@cisco.com Mon Oct 26 09:50: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 2191128C311 for ; Mon, 26 Oct 2009 09:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.191 X-Spam-Level: X-Spam-Status: No, score=-4.191 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 RvuAdr0Aann5 for ; Mon, 26 Oct 2009 09:50:21 -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 9394F28C2C6 for ; Mon, 26 Oct 2009 09:49:48 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAKBv5UpAZnwM/2dsb2JhbACbHKV1lwqEPwSBXg X-IronPort-AV: E=Sophos;i="4.44,626,1249257600"; d="scan'208";a="64968542" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 26 Oct 2009 16:50:01 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9QGo1Zk018986; Mon, 26 Oct 2009 16:50:01 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 12:50:01 -0400 Received: from 64.102.54.119 ([64.102.54.119]) by xmb-rtp-208.amer.cisco.com ([64.102.31.43]) with Microsoft Exchange Server HTTP-DAV ; Mon, 26 Oct 2009 16:50:00 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 26 Oct 2009 12:50:00 -0400 From: sratliff To: Alexandru Petrescu , Teco Boot Message-ID: Thread-Topic: [Autoconf] Adding list of LL protocols for-against (was: Protocols involving link-local addresses) Thread-Index: AcpWXFsqIeGocydBnkWltsDOtWsF+w== In-Reply-To: <4AE5D02B.8070809@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 26 Oct 2009 16:50:01.0483 (UTC) FILETIME=[5C0D35B0:01CA565C] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Adding list of LL protocols for-against (was: Protocols involving link-local addresses) 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, 26 Oct 2009 16:50:23 -0000 No. I think this discussion has become circular in nature, and is not productive.=20 Regards, Stan On 10/26/09 12:36 PM, "Alexandru Petrescu" wrote: > Teco, AUTOCONFers, >=20 > Do you agree with adding a list of IP protocols using link-local > addresses, in the AUTOCONF addressing model, and which may be pertinent > to MANET? >=20 > -yes > -no >=20 > Thanks, >=20 > Alex >=20 > Teco Boot a =E9crit : >> I would limit the list to protocols that are applicable to MANETs. >> This is a non-empty list. For IPv6: >> OSPF-MANET >> NDP RA >> MLD >> And I have my own middleware products that use LL for Peer discovery >> or 1-hop message disctribution (I could use hop-limit=3D1). >>=20 >> Teco. >>=20 >>> -----Oorspronkelijk bericht----- >>> Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namen= s >>> Alexandru Petrescu >>> Verzonden: maandag 26 oktober 2009 16:34 >>> Aan: autoconf@ietf.org >>> Onderwerp: [Autoconf] Protocols involving link-local addresses >>>=20 >>> In several earlier discussions question was raised about which protocol= s >>> use link-local addresses. >>>=20 >>> IPv4 >>> ---- >>> mDNS >>> ARP (the parts in IPv4 LL RFC) >>>=20 >>> IPv6 >>> ---- >>> DHCP >>> OSPF >>> RIPng >>> MLD >>> OLSR (a particular implementation) >>>=20 >>> If you know any other, feel free to add. I think it may be useful to >>> add to the AUTOCONF addressing model draft(s). >>>=20 >>> (I think Teco may have already written such a list but I have hard time >>> finding it). >>=20 >>=20 >> I would limit the list to protocols that are applicable to MANETs. >> This is a non-empty list. For IPv6: >> OSPF-MANET >> NDP RA >> MLD >> And I have my own middleware products that use LL for Peer discovery >> or 1-hop message disctribution (I could use hop-limit=3D1). >> I would prefer LLs for OLSR also. >>=20 >> Teco. >>=20 >>=20 >>> Alex >>>=20 >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf >>=20 >>=20 >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From emmanuel.baccelli@gmail.com Mon Oct 26 09:55: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 6F60D28C107 for ; Mon, 26 Oct 2009 09:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.812 X-Spam-Level: X-Spam-Status: No, score=-1.812 tagged_above=-999 required=5 tests=[AWL=0.164, 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 15El+Uxa9GR4 for ; Mon, 26 Oct 2009 09:55:48 -0700 (PDT) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 3547C3A6877 for ; Mon, 26 Oct 2009 09:55:48 -0700 (PDT) Received: by ywh13 with SMTP id 13so15434164ywh.29 for ; Mon, 26 Oct 2009 09:55:58 -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=fn9vFNy3JGGNTsVauUTwh2uFG+xOF2X77qnIbGO9Fn8=; b=SI0sQ4peNaeYXk3gOsJrertA+VxJSrrR8TcadftVSnw+H6/jE79790ALlrpeK9IN/T Up6XS9OZZWsqe6I6gspw78ntsqcJrFad5bJyBNI1kEqpPFpmrcb2CvtpvHm9/fj8NX70 kGgg42cp3h4/1ZTFbbrxm/8a6QeY/5pZp2W40= 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=rLqcMzKAzXY5PjBir9cIJ8MQGVATk9bEHQwSflM4vvFHgfjbCKOHMw9l5jfjqC59k8 2BJMvYE00IQMn6Bwpo0tu41VaDNBdAhBFXShZkM6cSiIqsCwE72B6bv5TZ+eqUcvMJnO YGQPmFZfE4T73cR699gjhHZVdOc2aVOFSKETM= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.90.41.29 with SMTP id o29mr7121870ago.101.1256576158090; Mon, 26 Oct 2009 09:55:58 -0700 (PDT) In-Reply-To: References: <4AE5D02B.8070809@gmail.com> From: Emmanuel Baccelli Date: Mon, 26 Oct 2009 17:55:38 +0100 X-Google-Sender-Auth: 817ad4e15cad4c54 Message-ID: To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=0016361e83da8948860476d96fb1 Subject: Re: [Autoconf] Adding list of LL protocols for-against (was: Protocols involving link-local addresses) 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, 26 Oct 2009 16:55:49 -0000 --0016361e83da8948860476d96fb1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 26, 2009 at 5:50 PM, sratliff wrote: > No. > > I think this discussion has become circular in nature, and is not > productive. > +1 Emmanuel > > Regards, > Stan > > > > On 10/26/09 12:36 PM, "Alexandru Petrescu" > wrote: > > > Teco, AUTOCONFers, > > > > Do you agree with adding a list of IP protocols using link-local > > addresses, in the AUTOCONF addressing model, and which may be pertinent > > to MANET? > > > > -yes > > -no > > > > Thanks, > > > > Alex > > > > Teco Boot a =E9crit : > >> I would limit the list to protocols that are applicable to MANETs. > >> This is a non-empty list. For IPv6: > >> OSPF-MANET > >> NDP RA > >> MLD > >> And I have my own middleware products that use LL for Peer discovery > >> or 1-hop message disctribution (I could use hop-limit=3D1). > >> > >> Teco. > >> > >>> -----Oorspronkelijk bericht----- > >>> Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] > Namens > >>> Alexandru Petrescu > >>> Verzonden: maandag 26 oktober 2009 16:34 > >>> Aan: autoconf@ietf.org > >>> Onderwerp: [Autoconf] Protocols involving link-local addresses > >>> > >>> In several earlier discussions question was raised about which > protocols > >>> use link-local addresses. > >>> > >>> IPv4 > >>> ---- > >>> mDNS > >>> ARP (the parts in IPv4 LL RFC) > >>> > >>> IPv6 > >>> ---- > >>> DHCP > >>> OSPF > >>> RIPng > >>> MLD > >>> OLSR (a particular implementation) > >>> > >>> If you know any other, feel free to add. I think it may be useful to > >>> add to the AUTOCONF addressing model draft(s). > >>> > >>> (I think Teco may have already written such a list but I have hard ti= me > >>> finding it). > >> > >> > >> I would limit the list to protocols that are applicable to MANETs. > >> This is a non-empty list. For IPv6: > >> OSPF-MANET > >> NDP RA > >> MLD > >> And I have my own middleware products that use LL for Peer discovery > >> or 1-hop message disctribution (I could use hop-limit=3D1). > >> I would prefer LLs for OLSR also. > >> > >> Teco. > >> > >> > >>> Alex > >>> > >>> _______________________________________________ > >>> 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 > --0016361e83da8948860476d96fb1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Oct 26, 2009 at 5:50 PM, sratlif= f <sratliff@cisc= o.com> wrote:
No.

I think this discussion has become circular in nature, and is not
productive.

+1
Emmanuel
=
=A0

Regards,
Stan




=A0

On 10/26/09 12:36 PM, "Alexandru Petrescu" <alexandru.petrescu@gmail.com>
wrote:

> Teco, AUTOCONFers,
>
> Do you agree with adding a list of IP protocols using link-local
> addresses, in the AUTOCONF addressing model, and which may be pertinen= t
> to MANET?
>
> -yes
> -no
>
> Thanks,
>
> Alex
>
> Teco Boot a =E9crit :
>> I would limit the list to protocols that are applicable to MANETs.=
>> This is a non-empty list. For IPv6:
>> =A0 OSPF-MANET
>> =A0 NDP RA
>> =A0 MLD
>> And I have my own middleware products that use LL for Peer discove= ry
>> or 1-hop message disctribution (I could use hop-limit=3D1).
>>
>> Teco.
>>
>>> -----Oorspronkelijk bericht-----
>>> Van: autoconf-bou= nces@ietf.org [mailto:auto= conf-bounces@ietf.org] Namens
>>> Alexandru Petrescu
>>> Verzonden: maandag 26 oktober 2009 16:34
>>> Aan: autoconf@ietf.org
>>> Onderwerp: [Autoconf] Protocols involving link-local addresses=
>>>
>>> In several earlier discussions question was raised about which= protocols
>>> use link-local addresses.
>>>
>>> IPv4
>>> ----
>>> mDNS
>>> ARP (the parts in IPv4 LL RFC)
>>>
>>> IPv6
>>> ----
>>> DHCP
>>> OSPF
>>> RIPng
>>> MLD
>>> OLSR (a particular implementation)
>>>
>>> If you know any other, feel free to add. =A0I think it may be = useful to
>>> add to the AUTOCONF addressing model draft(s).
>>>
>>> (I think Teco may have already written such a list but I have = hard time
>>> =A0finding it).
>>
>>
>> I would limit the list to protocols that are applicable to MANETs.=
>> This is a non-empty list. For IPv6:
>> =A0 OSPF-MANET
>> =A0 NDP RA
>> =A0 MLD
>> And I have my own middleware products that use LL for Peer discove= ry
>> or 1-hop message disctribution (I could use hop-limit=3D1).
>> I would prefer LLs for OLSR also.
>>
>> Teco.
>>
>>
>>> Alex
>>>
>>> _______________________________________________
>>> 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

--0016361e83da8948860476d96fb1-- From alexandru.petrescu@gmail.com Mon Oct 26 09:57: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 6DC4A28C114 for ; Mon, 26 Oct 2009 09:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[AWL=0.089, 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 xO1hxZrrOGAM for ; Mon, 26 Oct 2009 09:57:13 -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 EA6B028C104 for ; Mon, 26 Oct 2009 09:57:12 -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 n9QGvO4W024229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 17:57:24 +0100 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 n9QGvOMs031850; Mon, 26 Oct 2009 17:57:24 +0100 (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 n9QGvNDU021861; Mon, 26 Oct 2009 17:57:23 +0100 Message-ID: <4AE5D4F3.1010100@gmail.com> Date: Mon, 26 Oct 2009 17:57:23 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <4AE5C151.6000800@gmail.com> <4AE5C6BD.2030501@gmail.com> <4AE5C9CB.5030807@gmail.com> <4AE5CCF9.3060505@gmail.com> <4AE5D12D.6090605@gmail.com> <1AE426A5-A60D-4551-AE6B-AE2E9E63646B@thomasclausen.org> <4AE5D280.3070206@gmail.com> <080FCBF6-2D48-4D8A-91EA-8BF8B0BA51B8@thomasclausen.org> In-Reply-To: <080FCBF6-2D48-4D8A-91EA-8BF8B0BA51B8@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Protocols involving link-local addresses 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, 26 Oct 2009 16:57:14 -0000 Thomas, the OLSR implementation I talked about was reported in an email today. Strange you don't want to talk about OLSR and LLs. Alex Thomas Heide Clausen a écrit : > > On Oct 26, 2009, at 5:46 PM, Alexandru Petrescu wrote: > >> Thomas, it is not clear your first occurence of "discourage LL". >> >> If I insist, it is for that reason. Were you to put it last, maybe it >> would have been ok. >> > > The above makes no sense? > >> You seem ready to spend hours of discussion but don't touch that >> document. Why? > > I'm not an author. > > But, I agree with the document content. > >> >> Why does that OLSR implementation use LLs? > > Not my code, I do not know which implementation you're talking about -- > I don't know. > > But this time, EOD for real from my side. > > Thomas > >> Alex >> >> Thomas Heide Clausen a écrit : >>> On Oct 26, 2009, at 5:41 PM, Alexandru Petrescu wrote: >>>> Thomas Heide Clausen a écrit : >>>>> On Oct 26, 2009, at 5:23 PM, Alexandru Petrescu wrote: >>>>>> Thomas Heide Clausen a écrit : >>>>>>> On Oct 26, 2009, at 5:09 PM, Alexandru Petrescu wrote: >>>>>>>> Thomas Heide Clausen a écrit : >>>>>>>>> That's great and these all run fine across a MANET. That's the >>>>>>>>> beauty of end-to-end, you see, as long as the routers present >>>>>>>>> "just an IP hop", then applications on end systems are happy. >>>>>>>> >>>>>>>> I don't understand you. Please add a protocol to my list; that >>>>>>>> is the goal of the list. >>>>>>>> >>>>>>>> Presenting "just an IP" hop is like routers acting at L2. Is >>>>>>>> this some sort of a layer violation? >>>>>>>> >>>>>>> No, it's actually exactly what a router is supposed to do. >>>>>> >>>>>> Hmm... no doubt we are in contradiction. >>>>>> >>>>>> Two routers --R1--R2-- don't present an IP hop, there are three >>>>>> subnets and two IP hops. >>>>>> >>>>>> I think you don't agree with this model at all and you propose >>>>>> >>>>>> ---|----|--- >>>>>> R1 R2 >>>>>> >>>>>> where R1 and R2 IP forward with host-based routes. I know. I >>>>>> just don't see it that way. >>>>>> >>>>>> I believe both views should be accepted. >>>>>> >>>>> No, Alex, that's neither how it is. Nor is it how I see matters. >>>>> h1----R1--- ........ --Rn----h2 >>>>> Presents the host (h1) with one IP hop towards the router (R1). >>>> >>>> On which side of R1 do you discourage LLs? >>>> >>> I'll let you take a wild guess.....no, actually, I won't. The links >>> between R's... >>>>> Whatever happens between R1 and Rn is purely transparent to h1. It >>>>> can be avian carries, for all that h1 cares. >>>>> The link between h1 and R1 is whatever we usually have on the edge. >>>>> You can run NDP, mdns, ... over it, you can define subnets on that >>>>> link -- the link h1--R1. It's just a classic IP link. >>>> >>>> Ok! Say so in the addressing model draft. >>> No, this document is not about defining the properties of a classic >>> IP link. That's done before (and better than this WG could) elsewhere >>> by other people. >>>> >>>>> All works well >>>>> Between R1 and Rn there may be a lot of "magic" going on. Strange >>>>> links, complicated routing protocols. >>>> >>>> DO you discourage LLs on this "magic"? Say so in the draft. >>> That's what the draft says already, and which you have been disputing >>> for days now...... >>> EOD. >>> Thomas >>>> >>>>> It's a "routing domain" -- almost like magic ;) >>>>> h1 won't know. h1 shouldn't know -- because the interface of h1 to >>>>> the rest of the world is....an IP hop to R1. h1 will use R1 to >>>>> connect "to the rest of the world". >>>>> R1 should (on the interface towards the other routers) be aware of >>>>> that "magic", including those advanced algorithms working on >>>>> complicated data structures to find paths towards (in this case) >>>>> h2. That's alright, R1 is build for that purpose - to do exactly >>>>> that magic ;) >>>>> In the Internet, R1 and all the other R's would run OSPF or ISIS, >>>>> usually. In a MANET, it'd run a MANET protocol such as AODV, DYMO, >>>>> OLSR, >>>> >>>> But some OLSR does use LLs - do you discourage that? >>>> >>>>> .... >>>>> If you disagree with that then -- I'm sorry to say -- you disagree >>>>> with the Internet. >>>> >>>> No, I agree with Internet. >>>> >>>>> I'm not sure how much clearer I can make it, so I'll jump out of >>>>> this discussion now. >>>> >>>> But we were on the point to converge! >>>> >>>> Alex >>>> >>>>> Thomas >>>>>> Alex >>>>>> >>>>>> >>>>>>> Thomas >>>>>>>> Alex >>>>>>>> >>>>>>>>> Thomas >>>>>>>>> On Oct 26, 2009, at 4:56 PM, Alexandru Petrescu wrote: >>>>>>>>>> Updated list: added PPP IPv6, ND, ICMPv6, MIPv6 family. >>>>>>>>>> >>>>>>>>>> IPv4 >>>>>>>>>> ---- >>>>>>>>>> mDNS >>>>>>>>>> ARP (the parts in IPv4 LL RFC) >>>>>>>>>> >>>>>>>>>> IPv6 >>>>>>>>>> ---- >>>>>>>>>> DHCP >>>>>>>>>> OSPF >>>>>>>>>> RIPng >>>>>>>>>> MLD >>>>>>>>>> OLSR (a particular implementation) >>>>>>>>>> ND >>>>>>>>>> PPP IPv6 >>>>>>>>>> ICMPv6 >>>>>>>>>> SLAAC >>>>>>>>>> FMIPv6 >>>>>>>>>> MIPv6/NEMOv6/PMIPv6 >>>>>>>>>> >>>>>>>>>> Alex >>>>>>>>>> >>>>>>>>>> Alexandru Petrescu a écrit : >>>>>>>>>>> In several earlier discussions question was raised about >>>>>>>>>>> which protocols use link-local addresses. >>>>>>>>>>> IPv4 >>>>>>>>>>> ---- >>>>>>>>>>> mDNS >>>>>>>>>>> ARP (the parts in IPv4 LL RFC) >>>>>>>>>>> IPv6 >>>>>>>>>>> ---- >>>>>>>>>>> DHCP >>>>>>>>>>> OSPF >>>>>>>>>>> RIPng >>>>>>>>>>> MLD >>>>>>>>>>> OLSR (a particular implementation) >>>>>>>>>>> If you know any other, feel free to add. I think it may be >>>>>>>>>>> useful to add to the AUTOCONF addressing model draft(s). >>>>>>>>>>> (I think Teco may have already written such a list but I have >>>>>>>>>>> hard time >>>>>>>>>>> finding it). >>>>>>>>>>> Alex >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>> >>>> >> >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > From alexandru.petrescu@gmail.com Mon Oct 26 09:57: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 765F028C114 for ; Mon, 26 Oct 2009 09:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=0.088, 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 wF9OvwFZ6-ss for ; Mon, 26 Oct 2009 09:57: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 5203D28C107 for ; Mon, 26 Oct 2009 09:57:25 -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 n9QGvb1I024375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 17:57:37 +0100 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 n9QGvbwA031926; Mon, 26 Oct 2009 17:57:37 +0100 (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 n9QGvbBd021908; Mon, 26 Oct 2009 17:57:37 +0100 Message-ID: <4AE5D500.8090808@gmail.com> Date: Mon, 26 Oct 2009 17:57:36 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Emmanuel Baccelli References: <4AE5D02B.8070809@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] Adding list of LL protocols for-against (was: Protocols involving link-local addresses) 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, 26 Oct 2009 16:57:26 -0000 Well yes, discussion may sound circular in nature. You could ignore it. You may also wonder why am I posting tones of messages when I'm otherwise very silent on many lists where I look, including this one. Alex Emmanuel Baccelli a écrit : > > > On Mon, Oct 26, 2009 at 5:50 PM, sratliff > wrote: > > No. > > I think this discussion has become circular in nature, and is not > productive. > > > +1 > Emmanuel > > > > Regards, > Stan > > > > > > > > On 10/26/09 12:36 PM, "Alexandru Petrescu" > > > wrote: > > > Teco, AUTOCONFers, > > > > Do you agree with adding a list of IP protocols using link-local > > addresses, in the AUTOCONF addressing model, and which may be > pertinent > > to MANET? > > > > -yes > > -no > > > > Thanks, > > > > Alex > > > > Teco Boot a écrit : > >> I would limit the list to protocols that are applicable to MANETs. > >> This is a non-empty list. For IPv6: > >> OSPF-MANET > >> NDP RA > >> MLD > >> And I have my own middleware products that use LL for Peer discovery > >> or 1-hop message disctribution (I could use hop-limit=1). > >> > >> Teco. > >> > >>> -----Oorspronkelijk bericht----- > >>> Van: autoconf-bounces@ietf.org > [mailto:autoconf-bounces@ietf.org > ] Namens > >>> Alexandru Petrescu > >>> Verzonden: maandag 26 oktober 2009 16:34 > >>> Aan: autoconf@ietf.org > >>> Onderwerp: [Autoconf] Protocols involving link-local addresses > >>> > >>> In several earlier discussions question was raised about which > protocols > >>> use link-local addresses. > >>> > >>> IPv4 > >>> ---- > >>> mDNS > >>> ARP (the parts in IPv4 LL RFC) > >>> > >>> IPv6 > >>> ---- > >>> DHCP > >>> OSPF > >>> RIPng > >>> MLD > >>> OLSR (a particular implementation) > >>> > >>> If you know any other, feel free to add. I think it may be > useful to > >>> add to the AUTOCONF addressing model draft(s). > >>> > >>> (I think Teco may have already written such a list but I have > hard time > >>> finding it). > >> > >> > >> I would limit the list to protocols that are applicable to MANETs. > >> This is a non-empty list. For IPv6: > >> OSPF-MANET > >> NDP RA > >> MLD > >> And I have my own middleware products that use LL for Peer discovery > >> or 1-hop message disctribution (I could use hop-limit=1). > >> I would prefer LLs for OLSR also. > >> > >> Teco. > >> > >> > >>> Alex > >>> > >>> _______________________________________________ > >>> 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 > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From cjbc@it.uc3m.es Mon Oct 26 09:59:46 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 3A2403A696C for ; Mon, 26 Oct 2009 09:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.533 X-Spam-Level: X-Spam-Status: No, score=-5.533 tagged_above=-999 required=5 tests=[AWL=0.166, 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 DyPrl+gQx8mH for ; Mon, 26 Oct 2009 09:59:45 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 9CCB53A6877 for ; Mon, 26 Oct 2009 09:59:28 -0700 (PDT) Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id EEDB27F3FC9; Mon, 26 Oct 2009 17:59:40 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Alexandru Petrescu In-Reply-To: <4AE5D02B.8070809@gmail.com> References: <4AE5C151.6000800@gmail.com> <014f01ca5658$cd6130d0$68239270$@nl> <4AE5D02B.8070809@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-JUgfQGa2iFMl9maovF5n" Organization: Universidad Carlos III de Madrid Date: Mon, 26 Oct 2009 17:59:42 +0100 Message-Id: <1256576382.7742.21.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16972.000 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Adding list of LL protocols for-against (was: Protocols involving link-local addresses) 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: Mon, 26 Oct 2009 16:59:46 -0000 --=-JUgfQGa2iFMl9maovF5n Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Yes, I think it is quite useful. Carlos On Mon, 2009-10-26 at 17:36 +0100, Alexandru Petrescu wrote: > Teco, AUTOCONFers, >=20 > Do you agree with adding a list of IP protocols using link-local=20 > addresses, in the AUTOCONF addressing model, and which may be pertinent=20 > to MANET? >=20 > -yes > -no >=20 > Thanks, >=20 > Alex >=20 > Teco Boot a =E9crit : > > I would limit the list to protocols that are applicable to MANETs. > > This is a non-empty list. For IPv6: > > OSPF-MANET > > NDP RA > > MLD > > And I have my own middleware products that use LL for Peer discovery > > or 1-hop message disctribution (I could use hop-limit=3D1). > >=20 > > Teco. > >=20 > >> -----Oorspronkelijk bericht----- > >> Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Name= ns > >> Alexandru Petrescu > >> Verzonden: maandag 26 oktober 2009 16:34 > >> Aan: autoconf@ietf.org > >> Onderwerp: [Autoconf] Protocols involving link-local addresses > >> > >> In several earlier discussions question was raised about which protoco= ls > >> use link-local addresses. > >> > >> IPv4 > >> ---- > >> mDNS > >> ARP (the parts in IPv4 LL RFC) > >> > >> IPv6 > >> ---- > >> DHCP > >> OSPF > >> RIPng > >> MLD > >> OLSR (a particular implementation) > >> > >> If you know any other, feel free to add. I think it may be useful to > >> add to the AUTOCONF addressing model draft(s). > >> > >> (I think Teco may have already written such a list but I have hard tim= e > >> finding it). > >=20 > >=20 > > I would limit the list to protocols that are applicable to MANETs. > > This is a non-empty list. For IPv6: > > OSPF-MANET > > NDP RA > > MLD > > And I have my own middleware products that use LL for Peer discovery > > or 1-hop message disctribution (I could use hop-limit=3D1). > > I would prefer LLs for OLSR also. > >=20 > > Teco. > >=20 > >=20 > >> Alex > >> > >> _______________________________________________ > >> Autoconf mailing list > >> Autoconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/autoconf > >=20 > >=20 >=20 >=20 > _______________________________________________ > 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 --=-JUgfQGa2iFMl9maovF5n Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkrl1X0ACgkQNdy6TdFwT2d/hACglhSkSNT3+CUKqepp6ijNgY9K FN0AoOMNIjr7JBZQdNrrswnkQUYtG4QU =ME+J -----END PGP SIGNATURE----- --=-JUgfQGa2iFMl9maovF5n-- From charles.perkins@earthlink.net Mon Oct 26 10:09:46 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 B298C3A6877 for ; Mon, 26 Oct 2009 10:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[AWL=0.062, 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 RP75KOVUsTPm for ; Mon, 26 Oct 2009 10:09:46 -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 6A5453A68D5 for ; Mon, 26 Oct 2009 10:09:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=gbiURK9BP/ySeynR7hy4QTcuqC+wDxxzdSPWg6vUgEGJrYdAM5Kbi2pEju70Rck3; 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.16]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1N2T4v-00063I-Dr; Mon, 26 Oct 2009 13:09:57 -0400 Message-ID: <4AE5D7E5.60301@earthlink.net> Date: Mon, 26 Oct 2009 10:09:57 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Teco Boot References: <4AE5C151.6000800@gmail.com> <014f01ca5658$cd6130d0$68239270$@nl> In-Reply-To: <014f01ca5658$cd6130d0$68239270$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52193d30ff5ff11e000c486e1f72539f66350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Protocols involving link-local addresses 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, 26 Oct 2009 17:09:46 -0000 Hello Teco, Your list is much more sensible and to the point. I have some comments. Teco Boot wrote: > I would limit the list to protocols that are applicable to MANETs. > This is a non-empty list. For IPv6: > OSPF-MANET > Ouch. I've been trying to avoid the necessity to go study that document. Does OSPF-MANET really require verification that link-local addresses are unique across the entire MANET? > NDP RA > I really doubt we could have any sizable MANET networks if every node is beaconing RAs and running NUD. This would be a good topic for a research paper, but my guess is that anything over a couple of dozen nodes at low speed would just not work. > MLD > But, see below... > And I have my own middleware products that use LL for Peer discovery > or 1-hop message disctribution (I could use hop-limit=1). > I am firmly in the "hop-limit == 1", or, even better, "hop-limit received as 255" camp. It really works. Regards, Charlie P. From charles.perkins@earthlink.net Mon Oct 26 10:15:53 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 4ED443A686C for ; Mon, 26 Oct 2009 10:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=0.057, 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 CBphsDdGGJ5V for ; Mon, 26 Oct 2009 10:15:52 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id A06453A67AC for ; Mon, 26 Oct 2009 10:15:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=fSLv3bsAjMJg6V0WPvOXc04oTco5FI7PiGJ6+lrzTYR7NqUlb4/71AuORpUGh6Dn; 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.16]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1N2TAq-0002tE-Aj; Mon, 26 Oct 2009 12:16:04 -0500 Message-ID: <4AE5D954.8020705@earthlink.net> Date: Mon, 26 Oct 2009 10:16:04 -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: <4AE5C151.6000800@gmail.com> <4AE5C6BD.2030501@gmail.com> <4AE5C9CB.5030807@gmail.com> <5A0019AD-0BB0-4EAF-969E-73E3F1DAF1DE@thomasclausen.org> <4AE5CC23.1090105@gmail.com> <4AE5CF72.9070700@gmail.com> In-Reply-To: <4AE5CF72.9070700@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5235484392eaa034077bd50473477ecc22350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Protocols involving link-local addresses 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, 26 Oct 2009 17:15:53 -0000 Hello Alex, Alexandru Petrescu wrote: > >> >> Stuff that uses "link-local addresses" usually work across a *link* >> not across a *network*, correct? > > Right. There are ways of expressing this (stay on link, don't move > out); they shouldn't simply be "discouraged". This seems to make your point of view much clearer. You'd like to have a network of wireless nodes that don't move in relation to their link. I really don't see why we should hold up the rest of the work that needs to be done in order to conform to that model. > > You have now three people: you, myself and Teco who contributed to the > list. That sounds as a good candidate for inclusion. > > Or are you going to ignore this too? Sounds pretty aggressive. With as much attention that has been paid to that list (which missed the point) I don't understand why you claim it was ignored. > >> If your "router cloud" is a MANET or an IS-IS or an OSPF system >> doesn't make an iota of difference. The end-systems (hosts) have no >> idea of what's happening inside that cloud, how the links between >> routers look etc. > > LLs are not for end-systems only (hosts) they are for routers too. The fact is that routing protocols need to be modified in order to work well with ad hoc networks. And as we have discovered so do the address autoconfiguration protocols. Or else we can be satisfied with tiny, very slow networks. Regards, Charlie P. From charles.perkins@earthlink.net Mon Oct 26 10:18: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 380F63A6AE7 for ; Mon, 26 Oct 2009 10:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.053, 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 3xKI0pwmw5LR for ; Mon, 26 Oct 2009 10:18:16 -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 503B33A686C for ; Mon, 26 Oct 2009 10:18:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=FVUM57/s25ANOomoLb1beHaGTJKyszNIZ/hyzA8QrD1LjA8CdhqHvOm7RN1/ofVP; 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.16]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1N2TDB-0008SM-KN; Mon, 26 Oct 2009 13:18:29 -0400 Message-ID: <4AE5D9E6.4060207@earthlink.net> Date: Mon, 26 Oct 2009 10:18:30 -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: <4AE5C151.6000800@gmail.com> <014f01ca5658$cd6130d0$68239270$@nl> <4AE5D02B.8070809@gmail.com> In-Reply-To: <4AE5D02B.8070809@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f523ada50f925a0ccd11b2c51740af0e6d9350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Adding list of LL protocols for-against 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, 26 Oct 2009 17:18:17 -0000 Hello Alex, If MIPv6 is on that list, then the list is really entirely irrelevant, and yet another ring attraction in the circus of pointless distractions. Regards, Charlie P. Alexandru Petrescu wrote: > Teco, AUTOCONFers, > > Do you agree with adding a list of IP protocols using link-local > addresses, in the AUTOCONF addressing model, and which may be > pertinent to MANET? > > -yes > -no > > Thanks, > > Alex > > Teco Boot a écrit : >> I would limit the list to protocols that are applicable to MANETs. >> This is a non-empty list. For IPv6: >> OSPF-MANET >> NDP RA >> MLD >> And I have my own middleware products that use LL for Peer discovery >> or 1-hop message disctribution (I could use hop-limit=1). >> >> Teco. >> >>> -----Oorspronkelijk bericht----- >>> Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] >>> Namens >>> Alexandru Petrescu >>> Verzonden: maandag 26 oktober 2009 16:34 >>> Aan: autoconf@ietf.org >>> Onderwerp: [Autoconf] Protocols involving link-local addresses >>> >>> In several earlier discussions question was raised about which >>> protocols >>> use link-local addresses. >>> >>> IPv4 >>> ---- >>> mDNS >>> ARP (the parts in IPv4 LL RFC) >>> >>> IPv6 >>> ---- >>> DHCP >>> OSPF >>> RIPng >>> MLD >>> OLSR (a particular implementation) >>> >>> If you know any other, feel free to add. I think it may be useful to >>> add to the AUTOCONF addressing model draft(s). >>> >>> (I think Teco may have already written such a list but I have hard time >>> finding it). >> >> >> I would limit the list to protocols that are applicable to MANETs. >> This is a non-empty list. For IPv6: >> OSPF-MANET >> NDP RA >> MLD >> And I have my own middleware products that use LL for Peer discovery >> or 1-hop message disctribution (I could use hop-limit=1). >> I would prefer LLs for OLSR also. >> >> Teco. >> >> >>> Alex >>> >>> _______________________________________________ >>> 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 alexandru.petrescu@gmail.com Mon Oct 26 10:20: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 8B5A53A63EC for ; Mon, 26 Oct 2009 10:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=0.087, 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 139wOfkprhil for ; Mon, 26 Oct 2009 10:20:41 -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 564EF3A6AE7 for ; Mon, 26 Oct 2009 10:20:35 -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 n9QHKjPO007569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 18:20:46 +0100 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 n9QHKjrh003025; Mon, 26 Oct 2009 18:20:45 +0100 (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 n9QHKiK2001244; Mon, 26 Oct 2009 18:20:45 +0100 Message-ID: <4AE5DA6C.5030603@gmail.com> Date: Mon, 26 Oct 2009 18:20:44 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4AE5C151.6000800@gmail.com> <014f01ca5658$cd6130d0$68239270$@nl> <4AE5D02B.8070809@gmail.com> <4AE5D9E6.4060207@earthlink.net> In-Reply-To: <4AE5D9E6.4060207@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Adding list of LL protocols for-against 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, 26 Oct 2009 17:20:42 -0000 Charles E. Perkins a écrit : > > Hello Alex, > > If MIPv6 is on that list, then the > list is really entirely irrelevant, and > yet another ring attraction in the > circus of pointless distractions. Sorry for distracting you, Charles, but... anyways... Alex > > Regards, > Charlie P. > > > Alexandru Petrescu wrote: >> Teco, AUTOCONFers, >> >> Do you agree with adding a list of IP protocols using link-local >> addresses, in the AUTOCONF addressing model, and which may be >> pertinent to MANET? >> >> -yes >> -no >> >> Thanks, >> >> Alex >> >> Teco Boot a écrit : >>> I would limit the list to protocols that are applicable to MANETs. >>> This is a non-empty list. For IPv6: >>> OSPF-MANET >>> NDP RA >>> MLD >>> And I have my own middleware products that use LL for Peer discovery >>> or 1-hop message disctribution (I could use hop-limit=1). >>> >>> Teco. >>> >>>> -----Oorspronkelijk bericht----- >>>> Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] >>>> Namens >>>> Alexandru Petrescu >>>> Verzonden: maandag 26 oktober 2009 16:34 >>>> Aan: autoconf@ietf.org >>>> Onderwerp: [Autoconf] Protocols involving link-local addresses >>>> >>>> In several earlier discussions question was raised about which >>>> protocols >>>> use link-local addresses. >>>> >>>> IPv4 >>>> ---- >>>> mDNS >>>> ARP (the parts in IPv4 LL RFC) >>>> >>>> IPv6 >>>> ---- >>>> DHCP >>>> OSPF >>>> RIPng >>>> MLD >>>> OLSR (a particular implementation) >>>> >>>> If you know any other, feel free to add. I think it may be useful to >>>> add to the AUTOCONF addressing model draft(s). >>>> >>>> (I think Teco may have already written such a list but I have hard time >>>> finding it). >>> >>> >>> I would limit the list to protocols that are applicable to MANETs. >>> This is a non-empty list. For IPv6: >>> OSPF-MANET >>> NDP RA >>> MLD >>> And I have my own middleware products that use LL for Peer discovery >>> or 1-hop message disctribution (I could use hop-limit=1). >>> I would prefer LLs for OLSR also. >>> >>> Teco. >>> >>> >>>> Alex >>>> >>>> _______________________________________________ >>>> 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 teco@inf-net.nl Mon Oct 26 10:51: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 A6B4028C0FB for ; Mon, 26 Oct 2009 10:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, 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 PB-VEckPF+-w for ; Mon, 26 Oct 2009 10:51:41 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 4E63828B23E for ; Mon, 26 Oct 2009 10:51:41 -0700 (PDT) Received: (qmail 4212 invoked from network); 26 Oct 2009 18:51:45 +0100 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 26 Oct 2009 18:51:45 +0100 From: "Teco Boot" To: "'Charles E. Perkins'" References: <4AE5C151.6000800@gmail.com> <014f01ca5658$cd6130d0$68239270$@nl> <4AE5D7E5.60301@earthlink.net> In-Reply-To: <4AE5D7E5.60301@earthlink.net> Date: Mon, 26 Oct 2009 18:51:14 +0100 Message-ID: <017901ca5664$fb20a760$f161f620$@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: AcpWXyedYr+tLudxT9K6XxKOSIHGmwAAs5dg Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] Protocols involving link-local addresses 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, 26 Oct 2009 17:51:43 -0000 Hi Charlie, >Your list is much more sensible and to the point. Thanks. > >I have some comments. > >Teco Boot wrote: >> I would limit the list to protocols that are applicable to MANETs. >> This is a non-empty list. For IPv6: >> OSPF-MANET >> > >Ouch. I've been trying to avoid the necessity to go >study that document. Does OSPF-MANET really >require verification that link-local addresses are >unique across the entire MANET? There are three of them. The base spec says OSPF messages are send with LL source address, unless . OSPF-MANET RFCs / draft do not say otherwise. I could think of an implementation that use ULA or global, but this would be against IETF standards. The LL addresses doesn't need to be unique in the OSPF routing domain. It is link-local. For OSPF-MANET, this means xxx-local (replace xxx with segment, channel, medium, etc., I have posted many proposals for term and definition). Two OSPF interfaces on the same xxx MAY have connectivity, two interfaces on different xxx does by definition NOT have connectivity, because they are on distinct xxx. >> NDP RA >> > >I really doubt we could have any sizable MANET >networks if every node is beaconing RAs and running >NUD. This would be a good topic for a research >paper, but my guess is that anything over a couple >of dozen nodes at low speed would just not work. Beaconing RAs is no problem. It is similar to beaconing hellos. I agree on NUD. A hello protocol would perform better. And running both for the same purpose is all overhead. We could encapsulate RA payload in NHDP, but I'm not sure if we want to go into that direction. Or we could take over all RA capabilities in the MANET protocol. Not sure on going that way either. >> MLD >> > >But, see below... > >> And I have my own middleware products that use LL for Peer discovery >> or 1-hop message disctribution (I could use hop-limit=1). >> > >I am firmly in the "hop-limit == 1", or, even better, >"hop-limit received as 255" camp. ???? The link-local protects against forwarding. Checking "hop-limit received as 255" is for protection against spoofers multiple hops away. We need both. OK, we could use global/ULA source and LL destination with hop-limit sent and received as 255. This is not how the "long Alex LL list" works today. Regards, Teco From alexandru.petrescu@gmail.com Mon Oct 26 11:02: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 97A383A6AC5 for ; Mon, 26 Oct 2009 11:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.085, 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 ih1ohSmXWdqp for ; Mon, 26 Oct 2009 11:02:08 -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 7B48E3A6AE7 for ; Mon, 26 Oct 2009 11:02:08 -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 n9QI2J3a022486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 19:02:19 +0100 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 n9QI2Jee007349; Mon, 26 Oct 2009 19:02:19 +0100 (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 n9QI2Imk009507; Mon, 26 Oct 2009 19:02:19 +0100 Message-ID: <4AE5E42A.4050800@gmail.com> Date: Mon, 26 Oct 2009 19:02:18 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4AE5C151.6000800@gmail.com> <014f01ca5658$cd6130d0$68239270$@nl> <4AE5D7E5.60301@earthlink.net> In-Reply-To: <4AE5D7E5.60301@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Protocols involving link-local addresses 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, 26 Oct 2009 18:02:09 -0000 Charles - the point of mentioning this list of protocols is not how they don't work for MANET - it is how MANETs make sure they don't disturb somebody running these protocols and connecting to them. Don't you think we should do something about this Charter text: > It is required that such [addressing] models do not cause problems > for ad hoc-unaware parts of the system, such as standard applications > running on an ad hoc node or regular Internet nodes attached to the > ad hoc nodes. Don't you think we should describe what these "problems" the Charter talks about might be? Don't you think we should mention how the addressing model does not create these problems? Otherwise - why do we have a Charter? Do we have a Charter only to have a Chairman explaining his understanding of it? Do we have a Charter only to have a few members of the variable-geometry Design Team understand it they want to? Why do you need a WG at all? Alex Charles E. Perkins a écrit : > > Hello Teco, > > Your list is much more sensible and to the point. > > I have some comments. > > Teco Boot wrote: >> I would limit the list to protocols that are applicable to MANETs. >> This is a non-empty list. For IPv6: OSPF-MANET >> > > Ouch. I've been trying to avoid the necessity to go study that > document. Does OSPF-MANET really require verification that > link-local addresses are unique across the entire MANET? > >> NDP RA >> > > I really doubt we could have any sizable MANET networks if every node > is beaconing RAs and running NUD. This would be a good topic for a > research paper, but my guess is that anything over a couple of dozen > nodes at low speed would just not work. > > >> MLD >> > > But, see below... > >> And I have my own middleware products that use LL for Peer >> discovery or 1-hop message disctribution (I could use hop-limit=1). >> >> > > I am firmly in the "hop-limit == 1", or, even better, "hop-limit > received as 255" camp. > > It really works. > > Regards, Charlie P. > > _______________________________________________ Autoconf mailing list > Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf > From teco@inf-net.nl Mon Oct 26 11:05:38 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 25D9F3A6AEF for ; Mon, 26 Oct 2009 11:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, 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 WRhZ3qD05DJ6 for ; Mon, 26 Oct 2009 11:05:37 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id E14083A6AC5 for ; Mon, 26 Oct 2009 11:05:36 -0700 (PDT) Received: (qmail 18963 invoked from network); 26 Oct 2009 19:05:48 +0100 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 26 Oct 2009 19:05:48 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <4AE5C151.6000800@gmail.com> <014f01ca5658$cd6130d0$68239270$@nl> <4AE5D02B.8070809@gmail.com> In-Reply-To: <4AE5D02B.8070809@gmail.com> Date: Mon, 26 Oct 2009 19:05:16 +0100 Message-ID: <017a01ca5666$f128b430$d37a1c90$@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: AcpWWowKZrKwz/CtSu2KlJCjSe9NoQACmP7w Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] Adding list of LL protocols for-against (was: Protocols involving link-local addresses) 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, 26 Oct 2009 18:05:38 -0000 I say no. It will do if we recognize LLs are fact of life. So I think there is no need to list LL-usage in a draft or RFC. Moreover, the focus of Autoconf is not LL, but ULA and Global. Also, there is no need to "discourage" LLs, as written in the=20 baccelli draft. I suggested text for a clean-up, but unluckily this did not make it. With this terrible overheated discussion as result. I prefer transfer the discussion on LLs to 6MAN, as I think in the common case, usage of LLs for general applications is not preferred over ULA / globals also. I can describe a scenario where a node has multiple paths to another node, and links are not that stable, connectivity between these nodes is better using "routable addresses". Still, I think LLs should be used for those protocols that require a scope of a single hop. MANET protocols are an example. At cost of a ULA / global in the payload (e.g. RouterID). Regards, Teco. >-----Oorspronkelijk bericht----- >Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >Verzonden: maandag 26 oktober 2009 17:37 >Aan: Teco Boot >CC: 'Alexandru Petrescu'; autoconf@ietf.org >Onderwerp: Re: Adding list of LL protocols for-against (was: [Autoconf] >Protocols involving link-local addresses) > >Teco, AUTOCONFers, > >Do you agree with adding a list of IP protocols using link-local >addresses, in the AUTOCONF addressing model, and which may be pertinent >to MANET? > >-yes >-no > >Thanks, > >Alex > >Teco Boot a =E9crit : >> I would limit the list to protocols that are applicable to MANETs. >> This is a non-empty list. For IPv6: >> OSPF-MANET >> NDP RA >> MLD >> And I have my own middleware products that use LL for Peer discovery >> or 1-hop message disctribution (I could use hop-limit=3D1). >> >> Teco. >> >>> -----Oorspronkelijk bericht----- >>> Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] >Namens >>> Alexandru Petrescu >>> Verzonden: maandag 26 oktober 2009 16:34 >>> Aan: autoconf@ietf.org >>> Onderwerp: [Autoconf] Protocols involving link-local addresses >>> >>> In several earlier discussions question was raised about which >protocols >>> use link-local addresses. >>> >>> IPv4 >>> ---- >>> mDNS >>> ARP (the parts in IPv4 LL RFC) >>> >>> IPv6 >>> ---- >>> DHCP >>> OSPF >>> RIPng >>> MLD >>> OLSR (a particular implementation) >>> >>> If you know any other, feel free to add. I think it may be useful = to >>> add to the AUTOCONF addressing model draft(s). >>> >>> (I think Teco may have already written such a list but I have hard >time >>> finding it). >> >> >> I would limit the list to protocols that are applicable to MANETs. >> This is a non-empty list. For IPv6: >> OSPF-MANET >> NDP RA >> MLD >> And I have my own middleware products that use LL for Peer discovery >> or 1-hop message disctribution (I could use hop-limit=3D1). >> I would prefer LLs for OLSR also. >> >> Teco. >> >> >>> Alex >>> >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf >> >> From alexandru.petrescu@gmail.com Mon Oct 26 11:13: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 410253A6B52 for ; Mon, 26 Oct 2009 11:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.084, 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 e8eWeNX+ZE-L for ; Mon, 26 Oct 2009 11:13:17 -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 DE9B03A6B3F for ; Mon, 26 Oct 2009 11:13:16 -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 n9QIDT09030174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 19:13:29 +0100 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 n9QIDS7U009171; Mon, 26 Oct 2009 19:13:28 +0100 (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 n9QIDSCp006864; Mon, 26 Oct 2009 19:13:28 +0100 Message-ID: <4AE5E6C8.1040802@gmail.com> Date: Mon, 26 Oct 2009 19:13:28 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Teco Boot References: <4AE5C151.6000800@gmail.com> <014f01ca5658$cd6130d0$68239270$@nl> <4AE5D02B.8070809@gmail.com> <017a01ca5666$f128b430$d37a1c90$@nl> In-Reply-To: <017a01ca5666$f128b430$d37a1c90$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] cleanup text towards avoiding to discourage LLs (was: Adding list of LL protocols for-against) 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, 26 Oct 2009 18:13:18 -0000 Teco Boot a écrit : > I say no. Ok - it dies out. [...] > Also, there is no need to "discourage" LLs, as written in the > baccelli draft. I suggested text for a clean-up, but unluckily > this did not make it. With this terrible overheated discussion > as result. Teco - if you propose new text for a clean-up towards avoiding that "discourage LL"s, I agree with it from the start. As I agree with most of the draft-bernardos with respect to LL. That says - please take it into account. Alex > > I prefer transfer the discussion on LLs to 6MAN, as I think in > the common case, usage of LLs for general applications is not > preferred over ULA / globals also. I can describe a scenario > where a node has multiple paths to another node, and links are > not that stable, connectivity between these nodes is better using > "routable addresses". > Still, I think LLs should be used for those protocols that require > a scope of a single hop. MANET protocols are an example. At cost > of a ULA / global in the payload (e.g. RouterID). > > Regards, Teco. > > >> -----Oorspronkelijk bericht----- >> Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> Verzonden: maandag 26 oktober 2009 17:37 >> Aan: Teco Boot >> CC: 'Alexandru Petrescu'; autoconf@ietf.org >> Onderwerp: Re: Adding list of LL protocols for-against (was: [Autoconf] >> Protocols involving link-local addresses) >> >> Teco, AUTOCONFers, >> >> Do you agree with adding a list of IP protocols using link-local >> addresses, in the AUTOCONF addressing model, and which may be pertinent >> to MANET? >> >> -yes >> -no >> >> Thanks, >> >> Alex >> >> Teco Boot a écrit : >>> I would limit the list to protocols that are applicable to MANETs. >>> This is a non-empty list. For IPv6: >>> OSPF-MANET >>> NDP RA >>> MLD >>> And I have my own middleware products that use LL for Peer discovery >>> or 1-hop message disctribution (I could use hop-limit=1). >>> >>> Teco. >>> >>>> -----Oorspronkelijk bericht----- >>>> Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] >> Namens >>>> Alexandru Petrescu >>>> Verzonden: maandag 26 oktober 2009 16:34 >>>> Aan: autoconf@ietf.org >>>> Onderwerp: [Autoconf] Protocols involving link-local addresses >>>> >>>> In several earlier discussions question was raised about which >> protocols >>>> use link-local addresses. >>>> >>>> IPv4 >>>> ---- >>>> mDNS >>>> ARP (the parts in IPv4 LL RFC) >>>> >>>> IPv6 >>>> ---- >>>> DHCP >>>> OSPF >>>> RIPng >>>> MLD >>>> OLSR (a particular implementation) >>>> >>>> If you know any other, feel free to add. I think it may be useful to >>>> add to the AUTOCONF addressing model draft(s). >>>> >>>> (I think Teco may have already written such a list but I have hard >> time >>>> finding it). >>> >>> I would limit the list to protocols that are applicable to MANETs. >>> This is a non-empty list. For IPv6: >>> OSPF-MANET >>> NDP RA >>> MLD >>> And I have my own middleware products that use LL for Peer discovery >>> or 1-hop message disctribution (I could use hop-limit=1). >>> I would prefer LLs for OLSR also. >>> >>> Teco. >>> >>> >>>> Alex >>>> >>>> _______________________________________________ >>>> Autoconf mailing list >>>> Autoconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/autoconf >>> > > > From teco@inf-net.nl Mon Oct 26 11:13: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 AD0DB28C0F5 for ; Mon, 26 Oct 2009 11:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.666 X-Spam-Level: X-Spam-Status: No, score=-0.666 tagged_above=-999 required=5 tests=[AWL=-0.651, BAYES_05=-1.11, 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 gjmUQAJkKBc7 for ; Mon, 26 Oct 2009 11:13:29 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 972C83A6B52 for ; Mon, 26 Oct 2009 11:13:28 -0700 (PDT) Received: (qmail 26378 invoked from network); 26 Oct 2009 19:13:37 +0100 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 26 Oct 2009 19:13:37 +0100 From: "Teco Boot" To: "'Charles E. Perkins'" References: <4AE5C151.6000800@gmail.com> <4AE5C6BD.2030501@gmail.com> <4AE5C9CB.5030807@gmail.com> <5A0019AD-0BB0-4EAF-969E-73E3F1DAF1DE@thomasclausen.org> <4AE5CC23.1090105@gmail.com> <4AE5CF72.9070700@gmail.com> <4AE5D954.8020705@earthlink.net> In-Reply-To: <4AE5D954.8020705@earthlink.net> Date: Mon, 26 Oct 2009 19:13:05 +0100 Message-ID: <017b01ca5668$0901f070$1b05d150$@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: AcpWYbh1QXaZ4KgRSBOgjkWc9+EVUQABU//Q Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] Protocols involving link-local addresses 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, 26 Oct 2009 18:13:29 -0000 >Charles E. Perkins wrote: >The fact is that routing protocols need to be modified in order >to work well with ad hoc networks. And as we have discovered >so do the address autoconfiguration protocols. In my case, I can generate LLs and ULAs using existing specs. And I can generate globals, if a prefix is provided. The problem: RAs are single hop and the prefix is not advertised all over the place in the MANET. And there can be multi-homing, making things worse. By the way, can you tell more on your devices, which cannot generate a good PRN? How is L2 addressing implemented? What happens when there are L2 duplicates? Maybe I should stay far away from these, but for the discussion it might help to understand your problem. Yes, we need MANET protocols. Regards, Teco From charles.perkins@earthlink.net Mon Oct 26 11:31: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 2AB703A6831 for ; Mon, 26 Oct 2009 11:31:24 -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.050, 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 kjDL4Gdsk6b9 for ; Mon, 26 Oct 2009 11:31:23 -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 377C53A68A6 for ; Mon, 26 Oct 2009 11:31:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ZVfGnT5IYNgiDToUhcXUctVBRQc7bA3tGaa2hO0tw2rMw3195ldXXjqO1kUXRyvn; 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.16]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1N2ULv-00019W-V0; Mon, 26 Oct 2009 14:31:36 -0400 Message-ID: <4AE5EAF9.6080006@earthlink.net> Date: Mon, 26 Oct 2009 11:31:21 -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: <4AE5C151.6000800@gmail.com> <014f01ca5658$cd6130d0$68239270$@nl> <4AE5D7E5.60301@earthlink.net> <4AE5E42A.4050800@gmail.com> In-Reply-To: <4AE5E42A.4050800@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52ad6a64730f2cd67ee7b0f5833f9499d3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Protocols involving link-local addresses 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, 26 Oct 2009 18:31:24 -0000 Hello Alex, Alexandru Petrescu wrote: > Charles - the point of mentioning this list of protocols is not how they > don't work for MANET - it is how MANETs make sure they don't disturb > somebody running these protocols and connecting to them. I don't think so. I think that some things are going to have to be broken in order to run reasonable-sized ad hoc networks. Mobile IPv6 is a good example. It's just _not_ going to work automatically. Even more to the point, it was designed and built to run in networks that do NOT conform to the operational model of an ad hoc network. Jumping up and down and insisting that it does work is tantamount to declaring that you have no interest in ad hoc networks. > > Don't you think we should do something about this Charter text: >> It is required that such [addressing] models do not cause problems >> for ad hoc-unaware parts of the system, such as standard applications >> running on an ad hoc node or regular Internet nodes attached to the >> ad hoc nodes. This is fine with me. We can have an ad hoc network that doesn't mess up the Internet. It can get addresses. Those addresses do not mess up the Internet. The network can be attached to a gateway providing connectivity to the Internet. You can even have a subnet attached to an ad hoc node, and have the ad hoc node managing as a default router for the other nodes on that subnet. Those subnet- attached nodes may not even notice that they are being served as nodes within an ad hoc network. That's drastically and totally different than saying you should be able to take absolutely any Internet node today, stick it anywhere withiin an ad hoc network, and expect it to work. If you disagree with this, then we really have to go back to first grade and have some more basic discussions. > > Don't you think we should describe what these "problems" the Charter > talks about might be? It seems to me that the problems and solutions I have pointed out many many times are not of interest to you, as you insist on being able to maintain unique link-local addresses in environments where such uniqueness is quite difficult to guarantee. In effect, you exclude useful environments for networking, and only wish to serve environments which look to IP exactly like an Ethernet. So why do you bother with [autoconf]? Your problem is solved elsewhere. > > Don't you think we should mention how the addressing model does not > create these problems? Problems, problems. Right now our problem is managing a discussion about the realm of applicability for unique link-local addresses. It seems to be based almost purely on dogmatism instead of engineering tradeoffs. > > Otherwise - why do we have a Charter? Do we have a Charter only to > have a Chairman explaining his understanding of it? I'm not a chair of anything. Do I count as a potential person that might have understanding? > > > Do we have a Charter only to have a few members of the > variable-geometry Design Team understand it they want to? If you insist on fixed geometry networks, I really think you are in the wrong working group. > > Why do you need a WG at all? To solve problems of variable geometry networks. Regards, Charlie P. From charles.perkins@earthlink.net Mon Oct 26 11:41: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 A8AA228C144 for ; Mon, 26 Oct 2009 11:41:16 -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.047, 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 3ogfzAiWNzYU for ; Mon, 26 Oct 2009 11:41:15 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id BCE0A28C13C for ; Mon, 26 Oct 2009 11:41:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=uBOvGgupEnYB05fyiYGcnIPo5OWJosECBRDLkqzFgR0HdOHPjIfbwFymqMx1DlF/; 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.16]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1N2UVU-0007eQ-Tf; Mon, 26 Oct 2009 13:41:29 -0500 Message-ID: <4AE5ED59.3020801@earthlink.net> Date: Mon, 26 Oct 2009 11:41:29 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Teco Boot References: <4AE5C151.6000800@gmail.com> <4AE5C6BD.2030501@gmail.com> <4AE5C9CB.5030807@gmail.com> <5A0019AD-0BB0-4EAF-969E-73E3F1DAF1DE@thomasclausen.org> <4AE5CC23.1090105@gmail.com> <4AE5CF72.9070700@gmail.com> <4AE5D954.8020705@earthlink.net> <017b01ca5668$0901f070$1b05d150$@nl> In-Reply-To: <017b01ca5668$0901f070$1b05d150$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52f77f1cb1b6e6f4ad83cdedb99404bf2e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Protocols involving link-local addresses 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, 26 Oct 2009 18:41:16 -0000 Hello Teco, Teco Boot wrote: >> Charles E. Perkins wrote: >> The fact is that routing protocols need to be modified in order >> to work well with ad hoc networks. And as we have discovered >> so do the address autoconfiguration protocols. >> > > In my case, I can generate LLs and ULAs using existing specs. > Is this the case of BDRP? But the world is still hungry :-). Don't you think we should have a design team to develop recommendations in the case of IEEE-style MAC addresses, for which uniqueness can be assumed? Then we could have a general solution for non-unique link-locals, which should be compatible with the specific solution. The general solution could even admit the specific solution as a special case. As it should be. > And I can generate globals, if a prefix is provided. > The problem: RAs are single hop and the prefix is not advertised > all over the place in the MANET. And there can be multi-homing, > making things worse. > Exactly. These are the problems we should have been discussing years ago. Some of the problems are not hard, some (e.g., multi-homing) are much harder. > By the way, can you tell more on your devices, which cannot > generate a good PRN? How is L2 addressing implemented? What > happens when there are L2 duplicates? > I am not currently a practitioner of this excellent school of engineering, but I have experience with devices that have terribly small power budgets and unusual layer-2 addressing schemes. > Maybe I should stay far away from these, but for the discussion it > might help to understand your problem. > But this discussion has gone on many times. I think I remember some messages from John Mullen on the matter a while back. And then there is the historical matter of the development process for IPv6. There were strong proponents that we should rely on layer-2 uniqueness, but the consensus was quite broad that we needed to allow IPv6 to serve environments where that assumption is not true. And yet there is the universal agreement that in some restricted environments of the obvious sort, we can get better performance with Optimistic DAD and so on. Except that it seems all this wealth of experience gets left at the door when entering into the discussions on [autoconf]. > Yes, we need MANET protocols. > > I see that we have many points of agreement :-) Regards, Charlie P. From alexandru.petrescu@gmail.com Mon Oct 26 12:08: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 539CC28C369 for ; Mon, 26 Oct 2009 12:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.167 X-Spam-Level: X-Spam-Status: No, score=-3.167 tagged_above=-999 required=5 tests=[AWL=1.082, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 Zu7hXChkXy1l for ; Mon, 26 Oct 2009 12:07:59 -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 EE54B28C365 for ; Mon, 26 Oct 2009 12:04:39 -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 n9QJ4o7b009590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 20:04:50 +0100 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 n9QJ4ook013507; Mon, 26 Oct 2009 20:04:50 +0100 (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 n9QJ4nps015518; Mon, 26 Oct 2009 20:04:50 +0100 Message-ID: <4AE5F2D1.7040103@gmail.com> Date: Mon, 26 Oct 2009 20:04:49 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4AE5C151.6000800@gmail.com> <014f01ca5658$cd6130d0$68239270$@nl> <4AE5D7E5.60301@earthlink.net> <4AE5E42A.4050800@gmail.com> <4AE5EAF9.6080006@earthlink.net> In-Reply-To: <4AE5EAF9.6080006@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Protocols involving link-local addresses 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, 26 Oct 2009 19:08:00 -0000 Ha! :-) Charles E. Perkins a écrit : > Alexandru Petrescu wrote: >> Charles - the point of mentioning this list of protocols is not how they >> don't work for MANET - it is how MANETs make sure they don't disturb >> somebody running these protocols and connecting to them. > > I don't think so. I think that some things are going to > have to be broken in order to run reasonable-sized ad hoc > networks. And then let's mention those things which risk being broken. Which protocol, which implementaiton risks being broken. Go ahead. I have my ideas about what might break if LLs are discouraged. > Mobile IPv6 is a good example. It's just _not_ going to work > automatically. Even more to the point, it was designed and built to > run in networks that do NOT conform to the operational model of an ad > hoc network. Yes, right. MN is, however, a node which may want to connect to an adhoc network which may represent its "home" network, and thus use its LL address. And to that home network there may be a HA which should use ND to defend the HoA of the MN, which may be LL. If that adhoc network "discourages LLs" - how will it work? > Jumping up and down and insisting that it does work is > tantamount to declaring that you have no interest in ad hoc > networks. Well, I have interest in networks that may behave as you say, but which I don't want to call neither MANET nor "adhoc networks". BEcause once I call them so everybody forcefully feeds me a good dose of OLSR and DYMO. And that whatever I call "adhoc" - once I talk about it it's no longer adhoc, it's planned. >> Don't you think we should do something about this Charter text: >>> It is required that such [addressing] models do not cause problems >>> for ad hoc-unaware parts of the system, such as standard applications >>> running on an ad hoc node or regular Internet nodes attached to the >>> ad hoc nodes. > > This is fine with me. We can have an ad hoc network that doesn't > mess up the Internet. It can get addresses. Those addresses do > not mess up the Internet. There are few addresses which don't mess up the Internet: link-locals, globals, multicast, etc. You discourage the LLs, the globals are not mentioned, neither the multicast. > The network can be attached to a gateway > providing connectivity to the Internet. No such gateway mentioned in the draft. Charles - all that the draft is saying is this: -dont LL -do /128 prefixes -do unique addresses That's all! No mentioning of gateway, or how other non-MANET nodes work ok with MANET nodes. > You can even have a subnet > attached to an ad hoc node, and have the ad hoc node managing > as a default router for the other nodes on that subnet. Those subnet- > attached nodes may not even notice that they are being served as > nodes within an ad hoc network. Picture it and paste it in the draft, instead of "dont LL" and "/128 prefixes". > That's drastically and totally different than saying you should be > able to take absolutely any Internet node today, stick it anywhere > withiin an ad hoc network, and expect it to work. Well, if your intention is to not allow any Internet node to connect to the MANET then what is the Gateway? > If you disagree with this, then we really have to go back to > first grade and have some more basic discussions. More discussions? I will not refuse the invitation though. >> Don't you think we should describe what these "problems" the Charter >> talks about might be? > > It seems to me that the problems and solutions I have pointed out > many many times are not of interest to you, as you insist on being able > to maintain unique link-local addresses in environments where such > uniqueness is quite difficult to guarantee. Ok. I don't maintain that keeping LLs unique is easy. Let's just don't discourage them. I guess you want to invent a new way of keeping them unique, but not to discourage them. > In effect, you exclude useful environments for networking, and only > wish to serve environments which look to IP exactly like an Ethernet. It would be easier - yes. Adhoc MANETs is not the first time people encountered Ethernet-unfriendly places. Often the use is PPP/SLIP in such places. Often it suffices. PPP uses link-local addresses too. Remark too that recently more and more links try to offer an Ethernet-friendly IP, that is at least WLAN, WPAN and WMAN. WPAN 802.15.4, for example pertains to both "MANET" and to "Ethernet". WLAN 802.11s "mesh" also pertains to both EThernet _and_ to MANET. I don't understand why you say I exclude useful environments... > So why do you bother with [autoconf]? Your problem is solved > elsewhere. Well, let's say that I have a green light from the Chairs saying my opinion is welcome. Chairs have means to make me shut up, if they so decided. >> Don't you think we should mention how the addressing model does not >> create these problems? > > Problems, problems. Right now our problem is managing > a discussion about the realm of applicability for unique > link-local addresses. It seems to be based almost purely > on dogmatism instead of engineering tradeoffs. Avoid dogmatism - I want too. LEt's go practical and mention protocol names and practical problems and follow Charter. >> Otherwise - why do we have a Charter? Do we have a Charter only to >> have a Chairman explaining his understanding of it? > > I'm not a chair of anything. Do I count as a potential > person that might have understanding? Charles - you too don't see any problem in the Charter saying the non-MANET nodes should not be affected by the MANET nodes. I think - on a personal speculating note - that you believe Charter is so-and-so-relatively-so as long as it does not forbid you anything. To me, there is a huge difference between what Charter says and what DT does. >> Do we have a Charter only to have a few members of the >> variable-geometry Design Team understand it they want to? > > If you insist on fixed geometry networks, I really think you are > in the wrong working group. Well, sorry, variable-geometry might be a bad translation. I meant to say that the Design Team had a variable geometry (like the F14 plane) in that it changed members at one time, and that one of the members does not currently seem to be heard. >> Why do you need a WG at all? > > To solve problems of variable geometry networks. Ok variable geometry networks, not variable geometry DTs. Alex From teco@inf-net.nl Mon Oct 26 12:22: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 EAAC828C2B8 for ; Mon, 26 Oct 2009 12:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.339 X-Spam-Level: X-Spam-Status: No, score=-1.339 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, 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 eaK5rZzwoGu1 for ; Mon, 26 Oct 2009 12:22:41 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 8D88128C149 for ; Mon, 26 Oct 2009 12:22:40 -0700 (PDT) Received: (qmail 2504 invoked from network); 26 Oct 2009 20:22:51 +0100 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 26 Oct 2009 20:22:51 +0100 From: "Teco Boot" To: "'Charles E. Perkins'" References: <4AE5C151.6000800@gmail.com> <4AE5C6BD.2030501@gmail.com> <4AE5C9CB.5030807@gmail.com> <5A0019AD-0BB0-4EAF-969E-73E3F1DAF1DE@thomasclausen.org> <4AE5CC23.1090105@gmail.com> <4AE5CF72.9070700@gmail.com> <4AE5D954.8020705@earthlink.net> <017b01ca5668$0901f070$1b05d150$@nl> <4AE5ED59.3020801@earthlink.net> In-Reply-To: <4AE5ED59.3020801@earthlink.net> Date: Mon, 26 Oct 2009 20:22:20 +0100 Message-ID: <018f01ca5671$b51f6ff0$1f5e4fd0$@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: AcpWa/EaY7M9edNJRquD2uNhZ5wRpAAAFRxQ Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] Protocols involving link-local addresses 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, 26 Oct 2009 19:22:42 -0000 Hi Charlie, >-----Oorspronkelijk bericht----- >Van: Charles E. Perkins [mailto:charles.perkins@earthlink.net] >Verzonden: maandag 26 oktober 2009 19:41 >Aan: Teco Boot >CC: autoconf@ietf.org >Onderwerp: Re: [Autoconf] Protocols involving link-local addresses > > >Hello Teco, > >Teco Boot wrote: >>> Charles E. Perkins wrote: >>> The fact is that routing protocols need to be modified in order >>> to work well with ad hoc networks. And as we have discovered >>> so do the address autoconfiguration protocols. >>> >> >> In my case, I can generate LLs and ULAs using existing specs. >> > >Is this the case of BDRP? But the world is still hungry :-). World hungry is getting worse. Not sure on Autoconf... . However, BRDP could help. For me, it is the holy grail. But still in the embryo stage. Didn't MANET protocols stay that way over 10 years? I mean: BRDP works great in simulation !! >Don't you think we should have a design team to develop >recommendations in the case of IEEE-style MAC addresses, >for which uniqueness can be assumed? > >Then we could have a general solution for non-unique >link-locals, which should be compatible with the specific >solution. The general solution could even admit the >specific solution as a special case. As it should be. I've to think on this. Just some thoughts: - If it were IEEE-style MAC addresses, why not using IEEE MAC addresses? They don't have to be globally unique (universally/locally administered Address set to 1). Good to know IEEE ULA means Universal LAN Address. So IEEE is always just the opposite (like the U/L bit). - Deviations from IEEE could have to do with overhead. I know of L2 addresses that are only a few bits long. Still, these radios are capable of transmitting IP packets. Payload is compressed by application, L2-header is highly optimized. IP header compression is on the todo list (or "beta", or just out there). If we come up with something, it must interact with L2&L3 header compression. - The multiple hop uniqueness test need more thoughts. I'll write this on a piece of paper and put it under my pillow tonight. > > >> And I can generate globals, if a prefix is provided. >> The problem: RAs are single hop and the prefix is not advertised >> all over the place in the MANET. And there can be multi-homing, >> making things worse. >> > >Exactly. These are the problems we should have been >discussing years ago. Some of the problems are not hard, >some (e.g., multi-homing) are much harder. Multi-homing is (partly) solved by BRDP based routing. Just kill the default gateway and send packets to the BR that "owns" the SA prefix. What is left is address handover for apps. MIP/NEMO can do this, HIP, SHIM6 and multipath TCP, just to name a few. And of course SA selection. BRDP provides great metrics for it. > >> By the way, can you tell more on your devices, which cannot >> generate a good PRN? How is L2 addressing implemented? What >> happens when there are L2 duplicates? >> > >I am not currently a practitioner of this excellent school >of engineering, but I have experience with devices that >have terribly small power budgets and unusual layer-2 >addressing schemes. OK, you are in the IEEE camp right now! Great!! Or have devices by hand, that can come up with real good PRNs. I had the opinion you worked for a museum. Sorry for that, I was wrong. >> Maybe I should stay far away from these, but for the discussion it >> might help to understand your problem. >> > >But this discussion has gone on many times. I think I remember >some messages from John Mullen on the matter a while back. >And then there is the historical matter of the development >process for IPv6. There were strong proponents that we should >rely on layer-2 uniqueness, but the consensus was quite broad >that we needed to allow IPv6 to serve environments where that >assumption is not true. And yet there is the universal agreement >that in some restricted environments of the obvious sort, we can >get better performance with Optimistic DAD and so on. > >Except that it seems all this wealth of experience gets left at >the door when entering into the discussions on [autoconf]. I think no one wants to take DAD out of the specs. I have my doubts, for security reasons. On wired networks we can handle overhead and accept small delays. In a MANET, this is different and we are allowed to disable DAD. I remember the posting from Thomas Narten on this (September 2nd). Do we agree on a goal, having MANET unique InterfaceIDs and go from there? And forming a DT on a protocol for some assurance on uniqueness, for those who need it? I'm not candidate. But I support such an approach if it would rescue Autoconf. Regards, Teco > > >> Yes, we need MANET protocols. >> >> > >I see that we have many points of agreement :-) > >Regards, >Charlie P. From thomas@thomasclausen.org Mon Oct 26 12:34: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 42B2928C27A for ; Mon, 26 Oct 2009 12:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 N2OCfLEyvnDV for ; Mon, 26 Oct 2009 12:34:04 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 8740828C29E for ; Mon, 26 Oct 2009 12:34:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 3901032317B9; Mon, 26 Oct 2009 12:34:18 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 53E3232317BA; Mon, 26 Oct 2009 12:34:17 -0700 (PDT) Message-Id: <19E54CD4-453E-4E49-9AE3-52101B98CEFB@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE5F2D1.7040103@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: Mon, 26 Oct 2009 20:34:14 +0100 References: <4AE5C151.6000800@gmail.com> <014f01ca5658$cd6130d0$68239270$@nl> <4AE5D7E5.60301@earthlink.net> <4AE5E42A.4050800@gmail.com> <4AE5EAF9.6080006@earthlink.net> <4AE5F2D1.7040103@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Protocols involving link-local addresses 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, 26 Oct 2009 19:34:05 -0000 On Oct 26, 2009, at 8:04 PM, Alexandru Petrescu wrote: > Ha! :-) > > Charles E. Perkins a =E9crit : >> Alexandru Petrescu wrote: >>> Charles - the point of mentioning this list of protocols is not =20 >>> how they >>> don't work for MANET - it is how MANETs make sure they don't disturb >>> somebody running these protocols and connecting to them. >> I don't think so. I think that some things are going to >> have to be broken in order to run reasonable-sized ad hoc >> networks. > > And then let's mention those things which risk being broken. Which =20= > protocol, which implementaiton risks being broken. Go ahead. I =20 > have my ideas about what might break if LLs are discouraged. > >> Mobile IPv6 is a good example. It's just _not_ going to work >> automatically. Even more to the point, it was designed and built to >> run in networks that do NOT conform to the operational model of an ad >> hoc network. > > Yes, right. > > MN is, however, a node which may want to connect to an adhoc network =20= > which may represent its "home" network, and thus use its LL address. =20= > And to that home network there may be a HA which should use ND to =20 > defend the HoA of the MN, which may be LL. > > If that adhoc network "discourages LLs" - how will it work? It's getting tiresome to repeat it: because your "mobile node" (I =20 assume NEMO) will NOT connect to the "ad hoc side" of the network. Am I not saying it right? Thomas From alexandru.petrescu@gmail.com Mon Oct 26 12:36:10 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 6D7D13A6784 for ; Mon, 26 Oct 2009 12:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=0.069, 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 hpoPTYyxkE7O for ; Mon, 26 Oct 2009 12:36:09 -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 4F05528C253 for ; Mon, 26 Oct 2009 12:35:44 -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 n9QJZsDo007081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 20:35:54 +0100 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 n9QJZsoG015199; Mon, 26 Oct 2009 20:35:54 +0100 (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 n9QJZsPP022965; Mon, 26 Oct 2009 20:35:54 +0100 Message-ID: <4AE5FA19.4000309@gmail.com> Date: Mon, 26 Oct 2009 20:35:53 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <4AE5C151.6000800@gmail.com> <014f01ca5658$cd6130d0$68239270$@nl> <4AE5D7E5.60301@earthlink.net> <4AE5E42A.4050800@gmail.com> <4AE5EAF9.6080006@earthlink.net> <4AE5F2D1.7040103@gmail.com> <19E54CD4-453E-4E49-9AE3-52101B98CEFB@thomasclausen.org> In-Reply-To: <19E54CD4-453E-4E49-9AE3-52101B98CEFB@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Protocols involving link-local addresses 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, 26 Oct 2009 19:36:10 -0000 Thomas Heide Clausen a écrit : > > On Oct 26, 2009, at 8:04 PM, Alexandru Petrescu wrote: > >> Ha! :-) >> >> Charles E. Perkins a écrit : >>> Alexandru Petrescu wrote: >>>> Charles - the point of mentioning this list of protocols is not how >>>> they >>>> don't work for MANET - it is how MANETs make sure they don't disturb >>>> somebody running these protocols and connecting to them. >>> I don't think so. I think that some things are going to >>> have to be broken in order to run reasonable-sized ad hoc >>> networks. >> >> And then let's mention those things which risk being broken. Which >> protocol, which implementaiton risks being broken. Go ahead. I have >> my ideas about what might break if LLs are discouraged. >> >>> Mobile IPv6 is a good example. It's just _not_ going to work >>> automatically. Even more to the point, it was designed and built to >>> run in networks that do NOT conform to the operational model of an ad >>> hoc network. >> >> Yes, right. >> >> MN is, however, a node which may want to connect to an adhoc network >> which may represent its "home" network, and thus use its LL address. >> And to that home network there may be a HA which should use ND to >> defend the HoA of the MN, which may be LL. >> >> If that adhoc network "discourages LLs" - how will it work? > > It's getting tiresome to repeat it: because your "mobile node" (I assume > NEMO) will NOT connect to the "ad hoc side" of the network. And what if it does - what will break? Alex > > Am I not saying it right? > > Thomas > > From charles.perkins@earthlink.net Mon Oct 26 12:53: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 CAE4E28C2FA for ; Mon, 26 Oct 2009 12:53:43 -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.044, 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 Fsjnsmdki8vx for ; Mon, 26 Oct 2009 12:53:42 -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 65D7928C2B7 for ; Mon, 26 Oct 2009 12:53:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=XH3m7dBkEOhPn/pHdJ+nyhmeP2zeEycfZTCors/GHOaQgTGGkulZR/tzJU7qonRB; 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.16]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1N2Vdb-0004fY-QD; Mon, 26 Oct 2009 15:53:55 -0400 Message-ID: <4AE5FE54.2000808@earthlink.net> Date: Mon, 26 Oct 2009 12:53:56 -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: <4AE5C151.6000800@gmail.com> <014f01ca5658$cd6130d0$68239270$@nl> <4AE5D7E5.60301@earthlink.net> <4AE5E42A.4050800@gmail.com> <4AE5EAF9.6080006@earthlink.net> <4AE5F2D1.7040103@gmail.com> In-Reply-To: <4AE5F2D1.7040103@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f521d2edb35f0b7761e0c6ca30149de1c33350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Protocols involving link-local addresses 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, 26 Oct 2009 19:53:43 -0000 Hello Alex, Alexandru Petrescu wrote: > Ha! :-) I am starting off being confused already. > > Charles E. Perkins a écrit : >> Alexandru Petrescu wrote: >>> Charles - the point of mentioning this list of protocols is not how >>> they >>> don't work for MANET - it is how MANETs make sure they don't disturb >>> somebody running these protocols and connecting to them. >> >> I don't think so. I think that some things are going to >> have to be broken in order to run reasonable-sized ad hoc >> networks. > > And then let's mention those things which risk being broken. Which > protocol, which implementaiton risks being broken. Go ahead. I have > my ideas about what might break if LLs are discouraged. Let's say that link-locals are broken, and it will take effort to re-establish them for useful purposes. Then your list of protocols would serve notice for people to take a look and determine whether or not each item on that list might require modification. > >> Mobile IPv6 is a good example. It's just _not_ going to work >> automatically. Even more to the point, it was designed and built to >> run in networks that do NOT conform to the operational model of an ad >> hoc network. > > Yes, right. > > MN is, however, a node which may want to connect to an adhoc network > which may represent its "home" network, and thus use its LL address. > And to that home network there may be a HA which should use ND to > defend the HoA of the MN, which may be LL. > > If that adhoc network "discourages LLs" - how will it work? Mobile IP _can_ be made to work. It was, fortunately, designed to allow a home agent on a virtual network. That model applies immediately. You can also have a physical network employing techniques much like fixed hosts in NEMO. Too bad that in a MANET the home agent may frequently be unreachable due to network partition, but that isn't too much different than hiccups in Internet connectivity. Several Internet Drafts were published years ago with details. I could probably dig them up, but honestly I feel it would be to almost no benefit to you. > >> Jumping up and down and insisting that it does work is >> tantamount to declaring that you have no interest in ad hoc >> networks. > > Well, I have interest in networks that may behave as you say, but > which I don't want to call neither MANET nor "adhoc networks". > BEcause once I call them so everybody forcefully feeds me a good dose > of OLSR and DYMO. > > And that whatever I call "adhoc" - once I talk about it it's no longer > adhoc, it's planned. That is probably appropriate, as long as you describe networks with core forwarding nodes within a single hop of all other nodes, or single links. I might be wrong on this point. Can you suggest a model for ad hoc networks that is sufficiently general for all of your purposes? What if your model is then considered far too restrictive for the purposes of other people? Should we conform to your model, or enable development of protocols for the more general models desired by other people? > >>> Don't you think we should do something about this Charter text: >>>> It is required that such [addressing] models do not cause problems >>>> for ad hoc-unaware parts of the system, such as standard applications >>>> running on an ad hoc node or regular Internet nodes attached to the >>>> ad hoc nodes. >> >> This is fine with me. We can have an ad hoc network that doesn't >> mess up the Internet. It can get addresses. Those addresses do >> not mess up the Internet. > > There are few addresses which don't mess up the Internet: link-locals, > globals, multicast, etc. You discourage the LLs, the globals are not > mentioned, neither the multicast. Here I entirely miss your point. What if the draft "mentions" globals? And it is not at all unusual for initial work on address autoconfiguration to delay the consideration of multicast. In my opinion, it is highly appropriate for [autoconf] to delay multicast address allocation. > > No such gateway mentioned in the draft. Why should the draft mention the gateway? > > Charles - all that the draft is saying is this: > -dont LL I strongly encourage you to be accurate on this point. Namely, as I remember it anyway, the draft specifies that we not mandate the use of link-local addresses. "not mandate" != "prohibit". As has been said many many times. > -do /128 prefixes ... unless one knows how to use shorter prefixes ... > -do unique addresses Any protocol with flooding operations will find great benefit and simplification if it has the ability to rely on unique addresses. It turns out to be not absolutely required, but the additional design considerations are really quite nontrivial. That would be like learning to run before learning to crawl or walk. > > That's all! > > No mentioning of gateway, or how other non-MANET nodes work ok with > MANET nodes. Since we have currently zero solutions on the standards track, I fail to see how we can specify how the solution will work with a non-MANET node. At least we can say that all of our current solutions so far are completely compatible with non-MANET nodes. Is that a good start? > >> You can even have a subnet >> attached to an ad hoc node, and have the ad hoc node managing >> as a default router for the other nodes on that subnet. Those subnet- >> attached nodes may not even notice that they are being served as >> nodes within an ad hoc network. > > Picture it and paste it in the draft, instead of "dont LL" and "/128 > prefixes". (a) your characterization is wrong and (b) it would require illustration of a particular solution. > >> That's drastically and totally different than saying you should be >> able to take absolutely any Internet node today, stick it anywhere >> withiin an ad hoc network, and expect it to work. > > Well, if your intention is to not allow any Internet node to connect > to the MANET then what is the Gateway? Alex, please re-read your question and try to realize that it is solely argumentative without any possibility of increasing understanding. Wrong characterization of my intention, pretense that you don't know what a gateway might be, etc. etc. > >> >> It seems to me that the problems and solutions I have pointed out >> many many times are not of interest to you, as you insist on being able >> to maintain unique link-local addresses in environments where such >> uniqueness is quite difficult to guarantee. > > Ok. > > I don't maintain that keeping LLs unique is easy. > > Let's just don't discourage them. Do you mean, let's not describe their problems? Why would such pretense be beneficial to anyone? > > I guess you want to invent a new way of keeping them unique, but not > to discourage them. No. I want _you_ to invent a new way of keeping them unique before you ask others to mandate their use. > > > Adhoc MANETs is not the first time people encountered > Ethernet-unfriendly places. Often the use is PPP/SLIP in such places. > Often it suffices. PPP uses link-local addresses too. Your example proves my point. Mobile PPP? > > Remark too that recently more and more links try to offer an > Ethernet-friendly IP, that is at least WLAN, WPAN and WMAN. WPAN > 802.15.4, for example pertains to both "MANET" and to "Ethernet". > WLAN 802.11s "mesh" also pertains to both EThernet _and_ to MANET. Did we have any discussion yet about whether or not all [autoconf] nodes were blessed with unique MAC addresses? Hmm.... I'm trying to remember? Can you help? > > I don't understand why you say I exclude useful environments... Because you do. > >> So why do you bother with [autoconf]? Your problem is solved >> elsewhere. > > Well, let's say that I have a green light from the Chairs saying my > opinion is welcome. > > Chairs have means to make me shut up, if they so decided. My acquaintance of the chairs of this group is that they encourage thoughtful participation. And, they welcome constructive advice. > >>> Don't you think we should mention how the addressing model does not >>> create these problems? >> >> Problems, problems. Right now our problem is managing >> a discussion about the realm of applicability for unique >> link-local addresses. It seems to be based almost purely >> on dogmatism instead of engineering tradeoffs. > > Avoid dogmatism - I want too. Try on for size to disengage from requiring link-locals. > > >> I'm not a chair of anything. Do I count as a potential >> person that might have understanding? > > Charles - you too don't see any problem in the Charter saying the > non-MANET nodes should not be affected by the MANET nodes. > > I think - on a personal speculating note - that you believe Charter is > so-and-so-relatively-so as long as it does not forbid you anything. I might flatly say this is wrong, but I don't know what it means. > > To me, there is a huge difference between what Charter says and what > DT does. If there is ambiguity in the Charter, maybe it should be clarified. > >>> Do we have a Charter only to have a few members of the >>> variable-geometry Design Team understand it they want to? >> >> If you insist on fixed geometry networks, I really think you are >> in the wrong working group. > > Well, sorry, variable-geometry might be a bad translation. > > I meant to say that the Design Team had a variable geometry (like the > F14 plane) in that it changed members at one time, and that one of the > members does not currently seem to be heard. If you are referring to Teco, then I can assure you that I heard him, and I honestly think his opinions were not only heard but frequently solicited. For my own part I read practically all of his messages and his BDRP draft, made comments, and participated with him. Everyone can get a little bit frustrated that things don't go their way, and nevertheless try to achieve the best possible outcome. Regards, Charlie P. From alexandru.petrescu@gmail.com Mon Oct 26 13:01: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 A781E28C343 for ; Mon, 26 Oct 2009 13:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.068, 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 h1N3EKy17vxf for ; Mon, 26 Oct 2009 13:01:37 -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 4FE1528C142 for ; Mon, 26 Oct 2009 13:01:36 -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 n9QK1mUh029782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 26 Oct 2009 21:01:48 +0100 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 n9QK1m4l016507 for ; Mon, 26 Oct 2009 21:01:48 +0100 (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 n9QK1mn8025579 for ; Mon, 26 Oct 2009 21:01:48 +0100 Message-ID: <4AE6002C.3020704@gmail.com> Date: Mon, 26 Oct 2009 21:01:48 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "autoconf@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Autoconf] Which IPv6 addresses? 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, 26 Oct 2009 20:01:37 -0000 Currently the DT draft discourages LLs. Yet it doesn't mention any of the following: global addresses, multicast groups/addresses, anycast addresses, unspecified addresses, ULAs, documentation addresses, loopback address, 6to4 prefix (2002::), default route prefix (::), CGAs, HBAs, Teredo. There may be more. There's talk at IETF of "IPv6 short addresses" too. Some of the above may be yet inappropriate, but none? Draft only mentions to use a /128 prefix. So - I wonder - what addresses does AUTOCONF plan to use in the practical addressing model? Or do you plan to request a new IPv6 address type (see after my sig)? Do we only agree on "no LL, yes /128 unique prefixes"? Alex RFC4291: > 2.4. Address Type Identification > > The type of an IPv6 address is identified by the high-order bits of > the address, as follows: > > Address type Binary prefix IPv6 notation Section > ------------ ------------- ------------- ------- > Unspecified 00...0 (128 bits) ::/128 2.5.2 > Loopback 00...1 (128 bits) ::1/128 2.5.3 > Multicast 11111111 FF00::/8 2.7 > Link-Local unicast 1111111010 FE80::/10 2.5.6 > Global Unicast (everything else) From hrogge@googlemail.com Mon Oct 26 13:12: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 5BF4A3A6A7B for ; Mon, 26 Oct 2009 13:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.203, 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 Ii997PHApRJn for ; Mon, 26 Oct 2009 13:12:41 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 5BAA43A67AC for ; Mon, 26 Oct 2009 13:12:41 -0700 (PDT) Received: by ewy4 with SMTP id 4so3993028ewy.37 for ; Mon, 26 Oct 2009 13:12:52 -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=ns9keAI4dNzCwn9Q4Czjm7c89z72yVuB/0hZ2fx3mVQ=; b=OKoVed1rErBpr9eblMFqGIZQJ7d4UgPR7bK9+XQsCyOtJQ9CSayoONC1/CcTDA6xgA bNflhN+9O45xG1+EjcOEFhlyO3uqhigb4mvefu0GKaRh7OayYLP1IyFZSemoTeXio/1c lF41Q6BJQHA/ZWALCeiLUIiMeCXR/ZdPYMHZ8= 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=fpJx1UPx2DkOhJt+N7AljolOfLIigMAX6JWVAjmDT6+v+JsDVN0FB/bMY7ZVhBaFlk mDn/jJb7R3ARA55SZ3XBW/mnYbcBOumwo7jCGqDMKelwkCuT4bMqxkB6GrZ6w5vBhcxS oy08pgZ7MT47Br66xKF3BbHrOXSjhEVzJvltg= Received: by 10.211.130.6 with SMTP id h6mr4571031ebn.97.1256587972534; Mon, 26 Oct 2009 13:12:52 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 5sm614697eyf.9.2009.10.26.13.12.50 (version=SSLv3 cipher=RC4-MD5); Mon, 26 Oct 2009 13:12:51 -0700 (PDT) From: Henning Rogge To: autoconf@ietf.org Date: Mon, 26 Oct 2009 21:12:45 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-gentoo-r2; KDE/4.3.2; x86_64; ; ) References: <4AE6002C.3020704@gmail.com> In-Reply-To: <4AE6002C.3020704@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4656885.9LWkmN0uiP"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910262112.50128.hrogge@googlemail.com> Subject: Re: [Autoconf] Which IPv6 addresses? 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, 26 Oct 2009 20:12:42 -0000 --nextPart4656885.9LWkmN0uiP Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am Montag 26 Oktober 2009 21:01:48 schrieb Alexandru Petrescu: > Currently the DT draft discourages LLs. >=20 > Yet it doesn't mention any of the following: > global addresses, do work well > multicast groups/addresses, do work well for mesh wide multicast (see SMF). More work for global multic= ast=20 (as always). > anycast addresses, do work well > unspecified addresses, I don't think they are routed anywhere > ULAs, Should work like global ones, unless you get an address conflict > loopback address, Do not matter for manet routing as a destination. > 6to4 prefix (2002::), should work, because they can be handled like any global IP for routing > default route prefix (::),=20 Do not matter for manet routing as a destination. > documentation addresses, > CGAs, HBAs, Teredo. There may be more. There's talk > at IETF of "IPv6 short addresses" too. > Some of the above may be yet inappropriate, but none? I see no special problems with any of them LLs are special because they assume a closed broadcast domain for DAD runni= ng=20 well. Manets do not have a closed broadcast domain. Henning Rogge --nextPart4656885.9LWkmN0uiP Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEABECAAYFAkrmAsIACgkQcenvcwAcHWeQswCdEDVhcLd6f0QkcPCM7n3taOUD oC4An3Avm/nx4egqntaHUCcUhl+lcZWs =pbV4 -----END PGP SIGNATURE----- --nextPart4656885.9LWkmN0uiP-- From alexandru.petrescu@gmail.com Mon Oct 26 13:16: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 16ACF3A67AC for ; Mon, 26 Oct 2009 13:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.067, 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 baBToXgdimdb for ; Mon, 26 Oct 2009 13:16:42 -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 963EC3A6A80 for ; Mon, 26 Oct 2009 13:16:41 -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 n9QKGqva013590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 21:16:52 +0100 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 n9QKGqvK017460; Mon, 26 Oct 2009 21:16:52 +0100 (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 n9QKGp6L027236; Mon, 26 Oct 2009 21:16:52 +0100 Message-ID: <4AE603B3.1000005@gmail.com> Date: Mon, 26 Oct 2009 21:16:51 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4AE5C151.6000800@gmail.com> <014f01ca5658$cd6130d0$68239270$@nl> <4AE5D7E5.60301@earthlink.net> <4AE5E42A.4050800@gmail.com> <4AE5EAF9.6080006@earthlink.net> <4AE5F2D1.7040103@gmail.com> <4AE5FE54.2000808@earthlink.net> In-Reply-To: <4AE5FE54.2000808@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Protocols involving link-local addresses 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, 26 Oct 2009 20:16:43 -0000 HEllo Charles, I want to answer not leave unanswered quyestions. Charles E. Perkins a écrit : [...] >> And then let's mention those things which risk being broken. Which >> protocol, which implementaiton risks being broken. Go ahead. I >> have my ideas about what might break if LLs are discouraged. > > Let's say that link-locals are broken, and it will take effort to > re-establish them for useful purposes. Then your list of protocols > would serve notice for people to take a look and determine whether or > not each item on that list might require modification. Makes sense. [...] >> And that whatever I call "adhoc" - once I talk about it it's no >> longer adhoc, it's planned. > > That is probably appropriate, as long as you describe networks with > core forwarding nodes within a single hop of all other nodes, or > single links. I might be wrong on this point. No, you are right. I can not describe something which I can't describe. > Can you suggest a model for ad hoc networks that is sufficiently > general for all of your purposes? No - I can't. I can only describe networks for specific purposes. YEs, you will disagree. > What if your model is then > considered far too restrictive for the purposes of other people? > Should we conform to your model, or enable development of protocols > for the more general models desired by other people? Right. But let's see these models. Until now we only leave the door open. Spend time, keep the door open. >>>> Don't you think we should do something about this Charter text: >>>> >>>>> It is required that such [addressing] models do not cause >>>>> problems for ad hoc-unaware parts of the system, such as >>>>> standard applications running on an ad hoc node or regular >>>>> Internet nodes attached to the ad hoc nodes. >>> >>> This is fine with me. We can have an ad hoc network that doesn't >>> mess up the Internet. It can get addresses. Those addresses do >>> not mess up the Internet. >> >> There are few addresses which don't mess up the Internet: >> link-locals, globals, multicast, etc. You discourage the LLs, the >> globals are not mentioned, neither the multicast. > > Here I entirely miss your point. > > What if the draft "mentions" globals? It would be easier to read for someone used to RFCs: "global addresses" as in rfc4291, or anycast addresses as in RFCXXXX. Easier to see the implementation aspects too. > And it is not at all unusual for initial work on address > autoconfiguration to delay the consideration of multicast. In my > opinion, it is highly appropriate for [autoconf] to delay multicast > address allocation. I agree. But how about the use? Since the draft tends to discourage LLs, is it going to tend to discourage the solicited-node multicast addresses as well (Ulrich talked about those today). For LLs they're self-formed, no need to allocate them. They're there. If you plan on discouraging those too... Does the draft have an opinion on these self-formed solicited-node multicast addresses? Are they discouraged? Allowed? Not mandated? SIlence about them? But they are there on all nodes running IPv6. >> No such gateway mentioned in the draft. > > Why should the draft mention the gateway? To have a topology drawned, to descirbe some model. It has no picture now. >> Charles - all that the draft is saying is this: -dont LL > I strongly encourage you to be accurate on this point. Namely, as I > remember it anyway, the draft specifies that we not mandate the use > of link-local addresses. I think it comes from my IPv4 reading of it, which comes before IPv4: > Note that the use of IPv4 link-local addresses [RFC3927] in this > context should be discouraged for most applications > "not mandate" != "prohibit". Think that I think of IP as IPv4/6, excuse me. I agree with you on "not mandating" LLs. >> -do /128 prefixes > ... unless one knows how to use shorter prefixes ... > >> -do unique addresses > > Any protocol with flooding operations will find great benefit and > simplification if it has the ability to rely on unique addresses. Ok, known. > It turns out to be not absolutely required, but the additional design > considerations are really quite nontrivial. That would be like > learning to run before learning to crawl or walk. > >> >> That's all! >> >> No mentioning of gateway, or how other non-MANET nodes work ok with >> MANET nodes. > > Since we have currently zero solutions on the standards track, I fail > to see how we can specify how the solution will work with a non-MANET > node. > > At least we can say that all of our current solutions so far are > completely compatible with non-MANET nodes. > > Is that a good start? Were we to say upfront we don't discourage neither IPv4 nor IPv6 LLs. >>> You can even have a subnet attached to an ad hoc node, and have >>> the ad hoc node managing as a default router for the other nodes >>> on that subnet. Those subnet- attached nodes may not even notice >>> that they are being served as nodes within an ad hoc network. >> >> Picture it and paste it in the draft, instead of "dont LL" and >> "/128 prefixes". > > (a) your characterization is wrong and (b) it would require > illustration of a particular solution. ... > > >> >>> That's drastically and totally different than saying you should >>> be able to take absolutely any Internet node today, stick it >>> anywhere withiin an ad hoc network, and expect it to work. >> >> Well, if your intention is to not allow any Internet node to >> connect to the MANET then what is the Gateway? > > Alex, please re-read your question and try to realize that it is > solely argumentative without any possibility of increasing > understanding. > > Wrong characterization of my intention, pretense that you don't know > what a gateway might be, etc. etc. > > >> >>> >>> It seems to me that the problems and solutions I have pointed out >>> many many times are not of interest to you, as you insist on >>> being able to maintain unique link-local addresses in >>> environments where such uniqueness is quite difficult to >>> guarantee. >> >> Ok. >> >> I don't maintain that keeping LLs unique is easy. >> >> Let's just don't discourage them. > Do you mean, let's not describe their problems? If LLs have a DAD problem then globals have it too. I believe there may be a problem solely with uniqueness when things move so fast that uniqueness is impossible. > Why would such pretense be beneficial to anyone? > >> >> I guess you want to invent a new way of keeping them unique, but >> not to discourage them. > > No. I want _you_ to invent a new way of keeping them unique before > you ask others to mandate their use. Right, I do not mandate them. I dont want them discouraged. I do not work towards uniqueness. Nowadays I hardcode the uniqueness on machines and dynamically propagate routes to follow that hardcodedness. (I am even open to people proposing non-unique addresses). [...] Alex From alexandru.petrescu@gmail.com Mon Oct 26 13:19:46 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 6A0BA28C145 for ; Mon, 26 Oct 2009 13:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.066, 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 qSA3G4VMpEzz for ; Mon, 26 Oct 2009 13:19:45 -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 CDFCE28C17E for ; Mon, 26 Oct 2009 13:19:37 -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 n9QKJorq015601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 21:19:50 +0100 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 n9QKJnR7017600; Mon, 26 Oct 2009 21:19:49 +0100 (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 n9QKJnsx027551; Mon, 26 Oct 2009 21:19:49 +0100 Message-ID: <4AE60465.8090005@gmail.com> Date: Mon, 26 Oct 2009 21:19:49 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Henning Rogge References: <4AE6002C.3020704@gmail.com> <200910262112.50128.hrogge@googlemail.com> In-Reply-To: <200910262112.50128.hrogge@googlemail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Which IPv6 addresses? 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, 26 Oct 2009 20:19:46 -0000 Henning Rogge a écrit : > Am Montag 26 Oktober 2009 21:01:48 schrieb Alexandru Petrescu: >> Currently the DT draft discourages LLs. >> >> Yet it doesn't mention any of the following: > >> global addresses, > do work well >> multicast groups/addresses, > do work well for mesh wide multicast (see SMF). More work for global multicast > (as always). > >> anycast addresses, > do work well > >> unspecified addresses, > I don't think they are routed anywhere > >> ULAs, > Should work like global ones, unless you get an address conflict > >> loopback address, > Do not matter for manet routing as a destination. > >> 6to4 prefix (2002::), > should work, because they can be handled like any global IP for routing > >> default route prefix (::), > Do not matter for manet routing as a destination. > >> documentation addresses, >> CGAs, HBAs, Teredo. There may be more. There's talk >> at IETF of "IPv6 short addresses" too. > >> Some of the above may be yet inappropriate, but none? > I see no special problems with any of them > > LLs are special because they assume a closed broadcast domain for DAD running > well. Manets do not have a closed broadcast domain. But Henning, DAD is required for _all_ addresses on a link, not only the LLs. Why do you only LL stuff discouraging? Alex > > Henning Rogge From hrogge@googlemail.com Mon Oct 26 13:27: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 C90573A6B26 for ; Mon, 26 Oct 2009 13:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 0le8ls-eJgaC for ; Mon, 26 Oct 2009 13:27:45 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id C32A33A6B23 for ; Mon, 26 Oct 2009 13:27:44 -0700 (PDT) Received: by ewy4 with SMTP id 4so4006650ewy.37 for ; Mon, 26 Oct 2009 13:27:54 -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=d6AqGnPAReQ+QCr3CUqUoc/QQwF3ECPr3ErqXlX5e4M=; b=V9PiLaodk7R+d/UzMfcVldZQoUUt08Q8nDHtwLZpwHA1QkdDaAIgwC2O1bQH3GwW3y wrhdN7nML/qfQaU5WVYaw2RuK0k0eAt1zKPzuf6xu9/Bp8VnrRfTT+pvcniv3zaKA9Ot w1c482dYCgCjeSJQlHQZmdmYgtkykykatA7ek= 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=iygo2UJj3VdDvcM0vH1vS9SVoAsg9h+1SByoDBtrbB2r08TxXMrLW8V9n7gt87wdny c0VFMXG8qeu9buCW/CuycQ9UIo016VpjyPOUSp9XIV4wLb7cltHAr0Xi1ui3w6uCOX+j OfUa+vmrF7TKFmhK1uH1PpfATK1YttLcvGzUU= Received: by 10.211.155.11 with SMTP id h11mr5012153ebo.40.1256588873804; Mon, 26 Oct 2009 13:27:53 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 28sm5813684eyg.6.2009.10.26.13.27.51 (version=SSLv3 cipher=RC4-MD5); Mon, 26 Oct 2009 13:27:52 -0700 (PDT) From: Henning Rogge To: Alexandru Petrescu Date: Mon, 26 Oct 2009 21:27:46 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-gentoo-r2; KDE/4.3.2; x86_64; ; ) References: <4AE6002C.3020704@gmail.com> <200910262112.50128.hrogge@googlemail.com> <4AE60465.8090005@gmail.com> In-Reply-To: <4AE60465.8090005@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1544682.kFfc67t3xz"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910262127.51127.hrogge@googlemail.com> Cc: autoconf@ietf.org Subject: Re: [Autoconf] Which IPv6 addresses? 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, 26 Oct 2009 20:27:45 -0000 --nextPart1544682.kFfc67t3xz Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am Montag 26 Oktober 2009 21:19:49 schrieb Alexandru Petrescu: > But Henning, DAD is required for _all_ addresses on a link, not only the > LLs. DAD is nice to have... but I don't see it required for anything except=20 autogenerated addresses. DAD is not even helpful for global IPs... because the range of DAD is=20 (according to my knowledge) only 1 hop. =20 > Why do you only LL stuff discouraging? Okay, let me say it again. LL assume that your broadcast domain is closed. This way the IP stack can b= e=20 sure that DAD will create a unique LL-IP for the interface. Unfortunately most mesh networks are not behaving this way. So the semantic= of=20 LL-generation with DAD is not working correctly. Henning --nextPart1544682.kFfc67t3xz Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEABECAAYFAkrmBkcACgkQcenvcwAcHWeNpwCfQIqbKa5vV7AJIncd+PR/U9uk xJ8AmwQ9zP5B3UgM5bdDmm4nvvl1MHTv =dJi1 -----END PGP SIGNATURE----- --nextPart1544682.kFfc67t3xz-- From charles.perkins@earthlink.net Mon Oct 26 13:39: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 C3CAF3A680F for ; Mon, 26 Oct 2009 13:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.041, 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 7oFcI9ZNT6+l for ; Mon, 26 Oct 2009 13:39:08 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id AEB483A67E1 for ; Mon, 26 Oct 2009 13:39:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=TTD01hAL8tUdvyOuQLPZNerghO3CDxJJkygcRmvyAaC8ah5kuXoExViIIKMBHJwr; 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.16]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1N2WLZ-0000I5-RI; Mon, 26 Oct 2009 16:39:21 -0400 Message-ID: <4AE608F9.50102@earthlink.net> Date: Mon, 26 Oct 2009 13:39:21 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Teco Boot References: <4AE5C151.6000800@gmail.com> <4AE5C6BD.2030501@gmail.com> <4AE5C9CB.5030807@gmail.com> <5A0019AD-0BB0-4EAF-969E-73E3F1DAF1DE@thomasclausen.org> <4AE5CC23.1090105@gmail.com> <4AE5CF72.9070700@gmail.com> <4AE5D954.8020705@earthlink.net> <017b01ca5668$0901f070$1b05d150$@nl> <4AE5ED59.3020801@earthlink.net> <018f01ca5671$b51f6ff0$1f5e4fd0$@nl> In-Reply-To: <018f01ca5671$b51f6ff0$1f5e4fd0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f526b159acc37194a47628aca2c28b7c6f6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Protocols involving link-local addresses 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, 26 Oct 2009 20:39:09 -0000 Hello Teco, Teco Boot wrote: > > > ... BRDP could help. For me, it is the holy grail. But still > in the embryo stage. Didn't MANET protocols stay that way over 10 years? > I mean: BRDP works great in simulation !! > I think it is safe to say that MANET protocols have moved out of the lab and into real networks. However, I think they still have a long way to go. They are "widely" deployed, but not at all universally available. As I remember, BRDP really relies on a particular model of network, but now I would need to go review the details. > > >> Don't you think we should have a design team to develop >> recommendations in the case of IEEE-style MAC addresses, >> for which uniqueness can be assumed? >> >> Then we could have a general solution for non-unique >> link-locals, which should be compatible with the specific >> solution. The general solution could even admit the >> specific solution as a special case. As it should be. >> > > I've to think on this. > ... > - Deviations from IEEE could have to do with overhead. I know of > L2 addresses that are only a few bits long. Still, these radios are > capable of transmitting IP packets. Payload is compressed by > application, L2-header is highly optimized. IP header compression is > on the todo list (or "beta", or just out there). If we come up > with something, it must interact with L2&L3 header compression. > But this really isn't the point. The point is that IP is supposed to work over a great many kinds of media. Not only those media for which layer-2 address uniqueness can be assumed. Before you try to enforce such a restriction, I think you should try to update RFC 791 and RFC 2460 to specify that they are only supposed to work on networks that obey that restriction. > - The multiple hop uniqueness test need more thoughts. I'll write > this on a piece of paper and put it under my pillow tonight. Yes, it would be good to identify your position on multi-hop networks. > > > > > > > Multi-homing is (partly) solved by BRDP based routing. > Just kill the default gateway and send packets to the BR that > "owns" the SA prefix. > What is left is address handover for apps. MIP/NEMO can do this, > HIP, SHIM6 and multipath TCP, just to name a few. > And of course SA selection. BRDP provides great metrics for it. > I did not in any way mean to suggest that solutions for multi-homing were unknown. Just that it's quite a bit more difficult. > > >> I am not currently a practitioner of this excellent school >> of engineering, but I have experience with devices that >> have terribly small power budgets and unusual layer-2 >> addressing schemes. >> > > OK, you are in the IEEE camp right now! Great!! > Or have devices by hand, that can come up with real good PRNs. > > I had the opinion you worked for a museum. Sorry for that, I was wrong. > Right now I am in the LTE camp. Somehow your comment about the museum is hard for me to interpret in any flattering way, sigh. > >> But this discussion has gone on many times. I think I remember >> some messages from John Mullen on the matter a while back. >> And then there is the historical matter of the development >> process for IPv6. There were strong proponents that we should >> rely on layer-2 uniqueness, but the consensus was quite broad >> that we needed to allow IPv6 to serve environments where that >> assumption is not true. And yet there is the universal agreement >> that in some restricted environments of the obvious sort, we can >> get better performance with Optimistic DAD and so on. >> >> Except that it seems all this wealth of experience gets left at >> the door when entering into the discussions on [autoconf]. >> > > I think no one wants to take DAD out of the specs. I have my doubts, > for security reasons. On wired networks we can handle overhead and accept > small delays. In a MANET, this is different and we are allowed to disable > DAD. I remember the posting from Thomas Narten on this (September 2nd). > I am not sure about what specs DAD would be taken out of. And, the design of DAD will depend on what we can do to "substitute" for link-local addresses when the latter are determined to be unsuitable for use in the general case. > > Do we agree on a goal, having MANET unique InterfaceIDs and go from there? > For address autoconfiguration, address uniqueness is part of the _process_, not automatically given as one of the hypotheses. > And forming a DT on a protocol for some assurance on uniqueness, for those > who need it? I'm not candidate. But I support such an approach if it would > rescue Autoconf. > The design team would submit (1) a document about how to configure addresses given the existence of a unique MAC address and, if they are brave, (2) a protocol to guarantee link-local address uniqueness when the MAC address assumption does not hold. Document (2) might impose other restrictions, weaker than the MAC address assumption, but stronger than the general unrestricted case. Regards, Charlie P. From alexandru.petrescu@gmail.com Mon Oct 26 14:10:04 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 DF86528C2D8 for ; Mon, 26 Oct 2009 14:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.957 X-Spam-Level: X-Spam-Status: No, score=-1.957 tagged_above=-999 required=5 tests=[AWL=0.292, 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 acOlZZt4ewE4 for ; Mon, 26 Oct 2009 14:10:04 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id BDE3C3A6AE0 for ; Mon, 26 Oct 2009 14:09:31 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id CCFAED4814D; Mon, 26 Oct 2009 22:09:40 +0100 (CET) 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 9AF76D4800D; Mon, 26 Oct 2009 22:09:37 +0100 (CET) Message-ID: <4AE61010.9020406@gmail.com> Date: Mon, 26 Oct 2009 22:09:36 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Henning Rogge References: <4AE6002C.3020704@gmail.com> <200910262112.50128.hrogge@googlemail.com> <4AE60465.8090005@gmail.com> <200910262127.51127.hrogge@googlemail.com> In-Reply-To: <200910262127.51127.hrogge@googlemail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091026-0, 26/10/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD problem in IPv6 mesh networks for LL (was: Which IPv6 addresses?) 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, 26 Oct 2009 21:10:05 -0000 Henning Rogge a écrit : > Am Montag 26 Oktober 2009 21:19:49 schrieb Alexandru Petrescu: >> But Henning, DAD is required for _all_ addresses on a link, not only the >> LLs. > DAD is nice to have... but I don't see it required for anything except > autogenerated addresses. > > DAD is not even helpful for global IPs... because the range of DAD is > (according to my knowledge) only 1 hop. > >> Why do you only LL stuff discouraging? > Okay, let me say it again. > > LL assume that your broadcast domain is closed. Sorry, I do am open to talk, but what does it mean "broadcast domain closed" for IPv6? Is it the link on which these IPv6 LLs are present? IS it that that link is of definite size somehow? > This way the IP stack can be > sure that DAD will create a unique LL-IP for the interface. Yes, considering everybody on the link will hear the unsolicited NAs (part of the DAD procedure). And no, if you consider that that link does not hold anybody together at some point, and that people come in and move out of the link when DAD is running. So my node's LL's DAD starts, nobody replies NA to the three successive unsolicited NSs, and my node believes its LL is unique. And sudenly afterwards some other node comes in using my IPv6 LL. So we find both using the same LL. Is this the problem you talk about? Should we describe this example problem in detail (DAD, 3 unsolicited NAs, new member) such that draft's reader understand what's meant by this? If yes, then this problem may be important, because a router trying to deliver packets to my node will deliver them to somebody else too, or only to somebody else. > Unfortunately most mesh networks are not behaving this way. So the semantic of > LL-generation with DAD is not working correctly. Ok - can we describe how it does not work correctly? Alex From teco@inf-net.nl Mon Oct 26 14:23: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 B45BC28C31F for ; Mon, 26 Oct 2009 14:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 A6mWG2XfUY9j for ; Mon, 26 Oct 2009 14:23:03 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 9750128C14A for ; Mon, 26 Oct 2009 14:23:02 -0700 (PDT) Received: (qmail 23132 invoked from network); 26 Oct 2009 22:23:12 +0100 Received: from unknown (HELO M90Teco) (62.140.137.103) by server9.hosting2go.nl with SMTP; 26 Oct 2009 22:23:12 +0100 From: "Teco Boot" To: "'Henning Rogge'" , "'Alexandru Petrescu'" References: <4AE6002C.3020704@gmail.com> <200910262112.50128.hrogge@googlemail.com> <4AE60465.8090005@gmail.com> <200910262127.51127.hrogge@googlemail.com> In-Reply-To: <200910262127.51127.hrogge@googlemail.com> Date: Mon, 26 Oct 2009 22:22:36 +0100 Message-ID: <01af01ca5682$85339d50$8f9ad7f0$@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: AcpWetJvjjywQPDySUGDX0/sRVfXJgAB2IEg Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] Which IPv6 addresses? 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, 26 Oct 2009 21:23:03 -0000 >-----Oorspronkelijk bericht----- >Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens >Henning Rogge >Verzonden: maandag 26 oktober 2009 21:28 >Aan: Alexandru Petrescu >CC: autoconf@ietf.org >Onderwerp: Re: [Autoconf] Which IPv6 addresses? > >Am Montag 26 Oktober 2009 21:19:49 schrieb Alexandru Petrescu: >> But Henning, DAD is required for _all_ addresses on a link, not only >the >> LLs. >DAD is nice to have... but I don't see it required for anything except >autogenerated addresses. We are her in IETF and we have Standard Track RFCs. They specify otherwise. Can we all please read the RFCs? Teco. > >DAD is not even helpful for global IPs... because the range of DAD is >(according to my knowledge) only 1 hop. > >> Why do you only LL stuff discouraging? >Okay, let me say it again. > >LL assume that your broadcast domain is closed. This way the IP stack >can be >sure that DAD will create a unique LL-IP for the interface. > >Unfortunately most mesh networks are not behaving this way. So the >semantic of >LL-generation with DAD is not working correctly. > >Henning From alexandru.petrescu@gmail.com Mon Oct 26 14:39: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 3CD1028C183 for ; Mon, 26 Oct 2009 14:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=0.284, 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 Zw0Al1BMkPYO for ; Mon, 26 Oct 2009 14:39:46 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 4625628C2D8 for ; Mon, 26 Oct 2009 14:39:44 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 3BEA1D48087; Mon, 26 Oct 2009 22:39:53 +0100 (CET) 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 F17FDD48085; Mon, 26 Oct 2009 22:39:50 +0100 (CET) Message-ID: <4AE61725.9010508@gmail.com> Date: Mon, 26 Oct 2009 22:39:49 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Teco Boot References: <4AE6002C.3020704@gmail.com> <200910262112.50128.hrogge@googlemail.com> <4AE60465.8090005@gmail.com> <200910262127.51127.hrogge@googlemail.com> <01af01ca5682$85339d50$8f9ad7f0$@nl> In-Reply-To: <01af01ca5682$85339d50$8f9ad7f0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091026-0, 26/10/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] Which IPv6 addresses? 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, 26 Oct 2009 21:39:47 -0000 Teco Boot a écrit : > >> -----Oorspronkelijk bericht----- Van: autoconf-bounces@ietf.org >> [mailto:autoconf-bounces@ietf.org] Namens Henning Rogge Verzonden: >> maandag 26 oktober 2009 21:28 Aan: Alexandru Petrescu CC: >> autoconf@ietf.org Onderwerp: Re: [Autoconf] Which IPv6 addresses? >> >> Am Montag 26 Oktober 2009 21:19:49 schrieb Alexandru Petrescu: >>> But Henning, DAD is required for _all_ addresses on a link, not >>> only >> the >>> LLs. >> DAD is nice to have... but I don't see it required for anything >> except autogenerated addresses. > > We are her in IETF and we have Standard Track RFCs. They specify > otherwise. > > Can we all please read the RFCs? YEs, I agree, I sit all day long and read them. Moreover, I can not imagine myself doing "ifconfig del fe80:..." on all the interfaces on all the computers I use simply because this draft says: > o no two such interfaces in the network should be configured with > the same subnet prefix. or: > in general link-local addresses are of limited utility on links with > undetermined connectivity I prefer to think that my links have determined connectivity, as offered by the link-layer. And to understand that I go read IEEE documents too. Alex From teco@inf-net.nl Mon Oct 26 15:03:51 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 16B3928C2D8 for ; Mon, 26 Oct 2009 15:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 W7Z+DmeiTVHQ for ; Mon, 26 Oct 2009 15:03:50 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 563DF28C2C6 for ; Mon, 26 Oct 2009 15:03:49 -0700 (PDT) Received: (qmail 26570 invoked from network); 26 Oct 2009 23:03:57 +0100 Received: from unknown (HELO M90Teco) (62.140.137.103) by server9.hosting2go.nl with SMTP; 26 Oct 2009 23:03:57 +0100 From: "Teco Boot" To: "'Charles E. Perkins'" References: <4AE5C151.6000800@gmail.com> <4AE5C6BD.2030501@gmail.com> <4AE5C9CB.5030807@gmail.com> <5A0019AD-0BB0-4EAF-969E-73E3F1DAF1DE@thomasclausen.org> <4AE5CC23.1090105@gmail.com> <4AE5CF72.9070700@gmail.com> <4AE5D954.8020705@earthlink.net> <017b01ca5668$0901f070$1b05d150$@nl> <4AE5ED59.3020801@earthlink.net> <018f01ca5671$b51f6ff0$1f5e4fd0$@nl> <4AE608F9.50102@earthlink.net> In-Reply-To: <4AE608F9.50102@earthlink.net> Date: Mon, 26 Oct 2009 23:03:20 +0100 Message-ID: <01b001ca5688$363319a0$a2994ce0$@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: AcpWfGoh1+zAt2EgSISwbXJ8wgzk/QABivOg Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] Protocols involving link-local addresses 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, 26 Oct 2009 22:03:51 -0000 Hi Charlie, >-----Oorspronkelijk bericht----- >Van: Charles E. Perkins [mailto:charles.perkins@earthlink.net] >Verzonden: maandag 26 oktober 2009 21:39 >Aan: Teco Boot >CC: autoconf@ietf.org >Onderwerp: Re: [Autoconf] Protocols involving link-local addresses > > >Hello Teco, > >Teco Boot wrote: >> >> >> ... BRDP could help. For me, it is the holy grail. But still >> in the embryo stage. Didn't MANET protocols stay that way over 10 >years? >> I mean: BRDP works great in simulation !! >> > >I think it is safe to say that MANET protocols have moved out of the >lab and into real networks. However, I think they still have a long way >to go. They are "widely" deployed, but not at all universally >available. >As I remember, BRDP really relies on a particular model of network, >but now I would need to go review the details. I'll set up a test network at home, and maybe at a far more important environment after next. I'll asked IPv6 connectivity from my provider. Still waiting for a positive response. For now, BRDP is IPv6 based. I'll go for native IPv6. A bit principle, but it gives me some time to implement :-). Or get someone working it out for me. Volunteers? >>> Don't you think we should have a design team to develop >>> recommendations in the case of IEEE-style MAC addresses, >>> for which uniqueness can be assumed? >>> >>> Then we could have a general solution for non-unique >>> link-locals, which should be compatible with the specific >>> solution. The general solution could even admit the >>> specific solution as a special case. As it should be. >>> >> >> I've to think on this. >> ... >> - Deviations from IEEE could have to do with overhead. I know of >> L2 addresses that are only a few bits long. Still, these radios are >> capable of transmitting IP packets. Payload is compressed by >> application, L2-header is highly optimized. IP header compression is >> on the todo list (or "beta", or just out there). If we come up >> with something, it must interact with L2&L3 header compression. >> > >But this really isn't the point. The point is that IP is supposed to >work over >a great many kinds of media. Not only those media for which layer-2 >address >uniqueness can be assumed. Good PRN will do. Based on EMSI / EMEI or MAC address borrowed from another interface. Or use the radio Rx circuit as pretty good PRN seed. You were a bit kidding on the huge pre-shared key. And you did not respond on DHCP DUID. Or missed my question on this one? Did I miss an answer? As said, I'm fine with a protocol that helps multi-hop unique InterfaceIDs. I've no clue how to do it, but it is a nice design goal. > >Before you try to enforce such a restriction, I think you should try to >update >RFC 791 and RFC 2460 to specify that they are only supposed to work on >networks that obey that restriction. I'll stick to IPv6. RFC 2460 needs an update anyway (the, 6 pages on RH :-) But RFC4862 gives us all that we need. We have to decide spending cycles on good PRN (and some cents / pennies on HW) or the uniqueness protocol. Do you remember your strong opinion on saving each bit sent out, at costs of CPU cycles? I think the same is true for generating good PRN instead of try and error a duplicate test. >> - The multiple hop uniqueness test need more thoughts. I'll write >> this on a piece of paper and put it under my pillow tonight. > >Yes, it would be good to identify your position on multi-hop networks. > >> >> >> >> >> >> >> Multi-homing is (partly) solved by BRDP based routing. >> Just kill the default gateway and send packets to the BR that >> "owns" the SA prefix. >> What is left is address handover for apps. MIP/NEMO can do this, >> HIP, SHIM6 and multipath TCP, just to name a few. >> And of course SA selection. BRDP provides great metrics for it. >> > >I did not in any way mean to suggest that solutions for multi-homing >were unknown. Just that it's quite a bit more difficult. > >> >> >>> I am not currently a practitioner of this excellent school >>> of engineering, but I have experience with devices that >>> have terribly small power budgets and unusual layer-2 >>> addressing schemes. >>> >> >> OK, you are in the IEEE camp right now! Great!! >> Or have devices by hand, that can come up with real good PRNs. >> >> I had the opinion you worked for a museum. Sorry for that, I was >wrong. >> > >Right now I am in the LTE camp. Somehow your comment about >the museum is hard for me to interpret in any flattering way, sigh. > >> >>> But this discussion has gone on many times. I think I remember >>> some messages from John Mullen on the matter a while back. >>> And then there is the historical matter of the development >>> process for IPv6. There were strong proponents that we should >>> rely on layer-2 uniqueness, but the consensus was quite broad >>> that we needed to allow IPv6 to serve environments where that >>> assumption is not true. And yet there is the universal agreement >>> that in some restricted environments of the obvious sort, we can >>> get better performance with Optimistic DAD and so on. >>> >>> Except that it seems all this wealth of experience gets left at >>> the door when entering into the discussions on [autoconf]. >>> >> >> I think no one wants to take DAD out of the specs. I have my doubts, >> for security reasons. On wired networks we can handle overhead and >accept >> small delays. In a MANET, this is different and we are allowed to >disable >> DAD. I remember the posting from Thomas Narten on this (September >2nd). >> > >I am not sure about what specs DAD would be taken out of. And, the >design of >DAD will depend on what we can do to "substitute" for link-local >addresses when >the latter are determined to be unsuitable for use in the general case. > >> >> Do we agree on a goal, having MANET unique InterfaceIDs and go from >there? >> > >For address autoconfiguration, address uniqueness is part of the >_process_, not automatically >given as one of the hypotheses. > > >> And forming a DT on a protocol for some assurance on uniqueness, for >those >> who need it? I'm not candidate. But I support such an approach if it >would >> rescue Autoconf. >> > >The design team would submit (1) a document about how to configure >addresses >given the existence of a unique MAC address and, if they are brave, (2) >a protocol >to guarantee link-local address uniqueness when the MAC address >assumption >does not hold. Document (2) might impose other restrictions, weaker >than the >MAC address assumption, but stronger than the general unrestricted case. For (1), it is about unique InterfaceIDs, agreed? And implementers may use the mechanism for highly unique InterfaceIDs, at own risk. (BRDP is an example output, could be used as input) Then, we can indeed take a next step (2), working on multi-hop duplicate detection, either by purpose (spoofing) or accident (bad PRN) and switch-over to an alternative address. This would work together with private addresses and / or SeND. Great. Regards, Teco > > >Regards, >Charlie P. From ryuji.wakikawa@gmail.com Mon Oct 26 18:20:04 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 5B6E53A67B3 for ; Mon, 26 Oct 2009 18:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[AWL=-1.298, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_32=0.6, MIME_QP_LONG_LINE=1.396] 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 Kgio56+PS37l for ; Mon, 26 Oct 2009 18:20:03 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id ECFBE3A67B8 for ; Mon, 26 Oct 2009 18:20:02 -0700 (PDT) Received: by ewy4 with SMTP id 4so4214488ewy.37 for ; Mon, 26 Oct 2009 18:20:14 -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=+NoGH141210Yiymw7m5zJYhI+0JbVDoU8RL+MGwPYSw=; b=fLPGgrSTocoxUqp0zv48CsX2XD6ipJ+u6ZJVSN49qQdRq6XQzt7Ux8A8jCoaI3VuNy XTcdkoaeibzNFmVliuyhnLzq5bxXKgqo/4tcBqTaapxZYpOVe2AnWm3GB3hcH+8dNFay oIiztvgZCIvuETKeezdwzyvjEWGXaPOkm2CDw= 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=L5hGkSWVk/TImfGzbJa4bs7KIk8jmr/mRN9I3+x02Nb1XWligm+X/PJoSbrpDlzeFc xCt3ahutxYFpLy4YGm5mu4okgbJtL5cwC4ekcqjKzggpAWY2cRIUB5hqep58JebX6gO1 hfQnBAtlv/R5z81V3P72gag3KaZfTK/IRYv0g= Received: by 10.216.88.14 with SMTP id z14mr109421wee.25.1256606414506; Mon, 26 Oct 2009 18:20:14 -0700 (PDT) Received: from macbookpro-ryuji.paloalto.toyota-itc.com ([206.132.173.18]) by mx.google.com with ESMTPS id q9sm2042226gve.0.2009.10.26.18.20.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 26 Oct 2009 18:20:13 -0700 (PDT) From: Ryuji Wakikawa To: cjbc@it.uc3m.es In-Reply-To: <1256389726.5286.65.camel@acorde.it.uc3m.es> 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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <4AE2D5AD.6090701@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <125638 9726.5286.65.camel@acorde.it.uc3m.es> Message-Id: <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 18:20:10 -0700 X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind 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, 27 Oct 2009 01:20:04 -0000 Hi Carlos, On 2009/10/24, at 6:08, Carlos Jes=C3=BAs Bernardos Cano wrote: > On Sat, 2009-10-24 at 05:50 -0700, Ryuji Wakikawa wrote: >> Hi Teco, >> >> On 2009/10/24, at 4:46, Teco Boot wrote: >> >>>> Van: Ryuji Wakikawa >>>> If your observation is true, RFC4862(2462-bis) can be updated like >>>> "DAD is an option". >>>> But RFC4862 still mandate DAD. >>> >>> >>> Hi Ryuji, all, >>> >>> I have asked some pertinent questions to this workgroup about DAD. >>> Until now, I didn't see answers. What I see is more and more >>> confusion. >>> >>> Please confirm that: >>> >>> 1: DAD is not for link-local addresses only >>> =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 >>> DAD MUST run for all types of unicast addresses [RFC 4862, page >>> 12-13]. >>> In reality, it is not a MUST but a SHOULD. I say so, because there =20= >>> are >>> exceptions [RFC 4862, page 12-13]. >>> It is explicitly mentioned that new implementations MUST NOT do an >>> optimization for performing DAD for link-locals only [RFC 4862 page >>> 13]. >> >> DAD is mandatory. The document said "MUST". >> The exception is for interoperability with older implementations. > > Or if DupAddrDetectTransmits is set to zero, which I think it is not > forbidden by RFC4862. This value can be set if the link-local address is guaranteed its =20 uniqueness without IPv6 DAD operations. For example, RFC2472 As long as the Interface Identifier is negotiated in the IPV6CP phase of the PPP connection setup, it is redundant to perform duplicate address detection as a part of the IPv6 Stateless Autoconfiguration protocol [3]. Therefore it is recommended that for PPP links with the IPV6CP Interface-Identifier option enabled the default value of the DupAddrDetectTransmits autoconfiguration variable [3] be zero. This value is not introduced to skip the uniqueness check for Link-=20 local. The LL address MUST be always verified its uniqueness . We cannot change this definition at AUTOCONF WG. If you mandate the link-local in MANET addressing model, we need a DAD =20= mechanism to guarantee the uniqueness. We've discussed that this DAD is difficult in some scenarios. We knew =20= there is a scenario where this DAD can be optimized. Our addressing model should cover all the possible scenarios. regards, ryuji > > Thanks, > > Carlos > >> >>> 2: DAD may be disabled, in cases overhead outweighs its benefits >>> =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 >>> It is clearly specified that DAD may be disabled [RFC 4862 page 9]. >>> In my opinion, this is the case where bandwidth usage is constrained >>> and InterfaceIDs are highly unique or even guaranteed unique. >>> This is the case in all MANETs I dealt with, and is not restricted =20= >>> to >>> IEEE MAC addresses. >> >> fine in your network, but there are other MANETs not having such >> condition. >> >> >>> Because there is so much misconception on DAD, we fail to make even >>> the >>> smallest progress. I ask the chairs to correct all postings on false >>> statements on what Standards Track RFCs specify. >> >> What is the misconception? >> We cannot fix your issue of the general IPv6 spec. in AUTOCONF WG. >> >>> I am not interested in long discussions on DAD. But what I dislike =20= >>> is >>> strong opinions on DAD and link-locals that are based on false >>> assumptions. >> >> Even you think it's false, that is the current agreement in IETF >> (according to RFCs). >> >>> I continue posting on DAD and link-locals, because I think it is the >>> foundation for IPv6 Stateless Address Autoconfiguration. We need >>> some sort of uniqueness, either for each and every address or for a >>> piece of the address, that is used for all addresses of a box. I =20 >>> think >>> the IPv6 Addressing Architecture [RFC 4291] provides what we need, >>> that >>> is a 64-bits InterfaceID (unicast address start with binary 000) >>> [RFC 4291 page 8]. Having unique InterfaceIDs, we can easily add 64- >>> bit >>> prefixes, either ULA for MANET-local, or border router provided >>> prefixes >>> for attached MANETs. >>> >>> >>> When I read back both proposals for the MANET address model, I see >>> bernardos-autoconf-addressing-model is more complete (no open =20 >>> issues) >>> and better aligns with current Standard Track RFCs. I DO NOT say >>> link-local addresses MUST be used for routing protocols, but it can >>> be very practical, as is clearly shown in running code of OSPF-=20 >>> MANET. >> >> AFAIK, this issue was closed at the previous consensus call. >> We don't open the issue again. Please respect to the consensus in =20= >> WG. >> >>> Also, there is code of BRDP in simulators that run without problems. >>> I respect other opinions on using link-locals, and I have nothing >>> against >>> weakening mandatory usage of them. The key point here is having =20 >>> unique >>> InterfaceIDs. Using it, we are able to swap prefixes easily. We =20 >>> could >>> define a protocol for detecting duplicate InterfaceIDs in the MANET, >>> this would work for all of us, when needed. >> >> Your proposal is not what the current IPv6 specs said. >> In AUTOCONF env, we will face more chances to have address =20 >> duplication >> due to topology changes in some scenarios. >> We cannot ignore these scenarios and relax the DAD for link-local. >> >> That was what we had discussed at the previous IETF meeting and >> conclusion at the previous consensus call. >> I appreciate if you can follow the WG agreement. >> >> regards, >> ryuji >> >>> >>> I have posted proposals for corrections on the "DT draft". There was >>> low >>> acceptance. I think it doesn't help to resubmit. We have an archive >>> for it. >>> >>> >>> Regards, Teco >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > --=20 > Carlos Jes=C3=BAs Bernardos Cano http://www.netcoms.net > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 From ryuji.wakikawa@gmail.com Mon Oct 26 18:25: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 BA42F3A6778 for ; Mon, 26 Oct 2009 18:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] 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 g8Yy6scvQYUm for ; Mon, 26 Oct 2009 18:25:48 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 14AC73A66B4 for ; Mon, 26 Oct 2009 18:25:47 -0700 (PDT) Received: by ewy4 with SMTP id 4so4217705ewy.37 for ; Mon, 26 Oct 2009 18:25:59 -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=d4c1qpIxBDniBZw1jR9ZY6ezVAE8vA4MhPtIseQqiDE=; b=nniwnnZAc+BQ6pmUsThgHJKQU0a5VlbazC3h+0HDahKZO/0a5XEhFTk8fQsdFd/GpK 9Fr0TrG7RZD9R7UIie31+vhYNd0d6lFrbb158j43Um3jQ/tWcTcuNar3aA4ChbuQFfY7 KWGwVlrktnBBfnbS9HvdRmqsOpd+Qg3vHDTgA= 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=CLUhdVHYLKAE9xCoY0qNFsV5ic+IVDpHFyh1oiUmLxyYOUypvD5Yx+TcCSXsOEUN8L ru8ZZVmRXI/mCnUPEw24e6hYoJ43OGLZqiRFQE0gw4pO9ROeJARSYwFU8nHpWKkyl/gc RfDijnqrQ/39etj8lL1or1GYjMzNWSUogFu/c= Received: by 10.216.90.209 with SMTP id e59mr2601786wef.193.1256606758813; Mon, 26 Oct 2009 18:25:58 -0700 (PDT) Received: from macbookpro-ryuji.paloalto.toyota-itc.com ([206.132.173.18]) by mx.google.com with ESMTPS id n12sm11890362gve.21.2009.10.26.18.25.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 26 Oct 2009 18:25:57 -0700 (PDT) From: Ryuji Wakikawa To: cjbc@it.uc3m.es In-Reply-To: <1256492329.4766.39.camel@acorde.it.uc3m.es> References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <0E0F03A1-EC0C-4FF9-AB17-DB2029F7363E@gmail.com> <1256492329.4766.39.camel@acorde.it.uc3m.es> Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 18:25:53 -0700 X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 27 Oct 2009 01:25:49 -0000 Hi On 2009/10/25, at 10:38, Carlos Jes=C3=BAs Bernardos Cano wrote: > Hi Ryuji, > > On Sat, 2009-10-24 at 03:00 -0700, Ryuji Wakikawa wrote: >> Hi Carlos, >> >> On 2009/10/21, at 17:10, Carlos Jes=C3=BAs Bernardos Cano wrote: >> >>> Hi Charlie, >>> >>> On Wed, 2009-10-21 at 16:08 -0700, Charles E. Perkins wrote: >>>> Hello Carlos and Ronald, >>>> >>>> Intrigued by Alex's email to the [autoconf] mailing list, I read >>>> your draft, which suggests the mandate: >>> >>> Thanks for reading the draft. We are working on a -01 version (we >>> submitted -00 to meet the deadline and we hope to make some changes >>> before announcing it on the ML), but I'll provide my view on your >>> questions. >>> >>>> "MANET interfaces MUST also be configured with >>>> IPv6 Link-local addresses". >>>> >>>> But there is no indication in the draft about why that >>>> mandate might result in anything useful. >>>> >>>> What if [autoconf] recommended assignment of a distinguished >>>> link-local address to every MANET node? We could, for >>>> instance, designate the value fe80::FFFF as the distinguished >>>> useless link-local address designed _solely_ for the purpose >>>> of rigorous compliance with RFC 4861. Would this be >>>> satisfactory for the purposes you espouse in your draft? >>> >>> No, this would not be satisfactory. Link locals are not only >>> mandated by >>> RFC 4861 but also used by some protocols, so that's why we consider >>> important to configure them (so they can be used) in MANETs. >> >> We have to understand all the protocols using link-local address =20 >> expect >> the uniqueness of LL-address defined as RFC4861. >> >> If LL address cannot be guaranteed uniqueness as RFC4861, >> we cannot guarantee the correct behavior of other protocols. > > Sure, but IP is best-effort, so we also need to understand what do we > mean by "guarantee uniqueness"... Come on, IP is best-effort in terms of packet delivery. If the address uniqueness is not guaranteed, all the IP infrastructure =20= might be collapsed. > >> >> >>>> I also note that in your draft you advocate reliance on the >>>> typical (but not guaranteed) uniqueness of IEEE MAC addresses, >>> >>> It's true that it is not guaranteed, but the probability of >>> collision is >>> so low, that I'm not sure it's worth arguing about the necessity of >>> using DAD. >> >> see above. >> AFAIK, It's necessary to make sure the LL address uniqueness if we >> will use it. > > Sure, but ensuring address "uniqueness" (the level of guarantee that =20= > any > protocol running on IP can expect) does not necessarily mean running =20= > DAD > (or at least the DAD mechanism defined in IPv6 standards, we can =20 > work on > protocols in autoconf). The WG decision is not to work on this DAD solution for LL in AUTOCONF. We have decided to primary focus on non-LL address for its MANET =20 operations. Is that what we've dicussed since AUTOCONF was established, no? How many time do you repeat the same discussion? Let's move on. regards, ryuji > > Thanks, > > Carlos > >> >> regards, >> ryuji >> >>> >>>> and also turning off DAD or hacking the parameters. Did you >>>> try to calculate the overhead of, say, beaconing NA messages >>>> every 50 milliseconds, and the resulting too-frequent ND >>>> operations? Do you have any comments on the N^2 nature >>>> of this source of congestion? >>> >>> This could be certainly a scalability problem, but "hacking/ >>> configuring" >>> ND is just one proposed mechanism to tackle with fluctuating >>> reachability issues. There are other ways proposed in the draft >>> (such a >>> stronger interaction with the routing protocol) and surely there are >>> more. >>> >>> Even if globals are used instead, we would have a fluctuating >>> reachability issue, since the next IP hop used to reach a certain >>> destination might move out of radio coverage (you need to detect >>> this by >>> ND or the routing protocol). I think the same kind-of solutions that >>> be >>> used there can also be used when link-locals are used. Besides, we =20= >>> do >>> not mandate to use link-locals in the draft, we just think there are >>> use >>> cases where they are useful and therefore we should not prevent =20 >>> their >>> use in MANETs. >>> >>> Again, thanks for reading the draft. >>> >>> Regards, >>> >>> Carlos >>> >>>> >>>> Regards, >>>> Charlie P. >>>> >>>> >>>> Alexandru Petrescu wrote: >>>>> AUTOCONFers, >>>>> >>>>> I just noticed this draft just announced: >>>>> >>>>> Internet-Drafts@ietf.org a =C3=A9crit : >>>>>> A URL for this Internet-Draft is: >>>>>> = http://www.ietf.org/internet-drafts/draft-bernardos-autoconf-addressing-mo= del-00.txt >>>>>> >>>>> >>>>> This draft says, among others: >>>>> >>>>>> MANET interfaces MUST also be configured with IPv6 Link-local >>>>>> addresses (as required by RFC 4861 [RFC4861] and RFC 4291 >>>>>> [RFC4291]). >>>>>> Two main concerns may arise when considering the use of IPv6 >>>>>> Link- >>>>>> local addresses: >>>>>> >>>>>> o Address uniqueness: the event of having two duplicate >>>>>> addresses in >>>>>> the same link has proved to be very low (EUI64 derived >>>>>> interface >>>>>> identifiers very rarely collide, since MAC addresses are >>>>>> expected >>>>>> to be globally unique), and even some mechanisms have been >>>>>> proposed to reduce the collision probability >>>>>> [I-D.soto-mobileip-random-iids]. Therefore, in most >>>>>> scenarios it >>>>>> is safe to assume that the probability of having two or more >>>>>> duplicated link-local addresses in a MANET is negiglible. =20= >>>>>> For >>>>>> those scenarios, in which this cannot be safely assumed, we >>>>>> refer >>>>>> to the DAD considerations of Section 3.3. >>>>>> >>>>>> o Reachability: connectivity among neighbours in wireless >>>>>> links may >>>>>> be intermittent and/or short-lived. Therefore, the use of >>>>>> link- >>>>>> local addresses may lead to reachability issues, since two >>>>>> nodes >>>>>> that were in direct coverage range at one moment, might not =20= >>>>>> be >>>>>> anymore shortly after. These problems might also arise in >>>>>> wired >>>>>> networks (nodes going up/down), but it is not the common =20 >>>>>> case. >>>>>> >>>>>> Having brought to attention these concerns, it is further left >>>>>> to the >>>>>> designers of MANET routing protocols (and other protocols) to >>>>>> determine whether link-local addresses can be used in an >>>>>> effective >>>>>> way. >>>>> >>>>> I must say I fully agree with the above text, because it says >>>>> link-locals are "MUST". It is more positive towards link-=20 >>>>> locals, I >>>>> agree with it. >>>>> >>>>> I agree with it more than I agree with this text in >>>>> draft-ietf-autoconf-adhoc-addr-model-00.txt: >>>>>> Note that while link-local addresses are assumed to be "on >>>>>> link", the >>>>>> utility of link-local addresses is limited as described in >>>>>> Section 6. >>>>> >>>>> ... which has a negative co-notation in that use of the "limited" >>>>> word. >>>>> >>>>> So - please clarify this situation. >>>>> >>>>> Alex >>>>> >>>>>> >>>>> >>>>> >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>> Below is the data which will enable a MIME compliant mail reader >>>>>> implementation to automatically retrieve the ASCII version of the >>>>>> Internet-Draft. >>>>>> >>>>>> >>>>>> = ------------------------------------------------------------------------ >>>>>> >>>>>> _______________________________________________ >>>>>> I-D-Announce mailing list >>>>>> I-D-Announce@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>> >>>>> _______________________________________________ >>>>> Autoconf mailing list >>>>> Autoconf@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/autoconf >>>>> >>>>> >>>> >>> --=20 >>> Carlos Jes=C3=BAs Bernardos Cano http://www.netcoms.net >>> GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf >> > --=20 > Carlos Jes=C3=BAs Bernardos Cano http://www.netcoms.net > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 From ryuji.wakikawa@gmail.com Mon Oct 26 18:29: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 B00EC3A6778 for ; Mon, 26 Oct 2009 18:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] 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 G9IH9diSfItM for ; Mon, 26 Oct 2009 18:29:32 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 698263A66B4 for ; Mon, 26 Oct 2009 18:29:32 -0700 (PDT) Received: by ewy4 with SMTP id 4so4219996ewy.37 for ; Mon, 26 Oct 2009 18:29:43 -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=Bk5Ao84F2enSJb3s79dXeUDN/ebfzf9hqWVBsTpeRfY=; b=MItc+UAAEcDFI0KOMBnldZLum6RMyal6kFCR9pZKZLIBxCDPZfjSw3xF4saUf+y42w QC9znWKfAmihVRJ63kmYdswcRoxXbDbO+qtUnJHXLK2gWdIA5sWBws0ADQWP1ZFpWM+D DCMI8CsTKK5j+PwIYCSEWOTaNt/wdN2g/M9wk= 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=G5OBUcgbnw7aIpE5QuKBHXkOvbkkiLa+gqelVwagiGEvcglY1WpjtScMDramLtNKdF IenWci41HHlyEMIaDSF5MUKXLd5rU/7UJVd3DF1RGiSFUvV6Cwyj4uBshbAKSztRhY5E 3bgH7Jj28XqsaOhHqDweP1zfdJDdEZ9CClOBk= Received: by 10.216.90.81 with SMTP id d59mr891290wef.29.1256606983125; Mon, 26 Oct 2009 18:29:43 -0700 (PDT) Received: from macbookpro-ryuji.paloalto.toyota-itc.com ([206.132.173.18]) by mx.google.com with ESMTPS id i6sm2201506gve.17.2009.10.26.18.29.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 26 Oct 2009 18:29:42 -0700 (PDT) From: Ryuji Wakikawa To: cjbc@it.uc3m.es In-Reply-To: <1256491742.4766.35.camel@acorde.it.uc3m.es> References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 18:29:38 -0700 X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 27 Oct 2009 01:29:33 -0000 Hi Carlos, On 2009/10/25, at 10:29, Carlos Jes=C3=BAs Bernardos Cano wrote: > Hi Ryuji, > > On Sat, 2009-10-24 at 03:11 -0700, Ryuji Wakikawa wrote: >> Hi Carlos, >> >> On 2009/10/22, at 11:53, Carlos Jes=C3=BAs Bernardos Cano wrote: >> >>> Hi Charlie, >>>> >>>> Please explain the relationship between the following two =20 >>>> sentences: >>>> >>>>> "MANET interfaces MUST also be configured with >>>>> IPv6 Link-local addresses" >>>> >>>> and >>>>> "Besides, we do >>>>> not mandate to use link-locals in the draft, we just think there >>>>> are use >>>>> cases where they are useful and therefore we should not prevent >>>>> their >>>>> use in MANETs." >>> >>> The relationship is the following: LLs MUST be configured, but we >>> don't >>> mandate their use. It is a MUST, because there are IPv6 specs that =20= >>> say >>> so and because there are IPv6 protocols/applications that may want =20= >>> to >>> use them, but this does not imply that we force protocols/=20 >>> applications >>> to use them (it's up to the protocol/application designer to decide >>> whether to use them or not). >> >> The differences from the DT draft on this point are >> - mandating LL address >> - no warning to use it >> >> ? >> >> The DT document does not prohibit using LL address, but it clearly >> warn the possible problems (which are MANET specific). >> What is your problem of the texts in the DT document? >> You can still run existing protocols using the link-local with the >> same condition of your draft (i.e. no DAD). >> >> We should not let this DAD functionality as an optional. >> If we want to use LL, we have to provide uniqueness to LL and mandate >> DAD for it. >> This is because we shouldn't assume any L1/L2 technology in IP. > > I guess we have already addressed this in some other previous e-mails, > but just to avoid leaving e-mails without a reply, I'm providing my =20= > view > on this here. > > I think there is a difference between draft-bacceli and ours regarding > LL. You might say it is subtle, but I don't think so :-). One draft > says: LLs are not a MUST, but you are free to use them. The other =20 > says; > LLs are a MUST, but you are not forced to use them (this is exactly =20= > what > IPv6 specs say, in my understanding). > > DAD is not mandated for LL, but strongly encouraged. There is again =20= > a -- > maybe subtle, maybe not -- difference. This LL treatment had been discussed in AUTOCONF and were solved, right? People agreed what DT document said. I don't think we should re-visit the same issue so many times. regards, ryuji > > Thanks, > > Carlos > >> >> regards, >> ryuji >> >> >>> >>> Thanks, >>> >>> Carlos >>> >>>> >>>> Regards, >>>> Charlie P. >>>> >>> --=20 >>> Carlos Jes=C3=BAs Bernardos Cano http://www.netcoms.net >>> GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf >> > --=20 > Carlos Jes=C3=BAs Bernardos Cano http://www.netcoms.net > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 From henning.rogge@fkie.fraunhofer.de Mon Oct 26 23:33:04 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 868453A68FC for ; Mon, 26 Oct 2009 23:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.087 X-Spam-Level: X-Spam-Status: No, score=-6.087 tagged_above=-999 required=5 tests=[AWL=0.162, 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 WuQw4AzpWicb for ; Mon, 26 Oct 2009 23:33:03 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 096A828C0FA for ; Mon, 26 Oct 2009 23:33:02 -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 1N2fcJ-0002BN-0g; Tue, 27 Oct 2009 07:33:15 +0100 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 1N2fcI-0006k2-Lg; Tue, 27 Oct 2009 07:33:14 +0100 From: Henning Rogge To: autoconf@ietf.org Date: Tue, 27 Oct 2009 07:33:04 +0100 User-Agent: KMail/1.11.2 (Linux/2.6.30-10-generic; KDE/4.2.2; i686; ; ) References: <4AE6002C.3020704@gmail.com> <200910262127.51127.hrogge@googlemail.com> <4AE61010.9020406@gmail.com> In-Reply-To: <4AE61010.9020406@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart10744497.LHQxBfyutX"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910270733.09411.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/9945/Tue Oct 27 00:49:33 2009) by mailguard.fgan.de X-Scan-Signature: 16a282e4b1c134c294e7b6f7acb27d31 Subject: Re: [Autoconf] DAD problem in IPv6 mesh networks for LL (was: Which IPv6 addresses?) 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, 27 Oct 2009 06:33:04 -0000 --nextPart10744497.LHQxBfyutX Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Mon October 26 2009 22:09:36 schrieb Alexandru Petrescu: > Henning Rogge a =E9crit : > > LL assume that your broadcast domain is closed. > > Sorry, I do am open to talk, but what does it mean "broadcast domain > closed" for IPv6? Is it the link on which these IPv6 LLs are present? > IS it that that link is of definite size somehow? A closed broadcast domain is where you don't have a neighbor on a certain=20 interface which broadcast (on the interface it can hear you) can reach some= one=20 who does not hear your broadcast. It's the same as a transitive/symmetric '= A=20 can hear B's broadcast' condition. > > This way the IP stack can be > > sure that DAD will create a unique LL-IP for the interface. > > Yes, considering everybody on the link will hear the unsolicited NAs > (part of the DAD procedure). > > And no, if you consider that that link does not hold anybody together at > some point, and that people come in and move out of the link when DAD is > running. > > So my node's LL's DAD starts, nobody replies NA to the three successive > unsolicited NSs, and my node believes its LL is unique. And sudenly > afterwards some other node comes in using my IPv6 LL. So we find both > using the same LL. > > Is this the problem you talk about? Should we describe this example > problem in detail (DAD, 3 unsolicited NAs, new member) such that draft's > reader understand what's meant by this? > > If yes, then this problem may be important, because a router trying to > deliver packets to my node will deliver them to somebody else too, or > only to somebody else. The problem is that is not enough for MANET interfaces. Imagine a chain of three nodes A,B,C. All communication ranges are symmetri= c,=20 B can hear A and C, but A cannot hear C (because of too much distance betwe= en=20 the nodes). Even with DAD A and C might choose the same linklocal IP address. If they d= o=20 so B is unable to address A and C in a unique way, because of the address=20 conflict. > > Unfortunately most mesh networks are not behaving this way. So the > > semantic of LL-generation with DAD is not working correctly. > > Ok - can we describe how it does not work correctly? In a MANET you need to make sure that LL IPs are unique in each possible=20 broadcast domain. In a MANET without movement you can do this by make sure= =20 that each LL IP is 2-hop unique. In a MANET with movement you must either=20 reconfigure your LL on the fly or use mesh-unique LL IPs. 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 --nextPart10744497.LHQxBfyutX 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) iEYEABECAAYFAkrmlCAACgkQRIfGfFXsz+CnWACdGEkiAZaiMxKvXKrr/LqMtSY3 GY4AoIKuXQTx/ejYV2QnkAqelT0c/c56 =sDNE -----END PGP SIGNATURE----- --nextPart10744497.LHQxBfyutX-- From henning.rogge@fkie.fraunhofer.de Mon Oct 26 23:44:44 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 662313A67E5 for ; Mon, 26 Oct 2009 23:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.805 X-Spam-Level: X-Spam-Status: No, score=-5.805 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_32=0.6, 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 c0qk+fcv3iMl for ; Mon, 26 Oct 2009 23:44:43 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 50D6F3A67B1 for ; Mon, 26 Oct 2009 23:44:43 -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 1N2fnb-0004zv-N6; Tue, 27 Oct 2009 07:44:55 +0100 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 1N2fnb-0006m3-DK; Tue, 27 Oct 2009 07:44:55 +0100 From: Henning Rogge To: autoconf@ietf.org Date: Tue, 27 Oct 2009 07:44:45 +0100 User-Agent: KMail/1.11.2 (Linux/2.6.30-10-generic; KDE/4.2.2; i686; ; ) References: <125638 9726.5286.65.camel@acorde.it.uc3m.es> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> In-Reply-To: <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1285075.LdOB6U4mMQ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910270744.50317.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/9945/Tue Oct 27 00:49:33 2009) by mailguard.fgan.de X-Scan-Signature: 342e94ff8fe4d6b52457860454fe5b62 Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind 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, 27 Oct 2009 06:44:44 -0000 --nextPart1285075.LdOB6U4mMQ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Tue October 27 2009 02:20:10 schrieb Ryuji Wakikawa: > > Or if DupAddrDetectTransmits is set to zero, which I think it is not > > forbidden by RFC4862. > > This value can be set if the link-local address is guaranteed its > uniqueness without IPv6 DAD operations. > For example, RFC2472 > > As long as the Interface Identifier is negotiated in the IPV6CP phase > of the PPP connection setup, it is redundant to perform duplicate > address detection as a part of the IPv6 Stateless Autoconfiguration > protocol [3]. Therefore it is recommended that for PPP links with > the IPV6CP Interface-Identifier option enabled the default value of > the DupAddrDetectTransmits autoconfiguration variable [3] be zero. > > This value is not introduced to skip the uniqueness check for Link- > local. > The LL address MUST be always verified its uniqueness . > We cannot change this definition at AUTOCONF WG. > If you mandate the link-local in MANET addressing model, we need a DAD > mechanism to guarantee the uniqueness. > We've discussed that this DAD is difficult in some scenarios. We knew > there is a scenario where this DAD can be optimized. > Our addressing model should cover all the possible scenarios. That sounds like a good way to introduce a LL protocol for MANETs. If you h= ave=20 an unique MAC address, just use it to generate a unique LL. If not you need= a=20 protocol that ensures 2-hop unique LL IPs or mesh unique IPs for a moving=20 MANET. Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=C3=9Fe 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 --nextPart1285075.LdOB6U4mMQ 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) iEYEABECAAYFAkrmlt0ACgkQRIfGfFXsz+BYxACfa/WbbnBq65EDAsQUynEnmAly DL4AoI9HxLconCQGADaA/hKlyTXRvoj2 =jJtH -----END PGP SIGNATURE----- --nextPart1285075.LdOB6U4mMQ-- From teco@inf-net.nl Tue Oct 27 00:59: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 D28D23A6993 for ; Tue, 27 Oct 2009 00:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.148 X-Spam-Level: X-Spam-Status: No, score=-0.148 tagged_above=-999 required=5 tests=[AWL=-1.058, 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 tNkQIEOTsJlz for ; Tue, 27 Oct 2009 00:59:03 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id B99A83A6984 for ; Tue, 27 Oct 2009 00:59:02 -0700 (PDT) Received: (qmail 29434 invoked from network); 27 Oct 2009 08:59:13 +0100 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 27 Oct 2009 08:59:13 +0100 From: "Teco Boot" To: "'Ryuji Wakikawa'" 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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <4AE2D5AD.6090701@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <125638 9726.5286.65.camel@ac orde.it.uc3m.es> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> In-Reply-To: <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> Date: Tue, 27 Oct 2009 08:58:42 +0100 Message-ID: <01f901ca56db$5f4bf340$1de3d9c0$@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: AcpWo6RS+aNdqXOXS5CRoTh71kAzfwANmwyQ Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind 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, 27 Oct 2009 07:59:03 -0000 Ryuji wrote: >The LL address MUST be always verified its uniqueness . Total disagreement. RFC 4862 page 9: To accommodate sites that believe the overhead of performing Duplicate Address Detection outweighs its benefits, the use of Duplicate Address Detection can be disabled through the administrative setting of a per-interface configuration flag. >Our addressing model should cover all the possible scenarios. Total disagreement. Our charter says "practical addressing model". If we think IPv6 can boil the ocean, to begin with assigning a unique IPv6 address to each and every molecule, and we Autoconf punish ourselves to achieve this, I'm sure this WG is on a dead end. Regards, Teco From teco@inf-net.nl Tue Oct 27 01:05:21 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 634743A6984 for ; Tue, 27 Oct 2009 01:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.329 X-Spam-Level: X-Spam-Status: No, score=-0.329 tagged_above=-999 required=5 tests=[AWL=-0.684, BAYES_20=-0.74, 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 nx9uc9Tth4nN for ; Tue, 27 Oct 2009 01:05:20 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 38EBB3A691B for ; Tue, 27 Oct 2009 01:05:20 -0700 (PDT) Received: (qmail 3630 invoked from network); 27 Oct 2009 09:05:32 +0100 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 27 Oct 2009 09:05:32 +0100 From: "Teco Boot" To: "'Ryuji Wakikawa'" References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <0E0F03A1-EC0C-4FF9-AB17-DB2029F7363E@gmail.com> <1256492329.4766.39.camel@acorde.it.uc3m.es> In-Reply-To: Date: Tue, 27 Oct 2009 09:05:00 +0100 Message-ID: <01fa01ca56dc$40dd28b0$c2977a10$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpWpHWIgZX9yKJOTKuDL7bzDIfS5AANvlJw Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 27 Oct 2009 08:05:21 -0000 >Ryuji Wakikawa wrote: >If the address uniqueness is not guaranteed, all the IP infrastructure >might be collapsed. Yes, it might be. But it is reasonable to assume the larger part is not = affected at all. I'm almost sure duplicate L2 addresses have also a negative effect, and making sure IPv6 addresses are unique doesn't help much here. So the = gain on avoiding duplicates for these cases could be quite small. Of course, we all want to avoid duplicates. Regards, Teco From teco@inf-net.nl Tue Oct 27 01:10: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 D70C03A699F for ; Tue, 27 Oct 2009 01:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.457 X-Spam-Level: X-Spam-Status: No, score=-0.457 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_05=-1.11, 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 Lyw0HqyHQCLX for ; Tue, 27 Oct 2009 01:10:31 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id B21CA3A6878 for ; Tue, 27 Oct 2009 01:10:30 -0700 (PDT) Received: (qmail 8116 invoked from network); 27 Oct 2009 09:10:43 +0100 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 27 Oct 2009 09:10:43 +0100 From: "Teco Boot" To: "'Ryuji Wakikawa'" References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> In-Reply-To: Date: Tue, 27 Oct 2009 09:10:12 +0100 Message-ID: <01fb01ca56dc$fa550470$eeff0d50$@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: AcpWpQBpAPne9sQRSvOMPNq6RRny0AANzoOA Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 27 Oct 2009 08:10:32 -0000 >> DAD is not mandated for LL, but strongly encouraged. There is again >> a -- >> maybe subtle, maybe not -- difference. > >This LL treatment had been discussed in AUTOCONF and were solved, right? >People agreed what DT document said. >I don't think we should re-visit the same issue so many times. No, we did not agreed. I posted comments at early stages, I repeated a couple of times. I think the baccelli draft is still wrong. On details, but still. It seems that I am not the only one. Maybe there is a majority in the WG. If I missed a consensus, please provide a pointer in mail archive. Regards, Teco From ulrich@herberg.name Tue Oct 27 01:35: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 9627D3A68A5 for ; Tue, 27 Oct 2009 01:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 fyPYgdOVIRyx for ; Tue, 27 Oct 2009 01:35:18 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 4F6FA3A6838 for ; Tue, 27 Oct 2009 01:35:18 -0700 (PDT) Received: by fxm18 with SMTP id 18so12738458fxm.37 for ; Tue, 27 Oct 2009 01:35:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.175.80 with SMTP id w16mr2400979bkz.207.1256632528552; Tue, 27 Oct 2009 01:35:28 -0700 (PDT) In-Reply-To: <01f901ca56db$5f4bf340$1de3d9c0$@nl> References: <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <4AE2D5AD.6090701@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> Date: Tue, 27 Oct 2009 09:35:28 +0100 Message-ID: <25c114b90910270135i788a8a45oc0ac5cf87e2ae52@mail.gmail.com> From: Ulrich Herberg To: Teco Boot Content-Type: multipart/alternative; boundary=00032555b93a7a455e0476e68f91 Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind 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, 27 Oct 2009 08:35:19 -0000 --00032555b93a7a455e0476e68f91 Content-Type: text/plain; charset=ISO-8859-1 Teco, On Tue, Oct 27, 2009 at 8:58 AM, Teco Boot wrote: > Ryuji wrote: > > >The LL address MUST be always verified its uniqueness . > > Total disagreement. > RFC 4862 page 9: > To accommodate > sites that believe the overhead of performing Duplicate Address > Detection outweighs its benefits, the use of Duplicate Address > Detection can be disabled through the administrative setting of a > per-interface configuration flag. > Yes, however, this will not be the general case, because we want to accommodate all kind of radio interfaces in a MANET, not just IEEE interfaces with unique MAC addresses. So while you are right that in certain settings DAD can be disabled, that does not help us for mandating the use of LL in autoconf. > > > >Our addressing model should cover all the possible scenarios. > > Total disagreement. > Our charter says "practical addressing model". > > If we think IPv6 can boil the ocean, to begin with assigning a > unique IPv6 address to each and every molecule, and we Autoconf > punish ourselves to achieve this, I'm sure this WG is on a dead end. > I don't agree. We are not dealing with an extremely rare and unusual case, but simply the fact that we cannot assume uniqueness as per IEEE MAC address. So we need some kind of DAD. And with LLs, it is difficult to assure uniqueness over several hops, for all time. So their use is very limited. The DT address model is thus a practical model: It allows us to configure unambiguous addresses by using host prefixes and unique addresses MANET-wide. Mandating the use of LLs is not practical, because we will have a whole bunch of problems to solve, and so far I have not seen a single proposition of how to do that. Ulrich --00032555b93a7a455e0476e68f91 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Teco,

On Tue, Oct 27, 2009 at 8:58 AM, Te= co Boot <teco@inf-n= et.nl> wrote:
Ryuji wrote:

>The LL address MUST be always verified its uniqueness .

Total disagreement.
RFC 4862 page 9:
=A0 To accommodate
=A0 sites that believe the overhead of performing Duplicate Address
=A0 Detection outweighs its benefits, the use of Duplicate Address
=A0 Detection can be disabled through the administrative setting of a
=A0 per-interface configuration flag.

Yes, howeve= r, this will not be the general case, because we want to accommodate all ki= nd of radio interfaces in a MANET, not just IEEE interfaces with unique MAC= addresses. So while you are right that in certain settings DAD can be disa= bled, that does not help us for mandating the use of LL in autoconf.

=A0


>Our addressing model should cover all the possible scenarios.

Total disagreement.
Our charter says "practical addressing model".

If we think IPv6 can boil the ocean, to begin with assigning a
unique IPv6 address to each and every molecule, and we Autoconf
punish ourselves to achieve this, I'm sure this WG is on a dead end.

I don't agree. We are not dealing with an extrem= ely rare and unusual case, but simply the fact that we cannot assume unique= ness as per IEEE MAC address. So we need some kind of DAD. And with LLs, it= is difficult to assure uniqueness over several hops, for all time. So thei= r use is very limited. The DT address model is thus a practical model: It a= llows us to configure unambiguous addresses by using host prefixes and uniq= ue addresses MANET-wide. Mandating the use of LLs is not practical, because= we will have a whole bunch of problems to solve, and so far I have not see= n a single proposition of how to do that.

Ulrich
=A0
--00032555b93a7a455e0476e68f91-- From cjbc@it.uc3m.es Tue Oct 27 02:01: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 E43083A6929 for ; Tue, 27 Oct 2009 02:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.556 X-Spam-Level: X-Spam-Status: No, score=-5.556 tagged_above=-999 required=5 tests=[AWL=0.143, 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 olXQT2uE85FL for ; Tue, 27 Oct 2009 02:01:18 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id A6DB53A68D6 for ; Tue, 27 Oct 2009 02:01:17 -0700 (PDT) Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 2B7D16BA39D; Tue, 27 Oct 2009 10:01:30 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Teco Boot In-Reply-To: <01f901ca56db$5f4bf340$1de3d9c0$@nl> 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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <4AE2D5AD.6090701@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <125638 9726.5286.65.camel@ac orde.it.uc3m.es> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-s/yNHXJoqilNS7PBboM9" Organization: Universidad Carlos III de Madrid Date: Tue, 27 Oct 2009 10:01:31 +0100 Message-Id: <1256634091.5090.4.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16972.003 Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind 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, 27 Oct 2009 09:01:19 -0000 --=-s/yNHXJoqilNS7PBboM9 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Agree with Teco, Carlos On Tue, 2009-10-27 at 08:58 +0100, Teco Boot wrote: > Ryuji wrote: >=20 > >The LL address MUST be always verified its uniqueness . >=20 > Total disagreement. > RFC 4862 page 9: > To accommodate > sites that believe the overhead of performing Duplicate Address > Detection outweighs its benefits, the use of Duplicate Address > Detection can be disabled through the administrative setting of a > per-interface configuration flag. >=20 >=20 > >Our addressing model should cover all the possible scenarios. >=20 > Total disagreement. > Our charter says "practical addressing model". >=20 > If we think IPv6 can boil the ocean, to begin with assigning a=20 > unique IPv6 address to each and every molecule, and we Autoconf > punish ourselves to achieve this, I'm sure this WG is on a dead end. >=20 >=20 > Regards, Teco >=20 >=20 >=20 > _______________________________________________ > 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 --=-s/yNHXJoqilNS7PBboM9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkrmtusACgkQNdy6TdFwT2eUhgCg0dhg4KyShlI8LGMiKxFiUY77 aToAn2rfEcPwCbF7OHs6BRXnOh8wKeMq =Gv0d -----END PGP SIGNATURE----- --=-s/yNHXJoqilNS7PBboM9-- From alexandru.petrescu@gmail.com Tue Oct 27 02:47: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 B4B153A68A0 for ; Tue, 27 Oct 2009 02:47:25 -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.235, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_21=0.6] 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 dS0dK6B8H3zt for ; Tue, 27 Oct 2009 02:47:24 -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 0303E3A6814 for ; Tue, 27 Oct 2009 02:47:23 -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 n9R9lZK0013315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 10:47:35 +0100 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 n9R9lZK1003820; Tue, 27 Oct 2009 10:47:35 +0100 (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 n9R9lYk5000645; Tue, 27 Oct 2009 10:47:35 +0100 Message-ID: <4AE6C1B7.8010400@gmail.com> Date: Tue, 27 Oct 2009 10:47:35 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ryuji Wakikawa References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <0E0F03A1-EC0C-4FF9-AB17-DB2029F7363E@gmail.com> <1256492329.4766.39.camel@acorde.it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 27 Oct 2009 09:47:25 -0000 Ryuji Wakikawa a écrit : > Hi > On 2009/10/25, at 10:38, Carlos Jesús Bernardos Cano wrote: > >> Hi Ryuji, >> >> On Sat, 2009-10-24 at 03:00 -0700, Ryuji Wakikawa wrote: >>> Hi Carlos, >>> >>> On 2009/10/21, at 17:10, Carlos Jesús Bernardos Cano wrote: >>> >>>> Hi Charlie, >>>> >>>> On Wed, 2009-10-21 at 16:08 -0700, Charles E. Perkins wrote: >>>>> Hello Carlos and Ronald, >>>>> >>>>> Intrigued by Alex's email to the [autoconf] mailing list, I read >>>>> your draft, which suggests the mandate: >>>> >>>> Thanks for reading the draft. We are working on a -01 version (we >>>> submitted -00 to meet the deadline and we hope to make some changes >>>> before announcing it on the ML), but I'll provide my view on your >>>> questions. >>>> >>>>> "MANET interfaces MUST also be configured with >>>>> IPv6 Link-local addresses". >>>>> >>>>> But there is no indication in the draft about why that >>>>> mandate might result in anything useful. >>>>> >>>>> What if [autoconf] recommended assignment of a distinguished >>>>> link-local address to every MANET node? We could, for >>>>> instance, designate the value fe80::FFFF as the distinguished >>>>> useless link-local address designed _solely_ for the purpose >>>>> of rigorous compliance with RFC 4861. Would this be >>>>> satisfactory for the purposes you espouse in your draft? >>>> >>>> No, this would not be satisfactory. Link locals are not only >>>> mandated by >>>> RFC 4861 but also used by some protocols, so that's why we consider >>>> important to configure them (so they can be used) in MANETs. >>> >>> We have to understand all the protocols using link-local address expect >>> the uniqueness of LL-address defined as RFC4861. >>> >>> If LL address cannot be guaranteed uniqueness as RFC4861, >>> we cannot guarantee the correct behavior of other protocols. >> >> Sure, but IP is best-effort, so we also need to understand what do we >> mean by "guarantee uniqueness"... > > Come on, IP is best-effort in terms of packet delivery. > If the address uniqueness is not guaranteed, all the IP infrastructure > might be collapsed. I agree IP is best-effor mostly in terms of packet delivery. It is also true that the uniqueness ensuring mechanisms of IP are made to the best of one's capabilities - I don't think one can do any better. AUTOCONF can't do any better than DAD and DNA and DHCP and MAC did with respect to uniqueness. Especially since AUTOCONF is incapable of describing what's wrong with DAD, oDAD, DNA, DHCP and MAC. Be serious you too :-) Alex > >> >>> >>> >>>>> I also note that in your draft you advocate reliance on the >>>>> typical (but not guaranteed) uniqueness of IEEE MAC addresses, >>>> >>>> It's true that it is not guaranteed, but the probability of >>>> collision is >>>> so low, that I'm not sure it's worth arguing about the necessity of >>>> using DAD. >>> >>> see above. >>> AFAIK, It's necessary to make sure the LL address uniqueness if we >>> will use it. >> >> Sure, but ensuring address "uniqueness" (the level of guarantee that any >> protocol running on IP can expect) does not necessarily mean running DAD >> (or at least the DAD mechanism defined in IPv6 standards, we can work on >> protocols in autoconf). > > The WG decision is not to work on this DAD solution for LL in AUTOCONF. > We have decided to primary focus on non-LL address for its MANET > operations. > Is that what we've dicussed since AUTOCONF was established, no? > How many time do you repeat the same discussion? Let's move on. > > regards, > ryuji > > > > > >> >> Thanks, >> >> Carlos >> >>> >>> regards, >>> ryuji >>> >>>> >>>>> and also turning off DAD or hacking the parameters. Did you >>>>> try to calculate the overhead of, say, beaconing NA messages >>>>> every 50 milliseconds, and the resulting too-frequent ND >>>>> operations? Do you have any comments on the N^2 nature >>>>> of this source of congestion? >>>> >>>> This could be certainly a scalability problem, but "hacking/ >>>> configuring" >>>> ND is just one proposed mechanism to tackle with fluctuating >>>> reachability issues. There are other ways proposed in the draft >>>> (such a >>>> stronger interaction with the routing protocol) and surely there are >>>> more. >>>> >>>> Even if globals are used instead, we would have a fluctuating >>>> reachability issue, since the next IP hop used to reach a certain >>>> destination might move out of radio coverage (you need to detect >>>> this by >>>> ND or the routing protocol). I think the same kind-of solutions that >>>> be >>>> used there can also be used when link-locals are used. Besides, we do >>>> not mandate to use link-locals in the draft, we just think there are >>>> use >>>> cases where they are useful and therefore we should not prevent their >>>> use in MANETs. >>>> >>>> Again, thanks for reading the draft. >>>> >>>> Regards, >>>> >>>> Carlos >>>> >>>>> >>>>> Regards, >>>>> Charlie P. >>>>> >>>>> >>>>> Alexandru Petrescu wrote: >>>>>> AUTOCONFers, >>>>>> >>>>>> I just noticed this draft just announced: >>>>>> >>>>>> Internet-Drafts@ietf.org a écrit : >>>>>>> A URL for this Internet-Draft is: >>>>>>> http://www.ietf.org/internet-drafts/draft-bernardos-autoconf-addressing-model-00.txt >>>>>>> >>>>>>> >>>>>> >>>>>> This draft says, among others: >>>>>> >>>>>>> MANET interfaces MUST also be configured with IPv6 Link-local >>>>>>> addresses (as required by RFC 4861 [RFC4861] and RFC 4291 >>>>>>> [RFC4291]). >>>>>>> Two main concerns may arise when considering the use of IPv6 >>>>>>> Link- >>>>>>> local addresses: >>>>>>> >>>>>>> o Address uniqueness: the event of having two duplicate >>>>>>> addresses in >>>>>>> the same link has proved to be very low (EUI64 derived >>>>>>> interface >>>>>>> identifiers very rarely collide, since MAC addresses are >>>>>>> expected >>>>>>> to be globally unique), and even some mechanisms have been >>>>>>> proposed to reduce the collision probability >>>>>>> [I-D.soto-mobileip-random-iids]. Therefore, in most >>>>>>> scenarios it >>>>>>> is safe to assume that the probability of having two or more >>>>>>> duplicated link-local addresses in a MANET is negiglible. For >>>>>>> those scenarios, in which this cannot be safely assumed, we >>>>>>> refer >>>>>>> to the DAD considerations of Section 3.3. >>>>>>> >>>>>>> o Reachability: connectivity among neighbours in wireless >>>>>>> links may >>>>>>> be intermittent and/or short-lived. Therefore, the use of >>>>>>> link- >>>>>>> local addresses may lead to reachability issues, since two >>>>>>> nodes >>>>>>> that were in direct coverage range at one moment, might not be >>>>>>> anymore shortly after. These problems might also arise in >>>>>>> wired >>>>>>> networks (nodes going up/down), but it is not the common case. >>>>>>> >>>>>>> Having brought to attention these concerns, it is further left >>>>>>> to the >>>>>>> designers of MANET routing protocols (and other protocols) to >>>>>>> determine whether link-local addresses can be used in an >>>>>>> effective >>>>>>> way. >>>>>> >>>>>> I must say I fully agree with the above text, because it says >>>>>> link-locals are "MUST". It is more positive towards link-locals, I >>>>>> agree with it. >>>>>> >>>>>> I agree with it more than I agree with this text in >>>>>> draft-ietf-autoconf-adhoc-addr-model-00.txt: >>>>>>> Note that while link-local addresses are assumed to be "on >>>>>>> link", the >>>>>>> utility of link-local addresses is limited as described in >>>>>>> Section 6. >>>>>> >>>>>> ... which has a negative co-notation in that use of the "limited" >>>>>> word. >>>>>> >>>>>> So - please clarify this situation. >>>>>> >>>>>> Alex >>>>>> >>>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>> >>>>>>> Below is the data which will enable a MIME compliant mail reader >>>>>>> implementation to automatically retrieve the ASCII version of the >>>>>>> Internet-Draft. >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> I-D-Announce mailing list >>>>>>> I-D-Announce@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>> >>>>>> _______________________________________________ >>>>>> Autoconf mailing list >>>>>> Autoconf@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/autoconf >>>>>> >>>>>> >>>>> >>>> -- >>>> Carlos Jesús Bernardos Cano http://www.netcoms.net >>>> GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 >>>> _______________________________________________ >>>> Autoconf mailing list >>>> Autoconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/autoconf >>> >> -- >> Carlos Jesús Bernardos Cano http://www.netcoms.net >> GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From alexandru.petrescu@gmail.com Tue Oct 27 02:49: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 825EA28C1DE for ; Tue, 27 Oct 2009 02:49:14 -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.233, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_21=0.6] 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 Y4PZtsUiHA3H for ; Tue, 27 Oct 2009 02:49:13 -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 6679A28C1DD for ; Tue, 27 Oct 2009 02:49:13 -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 n9R9nOdl003094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 10:49:25 +0100 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 n9R9nOLC004421; Tue, 27 Oct 2009 10:49:24 +0100 (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 n9R9nOOJ001375; Tue, 27 Oct 2009 10:49:24 +0100 Message-ID: <4AE6C224.5080109@gmail.com> Date: Tue, 27 Oct 2009 10:49:24 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ryuji Wakikawa References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 27 Oct 2009 09:49:14 -0000 Ryuji Wakikawa a écrit : > Hi Carlos, > > On 2009/10/25, at 10:29, Carlos Jesús Bernardos Cano wrote: > >> Hi Ryuji, >> >> On Sat, 2009-10-24 at 03:11 -0700, Ryuji Wakikawa wrote: >>> Hi Carlos, >>> >>> On 2009/10/22, at 11:53, Carlos Jesús Bernardos Cano wrote: >>> >>>> Hi Charlie, >>>>> >>>>> Please explain the relationship between the following two sentences: >>>>> >>>>>> "MANET interfaces MUST also be configured with >>>>>> IPv6 Link-local addresses" >>>>> >>>>> and >>>>>> "Besides, we do >>>>>> not mandate to use link-locals in the draft, we just think there >>>>>> are use >>>>>> cases where they are useful and therefore we should not prevent >>>>>> their >>>>>> use in MANETs." >>>> >>>> The relationship is the following: LLs MUST be configured, but we >>>> don't >>>> mandate their use. It is a MUST, because there are IPv6 specs that say >>>> so and because there are IPv6 protocols/applications that may want to >>>> use them, but this does not imply that we force protocols/applications >>>> to use them (it's up to the protocol/application designer to decide >>>> whether to use them or not). >>> >>> The differences from the DT draft on this point are >>> - mandating LL address >>> - no warning to use it >>> >>> ? >>> >>> The DT document does not prohibit using LL address, but it clearly >>> warn the possible problems (which are MANET specific). >>> What is your problem of the texts in the DT document? >>> You can still run existing protocols using the link-local with the >>> same condition of your draft (i.e. no DAD). >>> >>> We should not let this DAD functionality as an optional. >>> If we want to use LL, we have to provide uniqueness to LL and mandate >>> DAD for it. >>> This is because we shouldn't assume any L1/L2 technology in IP. >> >> I guess we have already addressed this in some other previous e-mails, >> but just to avoid leaving e-mails without a reply, I'm providing my view >> on this here. >> >> I think there is a difference between draft-bacceli and ours regarding >> LL. You might say it is subtle, but I don't think so :-). One draft >> says: LLs are not a MUST, but you are free to use them. The other says; >> LLs are a MUST, but you are not forced to use them (this is exactly what >> IPv6 specs say, in my understanding). >> >> DAD is not mandated for LL, but strongly encouraged. There is again a -- >> maybe subtle, maybe not -- difference. > > This LL treatment had been discussed in AUTOCONF and were solved, right? > People agreed what DT document said. > I don't think we should re-visit the same issue so many times. Ryuji - I now fully disagree with the DT document. I disagree with _all_ of its recommendations. Alex > > regards, > ryuji > > > > > >> >> Thanks, >> >> Carlos >> >>> >>> regards, >>> ryuji >>> >>> >>>> >>>> Thanks, >>>> >>>> Carlos >>>> >>>>> >>>>> Regards, >>>>> Charlie P. >>>>> >>>> -- >>>> Carlos Jesús Bernardos Cano http://www.netcoms.net >>>> GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 >>>> _______________________________________________ >>>> Autoconf mailing list >>>> Autoconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/autoconf >>> >> -- >> Carlos Jesús Bernardos Cano http://www.netcoms.net >> GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From alexandru.petrescu@gmail.com Tue Oct 27 02:55: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 A2CE13A67D4 for ; Tue, 27 Oct 2009 02:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.070, 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 SctSK3bPw2iD for ; Tue, 27 Oct 2009 02:55:23 -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 7DFCA3A67BD for ; Tue, 27 Oct 2009 02:55:23 -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 n9R9tWdq018934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 10:55:32 +0100 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 n9R9tWmH006304; Tue, 27 Oct 2009 10:55:32 +0100 (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 n9R9tVoe007597; Tue, 27 Oct 2009 10:55:31 +0100 Message-ID: <4AE6C394.1040000@gmail.com> Date: Tue, 27 Oct 2009 10:55:32 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Henning Rogge References: <4AE6002C.3020704@gmail.com> <200910262127.51127.hrogge@googlemail.com> <4AE61010.9020406@gmail.com> <200910270733.09411.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <200910270733.09411.henning.rogge@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD problem in IPv6 mesh networks for LL 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, 27 Oct 2009 09:55:24 -0000 Henning Rogge a écrit : > Am Mon October 26 2009 22:09:36 schrieb Alexandru Petrescu: >> Henning Rogge a écrit : >>> LL assume that your broadcast domain is closed. >> Sorry, I do am open to talk, but what does it mean "broadcast domain >> closed" for IPv6? Is it the link on which these IPv6 LLs are present? >> IS it that that link is of definite size somehow? > > A closed broadcast domain is where you don't have a neighbor on a certain > interface which broadcast (on the interface it can hear you) can reach someone > who does not hear your broadcast. It's the same as a transitive/symmetric 'A > can hear B's broadcast' condition. I think it makes sense as I read it. However, it has no relationship whatsoever with any IEEE document, not even with the AUTOCONF document "manetarch" which describes the ABC problem too. That document doesn't use the term "closed broadcast domain". You seem to be very used to it. We may have a terminology problem here. People need same terminology in order to understand each other. >>> This way the IP stack can be >>> sure that DAD will create a unique LL-IP for the interface. >> Yes, considering everybody on the link will hear the unsolicited NAs >> (part of the DAD procedure). >> >> And no, if you consider that that link does not hold anybody together at >> some point, and that people come in and move out of the link when DAD is >> running. >> >> So my node's LL's DAD starts, nobody replies NA to the three successive >> unsolicited NSs, and my node believes its LL is unique. And sudenly >> afterwards some other node comes in using my IPv6 LL. So we find both >> using the same LL. >> >> Is this the problem you talk about? Should we describe this example >> problem in detail (DAD, 3 unsolicited NAs, new member) such that draft's >> reader understand what's meant by this? >> >> If yes, then this problem may be important, because a router trying to >> deliver packets to my node will deliver them to somebody else too, or >> only to somebody else. > The problem is that is not enough for MANET interfaces. > > Imagine a chain of three nodes A,B,C. All communication ranges are symmetric, > B can hear A and C, but A cannot hear C (because of too much distance between > the nodes). > > Even with DAD A and C might choose the same linklocal IP address. If they do > so B is unable to address A and C in a unique way, because of the address > conflict. Can you describe the DAD messages which generate that problem? With a flow chart? That would be a good candidate to a good problem statement. >>> Unfortunately most mesh networks are not behaving this way. So the >>> semantic of LL-generation with DAD is not working correctly. >> Ok - can we describe how it does not work correctly? > > In a MANET you need to make sure that LL IPs are unique in each possible > broadcast domain. In a MANET without movement you can do this by make sure > that each LL IP is 2-hop unique. In a MANET with movement you must either > reconfigure your LL on the fly or use mesh-unique LL IPs. Again, it is very difficult to talk "broadcast" when IPv6 talks all-node multicast, and when the manetarch document doesn't talk "broadcast domains" either. These things (broadcast, multicast, all-node, IPv4, IPv6) are very well understood in IEEE documents and in IETF documents. However, we have a hard time understanding each other if we don't use the same terminology. Alex > > Henning Rogge > From alexandru.petrescu@gmail.com Tue Oct 27 03:00: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 27A1C3A6784 for ; Tue, 27 Oct 2009 03:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.114 X-Spam-Level: * X-Spam-Status: No, score=1.114 tagged_above=-999 required=5 tests=[AWL=-3.225, BAYES_00=-2.599, FB_WORD1_END_DOLLAR=3.294, FB_WORD2_END_DOLLAR=3.294, 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 qzJiudrrmRL1 for ; Tue, 27 Oct 2009 03:00:11 -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 067DB3A677C for ; Tue, 27 Oct 2009 03:00:10 -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 n9RA0Ljo021763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 11:00:21 +0100 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 n9RA0LZm007800; Tue, 27 Oct 2009 11:00:21 +0100 (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 n9RA0LZu009579; Tue, 27 Oct 2009 11:00:21 +0100 Message-ID: <4AE6C4B5.1050309@gmail.com> Date: Tue, 27 Oct 2009 11:00:21 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ulrich Herberg References: <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <4AE2D5AD.6090701@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <25c114b90910270135i788a8a45oc0ac5cf87e2ae52@mail.gmail.com> In-Reply-To: <25c114b90910270135i788a8a45oc0ac5cf87e2ae52@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind 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, 27 Oct 2009 10:00:12 -0000 Ulrich Herberg a écrit : > Teco, > > On Tue, Oct 27, 2009 at 8:58 AM, Teco Boot > wrote: > > Ryuji wrote: > > >The LL address MUST be always verified its uniqueness . > > Total disagreement. > RFC 4862 page 9: > To accommodate > sites that believe the overhead of performing Duplicate Address > Detection outweighs its benefits, the use of Duplicate Address > Detection can be disabled through the administrative setting of a > per-interface configuration flag. > > > Yes, however, this will not be the general case, because we want to > accommodate all kind of radio interfaces in a MANET, Ulrich (and Stan too, 100k$ machines) - please state the names and specifications of the kinds of radio interfaces other than IEEE you plan to use. IEEE already covers a wide range of radios, WLAN, WPAN, WMAN. They even cover "mesh" and "ad-hoc" stuff. I am saying this after having seen same duplicate effort IEEE/IETF on FMIP and FastBSS. Please say how your links act. Until you don't say so - it's all a dark area. Alex not just IEEE > interfaces with unique MAC addresses. So while you are right that in > certain settings DAD can be disabled, that does not help us for > mandating the use of LL in autoconf. > > > > > > >Our addressing model should cover all the possible scenarios. > > Total disagreement. > Our charter says "practical addressing model". > > If we think IPv6 can boil the ocean, to begin with assigning a > unique IPv6 address to each and every molecule, and we Autoconf > punish ourselves to achieve this, I'm sure this WG is on a dead end. > > > I don't agree. We are not dealing with an extremely rare and unusual > case, but simply the fact that we cannot assume uniqueness as per IEEE > MAC address. So we need some kind of DAD. And with LLs, it is difficult > to assure uniqueness over several hops, for all time. So their use is > very limited. The DT address model is thus a practical model: It allows > us to configure unambiguous addresses by using host prefixes and unique > addresses MANET-wide. Mandating the use of LLs is not practical, because > we will have a whole bunch of problems to solve, and so far I have not > seen a single proposition of how to do that. > > Ulrich > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From alexandru.petrescu@gmail.com Tue Oct 27 03:00:27 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 4516C28C102 for ; Tue, 27 Oct 2009 03:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=0.105, 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 QFbbP9mVPDsp for ; Tue, 27 Oct 2009 03:00:26 -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 3D42028C0E4 for ; Tue, 27 Oct 2009 03:00:26 -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 n9RA0dZQ021971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 11:00:39 +0100 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 n9RA0dqc007913; Tue, 27 Oct 2009 11:00:39 +0100 (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 n9RA0cBe009711; Tue, 27 Oct 2009 11:00:38 +0100 Message-ID: <4AE6C4C7.5000803@gmail.com> Date: Tue, 27 Oct 2009 11:00:39 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <4AE2D5AD.6090701@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <125638 9726.5286.65.camel@ac orde.it.uc3m.es> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <1256634091.5090.4.camel@acorde.it.uc3m.es> In-Reply-To: <1256634091.5090.4.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind 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, 27 Oct 2009 10:00:27 -0000 I agree with Carlos. Alex Carlos Jesús Bernardos Cano a écrit : > Agree with Teco, > > Carlos > > On Tue, 2009-10-27 at 08:58 +0100, Teco Boot wrote: >> Ryuji wrote: >> >>> The LL address MUST be always verified its uniqueness . >> Total disagreement. >> RFC 4862 page 9: >> To accommodate >> sites that believe the overhead of performing Duplicate Address >> Detection outweighs its benefits, the use of Duplicate Address >> Detection can be disabled through the administrative setting of a >> per-interface configuration flag. >> >> >>> Our addressing model should cover all the possible scenarios. >> Total disagreement. >> Our charter says "practical addressing model". >> >> If we think IPv6 can boil the ocean, to begin with assigning a >> unique IPv6 address to each and every molecule, and we Autoconf >> punish ourselves to achieve this, I'm sure this WG is on a dead end. >> >> >> Regards, Teco >> >> >> >> _______________________________________________ >> 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 ulrich@herberg.name Tue Oct 27 03:03: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 414A93A67FA for ; Tue, 27 Oct 2009 03:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[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 idcgRwVpw0sZ for ; Tue, 27 Oct 2009 03:03:02 -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 5B3273A677C for ; Tue, 27 Oct 2009 03:03:02 -0700 (PDT) Received: by bwz19 with SMTP id 19so2864888bwz.28 for ; Tue, 27 Oct 2009 03:03:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.24.15 with SMTP id t15mr7191988bkb.113.1256637791468; Tue, 27 Oct 2009 03:03:11 -0700 (PDT) In-Reply-To: <4AE6C224.5080109@gmail.com> References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <4AE6C224.5080109@gmail.com> Date: Tue, 27 Oct 2009 11:03:11 +0100 Message-ID: <25c114b90910270303v1c928b77y7ae88895c1e8778f@mail.gmail.com> From: Ulrich Herberg To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=00032555bc9a2bff0f0476e7c93e Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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, 27 Oct 2009 10:03:03 -0000 --00032555bc9a2bff0f0476e7c93e Content-Type: text/plain; charset=ISO-8859-1 Alex, On Tue, Oct 27, 2009 at 10:49 AM, Alexandru Petrescu > [...] > Ryuji - I now fully disagree with the DT document. > > I disagree with _all_ of its recommendations. Now, that's a very helpful statement for the discussion. Could you be a bit more precise? Ulrich --00032555bc9a2bff0f0476e7c93e Content-Type: text/html; charset=ISO-8859-1 Alex,

On Tue, Oct 27, 2009 at 10:49 AM, Alexandru Petrescu
[...]
Ryuji - I now fully disagree with the DT document.

I disagree with _all_ of its recommendations.

<irony>Now, that's a very helpful statement for the discussion.</irony>

Could you be a bit more precise?

Ulrich
--00032555bc9a2bff0f0476e7c93e-- From alexandru.petrescu@gmail.com Tue Oct 27 03:12: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 650FD3A68E8 for ; Tue, 27 Oct 2009 03:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.145 X-Spam-Level: X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[AWL=0.104, 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 RNHC-nvkC+o5 for ; Tue, 27 Oct 2009 03:12: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 29D913A681D for ; Tue, 27 Oct 2009 03:12:43 -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 n9RACqSt032629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 11:12:53 +0100 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 n9RACqtT012283; Tue, 27 Oct 2009 11:12:52 +0100 (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 n9RACq09011826; Tue, 27 Oct 2009 11:12:52 +0100 Message-ID: <4AE6C7A4.8080506@gmail.com> Date: Tue, 27 Oct 2009 11:12:52 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ulrich Herberg References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <4AE6C224.5080109@gmail.com> <25c114b90910270303v1c928b77y7ae88895c1e8778f@mail.gmail.com> In-Reply-To: <25c114b90910270303v1c928b77y7ae88895c1e8778f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] disagreement on the DT document 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, 27 Oct 2009 10:12:45 -0000 Ulrich, From a procedural standpoint, two things: The DT draft has very little inherent validity as a WG item - it was forced on the WG without asking the WG. Additionally, it does not do some things that the Charter asks it to do: it doesn't describe how the addressing model impacts or not the non-MANET nodes connecting to MANET nodes. For technical details about what I don't agree in the DT draft: Ulrich Herberg a écrit : > Alex, > > On Tue, Oct 27, 2009 at 10:49 AM, Alexandru Petrescu > > [...] > Ryuji - I now fully disagree with the DT document. > > I disagree with _all_ of its recommendations. > > > Now, that's a very helpful statement for the discussion. > > Could you be a bit more precise? Seriously, here are the draft statements I disagree with: In the section 4 IP Subnet Prefix COnfiguration: [...] > o no two such interfaces in the network should be configured with > the same subnet prefix. [...] This ignores the presence of LL prefix fe80::/10. In section 6.1 IPv4 model: > Note that the use of IPv4 link-local addresses [RFC3927] in this > context should be discouraged for most applications, This ignores the existence and widespread use of applications using IPv4 LLs behind NAT. In section 6.2 IPv6 Model: > o A subnet prefix configured on this interface should be of length > /128. This is completely out of scope, because /128 prefixes make no sense in terms of subnet and multicast. > Therefore MANET autoconfiguration solutions should be encouraged to > primarily focus on configuring IP addresses that are not IPv6 link- > local. This says what should not be done, but it does not say what should be done. After writing all this text, are you going to agree with me? Alex > > Ulrich From ulrich@herberg.name Tue Oct 27 03:24: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 598EC3A659C for ; Tue, 27 Oct 2009 03:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.318 X-Spam-Level: * X-Spam-Status: No, score=1.318 tagged_above=-999 required=5 tests=[AWL=-3.294, BAYES_00=-2.599, FB_WORD1_END_DOLLAR=3.294, FB_WORD2_END_DOLLAR=3.294, 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 I+sfKRJIMmEm for ; Tue, 27 Oct 2009 03:24:46 -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 BD9173A657C for ; Tue, 27 Oct 2009 03:24:20 -0700 (PDT) Received: by bwz19 with SMTP id 19so2879310bwz.28 for ; Tue, 27 Oct 2009 03:24:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.34.13 with SMTP id j13mr687017bkd.32.1256639070767; Tue, 27 Oct 2009 03:24:30 -0700 (PDT) In-Reply-To: <4AE6C4B5.1050309@gmail.com> References: <4AE2D5AD.6090701@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <25c114b90910270135i788a8a45oc0ac5cf87e2ae52@mail.gmail.com> <4AE6C4B5.1050309@gmail.com> Date: Tue, 27 Oct 2009 11:24:30 +0100 Message-ID: <25c114b90910270324y3599756bhdebe9502f6026b93@mail.gmail.com> From: Ulrich Herberg To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=000325557abe6c8cdb0476e815bf Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind 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, 27 Oct 2009 10:24:47 -0000 --000325557abe6c8cdb0476e815bf Content-Type: text/plain; charset=ISO-8859-1 Alex, On Tue, Oct 27, 2009 at 11:00 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > [...] > Ulrich (and Stan too, 100k$ machines) - please state the names and > specifications of the kinds of radio interfaces other than IEEE you plan to > use. IEEE already covers a wide range of radios, WLAN, WPAN, WMAN. They > even cover "mesh" and "ad-hoc" stuff. I am saying this after having seen > same duplicate effort IEEE/IETF on FMIP and FastBSS. > > Please say how your links act. > > Until you don't say so - it's all a dark area. > > Alex > We are not a subgroup of IEEE, limiting our work to IEEE interfaces. Our work on IP layer and above should allow all kind of interface types. As Stan mentioned, he knows proprietary interfaces. I am not an expert for radio interface types, but a quick google search gave me this: http://en.wikipedia.org/wiki/Category:Packet_radio http://en.wikipedia.org/wiki/Communications,_Air-interface,_Long_and_Medium_range http://en.wikipedia.org/wiki/DSRC http://en.wikipedia.org/wiki/Long_Term_Evolution http://en.wikipedia.org/wiki/EVDO Not all of these links may be appropriate, but I think it shows that there are other interface types than just IEEE. Ulrich --000325557abe6c8cdb0476e815bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alex,

On Tue, Oct 27, 2009 at 11:00 AM, A= lexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
[...]
Ulrich (and Stan too, 100k$ machines) - please state the names and specific= ations of the kinds of radio interfaces other than IEEE you plan to use. = =A0IEEE already covers a wide range of radios, WLAN, WPAN, WMAN. They even = cover "mesh" and "ad-hoc" stuff. =A0I am saying this af= ter having seen same duplicate effort IEEE/IETF on FMIP and FastBSS.

Please say how your links act.

Until you don't say so - it's all a dark area.

Alex

We are not a subgroup of IEEE, limiting our w= ork to IEEE interfaces. Our work on IP layer and above should allow all kin= d of interface types. As Stan mentioned, he knows proprietary interfaces. I= am not an expert for radio interface types, but a quick google search gave= me this:

http://e= n.wikipedia.org/wiki/Category:Packet_radio
http:/= /en.wikipedia.org/wiki/Communications,_Air-interface,_Long_and_Medium_range=
http://en.wikipedia.org/wiki/= DSRC
ht= tp://en.wikipedia.org/wiki/Long_Term_Evolution
http://en.wikipedia.org/wiki/EVDO

Not all of these links may be appropriate, but I think it shows that th= ere are other interface types than just IEEE.

Ulrich
--000325557abe6c8cdb0476e815bf-- From alexandru.petrescu@gmail.com Tue Oct 27 03:36: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 AB12E3A6A0D for ; Tue, 27 Oct 2009 03:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.148 X-Spam-Level: * X-Spam-Status: No, score=1.148 tagged_above=-999 required=5 tests=[AWL=-3.191, BAYES_00=-2.599, FB_WORD1_END_DOLLAR=3.294, FB_WORD2_END_DOLLAR=3.294, 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 THn7I6g7sOu2 for ; Tue, 27 Oct 2009 03:36: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 8009728C1C7 for ; Tue, 27 Oct 2009 03:36:57 -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 n9RAb9pq022518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 11:37:09 +0100 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 n9RAb9nX020611; Tue, 27 Oct 2009 11:37:09 +0100 (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 n9RAb9cH021982; Tue, 27 Oct 2009 11:37:09 +0100 Message-ID: <4AE6CD55.1040205@gmail.com> Date: Tue, 27 Oct 2009 11:37:09 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ulrich Herberg References: <4AE2D5AD.6090701@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <25c114b90910270135i788a8a45oc0ac5cf87e2ae52@mail.gmail.com> <4AE6C4B5.1050309@gmail.com> <25c114b90910270324y3599756bhdebe9502f6026b93@mail.gmail.com> In-Reply-To: <25c114b90910270324y3599756bhdebe9502f6026b93@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind 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, 27 Oct 2009 10:36:58 -0000 Ulrich Herberg a écrit : > Alex, > > On Tue, Oct 27, 2009 at 11:00 AM, Alexandru Petrescu > > > wrote: > > [...] Ulrich (and Stan too, 100k$ machines) - please state the names > and specifications of the kinds of radio interfaces other than IEEE > you plan to use. IEEE already covers a wide range of radios, WLAN, > WPAN, WMAN. They even cover "mesh" and "ad-hoc" stuff. I am saying > this after having seen same duplicate effort IEEE/IETF on FMIP and > FastBSS. > > Please say how your links act. > > Until you don't say so - it's all a dark area. > > Alex > > > We are not a subgroup of IEEE, limiting our work to IEEE interfaces. > Our work on IP layer and above should allow all kind of interface > types. As Stan mentioned, he knows proprietary interfaces. I am not > an expert for radio interface types, but a quick google search gave > me this: > > http://en.wikipedia.org/wiki/Category:Packet_radio > http://en.wikipedia.org/wiki/Communications,_Air-interface,_Long_and_Medium_range > http://en.wikipedia.org/wiki/DSRC > http://en.wikipedia.org/wiki/Long_Term_Evolution > http://en.wikipedia.org/wiki/EVDO > > Not all of these links may be appropriate, but I think it shows that > there are other interface types than just IEEE. Ulrich, please first, do not point me to wikipedia, I refuse to be pointed to wikipedia. I do use it often but I refuse to be pointed to it. It's like you tell me to go read thousands of pages that you haven't read either - why do you do so? That apart. Which link layer are _you_ particularly concerned with and whose behaviour you'd like to see accepted in AUTOCONF? How does this link layer behave with respect to IPv6? There may be a risk that you expect it to behave some way and it does otherwise. I am saying this after having experimented with several wireless link layers: wavelan, wifi, bluetooth, irda, umts, 3g+, gsm, SLIP 2400bps, 802.16MAC, USB - to name just a few. My goal was all the time to see how IPv6 runs on it. I can tell you that I was not deceived and each time there was a solution, always involving link-local addresses. What do you think? What is that link-layer which does not support IPv6 link-layer addresses? Is it an imaginary link layer? Alex > > Ulrich From alexandru.petrescu@gmail.com Tue Oct 27 03:38:53 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 4192D28C1A7 for ; Tue, 27 Oct 2009 03:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.829 X-Spam-Level: * X-Spam-Status: No, score=1.829 tagged_above=-999 required=5 tests=[AWL=-3.802, BAYES_00=-2.599, FB_WORD1_END_DOLLAR=3.294, FB_WORD2_END_DOLLAR=3.294, HELO_EQ_FR=0.35, MISSING_HEADERS=1.292] 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 5kH5MpYq-hot for ; Tue, 27 Oct 2009 03:38:52 -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 29E6228C1C7 for ; Tue, 27 Oct 2009 03:38:52 -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 n9RAd4Ko028249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 11:39:04 +0100 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 n9RAd3QE021182; Tue, 27 Oct 2009 11:39:03 +0100 (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 n9RAd3q2022694; Tue, 27 Oct 2009 11:39:03 +0100 Message-ID: <4AE6CDC8.70800@gmail.com> Date: Tue, 27 Oct 2009 11:39:04 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 References: <4AE2D5AD.6090701@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <25c114b90910270135i788a8a45oc0ac5cf87e2ae52@mail.gmail.com> <4AE6C4B5.1050309@gmail.com> <25c114b90910270324y3599756bhdebe9502f6026b93@mail.gmail.com> <4AE6CD55.1040205@gmail.com> In-Reply-To: <4AE6CD55.1040205@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind 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, 27 Oct 2009 10:38:53 -0000 Alexandru Petrescu a écrit : > Ulrich Herberg a écrit : >> Alex, >> >> On Tue, Oct 27, 2009 at 11:00 AM, Alexandru Petrescu >> > >> wrote: >> >> [...] Ulrich (and Stan too, 100k$ machines) - please state the names >> and specifications of the kinds of radio interfaces other than IEEE >> you plan to use. IEEE already covers a wide range of radios, WLAN, >> WPAN, WMAN. They even cover "mesh" and "ad-hoc" stuff. I am saying >> this after having seen same duplicate effort IEEE/IETF on FMIP and >> FastBSS. >> >> Please say how your links act. >> >> Until you don't say so - it's all a dark area. >> >> Alex >> >> >> We are not a subgroup of IEEE, limiting our work to IEEE interfaces. >> Our work on IP layer and above should allow all kind of interface >> types. As Stan mentioned, he knows proprietary interfaces. I am not >> an expert for radio interface types, but a quick google search gave >> me this: >> >> http://en.wikipedia.org/wiki/Category:Packet_radio >> http://en.wikipedia.org/wiki/Communications,_Air-interface,_Long_and_Medium_range >> >> http://en.wikipedia.org/wiki/DSRC >> http://en.wikipedia.org/wiki/Long_Term_Evolution >> http://en.wikipedia.org/wiki/EVDO >> >> Not all of these links may be appropriate, but I think it shows that >> there are other interface types than just IEEE. > > Ulrich, please first, do not point me to wikipedia, I refuse to be > pointed to wikipedia. I do use it often but I refuse to be pointed to it. > > It's like you tell me to go read thousands of pages that you haven't > read either - why do you do so? > > That apart. > > Which link layer are _you_ particularly concerned with and whose > behaviour you'd like to see accepted in AUTOCONF? How does this link > layer behave with respect to IPv6? > > There may be a risk that you expect it to behave some way and it does > otherwise. > > I am saying this after having experimented with several wireless link > layers: wavelan, wifi, bluetooth, irda, umts, 3g+, gsm, SLIP 2400bps, > 802.16MAC, USB - to name just a few. My goal was all the time to see > how IPv6 runs on it. I can tell you that I was not deceived and each > time there was a solution, always involving link-local addresses. > > What do you think? What is that link-layer which does not support IPv6 > link-layer addresses? Sorry, I meant ^ IPv6 link-local address of course. Alex > > Is it an imaginary link layer? > > Alex > >> >> Ulrich > > > From henning.rogge@fkie.fraunhofer.de Tue Oct 27 03:42:07 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 988C63A6A10 for ; Tue, 27 Oct 2009 03:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.089 X-Spam-Level: X-Spam-Status: No, score=-6.089 tagged_above=-999 required=5 tests=[AWL=0.160, 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 7aCzRSFUqJ4v for ; Tue, 27 Oct 2009 03:42:06 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 17E223A6A0E for ; Tue, 27 Oct 2009 03:42:06 -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 1N2jVK-0005T8-0l; Tue, 27 Oct 2009 11:42:18 +0100 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 1N2jVJ-0000DG-JQ; Tue, 27 Oct 2009 11:42:17 +0100 From: Henning Rogge To: Alexandru Petrescu Date: Tue, 27 Oct 2009 11:41:27 +0100 User-Agent: KMail/1.11.2 (Linux/2.6.30-10-generic; KDE/4.2.2; i686; ; ) References: <4AE6002C.3020704@gmail.com> <200910270733.09411.henning.rogge@fkie.fraunhofer.de> <4AE6C394.1040000@gmail.com> In-Reply-To: <4AE6C394.1040000@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4444535.XBPA1EzHTQ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910271142.12180.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/9945/Tue Oct 27 00:49:33 2009) by mailguard.fgan.de X-Scan-Signature: deed7c2e435cc94a15d698e07c10212e Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD problem in IPv6 mesh networks for LL 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, 27 Oct 2009 10:42:07 -0000 --nextPart4444535.XBPA1EzHTQ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Tue October 27 2009 10:55:32 schrieb Alexandru Petrescu: > > A closed broadcast domain is where you don't have a neighbor on a certa= in > > interface which broadcast (on the interface it can hear you) can reach > > someone who does not hear your broadcast. It's the same as a > > transitive/symmetric 'A can hear B's broadcast' condition. > > I think it makes sense as I read it. > > However, it has no relationship whatsoever with any IEEE document, not > even with the AUTOCONF document "manetarch" which describes the ABC > problem too. > > That document doesn't use the term "closed broadcast domain". You seem > to be very used to it. It's an easy way to describe the difference between an ethernet switch (clo= sed=20 broadcast domain) and a WLAN MANET (not closed). > We may have a terminology problem here. > > People need same terminology in order to understand each other. So do you recognize what I mean with "closed/not closed" broadcast ? > > The problem is that is not enough for MANET interfaces. > > > > Imagine a chain of three nodes A,B,C. All communication ranges are > > symmetric, B can hear A and C, but A cannot hear C (because of too much > > distance between the nodes). > > > > Even with DAD A and C might choose the same linklocal IP address. If th= ey > > do so B is unable to address A and C in a unique way, because of the > > address conflict. > > Can you describe the DAD messages which generate that problem? With a > flow chart? That would be a good candidate to a good problem statement. No... I don't know DAD in this detail. The only thing I was told about DAD= =20 that it checks only for conflicts at 1-hop (1 layer-2 link away) distance. And that is (see above) not enough for well behaving LL IPs. > Again, it is very difficult to talk "broadcast" when IPv6 talks all-node > multicast, and when the manetarch document doesn't talk "broadcast > domains" either. A broadcast can typically only reach your direct neighbors in the network. 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 --nextPart4444535.XBPA1EzHTQ 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) iEYEABECAAYFAkrmzlcACgkQRIfGfFXsz+BbswCfa8J0NdWKLONN3z+bPKJRq/Yc Wy4An1QXRyFDtzors9kQVtlLojRkyfi9 =p3Ff -----END PGP SIGNATURE----- --nextPart4444535.XBPA1EzHTQ-- From alexandru.petrescu@gmail.com Tue Oct 27 03:45: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 836243A68E9 for ; Tue, 27 Oct 2009 03:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.07 X-Spam-Level: X-Spam-Status: No, score=-2.07 tagged_above=-999 required=5 tests=[AWL=0.179, 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 ouNcfT9rf8Kq for ; Tue, 27 Oct 2009 03:45:22 -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 106833A6955 for ; Tue, 27 Oct 2009 03:45:21 -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 n9RAjYo4031706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 11:45:34 +0100 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 n9RAjXtB022858; Tue, 27 Oct 2009 11:45:34 +0100 (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 n9RAjXM9024908; Tue, 27 Oct 2009 11:45:33 +0100 Message-ID: <4AE6CF4E.7000000@gmail.com> Date: Tue, 27 Oct 2009 11:45:34 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <4AE6C224.5080109@gmail.com> <25c114b90910270303v1c928b77y7ae88895c1e8778f@mail.gmail.com> <4AE6C7A4.8080506@gmail.com> In-Reply-To: <4AE6C7A4.8080506@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] disagreement on the DT document 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, 27 Oct 2009 10:45:23 -0000 Moreover, I disagree with this part of the document: > routers which connect to links with undetermined connectivity > properties. These links simply don't exist. All links deployed have determined connectivity properties, suffices it to test them according to their spec. Were they undetermined nobody would use them - run away from them. Alex Alexandru Petrescu a écrit : > Ulrich, > > From a procedural standpoint, two things: > > The DT draft has very little inherent validity as a WG item - it was > forced on the WG without asking the WG. > > Additionally, it does not do some things that the Charter asks it to > do: it doesn't describe how the addressing model impacts or not the > non-MANET nodes connecting to MANET nodes. > > For technical details about what I don't agree in the DT draft: > > Ulrich Herberg a écrit : >> Alex, >> >> On Tue, Oct 27, 2009 at 10:49 AM, Alexandru Petrescu >> >> [...] Ryuji - I now fully disagree with the DT document. >> >> I disagree with _all_ of its recommendations. >> >> >> Now, that's a very helpful statement for the >> discussion. >> >> Could you be a bit more precise? > > Seriously, here are the draft statements I disagree with: > > In the section 4 IP Subnet Prefix COnfiguration: [...] >> o no two such interfaces in the network should be configured with >> the same subnet prefix. > [...] > > This ignores the presence of LL prefix fe80::/10. > > In section 6.1 IPv4 model: >> Note that the use of IPv4 link-local addresses [RFC3927] in this >> context should be discouraged for most applications, > > This ignores the existence and widespread use of applications using > IPv4 LLs behind NAT. > > In section 6.2 IPv6 Model: >> o A subnet prefix configured on this interface should be of length >> /128. > > This is completely out of scope, because /128 prefixes make no sense > in terms of subnet and multicast. > >> Therefore MANET autoconfiguration solutions should be encouraged to >> primarily focus on configuring IP addresses that are not IPv6 >> link- local. > > This says what should not be done, but it does not say what should be > done. > > After writing all this text, are you going to agree with me? > > Alex > > >> >> Ulrich > > > From ulrich@herberg.name Tue Oct 27 03:52: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 231BB3A6774 for ; Tue, 27 Oct 2009 03:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[AWL=0.329, 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 BwnyjQK1NCQY for ; Tue, 27 Oct 2009 03:52:07 -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 EB4773A6906 for ; Tue, 27 Oct 2009 03:52:06 -0700 (PDT) Received: by bwz19 with SMTP id 19so11678bwz.28 for ; Tue, 27 Oct 2009 03:52:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.24.15 with SMTP id t15mr7248202bkb.113.1256640736141; Tue, 27 Oct 2009 03:52:16 -0700 (PDT) In-Reply-To: <4AE6CD55.1040205@gmail.com> References: <001501ca549f$a9015310$fb03f930$@nl> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <25c114b90910270135i788a8a45oc0ac5cf87e2ae52@mail.gmail.com> <4AE6C4B5.1050309@gmail.com> <25c114b90910270324y3599756bhdebe9502f6026b93@mail.gmail.com> <4AE6CD55.1040205@gmail.com> Date: Tue, 27 Oct 2009 11:52:16 +0100 Message-ID: <25c114b90910270352r7be3999ena54848beb1cf9472@mail.gmail.com> From: Ulrich Herberg To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=00032555bc9ab020cd0476e8784b Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind 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, 27 Oct 2009 10:52:12 -0000 --00032555bc9ab020cd0476e8784b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alex, On Tue, Oct 27, 2009 at 11:37 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Ulrich Herberg a =E9crit : > >> [...] > > > Ulrich, please first, do not point me to wikipedia, I refuse to be > pointed to wikipedia. I do use it often but I refuse to be pointed to it= . > > It's like you tell me to go read thousands of pages that you haven't > read either - why do you do so? > Because you asked me to name some non-IEEE interfaces. That's what I did. I let it up to you to read the specifications, if you desire so. My purpose was only to tell you that we are not solely focusing on IEEE interfaces. So all assumptions that IEEE interfaces typically have (such as unique MAC addresses) do not necessarily hold for other interfaces. > That apart. > > Which link layer are _you_ particularly concerned with and whose > behaviour you'd like to see accepted in AUTOCONF? How does this link > layer behave with respect to IPv6? > I am not particularly concerned with _any_ link layer. We are working purel= y on layer 3 autoconfiguration. We should not work on IP-over-IEEE-only-interface configuration. > > There may be a risk that you expect it to behave some way and it does > otherwise. > I don't have any particular expectation towards the link layer. It's you wh= o assumes that MAC addresses are unique (as for IEEE interfaces). I don't. > > I am saying this after having experimented with several wireless link > layers: wavelan, wifi, bluetooth, irda, umts, 3g+, gsm, SLIP 2400bps, > 802.16MAC, USB - to name just a few. My goal was all the time to see how > IPv6 runs on it. I can tell you that I was not deceived and each time th= ere > was a solution, always involving link-local addresses. > That's great! But it worked for you because you were using interfaces with unique MAC addresses (or am I wrong here?). In that case, you also don't need DAD as defined in RFC4862. > > What do you think? What is that link-layer which does not support IPv6 > link-layer addresses? > [Sorry, I meant ^ IPv6 link-local address of course.] > > > Is it an imaginary link layer? > I don't understand the question. Ulrich --00032555bc9ab020cd0476e8784b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alex,

On Tue, Oct 27, 2009 at 11:37 AM, A= lexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
Ulrich Herberg a =E9crit :
[...]

Ulrich, please first, do not point me to wikipedia, I refuse to be
pointed to wikipedia. =A0I do use it often but I refuse to be pointed to it= .

It's like you tell me to go read thousands of pages that you haven'= t
read either - why do you do so?

Because you asked = me to name some non-IEEE interfaces. That's what I did. I let it up to = you to read the specifications, if you desire so.
My purpose was only to= tell you that we are not solely focusing on IEEE interfaces. So all assump= tions that IEEE interfaces typically have (such as unique MAC addresses) do= not necessarily hold for other interfaces.


That apart.

Which link layer are _you_ particularly concerned with and whose
behaviour you'd like to see accepted in AUTOCONF? =A0How does this link=
layer behave with respect to IPv6?

I am not partic= ularly concerned with _any_ link layer. We are working purely on layer 3 au= toconfiguration. We should not work on IP-over-IEEE-only-interface configur= ation.
=A0

There may be a risk that you expect it to behave some way and it does
otherwise.

I don't have any particular expecta= tion towards the link layer. It's you who assumes that MAC addresses ar= e unique (as for IEEE interfaces).=A0 I don't.

I am saying this after having experimented with several wireless link layer= s: wavelan, wifi, bluetooth, irda, umts, 3g+, gsm, SLIP 2400bps, 802.16MAC,= USB - to name just a few. =A0My goal was all the time to see how IPv6 runs= on it. =A0I can tell you that I was not deceived and each time there was a= solution, always involving link-local addresses.

That's great! But it worked for you because you w= ere using interfaces with unique MAC addresses (or am I wrong here?). In th= at case, you also don't need DAD as defined in RFC4862.
=A0

What do you think? =A0What is that link-layer which does not support IPv6 link-layer addresses?
[Sorry, I meant ^ IPv6 link-local address of cours= e.]


Is it an imaginary link layer?

I don't underst= and the question.


Ulrich

--00032555bc9ab020cd0476e8784b-- From alexandru.petrescu@gmail.com Tue Oct 27 04:03: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 1CB1C3A6942 for ; Tue, 27 Oct 2009 04:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.072 X-Spam-Level: X-Spam-Status: No, score=-2.072 tagged_above=-999 required=5 tests=[AWL=0.177, 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 ydL4JMOtK-Sk for ; Tue, 27 Oct 2009 04:03:12 -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 CE57A3A6925 for ; Tue, 27 Oct 2009 04:03:11 -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 n9RB3F4K009019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 12:03:15 +0100 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 n9RB3FhG027002; Tue, 27 Oct 2009 12:03:15 +0100 (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 n9RB3Efp030454; Tue, 27 Oct 2009 12:03:15 +0100 Message-ID: <4AE6D373.4080300@gmail.com> Date: Tue, 27 Oct 2009 12:03:15 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Henning Rogge References: <4AE6002C.3020704@gmail.com> <200910270733.09411.henning.rogge@fkie.fraunhofer.de> <4AE6C394.1040000@gmail.com> <200910271142.12180.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <200910271142.12180.henning.rogge@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD problem in IPv6 mesh networks for LL 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, 27 Oct 2009 11:03:13 -0000 Henning Rogge a écrit : > Am Tue October 27 2009 10:55:32 schrieb Alexandru Petrescu: >>> A closed broadcast domain is where you don't have a neighbor on a certain >>> interface which broadcast (on the interface it can hear you) can reach >>> someone who does not hear your broadcast. It's the same as a >>> transitive/symmetric 'A can hear B's broadcast' condition. >> I think it makes sense as I read it. >> >> However, it has no relationship whatsoever with any IEEE document, not >> even with the AUTOCONF document "manetarch" which describes the ABC >> problem too. >> >> That document doesn't use the term "closed broadcast domain". You seem >> to be very used to it. > > It's an easy way to describe the difference between an ethernet switch (closed > broadcast domain) and a WLAN MANET (not closed). Well an ethernet switch is not such a closed broadcast domain because I can add cables and other switches to it and run link-layer spanning-tree protocols (802.1q) on them and they are open. The same in WLAN. I can add WLAN repeaters. >> We may have a terminology problem here. >> >> People need same terminology in order to understand each other. > > So do you recognize what I mean with "closed/not closed" broadcast ? Seems as a new definition we may discuss to nail down and put in a terminology document. I do however have hard time talking "broadcast" in the context of IPv6. We could be talking "broadcast" in terms of a specific link-layer, which we should name. >>> The problem is that is not enough for MANET interfaces. >>> >>> Imagine a chain of three nodes A,B,C. All communication ranges are >>> symmetric, B can hear A and C, but A cannot hear C (because of too much >>> distance between the nodes). >>> >>> Even with DAD A and C might choose the same linklocal IP address. If they >>> do so B is unable to address A and C in a unique way, because of the >>> address conflict. >> Can you describe the DAD messages which generate that problem? With a >> flow chart? That would be a good candidate to a good problem statement. > > No... I don't know DAD in this detail. The only thing I was told about DAD > that it checks only for conflicts at 1-hop (1 layer-2 link away) distance. Well... yes, DAD acts on a single-hop subnet (it's within the link-local scope) - the HopLimit of the base header of the DAD packets are not decremented. And that is good, because link-local addresses are valid only on a link-local scope. If you want to invent a new two-hop scope? With two-hop-local addresses? And a new duplicate address detection procedure working on two-hop scopes? If so, I don't know what to say, but please don't discard LLs, they are fine on their scope. One should mention the problems of using two times LLs on a link-local scope, before engaging on two-hop scopes. And thus make me understand why the two-hop scope is necessary. For example - why a two-hop scope and why not a three-hop scope? > And that is (see above) not enough for well behaving LL IPs. Would using two times a single-hop LL fit your two-hop need? For example, a router with two interfaces, attached thus to two link-local "1-hop" scopes, using a LL on each of its interface. Would this be able to run a routing protocol? I believe so, OSPF does so. I am not sure why you need a two-hop scope and addresses valid on two-hop scopes. >> Again, it is very difficult to talk "broadcast" when IPv6 talks all-node >> multicast, and when the manetarch document doesn't talk "broadcast >> domains" either. > > A broadcast can typically only reach your direct neighbors in the network. Well, hmm, IPv6 doesn't use the term "broadcast" but "all-node multicast". There is even a finer grained distinction, like "all-hosts" or "all-routers" or "all-ntp servers". These have different scopes: node, interface, host, link, site, global, etc. The working on this relies on the good working of IP multicast such as MLD and of link-layer multicast (IEEE MAC reused on many IEEE protocols). So in this, I would avoid the use of the term "broadcast" when talking IPv6. IPv4, and old Ethernet MAC implementations, do use the term "broadcast". For example, there is an IPv4 "broadcast" address 255.255.255.255 (there's no such equivalent all-1s in IPv6) and an Ethernet "broadcast" address "ff:ff:ff:ff:ff:ff". This latter is not used by IPv6 under any form, but it uses "33:33::1" which is called a link-layer multicast address. That's why I suggest to not use the term "broadcast" when talking IPv6. If I were you I would dig for all the IPv6-over-foo RFCs to see whether they use the term "broadcast" or not. I believe there is even an effort to write a document listing all link layers on which IPv6 runs, and how. Also, when you say neighbors, I believe them to be discovered by ND, which you don't seem to. IT is good to get in sync about terminology. Alex > > Henning Rogge > From alexandru.petrescu@gmail.com Tue Oct 27 04:12:56 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 911B228C10C for ; Tue, 27 Oct 2009 04:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.175, 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 3cjTMVPMOXGX for ; Tue, 27 Oct 2009 04:12:55 -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 6DB7E3A681D for ; Tue, 27 Oct 2009 04:12:55 -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 n9RBD7an014269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 12:13:07 +0100 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 n9RBD6S4028990; Tue, 27 Oct 2009 12:13:07 +0100 (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 n9RBD6eW001177; Tue, 27 Oct 2009 12:13:06 +0100 Message-ID: <4AE6D5C3.8080501@gmail.com> Date: Tue, 27 Oct 2009 12:13:07 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ulrich Herberg References: <001501ca549f$a9015310$fb03f930$@nl> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <25c114b90910270135i788a8a45oc0ac5cf87e2ae52@mail.gmail.com> <4AE6C4B5.1050309@gmail.com> <25c114b90910270324y3599756bhdebe9502f6026b93@mail.gmail.com> <4AE6CD55.1040205@gmail.com> <25c114b90910270352r7be3999ena54848beb1cf9472@mail.gmail.com> In-Reply-To: <25c114b90910270352r7be3999ena54848beb1cf9472@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind 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, 27 Oct 2009 11:12:56 -0000 Ulrich Herberg a écrit : > Alex, > > On Tue, Oct 27, 2009 at 11:37 AM, Alexandru Petrescu > > wrote: > > Ulrich Herberg a écrit : > > [...] > > > Ulrich, please first, do not point me to wikipedia, I refuse to be > pointed to wikipedia. I do use it often but I refuse to be pointed > to it. > > It's like you tell me to go read thousands of pages that you haven't > read either - why do you do so? > > > Because you asked me to name some non-IEEE interfaces. That's what I > did. I let it up to you to read the specifications, if you desire so. > My purpose was only to tell you that we are not solely focusing on IEEE > interfaces. So all assumptions that IEEE interfaces typically have (such > as unique MAC addresses) do not necessarily hold for other interfaces. Well, let's agree. I agree not all MAC addresses are available everywhere. A typical case is USB which uses 48bit addresses called MAC but which are not approved by IEEE and thus may clash with MAC addresses of IEEE. My point is to ask you to mention the link layer which you want to use and with which you have experience and on which IPv6 LLs are not used. In the list you have sent me, about which one do you want me to tell you my opinions with respect to LLs? For example, LTE surely will use LLs. > That apart. > > Which link layer are _you_ particularly concerned with and whose > behaviour you'd like to see accepted in AUTOCONF? How does this link > layer behave with respect to IPv6? > > > I am not particularly concerned with _any_ link layer. We are working > purely on layer 3 autoconfiguration. We should not work on > IP-over-IEEE-only-interface configuration. Remark IEEE is not that small, it covers many. Please state the link layers you're concerned with otherwise it's all pure speculation. > There may be a risk that you expect it to behave some way and it does > otherwise. > > > I don't have any particular expectation towards the link layer. It's you > who assumes that MAC addresses are unique (as for IEEE interfaces). I > don't. I don't assume unique MACs IEEE everywhere. But when that is not the case I do know what I am talking about with respect to the link layers I have experience with. What is the non-MAC-IEEE link layer you have experience with and which forbids the LLs? > I am saying this after having experimented with several wireless > link layers: wavelan, wifi, bluetooth, irda, umts, 3g+, gsm, SLIP > 2400bps, 802.16MAC, USB - to name just a few. My goal was all the > time to see how IPv6 runs on it. I can tell you that I was not > deceived and each time there was a solution, always involving > link-local addresses. > > > That's great! But it worked for you because you were using interfaces > with unique MAC addresses (or am I wrong here?). YEs, wrong - SLIP doesn't use MAC addresses from IEEE, USB either, 3g+ and gsm either. > In that case, you also don't need DAD as defined in RFC4862. On a link, there are more means to ensure uniqueness than just DAD. For example PPP has a means to negotiate it. Also, the nature of some links (ptp mostly) make such that only two nodes are there and the linked formed has unique link-layer addresses (USB). Also, some non-IEEE SDOs do offer unique MACs within their scopes. Now, even if a non-IEEE MAC number clashes with a IEEE MAC number, it is often the case that is because the two nodes can't talk to each other at link-layer - heterogeneous link-layers. In these cases one can't make IP work at all - you can't invent a new IP which solves the incompatibilities of the link layers. One could not connect a bluetooth node to a wifi node, because the PHY frequencies are different. > What do you think? What is that link-layer which does not support IPv6 > link-layer addresses? > [Sorry, I meant ^ IPv6 link-local address of course.] > > > Is it an imaginary link layer? > > > I don't understand the question. I don't understand when you state you want to work on links with undetermined connectivity properties. There exist no such links. What do you want to do? Alex > > > Ulrich > From Chris.Dearlove@baesystems.com Tue Oct 27 04:15: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 880943A6927 for ; Tue, 27 Oct 2009 04:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.305 X-Spam-Level: X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[AWL=0.294, 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 eoF-EwZaFq5u for ; Tue, 27 Oct 2009 04:15:27 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 79D523A682E for ; Tue, 27 Oct 2009 04:15:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,632,1249254000"; d="scan'208";a="29564909" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 27 Oct 2009 11:15:41 +0000 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 n9RBFleH005028; Tue, 27 Oct 2009 11:15:47 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 11:15:40 +0000 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, 27 Oct 2009 11:15:39 -0000 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Adding list of LL protocols for-against (was: Protocols involving link-local addresses) thread-index: AcpWXFsqIeGocydBnkWltsDOtWsF+wAmeXyA References: <4AE5D02B.8070809@gmail.com> From: "Dearlove, Christopher (UK)" To: "sratliff" , "Alexandru Petrescu" , "Teco Boot" X-OriginalArrivalTime: 27 Oct 2009 11:15:40.0840 (UTC) FILETIME=[D163C280:01CA56F6] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Adding list of LL protocols for-against (was: Protocols involving link-local addresses) 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, 27 Oct 2009 11:15:28 -0000 > I think this discussion has become circular in nature, and is not > productive. Having just come back from a short break which exactly corresponded with this storm of 200+ messages, so I'm seeing it all at once (and have got this far, not finished yet) I can absolutely agree with this statement. I'm waiting to finish all of the postings before considering if I have anything useful to say, or if anything useful can be said. ******************************************************************** 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 Oct 27 05:28: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 04F883A698E for ; Tue, 27 Oct 2009 05:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.299, 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 L8DsYpHh5-TM for ; Tue, 27 Oct 2009 05:28:11 -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 223C43A6782 for ; Tue, 27 Oct 2009 05:28:10 -0700 (PDT) Received: by bwz19 with SMTP id 19so113624bwz.28 for ; Tue, 27 Oct 2009 05:28:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.152.154 with SMTP id g26mr1545755bkw.54.1256646502259; Tue, 27 Oct 2009 05:28:22 -0700 (PDT) In-Reply-To: <4AE6D5C3.8080501@gmail.com> References: <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <25c114b90910270135i788a8a45oc0ac5cf87e2ae52@mail.gmail.com> <4AE6C4B5.1050309@gmail.com> <25c114b90910270324y3599756bhdebe9502f6026b93@mail.gmail.com> <4AE6CD55.1040205@gmail.com> <25c114b90910270352r7be3999ena54848beb1cf9472@mail.gmail.com> <4AE6D5C3.8080501@gmail.com> Date: Tue, 27 Oct 2009 13:28:22 +0100 Message-ID: <25c114b90910270528t238703afkdf34873a08539954@mail.gmail.com> From: Ulrich Herberg To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=0015175d09de601d300476e9d036 Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind 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, 27 Oct 2009 12:28:13 -0000 --0015175d09de601d300476e9d036 Content-Type: text/plain; charset=ISO-8859-1 Hi Alex, On Tue, Oct 27, 2009 at 12:13 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > [...] > Well, let's agree. I agree not all MAC addresses are available everywhere. > A typical case is USB which uses 48bit addresses called MAC but which are > not approved by IEEE and thus may clash with MAC addresses of IEEE. > > My point is to ask you to mention the link layer which you want to use and > with which you have experience and on which IPv6 LLs are not used. > > In the list you have sent me, about which one do you want me to tell you my > opinions with respect to LLs? For example, LTE surely will use LLs. I will try to rephrase what I meant: The address model of the DT tries to be as general as possible, proposing an address model that does not break anything and that does not have any special assumptions about connectivity. This discussion about which link layer I prefer or use, does not lead to anything. We should not limit ourselves in the addressing model to a particular link layer. If there were only IEEE interfaces in the world, and if it was assured that in the next some 50+ years there will only be IEEE interfaces with unique MAC addresses, [autoconf] would have a much easier task. The DT draft does not assume this limitation (and neither does IPv6 Stateless Autoconfiguration, by the way...). > > That apart. >> >> Which link layer are _you_ particularly concerned with and whose >> behaviour you'd like to see accepted in AUTOCONF? How does this link >> layer behave with respect to IPv6? >> >> >> I am not particularly concerned with _any_ link layer. We are working >> purely on layer 3 autoconfiguration. We should not work on >> IP-over-IEEE-only-interface configuration. >> > > Remark IEEE is not that small, it covers many. > Yes, many. But not all. > > Please state the link layers you're concerned with otherwise it's all pure > speculation. I tried to explain that before: I am not concerned with any particular link layer. I am concerned with the IP layer. IP over any kind of radio interface. IEEE have certain nice properties, but there are other interface types out there that have fewer assumptions. I want to allow such interfaces to work within a MANET, too. I did not find a general rule for NIC producers that they must have unique MAC addresses. > > > [...] >> > > I don't assume unique MACs IEEE everywhere. But when that is not the case > I do know what I am talking about with respect to the link layers I have > experience with. > Good! But then you have some additional assumptions. For example, when you _know_ that all of the interface MACs in your testbed are unique, the DT draft does not prohibit you from using LLs. It just says that if you _don't_ have such specific assumptions, LLs are of limited use. And this is the more general case that applies to MANETs that you don't plan beforehand (such as your testbed at work). [Skipping the rest of the email.. maybe I'll come back to that later] Ulrich > > What is the non-MAC-IEEE link layer you have experience with and which > forbids the LLs? > > > I am saying this after having experimented with several wireless >> link layers: wavelan, wifi, bluetooth, irda, umts, 3g+, gsm, SLIP >> 2400bps, 802.16MAC, USB - to name just a few. My goal was all the >> time to see how IPv6 runs on it. I can tell you that I was not >> deceived and each time there was a solution, always involving >> link-local addresses. >> >> >> That's great! But it worked for you because you were using interfaces with >> unique MAC addresses (or am I wrong here?). >> > > YEs, wrong - SLIP doesn't use MAC addresses from IEEE, USB either, 3g+ and > gsm either. > > > In that case, you also don't need DAD as defined in RFC4862. >> > > On a link, there are more means to ensure uniqueness than just DAD. > > For example PPP has a means to negotiate it. > > Also, the nature of some links (ptp mostly) make such that only two nodes > are there and the linked formed has unique link-layer addresses (USB). > > Also, some non-IEEE SDOs do offer unique MACs within their scopes. > > Now, even if a non-IEEE MAC number clashes with a IEEE MAC number, it is > often the case that is because the two nodes can't talk to each other at > link-layer - heterogeneous link-layers. In these cases one can't make IP > work at all - you can't invent a new IP which solves the incompatibilities > of the link layers. > > One could not connect a bluetooth node to a wifi node, because the PHY > frequencies are different. > > > What do you think? What is that link-layer which does not support IPv6 >> link-layer addresses? >> [Sorry, I meant ^ IPv6 link-local address of course.] >> >> >> Is it an imaginary link layer? >> >> >> I don't understand the question. >> > > I don't understand when you state you want to work on links with > undetermined connectivity properties. There exist no such links. > > What do you want to do? > > Alex > > >> >> Ulrich >> >> > > --0015175d09de601d300476e9d036 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alex,


On Tue, Oct 27, 2009 at 12:1= 3 PM, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 2= 04, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> [...]
Well, let's agree. =A0I agree not all MAC addresses are available every= where. =A0A typical case is USB which uses 48bit addresses called MAC but w= hich are not approved by IEEE and thus may clash with MAC addresses of IEEE= .

My point is to ask you to mention the link layer which you want to use and = with which you have experience and on which IPv6 LLs are not used.

In the list you have sent me, about which one do you want me to tell you my= opinions with respect to LLs? =A0For example, LTE surely will use LLs.


I will try to rephrase what I meant: The address mode= l of the DT tries to be as general as possible, proposing an address model = that does not break anything and that does not have any special assumptions= about connectivity. This discussion about which link layer I prefer or use= , does not lead to anything. We should not limit ourselves in the addressin= g model to a particular link layer. If there were only IEEE interfaces in t= he world, and if it was assured that in the next some 50+ years there will = only be IEEE interfaces with unique MAC addresses, [autoconf] would have a = much easier task. The DT draft does not assume this limitation (and neither= does IPv6 Stateless Autoconfiguration, by the way...).

=A0

=A0 =A0That apart.

=A0 =A0Which link layer are _you_ particularly concerned with and whose =A0 =A0behaviour you'd like to see accepted in AUTOCONF? =A0How does t= his link
=A0 =A0layer behave with respect to IPv6?


I am not particularly concerned with _any_ link layer. We are working purel= y on layer 3 autoconfiguration. We should not work on IP-over-IEEE-only-int= erface configuration.

Remark IEEE is not that small, it covers many.

Yes, many. But not all.

=A0

Please state the link layers you're concerned with otherwise it's a= ll pure speculation.

I tried to explain that before: I= am not concerned with any particular link layer. I am concerned with the I= P layer. IP over any kind of radio interface. IEEE have certain nice proper= ties, but there are other interface types out there that have fewer assumpt= ions. I want to allow such interfaces to work within a MANET, too. I did no= t find a general rule for NIC producers that they must have unique MAC addr= esses.=A0


=A0
=


[...]

I don't assume unique MACs IEEE everywhere. =A0But when that is not the= case I do know what I am talking about with respect to the link layers I h= ave experience with.

Good! But then you have some = additional assumptions. For example, when you _know_ that all of the interf= ace MACs in your testbed are unique, the DT draft does not prohibit you fro= m using LLs. It just says that if you _don't_ have such specific assump= tions, LLs are of limited use. And this is the more general case that appli= es to MANETs that you don't plan beforehand (such as your testbed at wo= rk).


[Skipping the rest of the email.. maybe I'll come back to that = later]

Ulrich
=A0

What is the non-MAC-IEEE link layer you have experience with and which forb= ids the LLs?
=A0


=A0 =A0I am saying this after having experimented with several wireless =A0 =A0link layers: wavelan, wifi, bluetooth, irda, umts, 3g+, gsm, SLIP =A0 =A02400bps, 802.16MAC, USB - to name just a few. =A0My goal was all th= e
=A0 =A0time to see how IPv6 runs on it. =A0I can tell you that I was not =A0 =A0deceived and each time there was a solution, always involving
=A0 =A0link-local addresses.


That's great! But it worked for you because you were using interfaces w= ith unique MAC addresses (or am I wrong here?).

YEs, wrong - SLIP doesn't use MAC addresses from IEEE, USB either, 3g+ = and gsm either.


In that case, you also don't need DAD as defined in RFC4862.

On a link, there are more means to ensure uniqueness than just DAD.

For example PPP has a means to negotiate it.

Also, the nature of some links (ptp mostly) make such that only two nodes a= re there and the linked formed has unique link-layer addresses (USB).

Also, some non-IEEE SDOs do offer unique MACs within their scopes.

Now, even if a non-IEEE MAC number clashes with a IEEE MAC number, it is of= ten the case that is because the two nodes can't talk to each other at = link-layer - heterogeneous link-layers. =A0In these cases one can't mak= e IP work at all - you can't invent a new IP which solves the incompati= bilities of the link layers.

One could not connect a bluetooth node to a wifi node, because the PHY freq= uencies are different.


=A0 =A0What do you think? =A0What is that link-layer which does not suppor= t IPv6
=A0 =A0link-layer addresses?
=A0 =A0[Sorry, I meant ^ IPv6 link-local address of course.]


=A0 =A0Is it an imaginary link layer?


I don't understand the question.

I don't understand when you state you want to work on links with undete= rmined connectivity properties. =A0There exist no such links.

What do you want to do?

Alex



Ulrich




--0015175d09de601d300476e9d036-- From alexandru.petrescu@gmail.com Tue Oct 27 06:31:21 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 9006528C204 for ; Tue, 27 Oct 2009 06:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AWL=0.173, 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 kuzBjOF2cEj6 for ; Tue, 27 Oct 2009 06:31:20 -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 22BBA28C205 for ; Tue, 27 Oct 2009 06:31:19 -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 n9RDVVOm027223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 14:31:32 +0100 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 n9RDVTVF026764; Tue, 27 Oct 2009 14:31:30 +0100 (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 n9RDVREa009318; Tue, 27 Oct 2009 14:31:28 +0100 Message-ID: <4AE6F630.7000606@gmail.com> Date: Tue, 27 Oct 2009 14:31:28 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ulrich Herberg References: <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <25c114b90910270135i788a8a45oc0ac5cf87e2ae52@mail.gmail.com> <4AE6C4B5.1050309@gmail.com> <25c114b90910270324y3599756bhdebe9502f6026b93@mail.gmail.com> <4AE6CD55.1040205@gmail.com> <25c114b90910270352r7be3999ena54848beb1cf9472@mail.gmail.com> <4AE6D5C3.8080501@gmail.com> <25c114b90910270528t238703afkdf34873a08539954@mail.gmail.com> In-Reply-To: <25c114b90910270528t238703afkdf34873a08539954@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] IP over "anything" (was: DAD, link-locals, two drafts and making up my mind 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, 27 Oct 2009 13:31:21 -0000 Ulrich, There is a high risk to work on something that we don't what is. Blindly hiding behind "IP over anything" without saying what is, and ignoring the so many IP-over-foo RFC documents - are indicators for this. Also, there was a zeroconf WG, "to enable networking in the absence of configuration and administration". Doesn't that sound MANETish enough. Well it gave the IPv4 LLs RFC. Ffwd to 2009 - discourage LLs... Alex Ulrich Herberg a écrit : > Hi Alex, > > > On Tue, Oct 27, 2009 at 12:13 PM, Alexandru Petrescu > > wrote: > > [...] > Well, let's agree. I agree not all MAC addresses are available > everywhere. A typical case is USB which uses 48bit addresses called > MAC but which are not approved by IEEE and thus may clash with MAC > addresses of IEEE. > > My point is to ask you to mention the link layer which you want to > use and with which you have experience and on which IPv6 LLs are not > used. > > In the list you have sent me, about which one do you want me to tell > you my opinions with respect to LLs? For example, LTE surely will > use LLs. > > > > I will try to rephrase what I meant: The address model of the DT tries > to be as general as possible, proposing an address model that does not > break anything and that does not have any special assumptions about > connectivity. This discussion about which link layer I prefer or use, > does not lead to anything. We should not limit ourselves in the > addressing model to a particular link layer. If there were only IEEE > interfaces in the world, and if it was assured that in the next some 50+ > years there will only be IEEE interfaces with unique MAC addresses, > [autoconf] would have a much easier task. The DT draft does not assume > this limitation (and neither does IPv6 Stateless Autoconfiguration, by > the way...). > > > > > That apart. > > Which link layer are _you_ particularly concerned with and whose > behaviour you'd like to see accepted in AUTOCONF? How does > this link > layer behave with respect to IPv6? > > > I am not particularly concerned with _any_ link layer. We are > working purely on layer 3 autoconfiguration. We should not work > on IP-over-IEEE-only-interface configuration. > > > Remark IEEE is not that small, it covers many. > > > > Yes, many. But not all. > > > > > Please state the link layers you're concerned with otherwise it's > all pure speculation. > > > I tried to explain that before: I am not concerned with any particular > link layer. I am concerned with the IP layer. IP over any kind of radio > interface. IEEE have certain nice properties, but there are other > interface types out there that have fewer assumptions. I want to allow > such interfaces to work within a MANET, too. I did not find a general > rule for NIC producers that they must have unique MAC addresses. > > > > > > > [...] > > > I don't assume unique MACs IEEE everywhere. But when that is not > the case I do know what I am talking about with respect to the link > layers I have experience with. > > > Good! But then you have some additional assumptions. For example, when > you _know_ that all of the interface MACs in your testbed are unique, > the DT draft does not prohibit you from using LLs. It just says that if > you _don't_ have such specific assumptions, LLs are of limited use. And > this is the more general case that applies to MANETs that you don't plan > beforehand (such as your testbed at work). > > > [Skipping the rest of the email.. maybe I'll come back to that later] > > Ulrich > > > > What is the non-MAC-IEEE link layer you have experience with and > which forbids the LLs? > > > > > > I am saying this after having experimented with several wireless > link layers: wavelan, wifi, bluetooth, irda, umts, 3g+, gsm, SLIP > 2400bps, 802.16MAC, USB - to name just a few. My goal was > all the > time to see how IPv6 runs on it. I can tell you that I was not > deceived and each time there was a solution, always involving > link-local addresses. > > > That's great! But it worked for you because you were using > interfaces with unique MAC addresses (or am I wrong here?). > > > YEs, wrong - SLIP doesn't use MAC addresses from IEEE, USB either, > 3g+ and gsm either. > > > In that case, you also don't need DAD as defined in RFC4862. > > > On a link, there are more means to ensure uniqueness than just DAD. > > For example PPP has a means to negotiate it. > > Also, the nature of some links (ptp mostly) make such that only two > nodes are there and the linked formed has unique link-layer > addresses (USB). > > Also, some non-IEEE SDOs do offer unique MACs within their scopes. > > Now, even if a non-IEEE MAC number clashes with a IEEE MAC number, > it is often the case that is because the two nodes can't talk to > each other at link-layer - heterogeneous link-layers. In these > cases one can't make IP work at all - you can't invent a new IP > which solves the incompatibilities of the link layers. > > One could not connect a bluetooth node to a wifi node, because the > PHY frequencies are different. > > > What do you think? What is that link-layer which does not > support IPv6 > link-layer addresses? > [Sorry, I meant ^ IPv6 link-local address of course.] > > > Is it an imaginary link layer? > > > I don't understand the question. > > > I don't understand when you state you want to work on links with > undetermined connectivity properties. There exist no such links. > > What do you want to do? > > Alex > > > > Ulrich > > > > From sratliff@cisco.com Tue Oct 27 07:53: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 64A033A698A for ; Tue, 27 Oct 2009 07:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.267 X-Spam-Level: X-Spam-Status: No, score=-0.267 tagged_above=-999 required=5 tests=[AWL=-3.720, BAYES_00=-2.599, FB_WORD1_END_DOLLAR=3.294, FB_WORD2_END_DOLLAR=3.294, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 oTXUSNdoINSD for ; Tue, 27 Oct 2009 07:53:14 -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 70B173A6975 for ; Tue, 27 Oct 2009 07:53:14 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFALyl5kqrRN+J/2dsb2JhbACCJC+XP4EOpiKYP4Q/BA X-IronPort-AV: E=Sophos;i="4.44,633,1249257600"; d="scan'208,217";a="199081682" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-3.cisco.com with ESMTP; 27 Oct 2009 14:53:28 +0000 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 n9RErKxE029123; Tue, 27 Oct 2009 14:53:28 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 10:53:28 -0400 Received: from 64.102.54.119 ([64.102.54.119]) by xmb-rtp-208.amer.cisco.com ([64.102.31.43]) with Microsoft Exchange Server HTTP-DAV ; Tue, 27 Oct 2009 14:53:27 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 27 Oct 2009 10:53:27 -0400 From: sratliff To: Ulrich Herberg , Alexandru Petrescu Message-ID: Thread-Topic: [Autoconf] DAD, link-locals, two drafts and making up my mind Thread-Index: AcpXFT1tkLGZPxbCbUqQLxJCbz3BVw== In-Reply-To: <25c114b90910270324y3599756bhdebe9502f6026b93@mail.gmail.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3339485607_19415489" X-OriginalArrivalTime: 27 Oct 2009 14:53:28.0358 (UTC) FILETIME=[3E3CC460:01CA5715] Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind 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, 27 Oct 2009 14:53:17 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3339485607_19415489 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Alex,=20 I was told not to pay attention to this discussion, no? Ulrich is correct. The interfaces are proprietary. I=B9m not going to go into a discussion about them in this forum. Ulrich has supplied pointers to well-known interface types that don=B9t adhere to IEEE specs. Regards, Stan On 10/27/09 6:24 AM, "Ulrich Herberg" wrote: > Alex, >=20 > On Tue, Oct 27, 2009 at 11:00 AM, Alexandru Petrescu > wrote: >> [...] >> Ulrich (and Stan too, 100k$ machines) - please state the names and >> specifications of the kinds of radio interfaces other than IEEE you plan= to >> use. =A0IEEE already covers a wide range of radios, WLAN, WPAN, WMAN. They= even >> cover "mesh" and "ad-hoc" stuff. =A0I am saying this after having seen sam= e >> duplicate effort IEEE/IETF on FMIP and FastBSS. >>=20 >> Please say how your links act. >>=20 >> Until you don't say so - it's all a dark area. >>=20 >> Alex >=20 > We are not a subgroup of IEEE, limiting our work to IEEE interfaces. Our = work > on IP layer and above should allow all kind of interface types. As Stan > mentioned, he knows proprietary interfaces. I am not an expert for radio > interface types, but a quick google search gave me this: >=20 > http://en.wikipedia.org/wiki/Category:Packet_radio > http://en.wikipedia.org/wiki/Communications,_Air-interface,_Long_and_Medi= um_ra > nge > http://en.wikipedia.org/wiki/DSRC > http://en.wikipedia.org/wiki/Long_Term_Evolution > http://en.wikipedia.org/wiki/EVDO >=20 > Not all of these links may be appropriate, but I think it shows that ther= e are > other interface types than just IEEE. >=20 > Ulrich=20 >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf --B_3339485607_19415489 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Autoconf] DAD, link-locals, two drafts and making up my mind</T= ITLE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt= '>Alex, <BR> <BR> <sarcasm>I was told not to pay attention to this discussion, no?</= sarcasm><BR> <BR> Ulrich is correct. The interfaces are proprietary. I’m not going to g= o into a discussion about them in this forum. Ulrich has supplied pointers t= o well-known interface types that don’t adhere to IEEE specs. <BR> <BR> Regards,<BR> Stan<BR> <BR> <BR> On 10/27/09 6:24 AM, "Ulrich Herberg" <<a href=3D"ulrich@herberg= .name">ulrich@herberg.name</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><= SPAN STYLE=3D'font-size:11pt'>Alex,<BR> <BR> On Tue, Oct 27, 2009 at 11:00 AM, Alexandru Petrescu <<a href=3D"alexandru= .petrescu@gmail.com">alexandru.petrescu@gmail.com</a>> wrote:<BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><= SPAN STYLE=3D'font-size:11pt'>[...]<BR> Ulrich (and Stan too, 100k$ machines) - please state the names and specific= ations of the kinds of radio interfaces other than IEEE you plan to use. =A0IE= EE already covers a wide range of radios, WLAN, WPAN, WMAN. They even cover = "mesh" and "ad-hoc" stuff. =A0I am saying this after havin= g seen same duplicate effort IEEE/IETF on FMIP and FastBSS.<BR> <BR> Please say how your links act.<BR> <BR> Until you don't say so - it's all a dark area.<BR> <BR> Alex<BR> </SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">= <SPAN STYLE=3D'font-size:11pt'><BR> We are not a subgroup of IEEE, limiting our work to IEEE interfaces. Our wo= rk on IP layer and above should allow all kind of interface types. As Stan m= entioned, he knows proprietary interfaces. I am not an expert for radio inte= rface types, but a quick google search gave me this:<BR> <BR> <a href=3D"http://en.wikipedia.org/wiki/Category:Packet_radio">http://en.wiki= pedia.org/wiki/Category:Packet_radio</a><BR> <a href=3D"http://en.wikipedia.org/wiki/Communications,_Air-interface,_Long_a= nd_Medium_range">http://en.wikipedia.org/wiki/Communications,_Air-interface,= _Long_and_Medium_range</a><BR> <a href=3D"http://en.wikipedia.org/wiki/DSRC">http://en.wikipedia.org/wiki/DS= RC</a><BR> <a href=3D"http://en.wikipedia.org/wiki/Long_Term_Evolution">http://en.wikipe= dia.org/wiki/Long_Term_Evolution</a><BR> <a href=3D"http://en.wikipedia.org/wiki/EVDO">http://en.wikipedia.org/wiki/EV= DO</a><BR> <BR> Not all of these links may be appropriate, but I think it shows that there = are other interface types than just IEEE. <BR> <BR> Ulrich <BR> <BR> <HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"></SPAN></FONT><FONT SIZE=3D"2"><FONT FA= CE=3D"Consolas, Courier New, Courier"><SPAN STYLE=3D'font-size:10pt'>___________= ____________________________________<BR> Autoconf mailing list<BR> <a href=3D"Autoconf@ietf.org">Autoconf@ietf.org</a><BR> <a href=3D"https://www.ietf.org/mailman/listinfo/autoconf">https://www.ietf.o= rg/mailman/listinfo/autoconf</a><BR> </SPAN></FONT></FONT></BLOCKQUOTE> </BODY> </HTML> --B_3339485607_19415489-- From Fred.L.Templin@boeing.com Tue Oct 27 07:54:38 2009 Return-Path: <Fred.L.Templin@boeing.com> 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 ACD3828C116 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 07:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 3+jto3BkHKit for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 07:54:37 -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 D25A928C0F3 for <autoconf@ietf.org>; Tue, 27 Oct 2009 07:54:37 -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 n9REsp7g023968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <autoconf@ietf.org>; Tue, 27 Oct 2009 09:54:51 -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 n9REsp2A029415 for <autoconf@ietf.org>; Tue, 27 Oct 2009 09:54:51 -0500 (CDT) Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n9REsoIo029396 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for <autoconf@ietf.org>; Tue, 27 Oct 2009 09:54:51 -0500 (CDT) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Tue, 27 Oct 2009 07:54:50 -0700 From: "Templin, Fred L" <Fred.L.Templin@boeing.com> To: "autoconf@ietf.org" <autoconf@ietf.org> Date: Tue, 27 Oct 2009 07:54:49 -0700 Thread-Topic: [Autoconf] Protocols involving link-local addresses Thread-Index: AcpWWnlOcDKMO/f2S1qyZ9MFA+o4tAAus6Kw Message-ID: <12F4112206976147A34FEC0277597CCF27A41F9382@XCH-NW-15V.nw.nos.boeing.com> References: <4AE5C151.6000800@gmail.com> <4AE5C6BD.2030501@gmail.com><C07A1019-4ED5-4CCB-87C6-BCFB06F5BDF6@thomascla usen.org><4AE5C9CB.5030807@gmail.com><EAA3406E-F481-4373-AAB5-58A494A719B6@thomasclausen.org><4AE5CCF9.3060505@gmail.com> <B3631619-D199-44BB-B9D5-08D8BA17ACD9@thomasclausen.org> In-Reply-To: <B3631619-D199-44BB-B9D5-08D8BA17ACD9@thomasclausen.org> 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] Protocols involving link-local addresses X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 14:54:38 -0000 Add LLMNR as a link-local candidate protocol. From alexandru.petrescu@gmail.com Tue Oct 27 08:16:22 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 9CE913A6A20 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 08:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=0.171, 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 HLh-GFqEemj9 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 08:16:22 -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 B2F883A6986 for <autoconf@ietf.org>; Tue, 27 Oct 2009 08:16:21 -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 n9RFGSj4002366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 16:16:28 +0100 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 n9RFGRkh027782; Tue, 27 Oct 2009 16:16:27 +0100 (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 n9RFGRWU020796; Tue, 27 Oct 2009 16:16:27 +0100 Message-ID: <4AE70ECB.3090104@gmail.com> Date: Tue, 27 Oct 2009 16:16:27 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: sratliff <sratliff@cisco.com> References: <C70C81A7.1761%sratliff@cisco.com> In-Reply-To: <C70C81A7.1761%sratliff@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 15:16:22 -0000 sratliff a écrit : > Alex, > > <sarcasm>I was told not to pay attention to this discussion, no?</sarcasm> > > Ulrich is correct. The interfaces are proprietary. I’m not going to go > into a discussion about them in this forum. Ulrich has supplied pointers > to well-known interface types that don’t adhere to IEEE specs. Stan - I am sorry, I can not help to run IPv6 on proprietary interfaces about which you don't want to talk. Please de-proprietarize them somehow. It makes no sense for you to say that the DT proposal works with your proprietary interface as long as you can't get feedback from the WG about it. If it works within your env - ok, good luck. But if you bring it here - then please talk about it. It may very well be that your env does use IPv6 link-local addresses too (as some OLSR implementations do use them too). Alex From alexandru.petrescu@gmail.com Tue Oct 27 08:42:12 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 7A0643A6858 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 08:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.170, 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 64lz7fIHRZdN for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 08:42:11 -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 72AA03A6872 for <autoconf@ietf.org>; Tue, 27 Oct 2009 08:42:11 -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 n9RFa2tN031392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 16:36:02 +0100 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 n9RFa2xL001525; Tue, 27 Oct 2009 16:36:02 +0100 (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 n9RFa1un029213; Tue, 27 Oct 2009 16:36:02 +0100 Message-ID: <4AE71361.3070407@gmail.com> Date: Tue, 27 Oct 2009 16:36:01 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Templin, Fred L" <Fred.L.Templin@boeing.com> References: <4AE5C151.6000800@gmail.com> <4AE5C6BD.2030501@gmail.com><C07A1019-4ED5-4CCB-87C6-BCFB06F5BDF6@thomascla usen.org><4AE5C9CB.5030807@gmail.com><EAA3406E-F481-4373-AAB5-58A494A719B6@thomasclausen.org><4AE5CCF9.3060505@gmail.com> <B3631619-D199-44BB-B9D5-08D8BA17ACD9@thomasclausen.org> <12F4112206976147A34FEC0277597CCF27A41F9382@XCH-NW-15V.nw.nos.boeing.com> In-Reply-To: <12F4112206976147A34FEC0277597CCF27A41F9382@XCH-NW-15V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "autoconf@ietf.org" <autoconf@ietf.org> Subject: Re: [Autoconf] Protocols involving link-local addresses X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 15:42:12 -0000 Templin, Fred L a écrit : > Add LLMNR as a link-local candidate protocol. Updated to include LLMNR: Protocols applicable to MANET which use IPv6 LLs ------------------------------------------------ OSPF-MANET NDP RA MLD IPv4 optional protocols using LLs --------------------------------- mDNS ARP (the parts in IPv4 LL RFC) LLMNR IPv6 optional protocols using LLs --------------------------------- DHCP OSPF RIPng MLD OLSR (a particular implementation) ND PPP IPv6 ICMPv6 SLAAC FMIPv6 MIPv6/NEMOv6/PMIPv6 LLMNR Alex Teco Boot a écrit : > I would limit the list to protocols that are applicable to MANETs. > This is a non-empty list. For IPv6: > OSPF-MANET > NDP RA > MLD > And I have my own middleware products that use LL for Peer discovery > or 1-hop message disctribution (I could use hop-limit=1). > > Teco. > >> -----Oorspronkelijk bericht----- >> Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens >> Alexandru Petrescu >> Verzonden: maandag 26 oktober 2009 16:34 >> Aan: autoconf@ietf.org >> Onderwerp: [Autoconf] Protocols involving link-local addresses >> >> In several earlier discussions question was raised about which protocols >> use link-local addresses. >> >> IPv4 >> ---- >> mDNS >> ARP (the parts in IPv4 LL RFC) >> >> IPv6 >> ---- >> DHCP >> OSPF >> RIPng >> MLD >> OLSR (a particular implementation) >> >> If you know any other, feel free to add. I think it may be useful to >> add to the AUTOCONF addressing model draft(s). >> >> (I think Teco may have already written such a list but I have hard time >> finding it). > > > I would limit the list to protocols that are applicable to MANETs. > This is a non-empty list. For IPv6: > OSPF-MANET > NDP RA > MLD > And I have my own middleware products that use LL for Peer discovery > or 1-hop message disctribution (I could use hop-limit=1). > I would prefer LLs for OLSR also. > > Teco. > > >> Alex >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > From hrogge@googlemail.com Tue Oct 27 09:10:43 2009 Return-Path: <hrogge@googlemail.com> 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 C97AB3A6A2E for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 09:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[AWL=0.166, 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 kwkoYpsbv3hM for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 09:10:38 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id BBE533A67CF for <autoconf@ietf.org>; Tue, 27 Oct 2009 09:10:37 -0700 (PDT) Received: by ewy4 with SMTP id 4so306019ewy.37 for <autoconf@ietf.org>; Tue, 27 Oct 2009 09:10:48 -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=X3yFkDYrDwVtZUELi5Dd7Ct/fK3N4IWolnyGFaKXIok=; b=dsnYzAFdNfOiuvnIiiH/WQheMoHkONt9UTQelH8jR9VEdqnF4G437LPCLxCKigSBQR A32Eacz1Ou/oRd9sX9RawfCWEAl90r2T67GC7GRHT437NJCb6NLgxLRvk3/HBf7iBCIX uC3cJwzGi2cw4kMXtAnSqei91oDEJ+VSOV5zg= 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=LeaAUS7WWOf82XPVcRSDeK8BHa/wdTr/5morEnTUiJlqEOJ63TDl8SVuY+ENlTHv+h wN9IDoRONbITzXBVjt8tQxZIh5cOqMVbOn51/MAX0osT6L5XSPaNwvxBRIPEZWF0X1uZ egla+S4C5L3QhMVfbz9XeyBA21VphQEUw1N4A= Received: by 10.210.95.26 with SMTP id s26mr1826030ebb.7.1256659848777; Tue, 27 Oct 2009 09:10:48 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 5sm2821091eyf.5.2009.10.27.09.10.46 (version=SSLv3 cipher=RC4-MD5); Tue, 27 Oct 2009 09:10:46 -0700 (PDT) From: Henning Rogge <hrogge@googlemail.com> To: Alexandru Petrescu <alexandru.petrescu@gmail.com> Date: Tue, 27 Oct 2009 17:10:40 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-gentoo-r2; KDE/4.3.2; x86_64; ; ) References: <4AE6002C.3020704@gmail.com> <200910271142.12180.henning.rogge@fkie.fraunhofer.de> <4AE6D373.4080300@gmail.com> In-Reply-To: <4AE6D373.4080300@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1295717.DTzMPCYnRt"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910271710.45170.hrogge@googlemail.com> Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD problem in IPv6 mesh networks for LL X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 16:10:43 -0000 --nextPart1295717.DTzMPCYnRt Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am Dienstag 27 Oktober 2009 12:03:15 schrieb Alexandru Petrescu: > > It's an easy way to describe the difference between an ethernet switch > > (closed broadcast domain) and a WLAN MANET (not closed). >=20 > Well an ethernet switch is not such a closed broadcast domain because I > can add cables and other switches to it and run link-layer spanning-tree > protocols (802.1q) on them and they are open. Which doesn't change that a group of connected ethernet switches is still a= =20 closed domain (it's still transitive/symmetric connectivity). All connected interfaces are in 1-hop (IP-)range of each other on switches.= No=20 amount of cable and other switches will change this. =20 > The same in WLAN. I can add WLAN repeaters. No. please read my former mails again, especially the example. On the other side you could try to find a configuration of ethernet switche= s=20 where a IPv4 broadcast will not be transitive or symmetric. I'm curious abo= ut=20 it. =20 > >> We may have a terminology problem here. > >> > >> People need same terminology in order to understand each other. > > > > So do you recognize what I mean with "closed/not closed" broadcast ? >=20 > Seems as a new definition we may discuss to nail down and put in a > terminology document. >=20 > I do however have hard time talking "broadcast" in the context of IPv6. "Broadcast" is a common term for MANETs... You will find it in most of the= =20 older RFCs. For packetBB there has been an updated specification what kind = of=20 'send to all neighbors' IPs a MANET protocol should use. You will find it i= n=20 RFC 5498 (IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols). > Well... yes, DAD acts on a single-hop subnet (it's within the link-local > scope) - the HopLimit of the base header of the DAD packets are not > decremented. >=20 > And that is good, because link-local addresses are valid only on a > link-local scope. Exactly... =20 > If you want to invent a new two-hop scope? With two-hop-local > addresses? And a new duplicate address detection procedure working on > two-hop scopes? If so, I don't know what to say, but please don't > discard LLs, they are fine on their scope. >=20 > One should mention the problems of using two times LLs on a link-local > scope, before engaging on two-hop scopes. And thus make me understand > why the two-hop scope is necessary. >=20 > For example - why a two-hop scope and why not a three-hop scope? >=20 > > And that is (see above) not enough for well behaving LL IPs. >=20 > Would using two times a single-hop LL fit your two-hop need? >=20 > For example, a router with two interfaces, attached thus to two > link-local "1-hop" scopes, using a LL on each of its interface. Would > this be able to run a routing protocol? I believe so, OSPF does so. >=20 > I am not sure why you need a two-hop scope and addresses valid on > two-hop scopes. Think about the A-B-C WLAN scenario again. each of them has one interface if A and C choose the same LL-IP DAD would not detect it, because A and C a= re=20 not in one-hop distance. But suddenly B would not be able to use A's and C's LL-IP to address them,= =20 because they are both on the same interface of B. Do you see it ? Henning --nextPart1295717.DTzMPCYnRt Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEABECAAYFAkrnG4UACgkQcenvcwAcHWeExACcDRPPE9cxyxULiHJ8fzTcygOo Q2AAn2aTYvJeogQ2KW4zIYVyMuXzBpVh =Fx2e -----END PGP SIGNATURE----- --nextPart1295717.DTzMPCYnRt-- From charles.perkins@earthlink.net Tue Oct 27 09:17:05 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A2263A6A38 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 09:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.941 X-Spam-Level: X-Spam-Status: No, score=-1.941 tagged_above=-999 required=5 tests=[AWL=0.039, 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 FqxDMizdndzN for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 09:17:05 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id CBA423A69E1 for <autoconf@ietf.org>; Tue, 27 Oct 2009 09:17:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=gAxSHW/oW08rLz3s/EVmf0AHeTz2hfRVN9XTe6TW0WPfXchQtHYw1ZxxKfydPtcU; 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.16]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N2ojV-0001L5-9a; Tue, 27 Oct 2009 12:17:17 -0400 Message-ID: <4AE71D0C.6000909@earthlink.net> Date: Tue, 27 Oct 2009 09:17:16 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Teco Boot <teco@inf-net.nl> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <125638 9726.5286.65.camel@ac orde.it.uc3m.es> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> In-Reply-To: <01f901ca56db$5f4bf340$1de3d9c0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f522841bd182b64d1dec65304754f89bceb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 16:17:05 -0000 Hello Teco, Teco Boot wrote: > > > >> Our addressing model should cover all the possible scenarios. >> > > Total disagreement. > Our charter says "practical addressing model". > > If we think IPv6 can boil the ocean, to begin with assigning a > unique IPv6 address to each and every molecule, and we Autoconf > punish ourselves to achieve this, I'm sure this WG is on a dead end. > You are missing the very important point that the problem of assigning global addresses in an ad hoc network, without relying on link-local addresses, has _already been solved_. In multiple ways. In innovative ways. In boring ways. It's not boiling the ocean, which may well dry up before the LL crew admit the abovementioned reality. In fact, convincing the stalwart defenders of link-local addressing that it can be done, has proved to be orders of magnitude more difficult than actually just doing it. Such is the IETF. Regards, Charlie P. From charles.perkins@earthlink.net Tue Oct 27 09:18:55 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66BCC28C0F8 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 09:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.943 X-Spam-Level: X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[AWL=0.037, 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 AUyFMDGP2P2K for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 09:18:54 -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 B0D7A28C0F7 for <autoconf@ietf.org>; Tue, 27 Oct 2009 09:18:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=UxRA6JNFfvJuYRkXWr7tmfmSpXdNzFdqjPoTmG9lFJpUqG6sswJrFZT5gJjNUB8M; 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.16]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N2olG-0005zH-OI; Tue, 27 Oct 2009 12:19:06 -0400 Message-ID: <4AE71D7A.7020705@earthlink.net> Date: Tue, 27 Oct 2009 09:19:06 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.com> <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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <125638 9726.5286.65.camel@ac orde.it.uc3m.es> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <1256634091.5090.4.camel@acorde.it.uc3m.es> In-Reply-To: <1256634091.5090.4.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52a4b76b698e2757c2999ebf3a3c7e7410350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 16:18:55 -0000 Hello Carlos, Carlos Jesús Bernardos Cano wrote: > Agree with Teco, > Then you too are denying the fact that we have already done what needs to be done in many different ways. It would be nice for the practitioners who have done it, to be able to standardize on one approach. Regards, Charlie P. From charles.perkins@earthlink.net Tue Oct 27 09:25:21 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2754F3A6767 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 09:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.945 X-Spam-Level: X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=0.035, 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 YHHHPqNg90gA for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 09:25:20 -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 562AF3A6359 for <autoconf@ietf.org>; Tue, 27 Oct 2009 09:25:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=al0s/5z0lNy+wZARPhjxahfyjTX6XY61sSHL5yBN0PiJd+dp/ZZZd5Ue0L2U2TvW; 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.16]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N2orW-0008LX-Fz; Tue, 27 Oct 2009 12:25:34 -0400 Message-ID: <4AE71EFF.8020609@earthlink.net> Date: Tue, 27 Oct 2009 09:25:35 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <0E0F03A1-EC0C-4FF9-AB17-DB2029F7363E@gmail.com> <1256492329.4766.39.camel@acorde.it.uc3m.es> <E91718ED-92C0-451D-9EEE-52DA64DC21C7@gmail.com> <4AE6C1B7.8010400@gmail.com> In-Reply-To: <4AE6C1B7.8010400@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f525e6f644652d99e2994e723f9bb041172350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 16:25:21 -0000 Hello Alex, Alexandru Petrescu wrote: > >> >> Come on, IP is best-effort in terms of packet delivery. >> If the address uniqueness is not guaranteed, all the IP >> infrastructure might be collapsed. > > I agree IP is best-effor mostly in terms of packet delivery. > > It is also true that the uniqueness ensuring mechanisms of IP are made > to the best of one's capabilities - I don't think one can do any better. This exhibits a lack of understanding. It is NOT the case that IP was designed with any sort of lackadaisical approach to address uniqueness. And, if the goal of the design of IP were assured packet delivery, it COULD have been done differently. Discussions like these, I am sure, have caused enormous grief to whoever coined the term "best effort". > > > AUTOCONF can't do any better than DAD and DNA and DHCP and MAC did > with respect to uniqueness. If one cares about scalability in the face of mobility and wireless connectivity, then yes we can, and people have. > Especially since AUTOCONF is incapable of describing what's wrong > with DAD, oDAD, DNA, DHCP and MAC. Perhaps you are incapable of digesting the descriptions that have been offered many times. > > Be serious you too :-) In my opinion, you make that into a difficult assignment. Regards, Charlie P. > From hrogge@googlemail.com Tue Oct 27 09:26:29 2009 Return-Path: <hrogge@googlemail.com> 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 D547528C1E5 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 09:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.152, 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 y2rY2KJVCOma for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 09:26:29 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id B1F5628C1E4 for <autoconf@ietf.org>; Tue, 27 Oct 2009 09:26:28 -0700 (PDT) Received: by ewy4 with SMTP id 4so321343ewy.37 for <autoconf@ietf.org>; Tue, 27 Oct 2009 09:26:42 -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=JC+fxKUU9z280Lxf4wD7R426D2L6cq+PeKu+gPhuGXM=; b=YNAydYSLK6eH9smahjRKPsbZrrOm1T92weTCBJKqWkVlZys9gGE/+xIUw7anmvZKq1 GNHBArF7eisOEHI2C6gH5qk5xVxxLtWV0zKiDgfyUxqb86omDylmvl8tkZnZfTj1aZ31 gDWA/TxRrrBhcI4SP8kwyfsSbsouTok44iKgE= 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=SQFaqy8s3fB5ie2YESypEU2Cr8hBNOEeBoH5q7VngnGuvV6DgoBoGC/aIli8OUn+YG mDdGzGTZq+iWCPUy4pkW32gKYsDALFMP/btgmndy3Gdekf96gSFDdUoYf/xN61E4aubT wEHYvUUBSLlAyuMzdKj1ujMAxgV0V03r72pyw= Received: by 10.211.146.10 with SMTP id y10mr3560730ebn.32.1256660802609; Tue, 27 Oct 2009 09:26:42 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 28sm461339eyg.38.2009.10.27.09.26.40 (version=SSLv3 cipher=RC4-MD5); Tue, 27 Oct 2009 09:26:41 -0700 (PDT) From: Henning Rogge <hrogge@googlemail.com> To: autoconf@ietf.org Date: Tue, 27 Oct 2009 17:26:35 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-gentoo-r2; KDE/4.3.2; x86_64; ; ) References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <4AE71D0C.6000909@earthlink.net> In-Reply-To: <4AE71D0C.6000909@earthlink.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart628333258.MJYLQD9xxa"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910271726.40008.hrogge@googlemail.com> Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 16:26:29 -0000 --nextPart628333258.MJYLQD9xxa Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am Dienstag 27 Oktober 2009 17:17:16 schrieb Charles E. Perkins: > You are missing the very important point that > the problem of assigning global addresses in an > ad hoc network, without relying on link-local > addresses, has _already been solved_. In multiple > ways. In innovative ways. In boring ways. I must admit I still sometimes miss the point of the discussion. If the "generate mesh unique IPs without linklocal IPs" is already solved=20 (maybe not perfect, but in many different ways, have read a few of them), w= hy=20 don't we just suggest to use the SAME algorithms and protocolls to generate= =20 the linklocal IPs ? Just take the unique postfix and add the linklocal=20 praefix. The result should be definitely link-unique. Henning Rogge --nextPart628333258.MJYLQD9xxa Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEABECAAYFAkrnH0AACgkQcenvcwAcHWckCwCeMyXTtgh91f0tEaMDXJlZroZd HWEAoI/9QUlr4Ps/19jY1OGoUnkaBMSD =t68i -----END PGP SIGNATURE----- --nextPart628333258.MJYLQD9xxa-- From charles.perkins@earthlink.net Tue Oct 27 09:28:22 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35F013A6767 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 09:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.348 X-Spam-Level: * X-Spam-Status: No, score=1.348 tagged_above=-999 required=5 tests=[AWL=-3.260, BAYES_00=-2.599, FB_WORD1_END_DOLLAR=3.294, FB_WORD2_END_DOLLAR=3.294, 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 VM1f7iuVd25q for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 09:28:21 -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 81D443A6359 for <autoconf@ietf.org>; Tue, 27 Oct 2009 09:28:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=GisBqKIGANREYWhrVjNYqsuoDojKf2c++6eZnIuOlQnBG0Hj+R+P752hqVkdR5cM; 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.16]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N2ouQ-00058g-8q; Tue, 27 Oct 2009 12:28:34 -0400 Message-ID: <4AE71FB3.9020702@earthlink.net> Date: Tue, 27 Oct 2009 09:28:35 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.com> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <25c114b90910270135i788a8a45oc0ac5cf87e2ae52@mail.gmail.com> <4AE6C4B5.1050309@gmail.com> In-Reply-To: <4AE6C4B5.1050309@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52d71835e128ece9e91596e22793123b0a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 16:28:22 -0000 Hello Alex, Alexandru Petrescu wrote: > > Ulrich (and Stan too, 100k$ machines) - please state the names and > specifications of the kinds of radio interfaces other than IEEE you > plan to use. IEEE already covers a wide range of radios, WLAN, WPAN, > WMAN. They even cover "mesh" and "ad-hoc" stuff. I am saying this > after having seen same duplicate effort IEEE/IETF on FMIP and FastBSS. > > Please say how your links act. > > Until you don't say so - it's all a dark area. > Emmanuel and I wrote an Internet Draft describing the properties of these links. You read it. Shall we post it again? Regards, Charlie P. From charles.perkins@earthlink.net Tue Oct 27 09:29:40 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A05333A68DD for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 09:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.804 X-Spam-Level: X-Spam-Status: No, score=-1.804 tagged_above=-999 required=5 tests=[AWL=0.176, 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 JI+U+BiBcCM1 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 09:29:40 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id E61D23A69E1 for <autoconf@ietf.org>; Tue, 27 Oct 2009 09:29:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=YOnRDiz+4p9uGPQUkRYi3s0Upq5H2Qe/gZlW413FTJDvvXN6JqbwfHcJCjIipJEA; 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.16]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N2ovg-0004KR-RG; Tue, 27 Oct 2009 12:29:52 -0400 Message-ID: <4AE72001.5040102@earthlink.net> Date: Tue, 27 Oct 2009 09:29:53 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <125638 9726.5286.65.camel@ac orde.it.uc3m.es> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <1256634091.5090.4.camel@acorde.it.uc3m.es> <4AE6C4C7.5000803@gmail.com> In-Reply-To: <4AE6C4C7.5000803@gmail.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52e6691f88c9eb14b1dd4fc0df62c07526350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 16:29:40 -0000 Hello Alex, Alexandru Petrescu wrote: > I agree with Carlos. > > Alex Then you too are denying the fact that we have already done what needs to be done in many different ways. It would be nice for the practitioners who have done it, to be able to standardize on one approach. Regards, Charlie P. From charles.perkins@earthlink.net Tue Oct 27 09:32:32 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35BE83A6A4A for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 09:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.812 X-Spam-Level: X-Spam-Status: No, score=-1.812 tagged_above=-999 required=5 tests=[AWL=0.168, 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 zNzyLHrVmIDC for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 09:32:30 -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 932E43A6A46 for <autoconf@ietf.org>; Tue, 27 Oct 2009 09:32:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=gcY6umTVdSg+5+meseR8ziA9MVvjpyd9AaLtWJEv2imH0dgcwRBc85tKSUl5Z1JF; 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.16]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N2oyQ-000889-UE; Tue, 27 Oct 2009 12:32:43 -0400 Message-ID: <4AE720AB.609@earthlink.net> Date: Tue, 27 Oct 2009 09:32:43 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <AE72A684-DF66-4E49-A291-06C950893A4A@gmail.com> <4AE6C224.5080109@gmail.com> <25c114b90910270303v1c928b77y7ae88895c1e8778f@mail.gmail.com> <4AE6C7A4.8080506@gmail.com> In-Reply-To: <4AE6C7A4.8080506@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f520f8f49e9dfa336e2e7baf5f58f5592f9350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] disagreement on the DT document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 16:32:32 -0000 Hello Alex, Alexandru Petrescu wrote: > Ulrich, > > From a procedural standpoint, two things: > > The DT draft has very little inherent validity as a WG item - it was > forced on the WG without asking the WG. Perhaps we should verify consensus. > > > Additionally, it does not do some things that the Charter asks it to > do: it doesn't describe how the addressing model impacts or not the > non-MANET nodes connecting to MANET nodes. By my reading it does not have to do this. The solutions have to obey that charter requirement. > > > Seriously, here are the draft statements I disagree with: > > In the section 4 IP Subnet Prefix COnfiguration: > [...] >> o no two such interfaces in the network should be configured with >> the same subnet prefix. > [...] > > This ignores the presence of LL prefix fe80::/10. For good reason! > > In section 6.1 IPv4 model: >> Note that the use of IPv4 link-local addresses [RFC3927] in this >> context should be discouraged for most applications, > > This ignores the existence and widespread use of applications using > IPv4 LLs behind NAT. Maybe they won't work in an ad hoc network. > > In section 6.2 IPv6 Model: >> o A subnet prefix configured on this interface should be of length >> /128. > > This is completely out of scope, because /128 prefixes make no sense > in terms of subnet and multicast. I don't have a problem with that. > >> Therefore MANET autoconfiguration solutions should be encouraged to >> primarily focus on configuring IP addresses that are not IPv6 link- >> local. > > This says what should not be done, but it does not say what should be > done. It says that you should pick long prefixes unless you have a reason to make less restrictive choices. Therefore your statement is false. Regards, Charlie P. From charles.perkins@earthlink.net Tue Oct 27 09:36:30 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA2DE3A6A03 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 09:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.818 X-Spam-Level: X-Spam-Status: No, score=-1.818 tagged_above=-999 required=5 tests=[AWL=0.162, 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 iWl+CpXL7ATc for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 09:36:30 -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 A12CB3A6886 for <autoconf@ietf.org>; Tue, 27 Oct 2009 09:36:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=U3MQRgtejzIwISyJkh3EGD96BcmogJwRhPnudG6+4SAeYKo6K2gBqSJThbUMfLkm; 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.16]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N2p2I-0006Uk-FE; Tue, 27 Oct 2009 12:36:42 -0400 Message-ID: <4AE7219A.4010601@earthlink.net> Date: Tue, 27 Oct 2009 09:36:42 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.com> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <25c114b90910270135i788a8a45oc0ac5cf87e2ae52@mail.gmail.com> <4AE6C4B5.1050309@gmail.com> <25c114b90910270324y3599756bhdebe9502f6026b93@mail.gmail.com> <4AE6CD55.1040205@gmail.com> In-Reply-To: <4AE6CD55.1040205@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f529aa0a3ccb24792236b0f17936ec703ac350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 16:36:30 -0000 Hello Alex, Alexandru Petrescu wrote: > > Ulrich, please first, do not point me to wikipedia, I refuse to be > pointed to wikipedia. I do use it often but I refuse to be pointed to > it. Why? > > It's like you tell me to go read thousands of pages that you haven't > read either - why do you do so? What if someone reads the article and then finds it to be potentially valuable for you? Why not offer a readily available source of information? > > That apart. > > Which link layer are _you_ particularly concerned with and whose > behaviour you'd like to see accepted in AUTOCONF? How does this link > layer behave with respect to IPv6? This is the IETF. Link-agnostic sorts of folks. > > > > I am saying this after having experimented with several wireless link > layers: wavelan, wifi, bluetooth, irda, umts, 3g+, gsm, SLIP 2400bps, > 802.16MAC, USB - to name just a few. My goal was all the time to see > how IPv6 runs on it. I can tell you that I was not deceived and each > time there was a solution, always involving link-local addresses. With three nodes? > > What do you think? What is that link-layer which does not support IPv6 > link-layer addresses? > > Is it an imaginary link layer? It's not the link-layer that doesn't support IPv6 addresses. It's the link layer that doesn't support guaranteed layer-2 unique addresses. It's the mobility that makes this into a threat against link-layer address uniqueness. Which, honestly, I think you could figure out directly except that it's so much fun to argue. Regards, Charlie P. From sratliff@cisco.com Tue Oct 27 09:43:31 2009 Return-Path: <sratliff@cisco.com> 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 1214928C1E2 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 09:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.64 X-Spam-Level: X-Spam-Status: No, score=-3.64 tagged_above=-999 required=5 tests=[AWL=0.892, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 oVTgW7li2N-6 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 09:43:30 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 9DE3C3A6A32 for <autoconf@ietf.org>; Tue, 27 Oct 2009 09:43:28 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEALe/5kpAZnwN/2dsb2JhbACbIKZPmE6EPwSBXw X-IronPort-AV: E=Sophos;i="4.44,634,1249257600"; d="scan'208";a="65122644" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 27 Oct 2009 16:43:42 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9RGhgnT027110; Tue, 27 Oct 2009 16:43:42 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 12:43:42 -0400 Received: from 64.102.54.119 ([64.102.54.119]) by xmb-rtp-208.amer.cisco.com ([64.102.31.43]) with Microsoft Exchange Server HTTP-DAV ; Tue, 27 Oct 2009 16:43:42 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 27 Oct 2009 12:43:41 -0400 From: sratliff <sratliff@cisco.com> To: Alexandru Petrescu <alexandru.petrescu@gmail.com> Message-ID: <C70C9B7D.177F%sratliff@cisco.com> Thread-Topic: [Autoconf] DAD, link-locals, two drafts and making up my mind Thread-Index: AcpXJKOtyg2g7III70Ca6uIfSH0m+g== In-Reply-To: <4AE70ECB.3090104@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 27 Oct 2009 16:43:42.0282 (UTC) FILETIME=[A4717AA0:01CA5724] Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 16:43:31 -0000 Alex,=20 You miss the point. There are other, non-IEEE interfaces that we *can* discuss. Ulrich has given you a (partial) list. What I'm trying to tell you is, if we consider those interfaces, and design accordingly, my proprietary interfaces should work. So there are things we can openly discuss. I just don't see a lot of progress when we discuss them. Regards, Stan On 10/27/09 11:16 AM, "Alexandru Petrescu" <alexandru.petrescu@gmail.com> wrote: > sratliff a =E9crit : >> Alex, >>=20 >> <sarcasm>I was told not to pay attention to this discussion, no?</sarcas= m> >>=20 >> Ulrich is correct. The interfaces are proprietary. I=B9m not going to go >> into a discussion about them in this forum. Ulrich has supplied pointers >> to well-known interface types that don=B9t adhere to IEEE specs. >=20 > Stan - I am sorry, I can not help to run IPv6 on proprietary interfaces > about which you don't want to talk. Please de-proprietarize them somehow= . >=20 > It makes no sense for you to say that the DT proposal works with your > proprietary interface as long as you can't get feedback from the WG > about it. >=20 > If it works within your env - ok, good luck. >=20 > But if you bring it here - then please talk about it. >=20 > It may very well be that your env does use IPv6 link-local addresses too > (as some OLSR implementations do use them too). >=20 > Alex >=20 >=20 From charles.perkins@earthlink.net Tue Oct 27 09:47:49 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA91628C1F0 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 09:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.825 X-Spam-Level: X-Spam-Status: No, score=-1.825 tagged_above=-999 required=5 tests=[AWL=0.155, 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 HVRCnbOU0bx1 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 09:47:48 -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 C755C28C0F0 for <autoconf@ietf.org>; Tue, 27 Oct 2009 09:47:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=RRwoK9ZinCRm5C7gDZ42jVYL2ddFK1vxkWdCTmtNW1NEC/iSKxAcPGFXPnDpDAA4; 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.16]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N2pDE-0003Y4-15; Tue, 27 Oct 2009 12:48:00 -0400 Message-ID: <4AE72440.3050308@earthlink.net> Date: Tue, 27 Oct 2009 09:48:00 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <4AE6002C.3020704@gmail.com> <200910270733.09411.henning.rogge@fkie.fraunhofer.de> <4AE6C394.1040000@gmail.com> <200910271142.12180.henning.rogge@fkie.fraunhofer.de> <4AE6D373.4080300@gmail.com> In-Reply-To: <4AE6D373.4080300@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f525f82fe3c3f73b716023d7914296ba9a3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD problem in IPv6 mesh networks for LL X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 16:47:49 -0000 Hello Alex, Alexandru Petrescu wrote: > >> It's an easy way to describe the difference between an ethernet >> switch (closed broadcast domain) and a WLAN MANET (not closed). > > Well an ethernet switch is not such a closed broadcast domain because > I can add cables and other switches to it and run link-layer > spanning-tree protocols (802.1q) on them and they are open. > > The same in WLAN. I can add WLAN repeaters. This is nonsense. It is wrong in this context to compare the rate of change of topology in a switched Ethernet system against that rate in a wireless system. But at least it gives us a good clue into your justification for DAD and NUD signaling overheads. > > I do however have hard time talking "broadcast" in the context of IPv6. > > We could be talking "broadcast" in terms of a specific link-layer, > which we should name. You should look at the earlier document on this point from Emmanuel and myself. > > >> No... I don't know DAD in this detail. The only thing I was told >> about DAD that it checks only for conflicts at 1-hop (1 layer-2 link >> away) distance. > > Well... yes, DAD acts on a single-hop subnet (it's within the > link-local scope) - the HopLimit of the base header of the DAD packets > are not decremented. > > And that is good, because link-local addresses are valid only on a > link-local scope. You're getting warm here. > > If you want to invent a new two-hop scope? With two-hop-local > addresses? And a new duplicate address detection procedure working on > two-hop scopes? If so, I don't know what to say, but please don't > discard LLs, they are fine on their scope. A scope which, in wireless networks we're interested in, basically doesn't exist on any timescale useful for protocol signaling. > > One should mention the problems of using two times LLs on a link-local > scope, before engaging on two-hop scopes. And thus make me understand > why the two-hop scope is necessary. > > For example - why a two-hop scope and why not a three-hop scope? Precisely. Why not a ten-hop scope? We did that. > >> And that is (see above) not enough for well behaving LL IPs. > > Would using two times a single-hop LL fit your two-hop need? That would be a great deal sillier than just working around the problem. As has been done many times in the past. Which is why the practitioners wanted to have a working group to standardize a solution. Which you keep ignoring. > > For example, a router with two interfaces, attached thus to two > link-local "1-hop" scopes, using a LL on each of its interface. Would > this be able to run a routing protocol? I believe so, OSPF does so. > > I am not sure why you need a two-hop scope and addresses valid on > two-hop scopes. Because the range of packet capture does not extend across the entire MANET. > >> A broadcast can typically only reach your direct neighbors in the >> network. > > Well, hmm, IPv6 doesn't use the term "broadcast" but "all-node > multicast". There is even a finer grained distinction, like > "all-hosts" or "all-routers" or "all-ntp servers". These have > different scopes: node, interface, host, link, site, global, etc. The > working on this relies on the good working of IP multicast such as MLD > and of link-layer multicast (IEEE MAC reused on many IEEE protocols). > > So in this, I would avoid the use of the term "broadcast" when talking > IPv6. We can avoid the use of that term. But it's O.K. for people who understand each other to use terminology that they understand. It's only when others want to nitpick about it that we have to be more careful. > > IPv4, and old Ethernet MAC implementations, do use the term > "broadcast". For example, there is an IPv4 "broadcast" address > 255.255.255.255 (there's no such equivalent all-1s in IPv6) and an > Ethernet "broadcast" address "ff:ff:ff:ff:ff:ff". This latter is not > used by IPv6 under any form, but it uses "33:33::1" which is called a > link-layer multicast address. That's why I suggest to not use the > term "broadcast" when talking IPv6. > > If I were you I would dig for all the IPv6-over-foo RFCs to see > whether they use the term "broadcast" or not. I believe there is even > an effort to write a document listing all link layers on which IPv6 > runs, and how. > > Also, when you say neighbors, I believe them to be discovered by ND, > which you don't seem to. Neighbors can deliver packets to each other directly, regardless of whether or not that capability is discovered by ND. This is also discussed at length in the Baccelli/Perkins draft that you have read in the past. Regards, Charlie P. From alexandru.petrescu@gmail.com Tue Oct 27 09:53:00 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 61D7D28C0EC for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 09:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.081 X-Spam-Level: X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[AWL=0.168, 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 nx736yBiV3+g for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 09:52:59 -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 E66F73A6A0E for <autoconf@ietf.org>; Tue, 27 Oct 2009 09:52:58 -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 n9RGqn2C010325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 17:52:49 +0100 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 n9RGqm12018919; Tue, 27 Oct 2009 17:52:49 +0100 (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 n9RGqmrV023893; Tue, 27 Oct 2009 17:52:48 +0100 Message-ID: <4AE72560.3000502@gmail.com> Date: Tue, 27 Oct 2009 17:52:48 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Henning Rogge <hrogge@googlemail.com> References: <4AE6002C.3020704@gmail.com> <200910271142.12180.henning.rogge@fkie.fraunhofer.de> <4AE6D373.4080300@gmail.com> <200910271710.45170.hrogge@googlemail.com> In-Reply-To: <200910271710.45170.hrogge@googlemail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD problem in IPv6 mesh networks for LL X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 16:53:00 -0000 Henning Rogge a écrit : > Am Dienstag 27 Oktober 2009 12:03:15 schrieb Alexandru Petrescu: >>> It's an easy way to describe the difference between an ethernet switch >>> (closed broadcast domain) and a WLAN MANET (not closed). >> Well an ethernet switch is not such a closed broadcast domain because I >> can add cables and other switches to it and run link-layer spanning-tree >> protocols (802.1q) on them and they are open. > Which doesn't change that a group of connected ethernet switches is still a > closed domain (it's still transitive/symmetric connectivity). > > All connected interfaces are in 1-hop (IP-)range of each other on switches. No > amount of cable and other switches will change this. Yes, ok. The same with wifi. They have a range of 50meters. You could extend that with more wifi cards/APs but no amount of cards/APs will open it, it's a "closed domain". Just because WiFi is deployed often outside and the switches often in a cabinet doesn't make any one of them more close than the other. >> The same in WLAN. I can add WLAN repeaters. > No. please read my former mails again, especially the example. You mean I can not add a WLAN repeater? I have already done that - why do you want me to not do it? Other people added WLAN PHY range extender antennas, up to 2km - do you want them to not do it too? > On the other side you could try to find a configuration of ethernet switches > where a IPv4 broadcast will not be transitive or symmetric. I'm curious about > it. Hmm... probably playing a bit with the myriad of the 802.1q config parameters? Why should I try? >>>> We may have a terminology problem here. >>>> >>>> People need same terminology in order to understand each other. >>> So do you recognize what I mean with "closed/not closed" broadcast ? >> Seems as a new definition we may discuss to nail down and put in a >> terminology document. >> >> I do however have hard time talking "broadcast" in the context of IPv6. > > "Broadcast" is a common term for MANETs... MANET speakers should change the terminology when talking IPv6 and broadcast. > You will find it in most of the > older RFCs. Hmm... I hope this is not important. Please mention one such MANET RFC talking IPv6 and broadcast and I will remark to it in the appropriate WG. > For packetBB there has been an updated specification what kind of > 'send to all neighbors' IPs a MANET protocol should use. You will find it in > RFC 5498 (IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols). Right, and that RFC says "multicast" for IPv6, not "broadcast" for IPv6. I think it doesn't say "broadcast" even for IPv4, but also "multicast". Your use of "broadcast" just because MANET speakers used it historically makes one think that one could use the term "broadcast" freely, like for example if I want to say "broadcast TV" which is wireless, and which pertains to IPv6 too (IPv6-over-DVB). I think we should be using the "broadcast" term in a non-ambiguous way as much as possible, such that to better understand each other. >> Well... yes, DAD acts on a single-hop subnet (it's within the link-local >> scope) - the HopLimit of the base header of the DAD packets are not >> decremented. >> >> And that is good, because link-local addresses are valid only on a >> link-local scope. > Exactly... > >> If you want to invent a new two-hop scope? With two-hop-local >> addresses? And a new duplicate address detection procedure working on >> two-hop scopes? If so, I don't know what to say, but please don't >> discard LLs, they are fine on their scope. >> >> One should mention the problems of using two times LLs on a link-local >> scope, before engaging on two-hop scopes. And thus make me understand >> why the two-hop scope is necessary. >> >> For example - why a two-hop scope and why not a three-hop scope? >> >>> And that is (see above) not enough for well behaving LL IPs. >> Would using two times a single-hop LL fit your two-hop need? >> >> For example, a router with two interfaces, attached thus to two >> link-local "1-hop" scopes, using a LL on each of its interface. Would >> this be able to run a routing protocol? I believe so, OSPF does so. >> >> I am not sure why you need a two-hop scope and addresses valid on >> two-hop scopes. > Think about the A-B-C WLAN scenario again. > > each of them has one interface > > if A and C choose the same LL-IP DAD would not detect it, because A and C are > not in one-hop distance. DAD running on which machine? You seem to think DAD on B won't detect A and C have the same address, which may be truly true. Also, DAD on A won't detect C having same address, and vice-versa, because they're too far apart. Ok. Nodes far apart cant talk to each other regardless of the addresses being duplicated. > But suddenly B would not be able to use A's and C's LL-IP to address them, > because they are both on the same interface of B. > > Do you see it ? Sorry, I don't see it. Who runs DAD? Normally every machine runs DAD. If A and B are close enough to hear each other and both run DAD then the duplicate between A and B is detected. Same for B and C. So, if A's address is not duplicated at B, and B's address is not duplicated at C - then A and C use distinctive addresses. Which seems a rather happy situation to be in. Don't you think so? Alex From charles.perkins@earthlink.net Tue Oct 27 09:53:31 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECC9E28C0F8 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 09:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[AWL=0.150, 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 440L6k01VWDc for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 09:53:31 -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 1E8C628C0F0 for <autoconf@ietf.org>; Tue, 27 Oct 2009 09:53:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=IxwtlI/56rPYvjn0ThGcFzD0iOCvz3d3vE5Tkc2AYqGJQRHwXmQMlIm1GnM7S6Vg; 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.16]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N2pIm-0002Ol-2B; Tue, 27 Oct 2009 12:53:44 -0400 Message-ID: <4AE72598.2050804@earthlink.net> Date: Tue, 27 Oct 2009 09:53:44 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.com> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <25c114b90910270135i788a8a45oc0ac5cf87e2ae52@mail.gmail.com> <4AE6C4B5.1050309@gmail.com> <25c114b90910270324y3599756bhdebe9502f6026b93@mail.gmail.com> <4AE6CD55.1040205@gmail.com> <25c114b90910270352r7be3999ena54848beb1cf9472@mail.gmail.com> <4AE6D5C3.8080501@gmail.com> <25c114b90910270528t238703afkdf34873a08539954@mail.gmail.com> <4AE6F630.7000606@gmail.com> In-Reply-To: <4AE6F630.7000606@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52d37e5e9fb7d86614d669d2aa595756fa350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] IP over "anything" X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 16:53:32 -0000 Hello Alex, Alexandru Petrescu wrote: > Ulrich, > > There is a high risk to work on something that we don't what is. You too are denying the fact that we have already done what needs to be done in many different ways. It would be nice for the practitioners who have done it, to be able to standardize on one approach. > > Blindly hiding behind "IP over anything" without saying what is, and > ignoring the so many IP-over-foo RFC documents - are indicators for this. Blindly assuming MAC-layer uniqueness is an indication of a bad fit for the [autoconf] working group, I think. > > Also, there was a zeroconf WG, "to enable networking in the absence of > configuration and administration". Doesn't that sound MANETish > enough. Well it gave the IPv4 LLs RFC. I was there. It was maximally non-MANET. In fact, it was a single extent of Ethernet. That's not a MANET. And it was terribly political. Ohh... well maybe that isn't a difference. Regards, Charlie P. From alexandru.petrescu@gmail.com Tue Oct 27 09:58:55 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 60BD328C1F0 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 09:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.083 X-Spam-Level: X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=0.166, 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 E9v0alMLxHQJ for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 09:58:54 -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 5321928C1A4 for <autoconf@ietf.org>; Tue, 27 Oct 2009 09:58: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 n9RGx5MP029008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 17:59:05 +0100 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 n9RGx4w1019860; Tue, 27 Oct 2009 17:59:05 +0100 (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 n9RGx4F6000403; Tue, 27 Oct 2009 17:59:04 +0100 Message-ID: <4AE726D8.1000705@gmail.com> Date: Tue, 27 Oct 2009 17:59:04 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" <charles.perkins@earthlink.net> References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <0E0F03A1-EC0C-4FF9-AB17-DB2029F7363E@gmail.com> <1256492329.4766.39.camel@acorde.it.uc3m.es> <E91718ED-92C0-451D-9EEE-52DA64DC21C7@gmail.com> <4AE6C1B7.8010400@gmail.com> <4AE71EFF.8020609@earthlink.net> In-Reply-To: <4AE71EFF.8020609@earthlink.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] best-effort, real politics and more (was: I-D Action:draft-bernardos-autoconf-addressing-model-00.txt) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 16:58:55 -0000 Charles E. Perkins a écrit : > > Hello Alex, > > > Alexandru Petrescu wrote: >> >>> >>> Come on, IP is best-effort in terms of packet delivery. If the >>> address uniqueness is not guaranteed, all the IP infrastructure >>> might be collapsed. >> >> I agree IP is best-effor mostly in terms of packet delivery. >> >> It is also true that the uniqueness ensuring mechanisms of IP are >> made to the best of one's capabilities - I don't think one can do >> any better. > > This exhibits a lack of understanding. > > It is NOT the case that IP was designed with any sort of > lackadaisical approach to address uniqueness. > > And, if the goal of the design of IP were assured packet delivery, it > COULD have been done differently. > > Discussions like these, I am sure, have caused enormous grief to > whoever coined the term "best effort". > >> >> >> AUTOCONF can't do any better than DAD and DNA and DHCP and MAC did >> with respect to uniqueness. > > If one cares about scalability in the face of mobility and wireless > connectivity, then yes we can, and people have. Too generic Charles, too generic to my reading. And ingeniously takes advantage of recent real politics verbiage - yes you can. Let's talk protocols and problems of protocols and link layers with names on them. >> Especially since AUTOCONF is incapable of describing what's wrong >> with DAD, oDAD, DNA, DHCP and MAC. > > Perhaps you are incapable of digesting the descriptions that have > been offered many times. Let's talk again the ABC problem. Alex > >> >> Be serious you too :-) > > In my opinion, you make that into a difficult assignment. > > Regards, Charlie P. >> > > From alexandru.petrescu@gmail.com Tue Oct 27 10:04:00 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 2FB3B3A6A5E for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.21 X-Spam-Level: * X-Spam-Status: No, score=1.21 tagged_above=-999 required=5 tests=[AWL=-3.129, BAYES_00=-2.599, FB_WORD1_END_DOLLAR=3.294, FB_WORD2_END_DOLLAR=3.294, 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 ph6FwW4qPRad for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:03:59 -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 4082F3A6A5D for <autoconf@ietf.org>; Tue, 27 Oct 2009 10:03:59 -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 n9RH4AoM017993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 18:04:10 +0100 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 n9RH4ACC021061; Tue, 27 Oct 2009 18:04:10 +0100 (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 n9RH49Gf002378; Tue, 27 Oct 2009 18:04:10 +0100 Message-ID: <4AE7280A.30508@gmail.com> Date: Tue, 27 Oct 2009 18:04:10 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" <charles.perkins@earthlink.net> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.com> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <25c114b90910270135i788a8a45oc0ac5cf87e2ae52@mail.gmail.com> <4AE6C4B5.1050309@gmail.com> <4AE71FB3.9020702@earthlink.net> In-Reply-To: <4AE71FB3.9020702@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 17:04:00 -0000 Charles E. Perkins a écrit : > > Hello Alex, > > Alexandru Petrescu wrote: >> >> Ulrich (and Stan too, 100k$ machines) - please state the names and >> specifications of the kinds of radio interfaces other than IEEE you >> plan to use. IEEE already covers a wide range of radios, WLAN, WPAN, >> WMAN. They even cover "mesh" and "ad-hoc" stuff. I am saying this >> after having seen same duplicate effort IEEE/IETF on FMIP and FastBSS. >> >> Please say how your links act. >> >> Until you don't say so - it's all a dark area. >> > Emmanuel and I wrote an Internet Draft describing the > properties of these links. > > You read it. > > Shall we post it again? Sorry which draft? I will read it again if you need my feedback. Alex > > Regards, > Charlie P. > > > > From alexandru.petrescu@gmail.com Tue Oct 27 10:04:52 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 D47003A690D for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.054 X-Spam-Level: X-Spam-Status: No, score=-2.054 tagged_above=-999 required=5 tests=[AWL=0.195, 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 7Yzx6unlZxqi for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:04:52 -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 EF7F23A6823 for <autoconf@ietf.org>; Tue, 27 Oct 2009 10:04:51 -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 n9RH531T018531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 18:05:03 +0100 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 n9RH530g021193; Tue, 27 Oct 2009 18:05:03 +0100 (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 n9RH53lC002662; Tue, 27 Oct 2009 18:05:03 +0100 Message-ID: <4AE7283F.9040600@gmail.com> Date: Tue, 27 Oct 2009 18:05:03 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" <charles.perkins@earthlink.net> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <125638 9726.5286.65.camel@ac orde.it.uc3m.es> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <1256634091.5090.4.camel@acorde.it.uc3m.es> <4AE6C4C7.5000803@gmail.com> <4AE72001.5040102@earthlink.net> In-Reply-To: <4AE72001.5040102@earthlink.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 17:04:52 -0000 Charles E. Perkins a écrit : > > Hello Alex, > > Alexandru Petrescu wrote: >> I agree with Carlos. >> >> Alex > > Then you too are denying the fact that we have > already done what needs to be done in many > different ways. It would be nice for the practitioners > who have done it, to be able to standardize on > one approach. Does what you have done involve link-layer addresses or not? Does it allow them to exist or not? Alex > > Regards, > Charlie P. > > > From charles.perkins@earthlink.net Tue Oct 27 10:06:05 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87C333A6A48 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.836 X-Spam-Level: X-Spam-Status: No, score=-1.836 tagged_above=-999 required=5 tests=[AWL=0.144, 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 BY2cglUg6JM1 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:06:04 -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 161AA3A68E8 for <autoconf@ietf.org>; Tue, 27 Oct 2009 10:06:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=KvjkrFBjjBxqFfdai/syq1YrqS/LdjUSCbShQLRKs9KNBmHiPKerFFzk3z68VvWo; 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.16]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N2pUu-0003Em-CU; Tue, 27 Oct 2009 13:06:16 -0400 Message-ID: <4AE72889.9010102@earthlink.net> Date: Tue, 27 Oct 2009 10:06:17 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <0E0F03A1-EC0C-4FF9-AB17-DB2029F7363E@gmail.com> <1256492329.4766.39.camel@acorde.it.uc3m.es> <E91718ED-92C0-451D-9EEE-52DA64DC21C7@gmail.com> <4AE6C1B7.8010400@gmail.com> <4AE71EFF.8020609@earthlink.net> <4AE726D8.1000705@gmail.com> In-Reply-To: <4AE726D8.1000705@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52c44ef1f2cf7a6117cfb59fd911e74d09350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] best-effort, real politics and more X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 17:06:05 -0000 Hello Alex, Alexandru Petrescu wrote: > >>> >>> >>> AUTOCONF can't do any better than DAD and DNA and DHCP and MAC did >>> with respect to uniqueness. >> >> If one cares about scalability in the face of mobility and wireless >> connectivity, then yes we can, and people have. > > Too generic Charles, too generic to my reading. And ingeniously takes > advantage of recent real politics verbiage - yes you can. I didn't even notice. But IP is pretty generic. I think that's a feature. > > > Let's talk protocols Check. > and problems of protocols Check. > and link layers with names on them. Strong disagreement. > > >>> Especially since AUTOCONF is incapable of describing what's wrong >>> with DAD, oDAD, DNA, DHCP and MAC. >> >> Perhaps you are incapable of digesting the descriptions that have >> been offered many times. > > Let's talk again the ABC problem. Are these the three nodes? I don't remember which problem it is. Regards, Charlie P. From charles.perkins@earthlink.net Tue Oct 27 10:08:08 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 663643A690D for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.841 X-Spam-Level: X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[AWL=0.139, 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 jZ1yjnqYsKN5 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:08:07 -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 A40203A6823 for <autoconf@ietf.org>; Tue, 27 Oct 2009 10:08:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=rQVDXrV+PRgKcYZZ2aXu7iZkbq3Jomkg343EM0fP3onzhSPS8kLHjwxZumsgpDwI; 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.16]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N2pWt-0002Xy-Ct; Tue, 27 Oct 2009 13:08:19 -0400 Message-ID: <4AE72902.9010104@earthlink.net> Date: Tue, 27 Oct 2009 10:08:18 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <125638 9726.5286.65.camel@ac orde.it.uc3m.es> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <1256634091.5090.4.camel@acorde.it.uc3m.es> <4AE6C4C7.5000803@gmail.com> <4AE72001.5040102@earthlink.net> <4AE7283F.9040600@gmail.com> In-Reply-To: <4AE7283F.9040600@gmail.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52a6b4dcf3fb0061352f7568c1f9128385350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 17:08:08 -0000 Hello Alex, Alexandru Petrescu wrote: > Charles E. Perkins a écrit : >> >> Hello Alex, >> >> Alexandru Petrescu wrote: >>> I agree with Carlos. >>> >>> Alex >> >> Then you too are denying the fact that we have >> already done what needs to be done in many >> different ways. It would be nice for the practitioners >> who have done it, to be able to standardize on >> one approach. > > Does what you have done involve link-layer addresses or not? Does it > allow them to exist or not? > It did not involve link-layer addresses. It did not prohibit, encourage, or validate link-layer addresses in any way. Not our problem. We just wanted to achieve a solution for address assignment in ad hoc networks. Regards, Charlie P. From charles.perkins@earthlink.net Tue Oct 27 10:08:41 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 127D73A6A5B for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[AWL=0.135, 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 5GKW-vYOE-T5 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:08:40 -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 67FB03A6A5A for <autoconf@ietf.org>; Tue, 27 Oct 2009 10:08:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=BaVHjD8cePqcvhVLJoz7qOgQgVVU0D+id50peibVj4J+tKbpfAfktqHqT/47ou8D; 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.16]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N2pXS-0006bc-3k; Tue, 27 Oct 2009 13:08:54 -0400 Message-ID: <4AE72925.20006@earthlink.net> Date: Tue, 27 Oct 2009 10:08:53 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <AE72A684-DF66-4E49-A291-06C950893A4A@gmail.com> <4AE6C224.5080109@gmail.com> <25c114b90910270303v1c928b77y7ae88895c1e8778f@mail.gmail.com> <4AE6C7A4.8080506@gmail.com> <4AE6CF4E.7000000@gmail.com> In-Reply-To: <4AE6CF4E.7000000@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f521f1fcbfb59b5f95e3f04da218b019a34350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] disagreement on the DT document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 17:08:41 -0000 Hello Alex, Alexandru Petrescu wrote: > Moreover, I disagree with this part of the document: > >> routers which connect to links with undetermined connectivity >> properties. > > These links simply don't exist. Perhaps you could offer a constructive improvement? Perhaps you'd prefer: "routers which connect via links with connectivity properties not conducive to supporting link-local addresses"...? Regards, Charlie P. From alexandru.petrescu@gmail.com Tue Oct 27 10:10:53 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 361063A690D for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.056 X-Spam-Level: X-Spam-Status: No, score=-2.056 tagged_above=-999 required=5 tests=[AWL=0.193, 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 Y1Gmc70GE1JH for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:10:52 -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 3B9103A6407 for <autoconf@ietf.org>; Tue, 27 Oct 2009 10:10:52 -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 n9RHB20j004015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 18:11:02 +0100 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 n9RHB2au022441; Tue, 27 Oct 2009 18:11:02 +0100 (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 n9RHB2ZF029899; Tue, 27 Oct 2009 18:11:02 +0100 Message-ID: <4AE729A6.3080607@gmail.com> Date: Tue, 27 Oct 2009 18:11:02 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" <charles.perkins@earthlink.net> References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <AE72A684-DF66-4E49-A291-06C950893A4A@gmail.com> <4AE6C224.5080109@gmail.com> <25c114b90910270303v1c928b77y7ae88895c1e8778f@mail.gmail.com> <4AE6C7A4.8080506@gmail.com> <4AE720AB.609@earthlink.net> In-Reply-To: <4AE720AB.609@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] disagreement on the DT document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 17:10:53 -0000 Charles E. Perkins a écrit : > Hello Alex, > > > Alexandru Petrescu wrote: >> Ulrich, >> >> From a procedural standpoint, two things: >> >> The DT draft has very little inherent validity as a WG item - it was >> forced on the WG without asking the WG. > > Perhaps we should verify consensus. Yes - let's start by removing it from the group and making it back a DT document - and only then verify consensus. Otherwise it makes no sense to make a consensus call on a draft already a WG item. >> Additionally, it does not do some things that the Charter asks it to >> do: it doesn't describe how the addressing model impacts or not the >> non-MANET nodes connecting to MANET nodes. > > By my reading it does not have to do this. The solutions have to > obey that charter requirement. I doubt that. The Charter was designed specifically for the addressing model draft only. The current Charter is only about the addressing model draft. Alex PS: let me paste its relevant 2nd half below for everybody else's quick view: http://www.ietf.org/dyn/wg/charter/autoconf-charter.html [...] > The main purpose of the AUTOCONF WG is to describe the addressing model > for ad hoc networks and how nodes in these networks configure their > addresses. It is required that such models do not cause problems for ad > hoc-unaware parts of the system, such as standard applications running > on an ad hoc node or regular Internet nodes attached to the ad hoc > nodes. This group's effort may include the development of new protocol > mechanisms, should the existing IP autoconfiguration mechanisms be found > inadequate. However, the first task of the working group is to describe > one practical addressing model for ad hoc networks. > > Once this sole work item is completed, the group can be rechartered to > work on additional issues. From charles.perkins@earthlink.net Tue Oct 27 10:18:59 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D63828C0EC for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:18:59 -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 JKAnoixV9Teb for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:18:58 -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 4C3C53A6A6A for <autoconf@ietf.org>; Tue, 27 Oct 2009 10:18:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=HX5IIggZX1DwclyWGFkPKCVsCC7dyKhvCUNw6XbiDhFTUhATAqipOt4Cmun4J49X; 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.16]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N2phN-0003dT-1x; Tue, 27 Oct 2009 13:19:09 -0400 Message-ID: <4AE72B8C.5020705@earthlink.net> Date: Tue, 27 Oct 2009 10:19:08 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.com> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <25c114b90910270135i788a8a45oc0ac5cf87e2ae52@mail.gmail.com> <4AE6C4B5.1050309@gmail.com> <4AE71FB3.9020702@earthlink.net> <4AE7280A.30508@gmail.com> In-Reply-To: <4AE7280A.30508@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f523fa5c72ed9afb6e416cf6494e22cbc84350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 17:18:59 -0000 Hello Alex, Alexandru Petrescu wrote: > >>> >>> Please say how your links act. >>> >>> Until you don't say so - it's all a dark area. >>> >> Emmanuel and I wrote an Internet Draft describing the >> properties of these links. >> >> You read it. >> >> Shall we post it again? > > Sorry which draft? > > I will read it again if you need my feedback. > http://www.potaroo.net/ietf/all-ids/draft-baccelli-multi-hop-wireless-communication-02.txt Feedback is always appreciated, but the main point is that I believe you already read this draft, and I think it answers all of your questions about the kinds of wireless network interfaces under consideration for [autoconf]. Regards, Charlie P. From alexandru.petrescu@gmail.com Tue Oct 27 10:24:01 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 B909328C112 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.058 X-Spam-Level: X-Spam-Status: No, score=-2.058 tagged_above=-999 required=5 tests=[AWL=0.191, 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 wnCG8uifkp+p for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:24:01 -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 84D8D28C10A for <autoconf@ietf.org>; Tue, 27 Oct 2009 10:23:59 -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 n9RHO9g3030871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 18:24:09 +0100 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 n9RHO9N9024818; Tue, 27 Oct 2009 18:24:09 +0100 (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 n9RHO8R2001047; Tue, 27 Oct 2009 18:24:09 +0100 Message-ID: <4AE72CB9.9040606@gmail.com> Date: Tue, 27 Oct 2009 18:24:09 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" <charles.perkins@earthlink.net> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.com> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <25c114b90910270135i788a8a45oc0ac5cf87e2ae52@mail.gmail.com> <4AE6C4B5.1050309@gmail.com> <25c114b90910270324y3599756bhdebe9502f6026b93@mail.gmail.com> <4AE6CD55.1040205@gmail.com> <4AE7219A.4010601@earthlink.net> In-Reply-To: <4AE7219A.4010601@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 17:24:01 -0000 Charles E. Perkins a écrit : > > Hello Alex, > > Alexandru Petrescu wrote: >> >> Ulrich, please first, do not point me to wikipedia, I refuse to be >> pointed to wikipedia. I do use it often but I refuse to be pointed to >> it. > > Why? > >> >> It's like you tell me to go read thousands of pages that you haven't >> read either - why do you do so? > > What if someone reads the article and then finds > it to be potentially valuable for you? Why not > offer a readily available source of information? That's easy. The common tendency when pointing to so many URLs is to google the keywords and then paste large body of evidence. Very often that evidence is not read by the posters themselves. For example (and no offence intended) Ulrich pointed to LTE, among others, whereas we're almost sure LTE will use link-local addresses. Pointing someone to google search results as evidence of something is alos wrong because the single negative thing about google is that it can't offer proofs of non-existence. I.e. people wrongly believe that because something is not on google then it does not exist - and that's people's wrongly using google fault. Same with wikipedia - if something is _not_ in wikipedia people tend to think it does not exist or, at least, is not important enough. This means that because wikipedia doesn't have an article saying "Many protocols use LLs" then people tend to think I am wrong. Well, what if I write such a wikipedia article then? Should I spend cycles on that or on IETF? >> Which link layer are _you_ particularly concerned with and whose >> behaviour you'd like to see accepted in AUTOCONF? How does this link >> layer behave with respect to IPv6? > > This is the IETF. Link-agnostic sorts of folks. This is IETF - IPv6-over-foo sorts of folks. >> I am saying this after having experimented with several wireless link >> layers: wavelan, wifi, bluetooth, irda, umts, 3g+, gsm, SLIP 2400bps, >> 802.16MAC, USB - to name just a few. My goal was all the time to see >> how IPv6 runs on it. I can tell you that I was not deceived and each >> time there was a solution, always involving link-local addresses. > > With three nodes? Well, more. If I enumerated that many links there were at least that many nodes. >> What do you think? What is that link-layer which does not support IPv6 >> link-layer addresses? >> >> Is it an imaginary link layer? > > It's not the link-layer that doesn't support IPv6 addresses. > > It's the link layer that doesn't support guaranteed layer-2 > unique addresses. Ok! I know one, it's USB. USB MAC addresses are "unique" among USBers but may clash with IEEE MAC addresses. That doesn't mean DAD won't spot them. > It's the mobility that makes this into a threat against > link-layer address uniqueness. > > Which, honestly, I think you could figure out directly > except that it's so much fun to argue. I had a point to make, not only fun to argue. Alex From alexandru.petrescu@gmail.com Tue Oct 27 10:24:49 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 1B6F63A6836 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.059 X-Spam-Level: X-Spam-Status: No, score=-2.059 tagged_above=-999 required=5 tests=[AWL=0.190, 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 bW5uR-D7gu52 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:24:48 -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 2492D3A6823 for <autoconf@ietf.org>; Tue, 27 Oct 2009 10:24:47 -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 n9RHOvU4008923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 18:24:57 +0100 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 n9RHOuk2025138; Tue, 27 Oct 2009 18:24:56 +0100 (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 n9RHOuqq001359; Tue, 27 Oct 2009 18:24:56 +0100 Message-ID: <4AE72CE8.7010804@gmail.com> Date: Tue, 27 Oct 2009 18:24:56 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: sratliff <sratliff@cisco.com> References: <C70C9B7D.177F%sratliff@cisco.com> In-Reply-To: <C70C9B7D.177F%sratliff@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 17:24:49 -0000 sratliff a écrit : > Alex, > > You miss the point. There are other, non-IEEE interfaces that we *can* > discuss. Ulrich has given you a (partial) list. What I'm trying to tell you > is, if we consider those interfaces, and design accordingly, my proprietary > interfaces should work. > > So there are things we can openly discuss. I just don't see a lot of > progress when we discuss them. LEt's enumerate them. If we enumerate them you'll see a large number of them do use LLs. Alex > > Regards, > Stan > > > On 10/27/09 11:16 AM, "Alexandru Petrescu" <alexandru.petrescu@gmail.com> > wrote: > >> sratliff a écrit : >>> Alex, >>> >>> <sarcasm>I was told not to pay attention to this discussion, no?</sarcasm> >>> >>> Ulrich is correct. The interfaces are proprietary. I¹m not going to go >>> into a discussion about them in this forum. Ulrich has supplied pointers >>> to well-known interface types that don¹t adhere to IEEE specs. >> Stan - I am sorry, I can not help to run IPv6 on proprietary interfaces >> about which you don't want to talk. Please de-proprietarize them somehow. >> >> It makes no sense for you to say that the DT proposal works with your >> proprietary interface as long as you can't get feedback from the WG >> about it. >> >> If it works within your env - ok, good luck. >> >> But if you bring it here - then please talk about it. >> >> It may very well be that your env does use IPv6 link-local addresses too >> (as some OLSR implementations do use them too). >> >> Alex >> >> > > From charles.perkins@earthlink.net Tue Oct 27 10:25:04 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9940828C0D6 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.126, 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 8L4WPAj3eH4V for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:25:03 -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 ACB863A6A4F for <autoconf@ietf.org>; Tue, 27 Oct 2009 10:25:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=RowlcQKHUCw+MeCmXqILX48wLs8xt9QItFVvAwwYVIgrfE+EyQK04xMMx76zpaS/; 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.16]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N2pnI-0006FY-5b; Tue, 27 Oct 2009 13:25:16 -0400 Message-ID: <4AE72CFC.20103@earthlink.net> Date: Tue, 27 Oct 2009 10:25:16 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <AE72A684-DF66-4E49-A291-06C950893A4A@gmail.com> <4AE6C224.5080109@gmail.com> <25c114b90910270303v1c928b77y7ae88895c1e8778f@mail.gmail.com> <4AE6C7A4.8080506@gmail.com> <4AE720AB.609@earthlink.net> <4AE729A6.3080607@gmail.com> In-Reply-To: <4AE729A6.3080607@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52268d7d2ffc5133fa524b80e9af52cc00350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] disagreement on the DT document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 17:25:04 -0000 Hello Alex, Alexandru Petrescu wrote: > >> >> Perhaps we should verify consensus. > > Yes - let's start by removing it from the group and making it back a > DT document - and only then verify consensus. Otherwise it makes no > sense to make a consensus call on a draft already a WG item. What does it mean to remove it from the group? And, I think the design team has completed its task. > >>> Additionally, it does not do some things that the Charter asks it to >>> do: it doesn't describe how the addressing model impacts or not the >>> non-MANET nodes connecting to MANET nodes. >> >> By my reading it does not have to do this. The solutions have to >> obey that charter requirement. > > I doubt that. The Charter was designed specifically for the > addressing model draft only. > > The current Charter is only about the addressing model draft. > > Alex > PS: let me paste its relevant 2nd half below for everybody else's > quick view: > > http://www.ietf.org/dyn/wg/charter/autoconf-charter.html > [...] >> The main purpose of the AUTOCONF WG is to describe the addressing model >> for ad hoc networks and how nodes in these networks configure their >> addresses. It is required that such models do not cause problems for ad >> hoc-unaware parts of the system, such as standard applications running >> on an ad hoc node or regular Internet nodes attached to the ad hoc >> nodes. This group's effort may include the development of new protocol >> mechanisms, should the existing IP autoconfiguration mechanisms be found >> inadequate. However, the first task of the working group is to describe >> one practical addressing model for ad hoc networks. >> >> Once this sole work item is completed, the group can be rechartered to >> work on additional issues. > The solutions that I am familiar with would fit within the solution space defined by the DT addressing model draft, and they do allow connectivity to non-MANET nodes within the MANET as suggested. So this is a non-issue. Regards, Charlie P. From thomas@thomasclausen.org Tue Oct 27 10:26:10 2009 Return-Path: <thomas@thomasclausen.org> 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 AB87928C0D6 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 c9jSZMpdGOqR for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:26:09 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id D24F53A6823 for <autoconf@ietf.org>; Tue, 27 Oct 2009 10:26:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 9C71532317B4; Tue, 27 Oct 2009 10:26:24 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 706C932317B5; Tue, 27 Oct 2009 10:26:23 -0700 (PDT) Message-Id: <13A8137D-CBE8-4F62-AC69-E40F4FF11167@thomasclausen.org> From: Thomas Heide Clausen <thomas@thomasclausen.org> To: "Charles E. Perkins" <charles.perkins@earthlink.net> In-Reply-To: <4AE720AB.609@earthlink.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 27 Oct 2009 18:26:21 +0100 References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <AE72A684-DF66-4E49-A291-06C950893A4A@gmail.com> <4AE6C224.5080109@gmail.com> <25c114b90910270303v1c928b77y7ae88895c1e8778f@mail.gmail.com> <4AE6C7A4.8080506@gmail.com> <4AE720AB.609@earthlink.net> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] disagreement on the DT document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 17:26:10 -0000 On Oct 27, 2009, at 5:32 PM, Charles E. Perkins wrote: > Hello Alex, > > > Alexandru Petrescu wrote: >> Ulrich, >> >> From a procedural standpoint, two things: >> >> The DT draft has very little inherent validity as a WG item - it >> was forced on the WG without asking the WG. > > Perhaps we should verify consensus. > >> >> >> Additionally, it does not do some things that the Charter asks it >> to do: it doesn't describe how the addressing model impacts or not >> the non-MANET nodes connecting to MANET nodes. > > By my reading it does not have to do this. The solutions have to > obey that charter requirement. > Dear Charlie, I think that what your correspondent doesn't fully get is, that MANET describes "what goes on between routers", not "what goes on between hosts and routers", and so therefore doesn't get what the "MANET aware" and "non-MANET aware" parts are. In part, I think that this is due to general confusion as to "what is a router": there are, at least, three diverging views on that, depending on whom you ask, and I think that if one focuses narrowly on one of these views one won't capture what it is we're talking about when we say "MANET aware" and "non-MANET aware". Thomas >> Seriously, here are the draft statements I disagree with: >> >> In the section 4 IP Subnet Prefix COnfiguration: >> [...] >>> o no two such interfaces in the network should be configured with >>> the same subnet prefix. >> [...] >> >> This ignores the presence of LL prefix fe80::/10. > > For good reason! > >> >> In section 6.1 IPv4 model: >>> Note that the use of IPv4 link-local addresses [RFC3927] in this >>> context should be discouraged for most applications, >> >> This ignores the existence and widespread use of applications using >> IPv4 LLs behind NAT. > > Maybe they won't work in an ad hoc network. > >> >> In section 6.2 IPv6 Model: >>> o A subnet prefix configured on this interface should be of >>> length >>> /128. >> >> This is completely out of scope, because /128 prefixes make no >> sense in terms of subnet and multicast. > > I don't have a problem with that. > >> >>> Therefore MANET autoconfiguration solutions should be encouraged >>> to >>> primarily focus on configuring IP addresses that are not IPv6 >>> link- >>> local. >> >> This says what should not be done, but it does not say what should >> be done. > > It says that you should pick long prefixes unless you > have a reason to make less restrictive choices. > > Therefore your statement is false. > > > Regards, > Charlie P. > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From alexandru.petrescu@gmail.com Tue Oct 27 10:29:48 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 501EA3A6778 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.061 X-Spam-Level: X-Spam-Status: No, score=-2.061 tagged_above=-999 required=5 tests=[AWL=0.188, 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 11A8JE1pDemQ for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:29:47 -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 6A8193A685D for <autoconf@ietf.org>; Tue, 27 Oct 2009 10:29:43 -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 n9RHTs7V001893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 18:29:54 +0100 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 n9RHTrgV027136; Tue, 27 Oct 2009 18:29:53 +0100 (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 n9RHTr4P003066; Tue, 27 Oct 2009 18:29:53 +0100 Message-ID: <4AE72E11.60600@gmail.com> Date: Tue, 27 Oct 2009 18:29:53 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" <charles.perkins@earthlink.net> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.com> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <25c114b90910270135i788a8a45oc0ac5cf87e2ae52@mail.gmail.com> <4AE6C4B5.1050309@gmail.com> <25c114b90910270324y3599756bhdebe9502f6026b93@mail.gmail.com> <4AE6CD55.1040205@gmail.com> <25c114b90910270352r7be3999ena54848beb1cf9472@mail.gmail.com> <4AE6D5C3.8080501@gmail.com> <25c114b90910270528t238703afkdf34873a08539954@mail.gmail.com> <4AE6F630.7000606@gmail.com> <4AE72598.2050804@earthlink.net> In-Reply-To: <4AE72598.2050804@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] IP over "anything" X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 17:29:48 -0000 Charles E. Perkins a écrit : > > Hello Alex, > > > Alexandru Petrescu wrote: >> Ulrich, >> >> There is a high risk to work on something that we don't what is. > > You too are denying the fact that we have > already done what needs to be done in many > different ways. It would be nice for the practitioners > who have done it, to be able to standardize on > one approach. Err... go ahead, I won't be part of it. Started this way there's little incentive to look into it. >> Blindly hiding behind "IP over anything" without saying what is, and >> ignoring the so many IP-over-foo RFC documents - are indicators for this. > > Blindly assuming MAC-layer uniqueness is an indication > of a bad fit for the [autoconf] working group, I think. Right. Let's say I assume DAD could help detecting duplicates. >> Also, there was a zeroconf WG, "to enable networking in the absence of >> configuration and administration". Doesn't that sound MANETish >> enough. Well it gave the IPv4 LLs RFC. > I was there. It was maximally non-MANET. In fact, it was a single > extent of Ethernet. > > That's not a MANET. At least it has that "adhoc non-planned" nature in it, by saying "absence of conf and admin". > And it was terribly political. Ohh... well maybe that isn't a difference. Hmmm... politics. Yes you can. Alex > > Regards, > Charlie P. > > From alexandru.petrescu@gmail.com Tue Oct 27 10:32:27 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 2B9EC3A67F3 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[AWL=0.186, 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 v2f-9BFDJnLf for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:32:26 -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 2036E3A6778 for <autoconf@ietf.org>; Tue, 27 Oct 2009 10:32:25 -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 n9RHWb7l012341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 18:32:37 +0100 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 n9RHWbDn027427; Tue, 27 Oct 2009 18:32:37 +0100 (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 n9RHWafX003596; Tue, 27 Oct 2009 18:32:36 +0100 Message-ID: <4AE72EB4.6020805@gmail.com> Date: Tue, 27 Oct 2009 18:32:36 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" <charles.perkins@earthlink.net> References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <0E0F03A1-EC0C-4FF9-AB17-DB2029F7363E@gmail.com> <1256492329.4766.39.camel@acorde.it.uc3m.es> <E91718ED-92C0-451D-9EEE-52DA64DC21C7@gmail.com> <4AE6C1B7.8010400@gmail.com> <4AE71EFF.8020609@earthlink.net> <4AE726D8.1000705@gmail.com> <4AE72889.9010102@earthlink.net> In-Reply-To: <4AE72889.9010102@earthlink.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] best-effort, real politics and more X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 17:32:27 -0000 Charles E. Perkins a écrit : > > Hello Alex, > > Alexandru Petrescu wrote: >> >>>> >>>> >>>> AUTOCONF can't do any better than DAD and DNA and DHCP and MAC did >>>> with respect to uniqueness. >>> >>> If one cares about scalability in the face of mobility and wireless >>> connectivity, then yes we can, and people have. >> >> Too generic Charles, too generic to my reading. And ingeniously takes >> advantage of recent real politics verbiage - yes you can. > > I didn't even notice. > > But IP is pretty generic. I think that's a feature. > >> >> >> Let's talk protocols > Check. > >> and problems of protocols > > Check. > >> and link layers with names on them. > > Strong disagreement. > >> >> >>>> Especially since AUTOCONF is incapable of describing what's wrong >>>> with DAD, oDAD, DNA, DHCP and MAC. >>> >>> Perhaps you are incapable of digesting the descriptions that have >>> been offered many times. >> >> Let's talk again the ABC problem. > > Are these the three nodes? > > I don't remember which problem it is. The problem was described like this: three nodes A-B-C each having one wireless interface. Because A and C can't hear each other then DAD cant detect duplicates. Worse, duplicates are likely to appear because MAC IEEE does not guarantee uniqueness across non-IEEE. That was the problem described. Alex > > Regards, > Charlie P. > > From charles.perkins@earthlink.net Tue Oct 27 10:34:20 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9129328C11C for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:34:20 -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 C3DumQIhSlsP for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:34:19 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 6C4FA3A6778 for <autoconf@ietf.org>; Tue, 27 Oct 2009 10:34:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=WhVPbYDIm3FQ1xStTMwWEIEPhANfqjmEa/7g18ajOFYg27Yg2Rr19aKPcdc1Yuhv; 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.16]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N2pwF-0003tJ-UF; Tue, 27 Oct 2009 13:34:32 -0400 Message-ID: <4AE72F27.5040603@earthlink.net> Date: Tue, 27 Oct 2009 10:34:31 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.com> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <25c114b90910270135i788a8a45oc0ac5cf87e2ae52@mail.gmail.com> <4AE6C4B5.1050309@gmail.com> <25c114b90910270324y3599756bhdebe9502f6026b93@mail.gmail.com> <4AE6CD55.1040205@gmail.com> <4AE7219A.4010601@earthlink.net> <4AE72CB9.9040606@gmail.com> In-Reply-To: <4AE72CB9.9040606@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f525690a054fb14d9af2568833db73212f3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 17:34:20 -0000 Hello Alex, Alexandru Petrescu wrote: > >> >>> >>> It's like you tell me to go read thousands of pages that you haven't >>> read either - why do you do so? >> >> What if someone reads the article and then finds >> it to be potentially valuable for you? Why not >> offer a readily available source of information? > > That's easy. > > The common tendency when pointing to so many URLs is to google the > keywords and then paste large body of evidence. Very often that > evidence is not read by the posters themselves. For example (and no > offence intended) Ulrich pointed to LTE, among others, whereas we're > almost sure LTE will use link-local addresses. It uses such addresses only after an extended negotiation that already insures uniqueness, and anyway all such nodes are equipped with guaranteed unique sub-IP layer addresses. > > I.e. people wrongly believe that because something is not on google > then it does not exist - and that's people's wrongly using google > fault. Same with wikipedia - if something is _not_ in wikipedia people > tend to think it does not exist or, at least, is not important enough. This statement may be true for some people, but I doubt it is true for Ulrich -- or, indeed, you, or me, or Teco, or Carlos, or anyone else in this discussion. > > This means that because wikipedia doesn't have an article saying "Many > protocols use LLs" then people tend to think I am wrong. Sorry, Alex, this is purely straw-man argumentation. > > Well, what if I write such a wikipedia article then? Should I spend > cycles on that or on IETF? It would be more productive than this recent discussion. > >>> Which link layer are _you_ particularly concerned with and whose >>> behaviour you'd like to see accepted in AUTOCONF? How does this link >>> layer behave with respect to IPv6? >> >> This is the IETF. Link-agnostic sorts of folks. > > This is IETF - IPv6-over-foo sorts of folks. You are missing that _first_ we specified IPv6 to run over layer-2 without specifying very many particular layer-2 characteristics. Then the IPv6-over-foo documents laid out the necessary techniques for adaptation. But I am pretty sure you knew that, and only make the remark as a clever sound-bite trying to extend the pointless argumentation. > >>> I am saying this after having experimented with several wireless >>> link layers: wavelan, wifi, bluetooth, irda, umts, 3g+, gsm, SLIP >>> 2400bps, 802.16MAC, USB - to name just a few. My goal was all the >>> time to see how IPv6 runs on it. I can tell you that I was not >>> deceived and each time there was a solution, always involving >>> link-local addresses. >> >> With three nodes? > > Well, more. If I enumerated that many links there were at least that > many nodes. Links != nodes. > >>> What do you think? What is that link-layer which does not support IPv6 >>> link-layer addresses? >>> >>> Is it an imaginary link layer? >> >> It's not the link-layer that doesn't support IPv6 addresses. >> >> It's the link layer that doesn't support guaranteed layer-2 >> unique addresses. > > Ok! I know one, it's USB. USB MAC addresses are "unique" among > USBers but may clash with IEEE MAC addresses. Usually I at least understand the context for pointless argumentation but now I have lost even that meager thread to what you might have in mind. > > That doesn't mean DAD won't spot them. Nobody ever claimed that DAD was incapable of spotting address conflicts. > >> It's the mobility that makes this into a threat against >> link-layer address uniqueness. >> >> Which, honestly, I think you could figure out directly >> except that it's so much fun to argue. > > I had a point to make, not only fun to argue. > > I must have missed that. Regards, Charlie P. From alexandru.petrescu@gmail.com Tue Oct 27 10:35:32 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 140AA3A683E for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=0.184, 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 ePQ7cImZZCHA for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:35: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 2ABDB3A6831 for <autoconf@ietf.org>; Tue, 27 Oct 2009 10:35:31 -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 n9RHZT6E005159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 18:35:29 +0100 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 n9RHZSr4027707; Tue, 27 Oct 2009 18:35:28 +0100 (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 n9RHZSGj013271; Tue, 27 Oct 2009 18:35:28 +0100 Message-ID: <4AE72F60.50006@gmail.com> Date: Tue, 27 Oct 2009 18:35:28 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" <charles.perkins@earthlink.net> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <125638 9726.5286.65.camel@ac orde.it.uc3m.es> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <1256634091.5090.4.camel@acorde.it.uc3m.es> <4AE6C4C7.5000803@gmail.com> <4AE72001.5040102@earthlink.net> <4AE7283F.9040600@gmail.com> <4AE72902.9010104@earthlink.net> In-Reply-To: <4AE72902.9010104@earthlink.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 17:35:32 -0000 Charles E. Perkins a écrit : > > Hello Alex, > > Alexandru Petrescu wrote: >> Charles E. Perkins a écrit : >>> >>> Hello Alex, >>> >>> Alexandru Petrescu wrote: >>>> I agree with Carlos. >>>> >>>> Alex >>> >>> Then you too are denying the fact that we have >>> already done what needs to be done in many >>> different ways. It would be nice for the practitioners >>> who have done it, to be able to standardize on >>> one approach. >> >> Does what you have done involve link-layer addresses or not? Does it >> allow them to exist or not? >> > > It did not involve link-layer addresses. It did not prohibit, > encourage, or validate link-layer addresses in any way. SO your solution does not have anything agains LLs. So why go discourage them in the addressing model draft? Why even talking about them in the draft? > Not our problem. We just wanted to achieve a solution > for address assignment in ad hoc networks. I have to read that solution now. Where is it? Alex > > Regards, > Charlie P. > > From alexandru.petrescu@gmail.com Tue Oct 27 10:37:34 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 E95163A6A60 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=0.183, 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 agjC7NB3neqS for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:37:34 -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 F3A8F3A6A64 for <autoconf@ietf.org>; Tue, 27 Oct 2009 10:37:33 -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 n9RHbjGU028483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 18:37:46 +0100 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 n9RHbjrm027977; Tue, 27 Oct 2009 18:37:45 +0100 (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 n9RHbjoZ013696; Tue, 27 Oct 2009 18:37:45 +0100 Message-ID: <4AE72FE9.5070104@gmail.com> Date: Tue, 27 Oct 2009 18:37:45 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" <charles.perkins@earthlink.net> References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <AE72A684-DF66-4E49-A291-06C950893A4A@gmail.com> <4AE6C224.5080109@gmail.com> <25c114b90910270303v1c928b77y7ae88895c1e8778f@mail.gmail.com> <4AE6C7A4.8080506@gmail.com> <4AE6CF4E.7000000@gmail.com> <4AE72925.20006@earthlink.net> In-Reply-To: <4AE72925.20006@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] disagreement on the DT document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 17:37:35 -0000 Charles E. Perkins a écrit : > > Hello Alex, > > Alexandru Petrescu wrote: >> Moreover, I disagree with this part of the document: >> >>> routers which connect to links with undetermined connectivity >>> properties. >> >> These links simply don't exist. > > Perhaps you could offer a constructive improvement? > > Perhaps you'd prefer: > "routers which connect via links with connectivity > properties not conducive to supporting link-local > addresses"...? Hmm... sounds better than "undetermined connectivity properties". But, a link-local address is not necessarily derived from the link-layer connectivity properties. It could be fe80::1 - would you agree with those LL addresses not derived from the link-layer properties? Alex > > > Regards, > Charlie P. > > From charles.perkins@earthlink.net Tue Oct 27 10:39:13 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 097AA3A6A64 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.861 X-Spam-Level: X-Spam-Status: No, score=-1.861 tagged_above=-999 required=5 tests=[AWL=0.119, 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 yt0-Tev2kdUp for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:39:12 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 30B3D3A6A60 for <autoconf@ietf.org>; Tue, 27 Oct 2009 10:39:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=D+VLkpcuAtWJuUMIlAqTt3F7uqp0zLunXTRbf6EmJlzyvyZIePML0FDOCHcts5ZD; 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.16]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N2q10-000200-HB; Tue, 27 Oct 2009 13:39:26 -0400 Message-ID: <4AE7304E.7010000@earthlink.net> Date: Tue, 27 Oct 2009 10:39:26 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <0E0F03A1-EC0C-4FF9-AB17-DB2029F7363E@gmail.com> <1256492329.4766.39.camel@acorde.it.uc3m.es> <E91718ED-92C0-451D-9EEE-52DA64DC21C7@gmail.com> <4AE6C1B7.8010400@gmail.com> <4AE71EFF.8020609@earthlink.net> <4AE726D8.1000705@gmail.com> <4AE72889.9010102@earthlink.net> <4AE72EB4.6020805@gmail.com> In-Reply-To: <4AE72EB4.6020805@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52097402f7ab7d1db75bee334f4975a923350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] best-effort, real politics and more X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 17:39:13 -0000 Hello Alex, Alexandru Petrescu wrote: >>>> >>>> Perhaps you are incapable of digesting the descriptions that have >>>> been offered many times. >>> >>> Let's talk again the ABC problem. >> >> Are these the three nodes? >> >> I don't remember which problem it is. > > The problem was described like this: three nodes A-B-C each having one > wireless interface. Because A and C can't hear each other then DAD > cant detect duplicates. Worse, duplicates are likely to appear > because MAC IEEE does not guarantee uniqueness across non-IEEE. > > That was the problem described. > This is discussed in the previously cited document: http://www.potaroo.net/ietf/all-ids/draft-baccelli-multi-hop-wireless-communication-02.txt Which I am almost sure you had already read. Regards, Charlie P. From alexandru.petrescu@gmail.com Tue Oct 27 10:41:25 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 747A33A6836 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.068 X-Spam-Level: X-Spam-Status: No, score=-2.068 tagged_above=-999 required=5 tests=[AWL=0.181, 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 poLnZdZh4Zgz for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:41:24 -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 C969B3A67F3 for <autoconf@ietf.org>; Tue, 27 Oct 2009 10:41:23 -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 n9RHfZIP032026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 18:41:35 +0100 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 n9RHfYln028333; Tue, 27 Oct 2009 18:41:34 +0100 (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 n9RHfY8e014382; Tue, 27 Oct 2009 18:41:34 +0100 Message-ID: <4AE730CE.2050601@gmail.com> Date: Tue, 27 Oct 2009 18:41:34 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" <charles.perkins@earthlink.net> References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <AE72A684-DF66-4E49-A291-06C950893A4A@gmail.com> <4AE6C224.5080109@gmail.com> <25c114b90910270303v1c928b77y7ae88895c1e8778f@mail.gmail.com> <4AE6C7A4.8080506@gmail.com> <4AE720AB.609@earthlink.net> <4AE729A6.3080607@gmail.com> <4AE72CFC.20103@earthlink.net> In-Reply-To: <4AE72CFC.20103@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] disagreement on the DT document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 17:41:25 -0000 Charles E. Perkins a écrit : > > Hello Alex, > > Alexandru Petrescu wrote: >> >>> >>> Perhaps we should verify consensus. >> >> Yes - let's start by removing it from the group and making it back a >> DT document - and only then verify consensus. Otherwise it makes no >> sense to make a consensus call on a draft already a WG item. > > What does it mean to remove it from the group? > And, I think the design team has completed its task. Charles - this is politics - your way of tempting me into believing a consensus could be called on something already adopted. Retire it first and then we talk consensus call, especially in the light of the existence of draft-bernardos. >>>> Additionally, it does not do some things that the Charter asks it to >>>> do: it doesn't describe how the addressing model impacts or not the >>>> non-MANET nodes connecting to MANET nodes. >>> >>> By my reading it does not have to do this. The solutions have to >>> obey that charter requirement. >> >> I doubt that. The Charter was designed specifically for the >> addressing model draft only. >> >> The current Charter is only about the addressing model draft. >> >> Alex >> PS: let me paste its relevant 2nd half below for everybody else's >> quick view: >> >> http://www.ietf.org/dyn/wg/charter/autoconf-charter.html >> [...] >>> The main purpose of the AUTOCONF WG is to describe the addressing model >>> for ad hoc networks and how nodes in these networks configure their >>> addresses. It is required that such models do not cause problems for ad >>> hoc-unaware parts of the system, such as standard applications running >>> on an ad hoc node or regular Internet nodes attached to the ad hoc >>> nodes. This group's effort may include the development of new protocol >>> mechanisms, should the existing IP autoconfiguration mechanisms be found >>> inadequate. However, the first task of the working group is to describe >>> one practical addressing model for ad hoc networks. >>> >>> Once this sole work item is completed, the group can be rechartered to >>> work on additional issues. >> > > > The solutions that I am familiar with would fit within the > solution space defined by the DT addressing model draft, > and they do allow connectivity to non-MANET nodes > within the MANET as suggested. Well that is ok - say so in the draft - that we allow the connectivity of non-MANET nodes to MANET. And this will include the LLs. That will mean that the MANET router does not behave badly when presented with a LL of somebody. Alex > > So this is a non-issue. > > Regards, > Charlie P. > > > From alexandru.petrescu@gmail.com Tue Oct 27 10:43:11 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 35D033A6839 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.07 X-Spam-Level: X-Spam-Status: No, score=-2.07 tagged_above=-999 required=5 tests=[AWL=0.179, 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 HjGXaHiEnUIp for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:43:10 -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 0FAEB3A67F3 for <autoconf@ietf.org>; Tue, 27 Oct 2009 10:43:09 -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 n9RHhLwW001267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 18:43:21 +0100 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 n9RHhLI0028477; Tue, 27 Oct 2009 18:43:21 +0100 (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 n9RHhLUv014735; Tue, 27 Oct 2009 18:43:21 +0100 Message-ID: <4AE73139.7090903@gmail.com> Date: Tue, 27 Oct 2009 18:43:21 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen <thomas@thomasclausen.org> References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <AE72A684-DF66-4E49-A291-06C950893A4A@gmail.com> <4AE6C224.5080109@gmail.com> <25c114b90910270303v1c928b77y7ae88895c1e8778f@mail.gmail.com> <4AE6C7A4.8080506@gmail.com> <4AE720AB.609@earthlink.net> <13A8137D-CBE8-4F62-AC69-E40F4FF11167@thomasclausen.org> In-Reply-To: <13A8137D-CBE8-4F62-AC69-E40F4FF11167@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] disagreement on the DT document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 17:43:11 -0000 Thomas Heide Clausen a écrit : > > On Oct 27, 2009, at 5:32 PM, Charles E. Perkins wrote: > >> Hello Alex, >> >> >> Alexandru Petrescu wrote: >>> Ulrich, >>> >>> From a procedural standpoint, two things: >>> >>> The DT draft has very little inherent validity as a WG item - it was >>> forced on the WG without asking the WG. >> >> Perhaps we should verify consensus. >> >>> >>> >>> Additionally, it does not do some things that the Charter asks it to >>> do: it doesn't describe how the addressing model impacts or not the >>> non-MANET nodes connecting to MANET nodes. >> >> By my reading it does not have to do this. The solutions have to >> obey that charter requirement. >> > > Dear Charlie, > > I think that what your correspondent doesn't fully get is, that MANET > describes "what goes on between routers", not "what goes on between > hosts and routers", and so therefore doesn't get what the "MANET aware" > and "non-MANET aware" parts are. Thomas - you forget that I wrote and implemented text and code precisely about that, i.e. a Router sometimes acting as a Host on its egress interface. About which I had some consensus. I think I know what I'm talking about. Alex > > In part, I think that this is due to general confusion as to "what is a > router": there are, at least, three diverging views on that, depending > on whom you ask, and I think that if one focuses narrowly on one of > these views one won't capture what it is we're talking about when we say > "MANET aware" and "non-MANET aware". > > Thomas > > > >>> Seriously, here are the draft statements I disagree with: >>> >>> In the section 4 IP Subnet Prefix COnfiguration: >>> [...] >>>> o no two such interfaces in the network should be configured with >>>> the same subnet prefix. >>> [...] >>> >>> This ignores the presence of LL prefix fe80::/10. >> >> For good reason! >> >>> >>> In section 6.1 IPv4 model: >>>> Note that the use of IPv4 link-local addresses [RFC3927] in this >>>> context should be discouraged for most applications, >>> >>> This ignores the existence and widespread use of applications using >>> IPv4 LLs behind NAT. >> >> Maybe they won't work in an ad hoc network. >> >>> >>> In section 6.2 IPv6 Model: >>>> o A subnet prefix configured on this interface should be of length >>>> /128. >>> >>> This is completely out of scope, because /128 prefixes make no sense >>> in terms of subnet and multicast. >> >> I don't have a problem with that. >> >>> >>>> Therefore MANET autoconfiguration solutions should be encouraged to >>>> primarily focus on configuring IP addresses that are not IPv6 link- >>>> local. >>> >>> This says what should not be done, but it does not say what should be >>> done. >> >> It says that you should pick long prefixes unless you >> have a reason to make less restrictive choices. >> >> Therefore your statement is false. >> >> >> Regards, >> Charlie P. >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > From charles.perkins@earthlink.net Tue Oct 27 10:47:22 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A13A3A6A46 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:47:22 -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 jeW0AKm8X4gl for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:47:21 -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 89AD33A6877 for <autoconf@ietf.org>; Tue, 27 Oct 2009 10:47:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=oNg52chfaAspOhWYywglZhiXltLo2wgf55HsDiMl2ndlE2jAR6MaBar4EzXYVjKj; 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.16]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N2q8s-0001ln-CB; Tue, 27 Oct 2009 13:47:34 -0400 Message-ID: <4AE73236.6080409@earthlink.net> Date: Tue, 27 Oct 2009 10:47:34 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.com> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <25c114b90910270135i788a8a45oc0ac5cf87e2ae52@mail.gmail.com> <4AE6C4B5.1050309@gmail.com> <25c114b90910270324y3599756bhdebe9502f6026b93@mail.gmail.com> <4AE6CD55.1040205@gmail.com> <25c114b90910270352r7be3999ena54848beb1cf9472@mail.gmail.com> <4AE6D5C3.8080501@gmail.com> <25c114b90910270528t238703afkdf34873a08539954@mail.gmail.com> <4AE6F630.7000606@gmail.com> <4AE72598.2050804@earthlink.net> <4AE72E11.60600@gmail.com> In-Reply-To: <4AE72E11.60600@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f527d4b8695e535de9beb795c17ac8dcaf5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] IP over "anything" X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 17:47:22 -0000 Hello Alex, I think you have very well identified an interesting point. Alexandru Petrescu wrote: > >> >> You too are denying the fact that we have >> already done what needs to be done in many >> different ways. It would be nice for the practitioners >> who have done it, to be able to standardize on >> one approach. > > Err... go ahead, I won't be part of it. > > Started this way there's little incentive to look into it. So let's be clear here. - People built ad hoc wireless networks. - They work with statically assigned addresses. - A method for address autoconfiguration was desired. - Internet Drafts were written for that purpose - A working group was formed to resolve differences in the approaches - An addressing model was required - An addressing model was produced that enabled solutions in the general solution space of the published solutions - You seem to even disavow the validity of considering wireless networks of the sort that is of interest to the original practitioners - You now claim that you won't be part of the solution team. So do you stand in the way of other peoples' progress? > >>> Blindly hiding behind "IP over anything" without saying what is, and >>> ignoring the so many IP-over-foo RFC documents - are indicators for >>> this. >> >> Blindly assuming MAC-layer uniqueness is an indication >> of a bad fit for the [autoconf] working group, I think. > > Right. Let's say I assume DAD could help detecting duplicates. That was never at issue. > >>> Also, there was a zeroconf WG, "to enable networking in the absence >>> of configuration and administration". Doesn't that sound MANETish >>> enough. Well it gave the IPv4 LLs RFC. >> I was there. It was maximally non-MANET. In fact, it was a single >> extent of Ethernet. >> >> That's not a MANET. > > At least it has that "adhoc non-planned" nature in it, by saying > "absence of conf and admin". There are many unplanned events, no doubt. > >> And it was terribly political. Ohh... well maybe that isn't a >> difference. > > Hmmm... politics. Yes you can. You are making fun of me. Regards, Charlie P. From alexandru.petrescu@gmail.com Tue Oct 27 10:52:27 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 823E53A6A46 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.071 X-Spam-Level: X-Spam-Status: No, score=-2.071 tagged_above=-999 required=5 tests=[AWL=0.178, 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 nbT2H4yxxk6y for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:52:26 -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 1C7D23A67F3 for <autoconf@ietf.org>; Tue, 27 Oct 2009 10:52:25 -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 n9RHqN7G020722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 18:52:24 +0100 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 n9RHqN2r029403; Tue, 27 Oct 2009 18:52:23 +0100 (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 n9RHqNlE007476; Tue, 27 Oct 2009 18:52:23 +0100 Message-ID: <4AE73357.70002@gmail.com> Date: Tue, 27 Oct 2009 18:52:23 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" <charles.perkins@earthlink.net> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.com> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <25c114b90910270135i788a8a45oc0ac5cf87e2ae52@mail.gmail.com> <4AE6C4B5.1050309@gmail.com> <25c114b90910270324y3599756bhdebe9502f6026b93@mail.gmail.com> <4AE6CD55.1040205@gmail.com> <4AE7219A.4010601@earthlink.net> <4AE72CB9.9040606@gmail.com> <4AE72F27.5040603@earthlink.net> In-Reply-To: <4AE72F27.5040603@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 17:52:27 -0000 Charles E. Perkins a écrit : > > Hello Alex, > > Alexandru Petrescu wrote: >> >>> >>>> >>>> It's like you tell me to go read thousands of pages that you haven't >>>> read either - why do you do so? >>> >>> What if someone reads the article and then finds >>> it to be potentially valuable for you? Why not >>> offer a readily available source of information? >> >> That's easy. >> >> The common tendency when pointing to so many URLs is to google the >> keywords and then paste large body of evidence. Very often that >> evidence is not read by the posters themselves. For example (and no >> offence intended) Ulrich pointed to LTE, among others, whereas we're >> almost sure LTE will use link-local addresses. > > It uses such addresses only after an extended negotiation > that already insures uniqueness, and anyway all such nodes > are equipped with guaranteed unique sub-IP layer addresses. Ok - but we can't say LTE doesnt use LL addresses, right? In this sense, the redirection to wikipedia looses a bit of sense. (although there are other part sin that redirection which do make sense). >> I.e. people wrongly believe that because something is not on google >> then it does not exist - and that's people's wrongly using google >> fault. Same with wikipedia - if something is _not_ in wikipedia people >> tend to think it does not exist or, at least, is not important enough. > > This statement may be true for some people, but I doubt it is > true for Ulrich -- or, indeed, you, or me, or Teco, or Carlos, > or anyone else in this discussion. Ok this. >> This means that because wikipedia doesn't have an article saying "Many >> protocols use LLs" then people tend to think I am wrong. > > Sorry, Alex, this is purely straw-man argumentation. It's good, so I don't need to do it. I can persuade without going wikipedia. >> Well, what if I write such a wikipedia article then? Should I spend >> cycles on that or on IETF? > > It would be more productive than this recent discussion. All discussion? DO you agree with at least one of the points Im trying to make? >>>> Which link layer are _you_ particularly concerned with and whose >>>> behaviour you'd like to see accepted in AUTOCONF? How does this link >>>> layer behave with respect to IPv6? >>> >>> This is the IETF. Link-agnostic sorts of folks. >> >> This is IETF - IPv6-over-foo sorts of folks. > > You are missing that _first_ we specified IPv6 to run over > layer-2 without specifying very many particular layer-2 > characteristics. Then the IPv6-over-foo documents laid > out the necessary techniques for adaptation. > > But I am pretty sure you knew that, and only make the > remark as a clever sound-bite trying to extend the pointless > argumentation. The point is to show that IPv6 protocols and links _do_ use link-local addresses and that disocuraging them makes little sense. >>>> I am saying this after having experimented with several wireless >>>> link layers: wavelan, wifi, bluetooth, irda, umts, 3g+, gsm, SLIP >>>> 2400bps, 802.16MAC, USB - to name just a few. My goal was all the >>>> time to see how IPv6 runs on it. I can tell you that I was not >>>> deceived and each time there was a solution, always involving >>>> link-local addresses. >>> >>> With three nodes? >> >> Well, more. If I enumerated that many links there were at least that >> many nodes. > > Links != nodes. At least two nodes per link, otherwise no need to link anybody. >>>> What do you think? What is that link-layer which does not support IPv6 >>>> link-layer addresses? >>>> >>>> Is it an imaginary link layer? >>> >>> It's not the link-layer that doesn't support IPv6 addresses. >>> >>> It's the link layer that doesn't support guaranteed layer-2 >>> unique addresses. >> >> Ok! I know one, it's USB. USB MAC addresses are "unique" among >> USBers but may clash with IEEE MAC addresses. > > Usually I at least understand the context for pointless > argumentation but now I have lost even that meager > thread to what you might have in mind. The point is to not discorage LLs. >> That doesn't mean DAD won't spot them. > > Nobody ever claimed that DAD was incapable of > spotting address conflicts. > >> >>> It's the mobility that makes this into a threat against >>> link-layer address uniqueness. >>> >>> Which, honestly, I think you could figure out directly >>> except that it's so much fun to argue. >> >> I had a point to make, not only fun to argue. >> >> > > I must have missed that. Don't discourage the LLs, my point is. Alex > > Regards, > Charlie P. > > > From charles.perkins@earthlink.net Tue Oct 27 10:53:48 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F3C828C0FC for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:53:48 -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 nIpC2kkBChF1 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:53:47 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 8911128C11C for <autoconf@ietf.org>; Tue, 27 Oct 2009 10:53:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=EJnMmGleXiFJpGRQ8zhmXpLtBG89vvSGYN7OUE9xxumECIuNUAh++bxOV0PhcMHN; 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.16]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N2qF8-0006cJ-40; Tue, 27 Oct 2009 12:54:02 -0500 Message-ID: <4AE733BA.10308@earthlink.net> Date: Tue, 27 Oct 2009 10:54:02 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <AE72A684-DF66-4E49-A291-06C950893A4A@gmail.com> <4AE6C224.5080109@gmail.com> <25c114b90910270303v1c928b77y7ae88895c1e8778f@mail.gmail.com> <4AE6C7A4.8080506@gmail.com> <4AE6CF4E.7000000@gmail.com> <4AE72925.20006@earthlink.net> <4AE72FE9.5070104@gmail.com> In-Reply-To: <4AE72FE9.5070104@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f520d0155cb009933d1818b7e9b2b7bc2c7350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] disagreement on the DT document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 17:53:48 -0000 Hello Alex, Alexandru Petrescu wrote: > >> >> Perhaps you'd prefer: >> "routers which connect via links with connectivity >> properties not conducive to supporting link-local >> addresses"...? > > Hmm... sounds better than "undetermined connectivity properties". > > But, a link-local address is not necessarily derived from the > link-layer connectivity properties. It could be fe80::1 - would you > agree with those LL addresses not derived from the link-layer properties? I don't care. This is useless argumentation. I only care that this has been such a monstrous waste of time and effort, for so precious little gain except to have a bit of practice in saying the same things over and over again to people who otherwise do not even care to solve the problem of interest to the practitioners. Regards, Charlie P. From alexandru.petrescu@gmail.com Tue Oct 27 10:58:28 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 752F73A689E for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.176, 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 o8Ym4cGtFZsS for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 10:58:27 -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 3DD003A6867 for <autoconf@ietf.org>; Tue, 27 Oct 2009 10:58:27 -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 n9RHwTlQ015838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 18:58:29 +0100 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 n9RHwSgw030028; Tue, 27 Oct 2009 18:58:29 +0100 (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 n9RHwSIC008591; Tue, 27 Oct 2009 18:58:28 +0100 Message-ID: <4AE734C4.5030306@gmail.com> Date: Tue, 27 Oct 2009 18:58:28 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" <charles.perkins@earthlink.net> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.com> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <25c114b90910270135i788a8a45oc0ac5cf87e2ae52@mail.gmail.com> <4AE6C4B5.1050309@gmail.com> <25c114b90910270324y3599756bhdebe9502f6026b93@mail.gmail.com> <4AE6CD55.1040205@gmail.com> <25c114b90910270352r7be3999ena54848beb1cf9472@mail.gmail.com> <4AE6D5C3.8080501@gmail.com> <25c114b90910270528t238703afkdf34873a08539954@mail.gmail.com> <4AE6F630.7000606@gmail.com> <4AE72598.2050804@earthlink.net> <4AE72E11.60600@gmail.com> <4AE73236.6080409@earthlink.net> In-Reply-To: <4AE73236.6080409@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] IP over "anything" X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 17:58:28 -0000 Charles E. Perkins a écrit : > > > Hello Alex, > > I think you have very well identified > an interesting point. > > Alexandru Petrescu wrote: >> >>> >>> You too are denying the fact that we have >>> already done what needs to be done in many >>> different ways. It would be nice for the practitioners >>> who have done it, to be able to standardize on >>> one approach. >> >> Err... go ahead, I won't be part of it. >> >> Started this way there's little incentive to look into it. > > So let's be clear here. > > - People built ad hoc wireless networks. > - They work with statically assigned addresses. > - A method for address autoconfiguration was > desired. > - Internet Drafts were written for that purpose > - A working group was formed to resolve > differences in the approaches > - An addressing model was required > - An addressing model was produced that > enabled solutions in the general solution space > of the published solutions > - You seem to even disavow the validity of > considering wireless networks of the sort that > is of interest to the original practitioners > - You now claim that you won't be part of the > solution team. > > So do you stand in the way of other peoples' > progress? Right, no, I don't. Good luck. >>>> Blindly hiding behind "IP over anything" without saying what is, and >>>> ignoring the so many IP-over-foo RFC documents - are indicators for >>>> this. >>> >>> Blindly assuming MAC-layer uniqueness is an indication >>> of a bad fit for the [autoconf] working group, I think. >> >> Right. Let's say I assume DAD could help detecting duplicates. > > That was never at issue. But the addressing model draft discards DAD. IT does not understand how DAD works and discards it. Look at this text: > 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, without it > being an explicit event that would trigger DAD again. Such > duplication would thus go undetected. There is an explicit event which happens when linking to a network: unsolicited NA; NS too. That may trigger many things. >>>> Also, there was a zeroconf WG, "to enable networking in the absence >>>> of configuration and administration". Doesn't that sound MANETish >>>> enough. Well it gave the IPv4 LLs RFC. >>> I was there. It was maximally non-MANET. In fact, it was a single >>> extent of Ethernet. >>> >>> That's not a MANET. >> >> At least it has that "adhoc non-planned" nature in it, by saying >> "absence of conf and admin". > > There are many unplanned events, no doubt. > >> >>> And it was terribly political. Ohh... well maybe that isn't a >>> difference. >> >> Hmmm... politics. Yes you can. > > You are making fun of me. Sorry, no intention. My point is to not discourage the LLs. Alex > > Regards, > Charlie P. > > > > From charles.perkins@earthlink.net Tue Oct 27 11:06:36 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93C7A28C220 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 11:06:36 -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 XqBKiJ3493-U for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 11:06:35 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id A2DF328C211 for <autoconf@ietf.org>; Tue, 27 Oct 2009 11:06:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Yjw2OX+YbrHqipj7dG6R+iWD1DBz1zTlQH9ax5MJjwyiv+ThKDKy4Qsuns3g4J3r; 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.16]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N2qRU-0004tf-KY; Tue, 27 Oct 2009 14:06:49 -0400 Message-ID: <4AE736B9.2060009@earthlink.net> Date: Tue, 27 Oct 2009 11:06:49 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <125638 9726.5286.65.camel@ac orde.it.uc3m.es> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <1256634091.5090.4.camel@acorde.it.uc3m.es> <4AE6C4C7.5000803@gmail.com> <4AE72001.5040102@earthlink.net> <4AE7283F.9040600@gmail.com> <4AE72902.9010104@earthlink.net> <4AE72F60.50006@gmail .com> In-Reply-To: <4AE72F60.50006@gmail.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52e7ae3fc4196b3a7a274b5dd7a653f47d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 18:06:36 -0000 Hello Alex, Alexandru Petrescu wrote: > >>> >>> Does what you have done involve link-layer addresses or not? Does >>> it allow them to exist or not? >>> >> >> It did not involve link-layer addresses. It did not prohibit, >> encourage, or validate link-layer addresses in any way. > > SO your solution does not have anything agains LLs. So why go > discourage them in the addressing model draft? Why even talking about > them in the draft? Perhaps you missed the first 50 times that I stated I do not have anything against link-local addresses. They are useful when there is a link on which link-local address uniqueness can be maintained. Oh, by the way.... please keep in mind that I am not against link-local addresses, just in case you ever feel tempted to make that false implication in the future. As far as link-locals in the draft -- I thought they were only there because of interactions with people who wanted to include them as part of the address architecture. If we can get the draft promulgated without any mention of link locals and without any mandate for autoconfiguring addresses based on the properties of link-locals, then that would be fine with me. Then we can have a separate informational document, perhaps purely as an individual submission, which describes the pitfalls of using link-locals in ad hoc networks. > >> Not our problem. We just wanted to achieve a solution >> for address assignment in ad hoc networks. > > I have to read that solution now. Where is it? > I'm having a little trouble finding my old documents. This is work done well over five years ago. I'll send another message when I find them. Regards, Charlie P. From hrogge@googlemail.com Tue Oct 27 11:08:53 2009 Return-Path: <hrogge@googlemail.com> 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 B134A28C221 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 11:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 5A1bpbk6vz+k for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 11:08:52 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 671EF28C220 for <autoconf@ietf.org>; Tue, 27 Oct 2009 11:08:52 -0700 (PDT) Received: by ewy4 with SMTP id 4so420531ewy.37 for <autoconf@ietf.org>; Tue, 27 Oct 2009 11:09:03 -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=lSU/2sJaX6ZdTBwRmXykaJPwzyFRMcwlMC7vYdUnkI4=; b=V5aCljLHwBOBrrwPm8HHx6qfBjkMiWGaZzo59ayTgi/rWvlo2lkeYlHcjBNP+0q+e3 +C09NxzdqW+2T74lL6/I605g/uiKfTki6dLLKaW4QK16k2L8OytI/IycqQEGliVGjQbA Kx/gq1325kEEJLkVzOaBA23SybVdT0Sv76b2I= 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=THx1NQzVcluc6Wm3aswswP9HuCmVm8LYKyOi7AmCnppdSZxFH+Cg5LymhL5wwgnJ/Z Rw0aPEcpk0GWGZmAxEuTQLRLR2FtUA7fmZasX8ly1n0XJFDaDFbfktzyK0nHBCyd5SQi muoe98nBcWFIdPHRBCzwSMEH136S06kBwiEn8= Received: by 10.211.141.15 with SMTP id t15mr10693895ebn.59.1256666943515; Tue, 27 Oct 2009 11:09:03 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 7sm666201eyg.41.2009.10.27.11.09.02 (version=SSLv3 cipher=RC4-MD5); Tue, 27 Oct 2009 11:09:03 -0700 (PDT) From: Henning Rogge <hrogge@googlemail.com> To: Alexandru Petrescu <alexandru.petrescu@gmail.com> Date: Tue, 27 Oct 2009 19:08:57 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-gentoo-r2; KDE/4.3.2; x86_64; ; ) References: <4AE6002C.3020704@gmail.com> <200910271710.45170.hrogge@googlemail.com> <4AE72560.3000502@gmail.com> In-Reply-To: <4AE72560.3000502@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart25136196.Eu37QmlBnk"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910271909.01967.hrogge@googlemail.com> Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD problem in IPv6 mesh networks for LL X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 18:08:53 -0000 --nextPart25136196.Eu37QmlBnk Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am Dienstag 27 Oktober 2009 17:52:48 schrieb Alexandru Petrescu: > > All connected interfaces are in 1-hop (IP-)range of each other on > > switches. No amount of cable and other switches will change this. >=20 > Yes, ok. Good, finally some aggreement. =20 > The same with wifi. They have a range of 50meters. You could extend > that with more wifi cards/APs but no amount of cards/APs will open it, > it's a "closed domain". Your are missing that a group of WLAN nodes on the same channel has not=20 necessarily symmetric or transitive connections. Ethernet cards connected to a switch (or a group of connected switches) do. > >> The same in WLAN. I can add WLAN repeaters. > > > > No. please read my former mails again, especially the example. >=20 > You mean I can not add a WLAN repeater? I have already done that - why > do you want me to not do it? >=20 > Other people added WLAN PHY range extender antennas, up to 2km - do you > want them to not do it too? Sorry, you are again evading the important point. With WLAN you CAN (often) have situations where the layer-2 connectivity is= =20 neither transitive nor symmetric. With ethernet it is always transitive and= =20 symmetric for all interfaces connected to a switch (or a group of connected= =20 switches). > > if A and C choose the same LL-IP DAD would not detect it, because A and= C > > are not in one-hop distance. >=20 > DAD running on which machine?=20 all of them. > You seem to think DAD on B won't detect A > and C have the same address, which may be truly true. =20 > Also, DAD on A won't detect C having same address, and vice-versa, > because they're too far apart. Ok. >=20 > Nodes far apart cant talk to each other regardless of the addresses > being duplicated. Yes, but if A and C (which cannot talk to each other) have the same LL-IP,= =20 then B cannot talk to them either, because both A and C have the same IP ! =20 > > But suddenly B would not be able to use A's and C's LL-IP to address > > them, because they are both on the same interface of B. > > > > Do you see it ? >=20 > Sorry, I don't see it. Who runs DAD? all of them =20 > Normally every machine runs DAD. If A and B are close enough to hear > each other and both run DAD then the duplicate between A and B is > detected. Same for B and C. >=20 > So, if A's address is not duplicated at B, and B's address is not > duplicated at C - then A and C use distinctive addresses. Which seems a > rather happy situation to be in. >=20 > Don't you think so? No. Henning Rogge --nextPart25136196.Eu37QmlBnk Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEABECAAYFAkrnNz0ACgkQcenvcwAcHWea+wCfUmD8sKzMCxK71xQWeAVHjmdF 9F4AoIySGgGr9pRCccH/WSXSj1OxTXO4 =tQFq -----END PGP SIGNATURE----- --nextPart25136196.Eu37QmlBnk-- From alexandru.petrescu@gmail.com Tue Oct 27 11:20:34 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 D17AA28C101 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 11:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.175, 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 WPpFLoxuAdIB for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 11:20:33 -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 4EF6828C178 for <autoconf@ietf.org>; Tue, 27 Oct 2009 11:20:33 -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 n9RIKbGd031681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 19:20:37 +0100 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 n9RIKaKH000624; Tue, 27 Oct 2009 19:20:37 +0100 (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 n9RIKa5C022039; Tue, 27 Oct 2009 19:20:36 +0100 Message-ID: <4AE739F4.8040907@gmail.com> Date: Tue, 27 Oct 2009 19:20:36 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Henning Rogge <hrogge@googlemail.com> References: <4AE6002C.3020704@gmail.com> <200910271710.45170.hrogge@googlemail.com> <4AE72560.3000502@gmail.com> <200910271909.01967.hrogge@googlemail.com> In-Reply-To: <200910271909.01967.hrogge@googlemail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD problem in IPv6 mesh networks for LL X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 18:20:35 -0000 Henning Rogge a écrit : [...] >>> if A and C choose the same LL-IP DAD would not detect it, because A and C >>> are not in one-hop distance. >> DAD running on which machine? > > all of them. > >> You seem to think DAD on B won't detect A >> and C have the same address, which may be truly true. > >> Also, DAD on A won't detect C having same address, and vice-versa, >> because they're too far apart. Ok. >> >> Nodes far apart cant talk to each other regardless of the addresses >> being duplicated. > > Yes, but if A and C (which cannot talk to each other) have the same LL-IP, > then B cannot talk to them either, because both A and C have the same IP ! Ah!, I start to see what you mean. However, what is the problem when A sends a packet and both B and C receive it? I can only vaguely see something, but not sure. Know too that this kind of wrong link-layer configuration (A far from C and B in between) can be done with longer than specified Ethernet cables too. I.e. it's not specific to MANET. People can artifically create problems by ignoring how their link-layers work. The "hidden terminal problem" which seems to be behind this story too, has already been addressed and solved during 802.11b design, long ago, at link-layer: DCF. Alex PS: and yes, I know, you want to do AUTOCONF and I will not stop you from doing so. >>> But suddenly B would not be able to use A's and C's LL-IP to address >>> them, because they are both on the same interface of B. >>> >>> Do you see it ? >> Sorry, I don't see it. Who runs DAD? > all of them > >> Normally every machine runs DAD. If A and B are close enough to hear >> each other and both run DAD then the duplicate between A and B is >> detected. Same for B and C. >> >> So, if A's address is not duplicated at B, and B's address is not >> duplicated at C - then A and C use distinctive addresses. Which seems a >> rather happy situation to be in. >> >> Don't you think so? > No. > > Henning Rogge From hrogge@googlemail.com Tue Oct 27 11:25:14 2009 Return-Path: <hrogge@googlemail.com> 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 B755F28C0CF for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 11:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.131, 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 K2Xkj-UIm3cw for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 11:25:13 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id A47443A698F for <autoconf@ietf.org>; Tue, 27 Oct 2009 11:25:13 -0700 (PDT) Received: by ewy4 with SMTP id 4so436505ewy.37 for <autoconf@ietf.org>; Tue, 27 Oct 2009 11:25:24 -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=IlQs0BCtn4KzsBkHQ5ymiw1WaIPML1bb8sgtcJ7+hQQ=; b=aSt7d+MGc8c5eYffe74knzJKWDvzA8LsHK0cAVOdViaJ/PU+w6yateT9j+mXSkiqro IOmw1xNxkaLzZd5iC5XRXSXEoVx7h6YotzFNWa5DQ1ATABRisxwmDUMoRk0S7Y/rQxEY a5Af8Qa4AtETD75UQcs18SX2+nZoCgvRutWv8= 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=uaYA1rfg84MIcvIWDYw6w3hV/vv4wF/j30NMFrOqEqvFS1dF5O+KWqYrghXFRwfAn+ zBhDeU30JmWV68PhWtXNpcv+McG3G3DPd88kjmuFPVPVOnA8hZJWMlNUBm/1oWTiR+Y6 KAWf6Sk0dnhLoDGlQk5sxedWWWn/dqGYuRBn4= Received: by 10.211.142.11 with SMTP id u11mr4537588ebn.8.1256667923683; Tue, 27 Oct 2009 11:25:23 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 7sm706732eyb.8.2009.10.27.11.25.22 (version=SSLv3 cipher=RC4-MD5); Tue, 27 Oct 2009 11:25:22 -0700 (PDT) From: Henning Rogge <hrogge@googlemail.com> To: Alexandru Petrescu <alexandru.petrescu@gmail.com> Date: Tue, 27 Oct 2009 19:25:02 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-gentoo-r2; KDE/4.3.2; x86_64; ; ) References: <4AE6002C.3020704@gmail.com> <200910271909.01967.hrogge@googlemail.com> <4AE739F4.8040907@gmail.com> In-Reply-To: <4AE739F4.8040907@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1978750.4ZmIP26aD6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910271925.21688.hrogge@googlemail.com> Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD problem in IPv6 mesh networks for LL X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 18:25:14 -0000 --nextPart1978750.4ZmIP26aD6 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am Dienstag 27 Oktober 2009 19:20:36 schrieb Alexandru Petrescu: > Ah!, I start to see what you mean. >=20 > However, what is the problem when A sends a packet and both B and C > receive it? I can only vaguely see something, but not sure. >=20 > Know too that this kind of wrong link-layer configuration (A far from C > and B in between) can be done with longer than specified Ethernet cables > too. I.e. it's not specific to MANET. People can artifically create > problems by ignoring how their link-layers work. In ethernet it would be "ignoring the linklayer parameters" or maybe a bad= =20 switch. In IEEE 802.11 based MANETs it's a typical situation ! =20 > The "hidden terminal problem" which seems to be behind this story too, > has already been addressed and solved during 802.11b design, long ago, > at link-layer: DCF. IEEE 802.11 DCF does only work with access points. MANETs run in adhoc-mode. Henning Rogge --nextPart1978750.4ZmIP26aD6 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEABECAAYFAkrnOxEACgkQcenvcwAcHWcYdgCcCHPbDoetf7GkdpdZU+F0Csur wJEAnjRLGEHbrwZaYQ2hu4h0OnwwhFGZ =pNC1 -----END PGP SIGNATURE----- --nextPart1978750.4ZmIP26aD6-- From hrogge@googlemail.com Tue Oct 27 11:28:30 2009 Return-Path: <hrogge@googlemail.com> 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 9330728C0FF for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 11:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 hvLv43vS3HFz for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 11:28:29 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 748543A698F for <autoconf@ietf.org>; Tue, 27 Oct 2009 11:28:29 -0700 (PDT) Received: by ewy4 with SMTP id 4so439746ewy.37 for <autoconf@ietf.org>; Tue, 27 Oct 2009 11:28:38 -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=iPDRw1xrpOsAHpTU0PI53eiFgCfX0fakwGGRuUKo8h8=; b=v0rPBac/9vmtO+oDbtIraOwE4WRblemJ2j64cwcWIDeRGVnH2S6aKXYG0YXTgBmL71 IhW4JVL9fYefEPhUWwLWTxxO9MjfqGqrFzpuk+C9txDvU+U8TEKcv6NQTUW44UEuFUy3 3zEsFd3LGFBNFTNKwZvOdrsluVfY+3ZIi/nOg= 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=OeldVcjR9CAR0Gn52hPJZyOQcPjM1s3g5vkxoEiwf39HsYvbJ2YTxrGQwZaylW9DNo Xq3J5he5r9vlWXIjwDKQr073C9Z51uM2GNyAAgwMprMWPnnIAckSnnboLXqxO9jVZd9s FvGHler4ONzaz8z8ovKth0pNT4LkPRZ51JtWw= Received: by 10.211.131.39 with SMTP id i39mr6259752ebn.98.1256668118780; Tue, 27 Oct 2009 11:28:38 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 28sm710832eyg.30.2009.10.27.11.28.36 (version=SSLv3 cipher=RC4-MD5); Tue, 27 Oct 2009 11:28:37 -0700 (PDT) From: Henning Rogge <hrogge@googlemail.com> To: Alexandru Petrescu <alexandru.petrescu@gmail.com> Date: Tue, 27 Oct 2009 19:28:31 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-gentoo-r2; KDE/4.3.2; x86_64; ; ) References: <4AE6002C.3020704@gmail.com> <4AE739F4.8040907@gmail.com> <200910271925.21688.hrogge@googlemail.com> In-Reply-To: <200910271925.21688.hrogge@googlemail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1605751.cpsn6U1Ex1"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910271928.36021.hrogge@googlemail.com> Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD problem in IPv6 mesh networks for LL X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 18:28:30 -0000 --nextPart1605751.cpsn6U1Ex1 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Am Dienstag 27 Oktober 2009 19:25:02 schrieb Henning Rogge: > Am Dienstag 27 Oktober 2009 19:20:36 schrieb Alexandru Petrescu: > > Ah!, I start to see what you mean. > > > > However, what is the problem when A sends a packet and both B and C > > receive it? I can only vaguely see something, but not sure. > > > > Know too that this kind of wrong link-layer configuration (A far from C > > and B in between) can be done with longer than specified Ethernet cables > > too. I.e. it's not specific to MANET. People can artifically create > > problems by ignoring how their link-layers work. >=20 > In ethernet it would be "ignoring the linklayer parameters" or maybe a bad > switch. >=20 > In IEEE 802.11 based MANETs it's a typical situation ! >=20 > > The "hidden terminal problem" which seems to be behind this story too, > > has already been addressed and solved during 802.11b design, long ago, > > at link-layer: DCF. >=20 > IEEE 802.11 DCF does only work with access points. MANETs run in > adhoc-mode. Sorry, PCF needs an access point... But DCF does only help against collisions, which is not the problem here. Henning Rogge --nextPart1605751.cpsn6U1Ex1 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEABECAAYFAkrnO9QACgkQcenvcwAcHWf+kwCeOL8FgFhtBBCpfEdYcdOyEdhZ Jt0An0THCbHEqbonVjlzLKmQuaCn+Xh/ =Io6d -----END PGP SIGNATURE----- --nextPart1605751.cpsn6U1Ex1-- From charles.perkins@earthlink.net Tue Oct 27 11:30:24 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF1CC28C0FF for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 11:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=0.106, 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 xnhEIfTL41aG for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 11:30:23 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 6679B28C0FB for <autoconf@ietf.org>; Tue, 27 Oct 2009 11:30:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=FP+2/W/PR2H/Pn8f1RtH3/IBvOgaaRj4J+UyFRVffc/0OwgPRIHwNFn4L0Wz4TQp; 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.16]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N2qoX-0004AR-R5; Tue, 27 Oct 2009 14:30:37 -0400 Message-ID: <4AE73C4E.7020209@earthlink.net> Date: Tue, 27 Oct 2009 11:30:38 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <125638 9726.5286.65.camel@ac orde.it.uc3m.es> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <1256634091.5090.4.camel@acorde.it.uc3m.es> <4AE6C4C7.5000803@gmail.com> <4AE72001.5040102@earthlink.net> <4AE7283F.9040600@gmail.com> <4AE72902.9010104@earthlink.net> <4AE72F60.50006@gmail .com> In-Reply-To: <4AE72F60.50006@gmail.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f525753ee09890bef114d57d54d46b23cf3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: [Autoconf] http://www.psg.com/~charliep/txt/ietf76/autoconf.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 18:30:25 -0000 Hello Alex, I found a copy of our very old solution. Perhaps it could be done better now with _eight years_ experience since it was published -- and that makes it nearly _ten years_ since the system was implemented. Please see: http://www.psg.com/~charliep/txt/ietf76/autoconf.txt But, instead, we've had oh-so-much fun dallying over verbiage on link-locals. I think the repeated discussion over the same discredited points has been an extraordinarily poor investment of time. By the way, I'm not really interested in incorporating comments on the draft. It would still be a good basis for starting work on the solution space, but there are other ways to do it, and I don't want to get bogged down in nitpicking over the details of this draft. Regards, Charlie P. Alexandru Petrescu wrote: > >>>> >>>> Then you too are denying the fact that we have >>>> already done what needs to be done in many >>>> different ways. It would be nice for the practitioners >>>> who have done it, to be able to standardize on >>>> one approach. >>> >>> Does what you have done involve link-layer addresses or not? Does >>> it allow them to exist or not? >>> >> >> It did not involve link-layer addresses. It did not prohibit, >> encourage, or validate link-layer addresses in any way. > > SO your solution does not have anything agains LLs. So why go > discourage them in the addressing model draft? Why even talking about > them in the draft? > >> Not our problem. We just wanted to achieve a solution >> for address assignment in ad hoc networks. > > I have to read that solution now. Where is it? > > From alexandru.petrescu@gmail.com Tue Oct 27 11:36:22 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 71C663A6899 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 11:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[AWL=0.172, 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 RFRA0DvG901o for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 11:36:21 -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 7BB193A63EC for <autoconf@ietf.org>; Tue, 27 Oct 2009 11:36:21 -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 n9RIaVQD008498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 19:36:31 +0100 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 n9RIaV3e002180; Tue, 27 Oct 2009 19:36:31 +0100 (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 n9RIaUFX016212; Tue, 27 Oct 2009 19:36:31 +0100 Message-ID: <4AE73DAE.2000508@gmail.com> Date: Tue, 27 Oct 2009 19:36:30 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Henning Rogge <hrogge@googlemail.com> References: <4AE6002C.3020704@gmail.com> <200910271909.01967.hrogge@googlemail.com> <4AE739F4.8040907@gmail.com> <200910271925.21688.hrogge@googlemail.com> In-Reply-To: <200910271925.21688.hrogge@googlemail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD problem in IPv6 mesh networks for LL X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 18:36:22 -0000 Henning Rogge a écrit : > Am Dienstag 27 Oktober 2009 19:20:36 schrieb Alexandru Petrescu: >> Ah!, I start to see what you mean. >> >> However, what is the problem when A sends a packet and both B and C >> receive it? I can only vaguely see something, but not sure. >> >> Know too that this kind of wrong link-layer configuration (A far from C >> and B in between) can be done with longer than specified Ethernet cables >> too. I.e. it's not specific to MANET. People can artifically create >> problems by ignoring how their link-layers work. > In ethernet it would be "ignoring the linklayer parameters" or maybe a bad > switch. It would be longer-than-specified cables. > In IEEE 802.11 based MANETs it's a typical situation ! Well - I have never seen this situation. I do take a lot of time planning WiFi networks, I did it several times. I follow the manuals. There is this 50m rule which should not be tresspassed, as there is a length limit on the Ethernet cable. There is also the channel planning. As for building larger wifi networks, please put repeaters or real routers in between. As for them moving too non-deterministically - is the same thing that may come back at you with somehing new you may design. >> The "hidden terminal problem" which seems to be behind this story too, >> has already been addressed and solved during 802.11b design, long ago, >> at link-layer: DCF. > > IEEE 802.11 DCF does only work with access points. MANETs run in adhoc-mode. So put an access point there, if so is the need. An AP does not necessarily mean you need 220V power - it could run on battery and without any cables, it could be mobile. Moreover, it could be the hostap software on linux PDA or smaller - what's wrong with that? Have you somehow decided that MANET is _only_ adhoc mode (and not AP mode)? Why so? Alex > > Henning Rogge From alexandru.petrescu@gmail.com Tue Oct 27 11:37:30 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 5F96728C12F for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 11:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.170, 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 WEyXjcf-jE2f for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 11:37: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 37B6728C12B for <autoconf@ietf.org>; Tue, 27 Oct 2009 11:37: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 n9RIbfYi009203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 19:37:41 +0100 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 n9RIbe4U002316; Tue, 27 Oct 2009 19:37:41 +0100 (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 n9RIbeaI016411; Tue, 27 Oct 2009 19:37:40 +0100 Message-ID: <4AE73DF4.2090706@gmail.com> Date: Tue, 27 Oct 2009 19:37:40 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" <charles.perkins@earthlink.net> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.com> <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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <125638 9726.5286.65.camel@ac orde.it.uc3m.es> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <1256634091.5090.4.camel@acorde.it.uc3m.es> <4AE6C4C7.5000803@gmail.com> <4AE72001.5040102@earthlink.net> <4AE7283F.9040600@gmail.com> <4AE72902.9010104@earthlink.net> <4AE72F60.50006@gmai! l.com> <4AE73C4E.7020209@earthl! ink.net> In-Reply-To: <4AE73C4E.7020209@earthlink.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] http://www.psg.com/~charliep/txt/ietf76/autoconf.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 18:37:30 -0000 Thanks for the draft Charles. I will not hurry to read it then. Alex Charles E. Perkins a écrit : > > Hello Alex, > > I found a copy of our very old solution. Perhaps it could > be done better now with _eight years_ experience since > it was published -- and that makes it nearly _ten years_ > since the system was implemented. > > Please see: > http://www.psg.com/~charliep/txt/ietf76/autoconf.txt > > But, instead, we've had oh-so-much fun dallying over > verbiage on link-locals. I think the repeated discussion > over the same discredited points has been an extraordinarily > poor investment of time. > > By the way, I'm not really interested in incorporating > comments on the draft. It would still be a good basis for > starting work on the solution space, but there are other > ways to do it, and I don't want to get bogged down in > nitpicking over the details of this draft. > > Regards, > Charlie P. > > > Alexandru Petrescu wrote: >> >>>>> >>>>> Then you too are denying the fact that we have >>>>> already done what needs to be done in many >>>>> different ways. It would be nice for the practitioners >>>>> who have done it, to be able to standardize on >>>>> one approach. >>>> >>>> Does what you have done involve link-layer addresses or not? Does >>>> it allow them to exist or not? >>>> >>> >>> It did not involve link-layer addresses. It did not prohibit, >>> encourage, or validate link-layer addresses in any way. >> >> SO your solution does not have anything agains LLs. So why go >> discourage them in the addressing model draft? Why even talking about >> them in the draft? >> >>> Not our problem. We just wanted to achieve a solution >>> for address assignment in ad hoc networks. >> >> I have to read that solution now. Where is it? >> >> > > From cjbc@it.uc3m.es Tue Oct 27 11:37:31 2009 Return-Path: <cjbc@it.uc3m.es> 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 65E1128C1A4 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 11:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.574 X-Spam-Level: X-Spam-Status: No, score=-5.574 tagged_above=-999 required=5 tests=[AWL=0.125, 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 cx9h6auKgTb8 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 11:37:30 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 1A11128C12C for <autoconf@ietf.org>; Tue, 27 Oct 2009 11:37:30 -0700 (PDT) Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 35723657352; Tue, 27 Oct 2009 19:37:43 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano <cjbc@it.uc3m.es> To: "Charles E. Perkins" <charles.perkins@earthlink.net> In-Reply-To: <4AE736B9.2060009@earthlink.net> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <125638 9726.5286.65.camel@ac orde.it.uc3m.es> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <1256634091.5090.4.camel@acorde.it.uc3m.es> <4AE6C4C7.5000803@gmail.com> <4AE72001.5040102@earthlink.net> <4AE7283F.9040600@gmail.com> <4AE72902.9010104@earthlink.net> <4AE72F60.50006@gmail .com> <4AE736B9.2060009@earthlink.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-VTJpMzEUB6BcqClFudju" Organization: Universidad Carlos III de Madrid Date: Tue, 27 Oct 2009 19:37:43 +0100 Message-Id: <1256668663.5090.148.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16974.000 Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind 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 <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 18:37:31 -0000 --=-VTJpMzEUB6BcqClFudju Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable (text skipped) > > I have to read that solution now. Where is it? > > > I'm having a little trouble finding my old documents. > This is work done well over five years ago. >=20 > I'll send another message when I find them. Maybe it is included in the survey draft we wrote in the past: http://tools.ietf.org/html/draft-bernardos-manet-autoconf-survey-04 :-) Otherwise, let me know to include it in future revisions of the draft. Thanks, Carlos >=20 > Regards, > Charlie P. >=20 >=20 >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-VTJpMzEUB6BcqClFudju Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkrnPfcACgkQNdy6TdFwT2ftAQCgwt27esptgzFD1SocZ7rxWm0l BSkAniuuNbNPQQmW7ADyqeSxKEfvfOP3 =GLko -----END PGP SIGNATURE----- --=-VTJpMzEUB6BcqClFudju-- From hrogge@googlemail.com Tue Oct 27 11:40:51 2009 Return-Path: <hrogge@googlemail.com> 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 88A5E3A687E for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 11:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 kOut7cGkP-vz for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 11:40:50 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id C98733A63EC for <autoconf@ietf.org>; Tue, 27 Oct 2009 11:40:49 -0700 (PDT) Received: by ewy4 with SMTP id 4so479ewy.37 for <autoconf@ietf.org>; Tue, 27 Oct 2009 11:41:00 -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=ixiYti0XLdEFv1jRdj7q9+yyuQcxGA5tWgGJ39Ings4=; b=cHiOmRtNMGekcXB+FnrsquSCNu0MO0lwenI4PEwH1T+pJt4YyfWSGjPN2BGp82NdeW 1NM977UcIx4f9vEytd+lrkszL2rDUzVwt2+1V+04bw3sQujV5UGaT45NpXL58tyGBuLX /wi2urzwMNZQ5NNj8hUiPOjF5V/HOtu6k7lFE= 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=hkcQfFclxx/gwe/wcln4HMaN6/k7/O2HiKQeqpXGTQAzpTrW5uDk74z93lwsONLzkj /z7M3MHO6xDlHHdnNvaQl2OPu26ct05TfUbcryzrpF+ImfOmvwl2LCpdAbyEiHCnfGKp OhgMsRGJZYpGW4iB81u4P2UkfBAls2teUj5CI= Received: by 10.216.90.79 with SMTP id d57mr2309326wef.117.1256668860789; Tue, 27 Oct 2009 11:41:00 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 5sm3145068eyf.3.2009.10.27.11.40.59 (version=SSLv3 cipher=RC4-MD5); Tue, 27 Oct 2009 11:41:00 -0700 (PDT) From: Henning Rogge <hrogge@googlemail.com> To: Alexandru Petrescu <alexandru.petrescu@gmail.com> Date: Tue, 27 Oct 2009 19:40:54 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-gentoo-r2; KDE/4.3.2; x86_64; ; ) References: <4AE6002C.3020704@gmail.com> <200910271925.21688.hrogge@googlemail.com> <4AE73DAE.2000508@gmail.com> In-Reply-To: <4AE73DAE.2000508@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2059599.0sN50uqY7D"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910271940.59120.hrogge@googlemail.com> Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD problem in IPv6 mesh networks for LL X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 18:40:52 -0000 --nextPart2059599.0sN50uqY7D Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am Dienstag 27 Oktober 2009 19:36:30 schrieb Alexandru Petrescu: > > In ethernet it would be "ignoring the linklayer parameters" or maybe a > > bad switch. >=20 > It would be longer-than-specified cables. Either way it would be something stupid done on layer 8. =20 > > In IEEE 802.11 based MANETs it's a typical situation ! >=20 > Well - I have never seen this situation. I do take a lot of time > planning WiFi networks, I did it several times. I follow the manuals. >=20 > There is this 50m rule which should not be tresspassed, as there is a > length limit on the Ethernet cable. There is also the channel planning. >=20 > As for building larger wifi networks, please put repeaters or real > routers in between. >=20 > As for them moving too non-deterministically - is the same thing that > may come back at you with somehing new you may design. Sorry, you miss the point in MANETs. Many of them are not preplanned by a=20 single entity, many of them have mobile nodes and many of them have no fixe= d=20 infrastructure. > >> The "hidden terminal problem" which seems to be behind this story too, > >> has already been addressed and solved during 802.11b design, long ago, > >> at link-layer: DCF. > > > > IEEE 802.11 DCF does only work with access points. MANETs run in > > adhoc-mode. >=20 > So put an access point there, if so is the need. An AP does not > necessarily mean you need 220V power - it could run on battery and > without any cables, it could be mobile. Moreover, it could be the > hostap software on linux PDA or smaller - what's wrong with that? >=20 > Have you somehow decided that MANET is _only_ adhoc mode (and not AP > mode)? Why so? It's the NORMAL use case for MANETs. I know a lot of MANETs. I have read a lot of papers on them. NONE of them=20 suggested running a IEEE 802.11 based MANET in access point mode. NONE. Henning Rogge --nextPart2059599.0sN50uqY7D Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEABECAAYFAkrnPrsACgkQcenvcwAcHWfR7gCfQ2ooxlcUu5WQQC6xozfPPnDF Zi0An15gPbnjBtdvjJmY9e1OQU4s174J =6E/o -----END PGP SIGNATURE----- --nextPart2059599.0sN50uqY7D-- From alexandru.petrescu@gmail.com Tue Oct 27 11:48:39 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 30FC228C12F for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 11:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[AWL=0.169, 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 DHYpPRObKVe6 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 11:48:38 -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 25CC228C110 for <autoconf@ietf.org>; Tue, 27 Oct 2009 11:48:37 -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 n9RImjEY015895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 19:48:45 +0100 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 n9RImj1x003191; Tue, 27 Oct 2009 19:48:45 +0100 (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 n9RImi4Z026191; Tue, 27 Oct 2009 19:48:44 +0100 Message-ID: <4AE7408C.5060602@gmail.com> Date: Tue, 27 Oct 2009 19:48:44 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Henning Rogge <hrogge@googlemail.com> References: <4AE6002C.3020704@gmail.com> <200910271925.21688.hrogge@googlemail.com> <4AE73DAE.2000508@gmail.com> <200910271940.59120.hrogge@googlemail.com> In-Reply-To: <200910271940.59120.hrogge@googlemail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD problem in IPv6 mesh networks for LL X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 18:48:39 -0000 Henning Rogge a écrit : > Am Dienstag 27 Oktober 2009 19:36:30 schrieb Alexandru Petrescu: >>> In ethernet it would be "ignoring the linklayer parameters" or maybe a >>> bad switch. >> It would be longer-than-specified cables. > Either way it would be something stupid done on layer 8. > >>> In IEEE 802.11 based MANETs it's a typical situation ! >> Well - I have never seen this situation. I do take a lot of time >> planning WiFi networks, I did it several times. I follow the manuals. >> >> There is this 50m rule which should not be tresspassed, as there is a >> length limit on the Ethernet cable. There is also the channel planning. >> >> As for building larger wifi networks, please put repeaters or real >> routers in between. >> >> As for them moving too non-deterministically - is the same thing that >> may come back at you with somehing new you may design. > Sorry, you miss the point in MANETs. Many of them are not preplanned by a > single entity, many of them have mobile nodes and many of them have no fixed > infrastructure. > >>>> The "hidden terminal problem" which seems to be behind this story too, >>>> has already been addressed and solved during 802.11b design, long ago, >>>> at link-layer: DCF. >>> IEEE 802.11 DCF does only work with access points. MANETs run in >>> adhoc-mode. >> So put an access point there, if so is the need. An AP does not >> necessarily mean you need 220V power - it could run on battery and >> without any cables, it could be mobile. Moreover, it could be the >> hostap software on linux PDA or smaller - what's wrong with that? >> >> Have you somehow decided that MANET is _only_ adhoc mode (and not AP >> mode)? Why so? > It's the NORMAL use case for MANETs. > > I know a lot of MANETs. I have read a lot of papers on them. Good. > NONE of them > suggested running a IEEE 802.11 based MANET in access point mode. NONE. Why did they avoid the AP mode? What's wrong with it in MANETs? APs can be as small and mobile as any other non-AP nodes. The 802.11b association procedure is the same when doing AP mode or adhoc mode - the messages are the same. The WEP and WPA security is also available in both modes. What's wrong with ap mode? ? Alex > > Henning Rogge From alexandru.petrescu@gmail.com Tue Oct 27 11:54:57 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 0663F3A67FB for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 11:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.083 X-Spam-Level: X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=0.166, 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 hHk-TInJtKQl for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 11:54:56 -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 E88913A67E4 for <autoconf@ietf.org>; Tue, 27 Oct 2009 11:54:55 -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 n9RIt5fB005116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 19:55:05 +0100 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 n9RIt4I6003509; Tue, 27 Oct 2009 19:55:04 +0100 (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 n9RIt4oR018539; Tue, 27 Oct 2009 19:55:04 +0100 Message-ID: <4AE74208.1040700@gmail.com> Date: Tue, 27 Oct 2009 19:55:04 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <4AE6002C.3020704@gmail.com> <200910271925.21688.hrogge@googlemail.com> <4AE73DAE.2000508@gmail.com> <200910271940.59120.hrogge@googlemail.com> <4AE7408C.5060602@gmail.com> In-Reply-To: <4AE7408C.5060602@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD problem in IPv6 mesh networks for LL X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 18:54:57 -0000 Alexandru Petrescu a écrit : > Henning Rogge a écrit : >> Am Dienstag 27 Oktober 2009 19:36:30 schrieb Alexandru Petrescu: >>>> In ethernet it would be "ignoring the linklayer parameters" or maybe a >>>> bad switch. >>> It would be longer-than-specified cables. >> Either way it would be something stupid done on layer 8. >> >>>> In IEEE 802.11 based MANETs it's a typical situation ! >>> Well - I have never seen this situation. I do take a lot of time >>> planning WiFi networks, I did it several times. I follow the manuals. >>> >>> There is this 50m rule which should not be tresspassed, as there is a >>> length limit on the Ethernet cable. There is also the channel planning. >>> >>> As for building larger wifi networks, please put repeaters or real >>> routers in between. >>> >>> As for them moving too non-deterministically - is the same thing that >>> may come back at you with somehing new you may design. >> Sorry, you miss the point in MANETs. Many of them are not preplanned >> by a single entity, many of them have mobile nodes and many of them >> have no fixed infrastructure. >> >>>>> The "hidden terminal problem" which seems to be behind this story too, >>>>> has already been addressed and solved during 802.11b design, long ago, >>>>> at link-layer: DCF. >>>> IEEE 802.11 DCF does only work with access points. MANETs run in >>>> adhoc-mode. >>> So put an access point there, if so is the need. An AP does not >>> necessarily mean you need 220V power - it could run on battery and >>> without any cables, it could be mobile. Moreover, it could be the >>> hostap software on linux PDA or smaller - what's wrong with that? >>> >>> Have you somehow decided that MANET is _only_ adhoc mode (and not AP >>> mode)? Why so? >> It's the NORMAL use case for MANETs. >> >> I know a lot of MANETs. I have read a lot of papers on them. > > Good. > >> NONE of them suggested running a IEEE 802.11 based MANET in access >> point mode. NONE. > > Why did they avoid the AP mode? What's wrong with it in MANETs? APs > can be as small and mobile as any other non-AP nodes. > > The 802.11b association procedure is the same when doing AP mode or > adhoc mode - the messages are the same. I meant the essential messages ^ (ap mode has usually messages than adhoc mode, sometimes yes, no, depending on implementaiton) I am still wondering why MANETs dont want to use wifi ap mode? (even without connecting to the infrastructure, and without 220V available, no cables - just one PDA doing hostap). What's so wrong about it? Alex The WEP and WPA security is > also available in both modes. What's wrong with ap mode? > > ? > > Alex > >> >> Henning Rogge > > > From charles.perkins@earthlink.net Tue Oct 27 12:00:43 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E8E328C129 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 12:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.876 X-Spam-Level: X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[AWL=0.104, 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 Spgw+JiVntA4 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 12:00:42 -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 E0F0F28C3BE for <autoconf@ietf.org>; Tue, 27 Oct 2009 12:00:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=X1sO/+/OW461/C27KWK1CszR0qqlIHgL0O+twJf/wpm7dGwJZIxGqRUJiK/GaPu8; 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.16]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N2rHT-0007j3-Mq; Tue, 27 Oct 2009 15:00:31 -0400 Message-ID: <4AE74350.4010304@earthlink.net> Date: Tue, 27 Oct 2009 12:00:32 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <125638 9726.5286.65.camel@ac orde.it.uc3m.es> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <1256634091.5090.4.camel@acorde.it.uc3m.es> <4AE6C4C7.5000803@gmail.com> <4AE72001.5040102@earthlink.net> <4AE7283F.9040600@gmail.com> <4AE72902.9010104@earthlink.net> <4AE72F60.50006@gmail .com> <4AE736B9.2060009@earthlink.net> <1256668663.5090.148.camel@acorde.it.uc3m.es> In-Reply-To: <1256668663.5090.148.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52da9cb6a34e408c0f14c554846a7d06fd350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 19:00:43 -0000 Hello Carlos, Yes, it is the same protocol that you described in your draft. I think you draft should be considered important background material for understanding the issues. Once we get to work, that is. Regards, Charlie P. Carlos Jesús Bernardos Cano wrote: > (text skipped) > >>> I have to read that solution now. Where is it? >>> >>> >> I'm having a little trouble finding my old documents. >> This is work done well over five years ago. >> >> I'll send another message when I find them. >> > > Maybe it is included in the survey draft we wrote in the past: > > http://tools.ietf.org/html/draft-bernardos-manet-autoconf-survey-04 > > :-) > > Otherwise, let me know to include it in future revisions of the draft. > > Thanks, > > Carlos > > >> Regards, >> Charlie P. >> >> >> >> From hrogge@googlemail.com Tue Oct 27 12:33:41 2009 Return-Path: <hrogge@googlemail.com> 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 E298328C140 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 12:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 vkKjylRKxsBC for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 12:33:41 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id C320328C13F for <autoconf@ietf.org>; Tue, 27 Oct 2009 12:33:40 -0700 (PDT) Received: by ewy4 with SMTP id 4so52575ewy.37 for <autoconf@ietf.org>; Tue, 27 Oct 2009 12:33:51 -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=w07jDVl10f2cXxPlRDgkZFjizN6YlvfU/1Zl7aopgOo=; b=wjxCwz+OFwhHvLc6MAYj9+Cgayaot/lGy+FWJYFIyt7iL6OB+5x3F9uNivQH8lRyMX dmGpBsptvgLOnt8SG2rTTeYfBxcmuwqGLboijLB1RpcctJDCdEeAnobOCcB0qx22wUwR J+DNfotCHu7YHpj580NaAPv96BrXGpTtIho2Q= 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=IQ5wW4Y9dNQblgxQ2cGr1LjcmDKPfG6pO8LqVILF1caitQRMxUEo9na90Qs/ywIuB5 MiGKPp90zru2pMWA2N66JM6etgbt/CVBnKgLtbumXRZJUo6MA9E/hQvhAxdGtqyKpbbb h2u/VX/7KCjhHih84LZM4DezXlmq9TTGll9Tw= Received: by 10.210.9.18 with SMTP id 18mr7312569ebi.34.1256672030710; Tue, 27 Oct 2009 12:33:50 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 5sm3235376eyf.7.2009.10.27.12.33.49 (version=SSLv3 cipher=RC4-MD5); Tue, 27 Oct 2009 12:33:49 -0700 (PDT) From: Henning Rogge <hrogge@googlemail.com> To: Alexandru Petrescu <alexandru.petrescu@gmail.com> Date: Tue, 27 Oct 2009 20:33:39 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-gentoo-r2; KDE/4.3.2; x86_64; ; ) References: <4AE6002C.3020704@gmail.com> <200910271940.59120.hrogge@googlemail.com> <4AE7408C.5060602@gmail.com> In-Reply-To: <4AE7408C.5060602@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3731855.siZ5rErszZ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910272033.43884.hrogge@googlemail.com> Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD problem in IPv6 mesh networks for LL X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 19:33:42 -0000 --nextPart3731855.siZ5rErszZ Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am Dienstag 27 Oktober 2009 19:48:44 schrieb Alexandru Petrescu: > > I know a lot of MANETs. I have read a lot of papers on them. >=20 > Good. >=20 > > NONE of them > > suggested running a IEEE 802.11 based MANET in access point mode. NONE. >=20 > Why did they avoid the AP mode? What's wrong with it in MANETs? APs > can be as small and mobile as any other non-AP nodes. >=20 > The 802.11b association procedure is the same when doing AP mode or > adhoc mode - the messages are the same. The WEP and WPA security is > also available in both modes. WPA2 is not implemented for most adhoc capable cards. > What's wrong with ap mode? AP mode does not work well for MANET, because they are designed for a=20 centralized controll point in the network. A MANET in AP mode would be forc= ed=20 that EVERY node is an AP and all nodes have to be clients of all their=20 neighbors to be able to build a MANET. This configuration is not supported = by=20 most WLAN stacks And you loose the advantages of AP mode as soon as you have multiple APs wi= th=20 overlapping ranges (hidden station APs). Neither PCF nor DCF make sense in= =20 this configuration, because there is no single controller which can decide= =20 that airtime is now "reserved" for it's area of interest. Henning Rogge --nextPart3731855.siZ5rErszZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEABECAAYFAkrnSxcACgkQcenvcwAcHWdFDwCff+8zjbhHYWX7/xnrN33khS+y 1BQAoJRkrIR+b5CzUWuK6NJHa224GW0f =y3jD -----END PGP SIGNATURE----- --nextPart3731855.siZ5rErszZ-- From alexandru.petrescu@gmail.com Tue Oct 27 13:22:32 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 A815728C15E for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 13:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.310, 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 bpy5FZWZXfQo for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 13:22:31 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 9026328C222 for <autoconf@ietf.org>; Tue, 27 Oct 2009 13:22:29 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 3BE76D48173; Tue, 27 Oct 2009 21:22:39 +0100 (CET) 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 CCB3BD4818A; Tue, 27 Oct 2009 21:22:36 +0100 (CET) Message-ID: <4AE7568A.1030206@gmail.com> Date: Tue, 27 Oct 2009 21:22:34 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Henning Rogge <hrogge@googlemail.com> References: <4AE6002C.3020704@gmail.com> <200910271940.59120.hrogge@googlemail.com> <4AE7408C.5060602@gmail.com> <200910272033.43884.hrogge@googlemail.com> In-Reply-To: <200910272033.43884.hrogge@googlemail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091027-0, 27/10/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD problem in IPv6 mesh networks for LL X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 20:22:32 -0000 Henning Rogge a écrit : > Am Dienstag 27 Oktober 2009 19:48:44 schrieb Alexandru Petrescu: >>> I know a lot of MANETs. I have read a lot of papers on them. >> Good. >> >>> NONE of them suggested running a IEEE 802.11 based MANET in >>> access point mode. NONE. >> Why did they avoid the AP mode? What's wrong with it in MANETs? >> APs can be as small and mobile as any other non-AP nodes. >> >> The 802.11b association procedure is the same when doing AP mode or >> adhoc mode - the messages are the same. The WEP and WPA security >> is also available in both modes. > > WPA2 is not implemented for most adhoc capable cards. Ok for "most" and except WPA-NONE which is. (it is secure too). But I think you prefer adhoc mode anyways, which is good for WPA-NONE. >> What's wrong with ap mode? > > AP mode does not work well for MANET, because they are designed for a > centralized controll point in the network. The link-layer AP wifi is centralized, yes, but the IP on top of it not so - DAD running on AP and on Client is fully equipotential (distributed): AP and Client send same NS/NA messages. For AUTOCONF: I believe the ABC problem does not apply as a problem and can't lead to an AUTOCONF solution solving it. > A MANET in AP mode would be forced that EVERY node is an AP and all > nodes have to be clients of all their neighbors to be able to build a > MANET. This configuration is not supported by most WLAN stacks Ok, I agree on that. Let me write my point this way: If two nodes are too far apart - don't put a single IP subnet between them with a fooled node in the middle. Better have two subnets one for AB and one for BC. No need to use /128 prefixes, no need to avoid LLs. If an AP can help here and there then use it, following the wifi manuals. I will write again separately about ABC problem. > And you loose the advantages of AP mode as soon as you have multiple > APs with overlapping ranges (hidden station APs). YEs - make sure to not overlap the AP ranges. It's a wifi guidance ensuring connectivity ok. > Neither PCF nor DCF make sense in this configuration, because there > is no single controller which can decide that airtime is now > "reserved" for it's area of interest. Right. I believe though this is a matter of good planning of the use of the link layer, without which the link-layer breaks. And yes, I know, MANET is unplanned network. Alex > > Henning Rogge From alexandru.petrescu@gmail.com Tue Oct 27 13:56:06 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 D9CF43A68C3 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 13:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.646 X-Spam-Level: X-Spam-Status: No, score=-0.646 tagged_above=-999 required=5 tests=[AWL=-0.997, 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 bnOP7TmcxDPx for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 13:56:06 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 021183A692B for <autoconf@ietf.org>; Tue, 27 Oct 2009 13:56:04 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 9E56AD480C4 for <autoconf@ietf.org>; Tue, 27 Oct 2009 21:56:16 +0100 (CET) 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 69B49D481AF for <autoconf@ietf.org>; Tue, 27 Oct 2009 21:56:12 +0100 (CET) Message-ID: <4AE75E6B.2020601@gmail.com> Date: Tue, 27 Oct 2009 21:56:11 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "autoconf@ietf.org" <autoconf@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 091027-0, 27/10/2009), Outbound message X-Antivirus-Status: Clean Subject: [Autoconf] ABC problem redux X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 27 Oct 2009 20:56:06 -0000 The ABC problem we discussed about recently is about this (substitute A, B and C for the PRs below). MANETARCH draft pictures: > Communication > Range > <~~~~~~+~~~~~~> <~~~~~~+~~~~~~> > Single | <~~~~~~+~~~~~~> | > MANET +-|-+ +-|-+ +-|-+ > Interface |PR1| |PR2| |PR3| > +---+ +---+ +---+ > This may cause a problem because, if PR3 and PR1 have the same LL address (PR2 different), the DAD executing on PR3 and PR1 won't hear each other, so they'll continue using the same LL. Probably, PR2 will get two entries in its NC having the same LL address (of PR1 and 3), yet different MAC addresses. Which may cause problems (not sure which). Link-local addresses are required to be unique on a single link. In this sense - is the medium between PR1-2-3 a single link? I believe no, at least the picture tells me so. If we put two distinct links: one between PR1-2 and one between PR2-3 then the fact that those LLs are duplicated will be less of a problem - each is unique on its own link. Would this solve the ABC problem? Alex From ryuji.wakikawa@gmail.com Tue Oct 27 23:38:25 2009 Return-Path: <ryuji.wakikawa@gmail.com> 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 954BE3A68F1 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 23:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, J_CHICKENPOX_52=0.6] 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 cyNxu0C+ferh for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 23:38:24 -0700 (PDT) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id B43223A6884 for <autoconf@ietf.org>; Tue, 27 Oct 2009 23:38:24 -0700 (PDT) Received: by ywh13 with SMTP id 13so457315ywh.29 for <autoconf@ietf.org>; Tue, 27 Oct 2009 23:38:36 -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=7EvQ5pG4mUQUdGc8037ddnsaJp7tBu94f5a0fTYeHWs=; b=T/142Mcdjd5WzQbrR5IcuVfPt6N/FQKGpb/LzjC4JM7qR/ATkm3VuQ0rSJQue6EiYc xMu+tqbrI+loMN7T5Ij33yeQ8txyr9lkq6PpedBKHt6/DN8g4GDmuPLA+/m1WJazxPGH oMCW75IiL6gTfLsi1/X/qzPDA8c5RQU8M15Rk= 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=QwTI2oXYmpJcZaWZRk37WRYBbWx4TprDltjTwPRxf+C7TQiD93IazWWymH8WaTw7NL lh2WmOSl1BA1qEMKZ4sEiTO2vS3uurHabwz33JcvKDGtdPD9w1F5ghwHLalK/vchOrPN wYjp9JoIino/U0um8F7H/n4/F9qhsRBvsg/gE= Received: by 10.91.103.17 with SMTP id f17mr11745052agm.114.1256711916721; Tue, 27 Oct 2009 23:38:36 -0700 (PDT) Received: from ?10.0.1.2? (c-98-248-44-75.hsd1.ca.comcast.net [98.248.44.75]) by mx.google.com with ESMTPS id 5sm319361yxg.64.2009.10.27.23.38.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 27 Oct 2009 23:38:35 -0700 (PDT) From: Ryuji Wakikawa <ryuji.wakikawa@gmail.com> To: Thomas Heide Clausen <ietf@thomasclausen.org> In-Reply-To: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> Message-Id: <C228A97A-1D28-43CE-8BA4-07A9C7BD3AC5@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 27 Oct 2009 23:38:32 -0700 X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 06:38:25 -0000 Hi all, Reminder, we currently solicit your opinion. The deadline is Thursday. We only have few reply from WG. thanks ryuji On 2009/10/21, at 16:49, Thomas Heide Clausen wrote: > All, > > It appeared to the chairs that the comments raised at the Stockholm > IETF, as well as on the list subsequently, concerning the document: > > http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model > > had been addressed fully by the editors, and to the WGs satisfaction > - at least, there were no issue raised to the latter/latest version > hereof. The chairs therefore found it a good idea to move the > document forward as a WG document, and progress this document as > such. We therefore approved for publication: > > http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model > > We (the chairs) still believe that this is the proper approach in > order to make progress for the WG. > > Do note that the WG is 7 months past the milestone for initial > document submission, and 1 month past the milestone for having > progressed the document to the IESG and/or closed up shop! And, > there has been no discussions (in meetings or on this list) on > alternative candidate documents for the work item which [autoconf] > is chartered to accomplish. > > To put it bluntly, this WG is far far behind schedule and this > document seemed, and still seems, by virtue of having been widely > discussed and agreed upon, as the best shot at making progress for > this WG. > > That said, we (and, this we is also the chairs) will take this > opportunity to ask the WGs opinion on how to progress. If you have > any opinion, please let it be known to the WG (via this mailing > list) before 29/10/09 (i.e. Thursday next week) at noon CET. Please > be specific and constructive, i.e., pick one of: > > o if you think that the WG should proceed with draft-ietf-autoconf- > adhoc-addr-model > as a baseline, say so! > > o if you think there're cardinal (but fixable) issues missing or > wrong with > draft-ietf-autoconf-adhoc-addr-model, then let the WG know what > these > issues are, and propose a solution before the deadline. The Editors > will certainly do their best to address the issues. > > o if you think that draft-ietf-autoconf-adhoc-addr-model is beyond > hope, > let the WG know explicitly how you suggest that we progress at > this point -- > considering the current timeline!! > > Cheers, > > Ryuji & Thomas > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From mase@ie.niigata-u.ac.jp Tue Oct 27 23:49:54 2009 Return-Path: <mase@ie.niigata-u.ac.jp> 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 871AC3A6887 for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 23:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.324 X-Spam-Level: ** X-Spam-Status: No, score=2.324 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 zmlTZeLwkUXw for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 23:49:53 -0700 (PDT) Received: from mxav01.cc.niigata-u.ac.jp (mxav01.cc.niigata-u.ac.jp [133.35.17.129]) by core3.amsl.com (Postfix) with ESMTP id C64EA3A687D for <autoconf@ietf.org>; Tue, 27 Oct 2009 23:49:53 -0700 (PDT) Received: from mxav01.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 245CB4F41E2 for <autoconf@ietf.org>; Wed, 28 Oct 2009 15:50:08 +0900 (JST) Received: from chamame.ie.niigata-u.ac.jp (chamame.ie.niigata-u.ac.jp [133.35.169.34]) by mxav01.cc.niigata-u.ac.jp (Postfix) with SMTP id 122C94F41C9 for <autoconf@ietf.org>; Wed, 28 Oct 2009 15:50:08 +0900 (JST) Received: (qmail 8321 invoked from network); 28 Oct 2009 15:50:02 +0900 Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 28 Oct 2009 15:50:02 +0900 Message-Id: <7.0.0.16.2.20091028154932.06352778@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Wed, 28 Oct 2009 15:50:06 +0900 To: Ryuji Wakikawa <ryuji.wakikawa@gmail.com>, Thomas Heide Clausen <ietf@thomasclausen.org> From: mase <mase@ie.niigata-u.ac.jp> In-Reply-To: <C228A97A-1D28-43CE-8BA4-07A9C7BD3AC5@gmail.com> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <C228A97A-1D28-43CE-8BA4-07A9C7BD3AC5@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress anddraft-ietf-autoconf-adhoc-addr-model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 06:49:54 -0000 Fine with me. Regards. Kenichi At 15:38 09/10/28, Ryuji Wakikawa wrote: >o if you think that the WG should proceed with draft-ietf-autoconf- >adhoc-addr-model > as a baseline, say so! From ryuji.wakikawa@gmail.com Tue Oct 27 23:59:35 2009 Return-Path: <ryuji.wakikawa@gmail.com> 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 37C483A689B for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 23:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 F+KpyBHtmcFA for <autoconf@core3.amsl.com>; Tue, 27 Oct 2009 23:59:34 -0700 (PDT) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 317133A6830 for <autoconf@ietf.org>; Tue, 27 Oct 2009 23:59:33 -0700 (PDT) Received: by ywh13 with SMTP id 13so467015ywh.29 for <autoconf@ietf.org>; Tue, 27 Oct 2009 23:59:45 -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=sWSYyAkloH6xyUhtCBzQXssmvh6NozxGVHg7dtFiCVo=; b=p1/YRpQWQcNJTv/VADbGlrzRugpYYBhxEH7Zqf3TDvN+Z37mVtGwZi8K2col+Gnnh8 CmmYYKNwaoBGLIbcAGih67OUzoUANNdNeIXj7reYDYmMWlOxW3hBWGaxVEANf5DANvcA 29odW2YnTyEM+0vBbmgPl+D9gHjZNVNgz+Q2Q= 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=ZzsvnCQL9JT0Qbd25yh6QjVrnVcmWloMkeu/8c2ml90XbGx4LhETOSrsj69xRZALuf N3SELnavqprpFCPXAgee+3LF0cvgf1quNKkanQp5D7pAN6CWfZvfHOx+KS59d87ZH3yH c0dZW4WtRFgsLlr76dltVMTxXikrLX83tO13k= Received: by 10.150.176.15 with SMTP id y15mr28407475ybe.242.1256713185555; Tue, 27 Oct 2009 23:59:45 -0700 (PDT) Received: from ?10.0.1.2? (c-98-248-44-75.hsd1.ca.comcast.net [98.248.44.75]) by mx.google.com with ESMTPS id 9sm297413ywe.26.2009.10.27.23.59.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 27 Oct 2009 23:59:44 -0700 (PDT) From: Ryuji Wakikawa <ryuji.wakikawa@gmail.com> To: Teco Boot <teco@inf-net.nl> In-Reply-To: <01f901ca56db$5f4bf340$1de3d9c0$@nl> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.com> <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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <125638 9726.5286.65.camel@ac orde.it.uc3m.es> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> Message-Id: <F76FA0EE-E3BB-4280-8C7B-6CD5A7FEDF0F@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 27 Oct 2009 23:59:41 -0700 X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 06:59:35 -0000 Teco, On 2009/10/27, at 0:58, Teco Boot wrote: > Ryuji wrote: > >> The LL address MUST be always verified its uniqueness . > > Total disagreement. > RFC 4862 page 9: > To accommodate > sites that believe the overhead of performing Duplicate Address > Detection outweighs its benefits, the use of Duplicate Address > Detection can be disabled through the administrative setting of a > per-interface configuration flag. If your statement is correct, we don't need DAD at the ethernet link (any link). Do you ever think why IPv6 mandate the DAD even for the ethernet link? why? >> Our addressing model should cover all the possible scenarios. > > Total disagreement. > Our charter says "practical addressing model". > > If we think IPv6 can boil the ocean, to begin with assigning a > unique IPv6 address to each and every molecule, and we Autoconf > punish ourselves to achieve this, I'm sure this WG is on a dead end. AUTOCONF does not prohibit using LL.. I don't know how you will be punished. regards, ryuji > > Regards, Teco > > > From teco@inf-net.nl Wed Oct 28 00:05:21 2009 Return-Path: <teco@inf-net.nl> 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 A8E913A6870 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 00:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.907 X-Spam-Level: X-Spam-Status: No, score=-0.907 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 zKDsBtFJVySM for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 00:05:21 -0700 (PDT) Received: from CPSMTPM-EML104.kpnxchange.com (cpsmtpm-eml104.kpnxchange.com [195.121.3.8]) by core3.amsl.com (Postfix) with ESMTP id BB2573A6830 for <autoconf@ietf.org>; Wed, 28 Oct 2009 00:05:20 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML104.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Wed, 28 Oct 2009 08:05:33 +0100 From: "Teco Boot" <teco@inf-net.nl> To: "'Charles E. Perkins'" <charles.perkins@earthlink.net> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.com> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <25c114b90910270135i788a8a45oc0ac5cf87e2ae52@mail.gmail.com> <4AE6C4B5.1050309@gmail.com> <4AE71FB3.9020702@earthlink.net> In-Reply-To: <4AE71FB3.9020702@earthlink.net> Date: Wed, 28 Oct 2009 08:05:33 +0100 Message-ID: <005001ca579d$0aa1fa70$1fe5ef50$@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: AcpXIoqkuwORwmuyQG6Msg52MV7PgQAeiuxg Content-Language: nl X-OriginalArrivalTime: 28 Oct 2009 07:05:33.0561 (UTC) FILETIME=[0AC47690:01CA579D] Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 07:05:21 -0000 >Charles E. Perkins wrote: >Emmanuel and I wrote an Internet Draft describing the >properties of these links. >Shall we post it again? Yes. I think this draft is very helpful. And please correct or leave out exposed node. Regards, Teco From thomas@thomasclausen.org Wed Oct 28 00:07:07 2009 Return-Path: <thomas@thomasclausen.org> 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 C3C253A68CE for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 00:07:07 -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 IFmpBpEZ8q0m for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 00:07:07 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 1105C3A6830 for <autoconf@ietf.org>; Wed, 28 Oct 2009 00:07:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 5B9F432317AB; Wed, 28 Oct 2009 00:07:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-57-17.w81-249.abo.wanadoo.fr [81.249.151.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 71A793228040; Wed, 28 Oct 2009 00:07:21 -0700 (PDT) Message-Id: <0E3D4BA4-DA3E-4AF7-95B1-133A15939239@thomasclausen.org> From: Thomas Heide Clausen <thomas@thomasclausen.org> To: "Teco Boot" <teco@inf-net.nl> In-Reply-To: <005001ca579d$0aa1fa70$1fe5ef50$@nl> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 28 Oct 2009 08:07:19 +0100 References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.com> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <25c114b90910270135i788a8a45oc0ac5cf87e2ae52@mail.gmail.com> <4AE6C4B5.1050309@gmail.com> <4AE71FB3.9020702@earthlink.net> <005001ca579d$0aa1fa70$1fe5ef50$@nl> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 07:07:07 -0000 Can you remind me, Teco, what was wrong with "exposed node"? Thanks, Thomas On Oct 28, 2009, at 8:05 AM, Teco Boot wrote: >> Charles E. Perkins wrote: >> Emmanuel and I wrote an Internet Draft describing the >> properties of these links. >> Shall we post it again? > > Yes. I think this draft is very helpful. > And please correct or leave out exposed node. > > Regards, Teco > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From ietf@thomasclausen.org Wed Oct 28 00:09:09 2009 Return-Path: <ietf@thomasclausen.org> 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 03B873A68F1 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 00:09:09 -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 eRWLzNMgLDnd for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 00:09:08 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 574CF3A6830 for <autoconf@ietf.org>; Wed, 28 Oct 2009 00:09:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id A65D732317AE; Wed, 28 Oct 2009 00:09:23 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-57-17.w81-249.abo.wanadoo.fr [81.249.151.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id C264132317AB; Wed, 28 Oct 2009 00:09:22 -0700 (PDT) Message-Id: <37D2EFED-EAE1-41A3-880D-FC143C9E84C5@thomasclausen.org> From: Thomas Heide Clausen <ietf@thomasclausen.org> To: mase <mase@ie.niigata-u.ac.jp> In-Reply-To: <7.0.0.16.2.20091028154932.06352778@ie.niigata-u.ac.jp> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 28 Oct 2009 08:09:20 +0100 References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <C228A97A-1D28-43CE-8BA4-07A9C7BD3AC5@gmail.com> <7.0.0.16.2.20091028154932.06352778@ie.niigata-u.ac.jp> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress anddraft-ietf-autoconf-adhoc-addr-model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 07:09:09 -0000 I guess it's hardly a surprise that I also support this document as baseline.. Thomas On Oct 28, 2009, at 7:50 AM, mase wrote: > Fine with me. > > Regards. > Kenichi > > At 15:38 09/10/28, Ryuji Wakikawa wrote: >> o if you think that the WG should proceed with draft-ietf-autoconf- >> adhoc-addr-model >> as a baseline, say so! > > From teco@inf-net.nl Wed Oct 28 00:15:40 2009 Return-Path: <teco@inf-net.nl> 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 87D113A68AF for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 00:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.813 X-Spam-Level: X-Spam-Status: No, score=-1.813 tagged_above=-999 required=5 tests=[AWL=0.786, 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 YE7KjvyrwhNu for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 00:15:39 -0700 (PDT) Received: from CPSMTPM-EML104.kpnxchange.com (cpsmtpm-eml104.kpnxchange.com [195.121.3.8]) by core3.amsl.com (Postfix) with ESMTP id 75F733A68CE for <autoconf@ietf.org>; Wed, 28 Oct 2009 00:15:39 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML104.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Wed, 28 Oct 2009 08:15:53 +0100 From: "Teco Boot" <teco@inf-net.nl> To: "'Charles E. Perkins'" <charles.perkins@earthlink.net> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.com> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <25c114b90910270135i788a8a45oc0ac5cf87e2ae52@mail.gmail.com> <4AE6C4B5.1050309@gmail.com> <4AE71FB3.9020702@earthlink.net> <4AE7280A.30508@gmail.com> <4AE72B8C.5020705@earthlink.net> In-Reply-To: <4AE72B8C.5020705@earthlink.net> Date: Wed, 28 Oct 2009 08:15:53 +0100 Message-ID: <005101ca579e$7c6f2af0$754d80d0$@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: AcpXKZ4GnKhsAvFHS/uLEDkPPYd/CwAdBHPQ Content-Language: nl X-OriginalArrivalTime: 28 Oct 2009 07:15:53.0877 (UTC) FILETIME=[7C812C50:01CA579E] Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 07:15:40 -0000 Hi Charlie, >http://www.potaroo.net/ietf/all-ids/draft-baccelli-multi-hop-wireless- >communication-02.txt > >Feedback is always appreciated, but the main point is that >I believe you already read this draft, and I think it answers >all of your questions about the kinds of wireless network >interfaces under consideration for [autoconf]. I think Autoconf shall also work on other link types. Link types with LLs, DAD and all the usual stuff. Same is true for MANET routing protocols, these shall work also on a broad range of link types (although OLSR - MPR cannot support most of them, see MANET archive for details). Regards, Teco From thomas@thomasclausen.org Wed Oct 28 00:18:18 2009 Return-Path: <thomas@thomasclausen.org> 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 F10293A691A for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 00:18:18 -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 TKiMQV+ZBDfj for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 00:18:18 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 1C3A83A693E for <autoconf@ietf.org>; Wed, 28 Oct 2009 00:18:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 6E93832317AE; Wed, 28 Oct 2009 00:18:33 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-57-17.w81-249.abo.wanadoo.fr [81.249.151.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 8919432317AD; Wed, 28 Oct 2009 00:18:32 -0700 (PDT) Message-Id: <1E985C1A-7EC6-4D32-8CA5-65BCC19EFB9F@thomasclausen.org> From: Thomas Heide Clausen <thomas@thomasclausen.org> To: "Teco Boot" <teco@inf-net.nl> In-Reply-To: <005101ca579e$7c6f2af0$754d80d0$@nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 28 Oct 2009 08:18:30 +0100 References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.com> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <25c114b90910270135i788a8a45oc0ac5cf87e2ae52@mail.gmail.com> <4AE6C4B5.1050309@gmail.com> <4AE71FB3.9020702@earthlink.net> <4AE7280A.30508@gmail.com> <4AE72B8C.5020705@earthlink.net> <005101ca579e$7c6f2af0$754d80d0$@nl> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 07:18:19 -0000 On Oct 28, 2009, at 8:15 AM, Teco Boot wrote: > Hi Charlie, > >> http://www.potaroo.net/ietf/all-ids/draft-baccelli-multi-hop- >> wireless- >> communication-02.txt >> >> Feedback is always appreciated, but the main point is that >> I believe you already read this draft, and I think it answers >> all of your questions about the kinds of wireless network >> interfaces under consideration for [autoconf]. > > I think Autoconf shall also work on other link types. Link types > with LLs, DAD and all the usual stuff. > > Same is true for MANET routing protocols, these shall work also > on a broad range of link types (although OLSR - MPR cannot > support most of them, see MANET archive for details). > I can't let an untrue statement stay unanswered, but I think you must be doing it wrong if you can't make OLSR or MPRs run correctly. That said, I would like to suggest moving the discussions on [manet] routing protocols to the [manet] list. Thanks, Thomas From teco@inf-net.nl Wed Oct 28 00:31:10 2009 Return-Path: <teco@inf-net.nl> 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 C4BBB3A6870 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 00:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[AWL=0.688, 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 IssiDEU0iV+z for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 00:31:09 -0700 (PDT) Received: from CPSMTPM-EML103.kpnxchange.com (cpsmtpm-eml103.kpnxchange.com [195.121.3.7]) by core3.amsl.com (Postfix) with ESMTP id 992053A6403 for <autoconf@ietf.org>; Wed, 28 Oct 2009 00:31:08 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML103.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Wed, 28 Oct 2009 08:31:22 +0100 From: "Teco Boot" <teco@inf-net.nl> To: "'Alexandru Petrescu'" <alexandru.petrescu@gmail.com> References: <4AE6002C.3020704@gmail.com> <200910271710.45170.hrogge@googlemail.com> <4AE72560.3000502@gmail.com> <200910271909.01967.hrogge@googlemail.com> <4AE739F4.8040907@gmail.com> In-Reply-To: <4AE739F4.8040907@gmail.com> Date: Wed, 28 Oct 2009 08:31:22 +0100 Message-ID: <005201ca57a0$a5e4f570$f1aee050$@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: AcpXMjfSdM/1zpKLTIuU1g+QpnLaFAAbYEhA Content-Language: nl X-OriginalArrivalTime: 28 Oct 2009 07:31:22.0622 (UTC) FILETIME=[A61469E0:01CA57A0] Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD problem in IPv6 mesh networks for LL X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 07:31:10 -0000 >Alexandru Petrescu wrote: >The "hidden terminal problem" which seems to be behind this story too, >has already been addressed and solved during 802.11b design, long ago, >at link-layer: DCF. I wish this was true! Maybe DCF partly solves problems for unicast. For multicast, there is not much out there that helps the hidden terminal problem. Regards, Teco From teco@inf-net.nl Wed Oct 28 00:36:02 2009 Return-Path: <teco@inf-net.nl> 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 7A0343A677D for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 00:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[AWL=0.612, 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 zx3WMpu1xZ6z for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 00:36:01 -0700 (PDT) Received: from CPSMTPM-EML105.kpnxchange.com (cpsmtpm-eml105.kpnxchange.com [195.121.3.9]) by core3.amsl.com (Postfix) with ESMTP id 727933A6830 for <autoconf@ietf.org>; Wed, 28 Oct 2009 00:36:01 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML105.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Wed, 28 Oct 2009 08:36:11 +0100 From: "Teco Boot" <teco@inf-net.nl> To: "'Henning Rogge'" <hrogge@googlemail.com> References: <4AE6002C.3020704@gmail.com> <200910271909.01967.hrogge@googlemail.com> <4AE739F4.8040907@gmail.com> <200910271925.21688.hrogge@googlemail.com> In-Reply-To: <200910271925.21688.hrogge@googlemail.com> Date: Wed, 28 Oct 2009 08:36:11 +0100 Message-ID: <005301ca57a1$525761d0$f7062570$@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: AcpXMt6328bOigq+S7iZK9Rb54UnGAAbeXkA Content-Language: nl X-OriginalArrivalTime: 28 Oct 2009 07:36:11.0388 (UTC) FILETIME=[52329BC0:01CA57A1] Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD problem in IPv6 mesh networks for LL X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 07:36:02 -0000 >Henning Rogge wrote: >IEEE 802.11 DCF does only work with access points. MANETs run in adhoc- >mode. DCF: distributed coordination function This is the mode used in all modes, including IBSS. IBSS is often called adhoc mode. Regards, Reco From teco@inf-net.nl Wed Oct 28 00:54:45 2009 Return-Path: <teco@inf-net.nl> 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 112513A6891 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 00:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.550, 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 62Hwo+ZhYsLx for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 00:54:44 -0700 (PDT) Received: from CPSMTPM-EML109.kpnxchange.com (Cpsmtpm-eml109.kpnxchange.com [195.121.3.13]) by core3.amsl.com (Postfix) with ESMTP id B3F873A68C2 for <autoconf@ietf.org>; Wed, 28 Oct 2009 00:54:43 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML109.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Wed, 28 Oct 2009 08:54:56 +0100 From: "Teco Boot" <teco@inf-net.nl> To: "'Charles E. Perkins'" <charles.perkins@earthlink.net> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <125638 9726.5286.65.camel@ac orde.it.uc3m.es> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <4AE71D0C.6000909@earthlin k.net> In-Reply-To: <4AE71D0C.6000909@earthlink.net> Date: Wed, 28 Oct 2009 08:54:56 +0100 Message-ID: <005401ca57a3$f1228ea0$d367abe0$@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: AcpXIPVU5YkSfGN/QVqhI2GHGsSUlQAelYtw Content-Language: nl X-OriginalArrivalTime: 28 Oct 2009 07:54:57.0060 (UTC) FILETIME=[F1268640:01CA57A3] Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 07:54:45 -0000 Hi Charlie, >>> Our addressing model should cover all the possible scenarios. >>> >> >> Total disagreement. >> Our charter says "practical addressing model". >> >> If we think IPv6 can boil the ocean, to begin with assigning a >> unique IPv6 address to each and every molecule, and we Autoconf >> punish ourselves to achieve this, I'm sure this WG is on a dead end. >> > >You are missing the very important point that >the problem of assigning global addresses in an >ad hoc network, without relying on link-local >addresses, has _already been solved_. In multiple >ways. In innovative ways. In boring ways. I made my comment on "all the possible scenarios". We never will reach this goal. I'm sure your "solution" will not work in all cases. What about a MANET merge? This is a common scenario in my environment. What about (unneeded) overhead? How to swap globals when attachment to Internet changes? Uses it classical flooding? Does it provide A unique Interface ID, so it provide also Unique LLs? (but please provide pointers, I'll take a look at it). (( I saw the ref to ietf-manet-autoconf. Shall I comment on the IPv4 LLs ? Oeps, I did! OK, IPv4 LLs work different as was assumed at that time. On answers above: - It provides unique LLs, for IPv4 and IPv6 - MANET merges break guaranteed uniqueness - Classical flooding is used, or maybe some optimization (not described). Overhead can be unacceptable, especially when addresses are defended in whole lifetime. - IPv6 prefix swap for getting globals is supported, Just like BRDP (and others; BRDP is a method to provide the prefix, and is thus complementary). And I don't see how parallel duplicate checks are handled. This was the goal of the protocol, right? )) >It's not boiling the ocean, which may well >dry up before the LL crew admit the >abovementioned reality. I really want to stop the LL discussion ASAP. I suggested text months ago, which I think can be agreed on by all of us. >In fact, convincing the stalwart defenders of >link-local addressing that it can be done, has >proved to be orders of magnitude more difficult >than actually just doing it. This is your opinion. Accepted. But please accept LLs are very useful also. Regards, Teco From teco@inf-net.nl Wed Oct 28 01:21:59 2009 Return-Path: <teco@inf-net.nl> 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 27CDA3A6891 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 01:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 QPqzr4LD9hHS for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 01:21:58 -0700 (PDT) Received: from CPSMTPM-EML104.kpnxchange.com (cpsmtpm-eml104.kpnxchange.com [195.121.3.8]) by core3.amsl.com (Postfix) with ESMTP id DF1B33A67EA for <autoconf@ietf.org>; Wed, 28 Oct 2009 01:21:57 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML104.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Wed, 28 Oct 2009 09:22:11 +0100 From: "Teco Boot" <teco@inf-net.nl> To: "'Ryuji Wakikawa'" <ryuji.wakikawa@gmail.com> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.com> <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> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <125638 9726.5286.65.camel@a c orde.it.uc3m.es> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <F76FA0EE-E3BB-4280-8C7B-6CD5A7FEDF0F@gmail.com> In-Reply-To: <F76FA0EE-E3BB-4280-8C7B-6CD5A7FEDF0F@gmail.com> Date: Wed, 28 Oct 2009 09:22:11 +0100 Message-ID: <005501ca57a7$bfa46f20$3eed4d60$@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: AcpXnD1kOB4RjJ6xSKmrNLYpKqZCJAACJT4w Content-Language: nl X-OriginalArrivalTime: 28 Oct 2009 08:22:11.0700 (UTC) FILETIME=[BF78CB40:01CA57A7] Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 08:21:59 -0000 Hi Ryuji, >>> The LL address MUST be always verified its uniqueness . >> >> Total disagreement. >> RFC 4862 page 9: >> To accommodate >> sites that believe the overhead of performing Duplicate Address >> Detection outweighs its benefits, the use of Duplicate Address >> Detection can be disabled through the administrative setting of a >> per-interface configuration flag. > >If your statement is correct, we don't need DAD at the ethernet link >(any link). >Do you ever think why IPv6 mandate the DAD even for the ethernet link? >why? DAD is *ONLY* required when the flag is set to do so. On high speed Ethernet, the overhead and delay are low, so DAD is not harmful. But on wireless networks, this may be different, and in some of my use cases, it is very, very different. I think that DAD for manual configured addresses is far more important than for EUI-64 or PRN addresses. Even for DHCP assigned, sequenced addresses, DAD helps in cases DHCP cannot ensure uniqueness (I do not like this approach, but I understand the need for it). So it is not mandating or banishing DAD. DAD is a nice tool, enabled by default and disabled when it is harmful. Even in a MANET, I can think of a MANET wide check for uniqueness during generation and 1-hop DAD during lifetime. We can use SeND for it. >>> Our addressing model should cover all the possible scenarios. >> >> Total disagreement. >> Our charter says "practical addressing model". >> >> If we think IPv6 can boil the ocean, to begin with assigning a >> unique IPv6 address to each and every molecule, and we Autoconf >> punish ourselves to achieve this, I'm sure this WG is on a dead end. > >AUTOCONF does not prohibit using LL.. I don't know how you will be >punished. I hope you leave configuring each molecule out of scope for Autoconf. Regards, Teco From emmanuel.baccelli@gmail.com Wed Oct 28 01:23:53 2009 Return-Path: <emmanuel.baccelli@gmail.com> 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 C55B23A6891 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 01:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.824 X-Spam-Level: X-Spam-Status: No, score=-1.824 tagged_above=-999 required=5 tests=[AWL=0.152, 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 YseOJCsg+2gH for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 01:23:52 -0700 (PDT) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id A4E0B3A68E2 for <autoconf@ietf.org>; Wed, 28 Oct 2009 01:23:52 -0700 (PDT) Received: by ywh13 with SMTP id 13so504444ywh.29 for <autoconf@ietf.org>; Wed, 28 Oct 2009 01:24:04 -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=kMr5glPZr+eH9KhfGj3ene9G+6uL1ny7C0EOOQph5zw=; b=ptLv4u/YjUjysC3rx9yJr0azBfOKdmfN30it4omvq6qTTrgx7wMMA4lZ7rO5anlHTs 44u1HuR1VzNz/v+y5E7kcoNRMQN658DImXxctlNMyUtXUHAu/50nFBP/waWSFXaUI9T0 ZQHzeu/sHz3UOOmYLIwsBH7kAPAt2++NPs3uM= 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=cAuVXgrlCyHg+NKE1OfKY1MWEoAmFTeProKrzv/87B3+baLKS0Nv18DUl9YFvFSYPd 7pruTEIsZWMp2vLekI+Ol+rHkJ/ZxT3WE5J5fZScfYxe6VFnY2GAVdkuPjdbxV/l54ge iD6bZDAyfQ/X6IjgpsKnABr0F7iNU7VGPxVYk= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.91.160.29 with SMTP id m29mr1719708ago.67.1256718241264; Wed, 28 Oct 2009 01:24:01 -0700 (PDT) In-Reply-To: <37D2EFED-EAE1-41A3-880D-FC143C9E84C5@thomasclausen.org> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <C228A97A-1D28-43CE-8BA4-07A9C7BD3AC5@gmail.com> <7.0.0.16.2.20091028154932.06352778@ie.niigata-u.ac.jp> <37D2EFED-EAE1-41A3-880D-FC143C9E84C5@thomasclausen.org> From: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr> Date: Wed, 28 Oct 2009 09:23:41 +0100 X-Google-Sender-Auth: 0d0783bd7cf64a61 Message-ID: <be8c8d780910280123v633e06a1u4e0f4d876e89684a@mail.gmail.com> To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=001485f1d9585a74940476fa84fc Subject: Re: [Autoconf] On WG progress anddraft-ietf-autoconf-adhoc-addr-model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 08:23:53 -0000 --001485f1d9585a74940476fa84fc Content-Type: text/plain; charset=ISO-8859-1 I suppose I should also mention I support draft-ietf-autoconf- adhoc-addr-model as baseline. Emmanuel On Wed, Oct 28, 2009 at 8:09 AM, Thomas Heide Clausen < ietf@thomasclausen.org> wrote: > I guess it's hardly a surprise that I also support this document as > baseline.. > > Thomas > > > On Oct 28, 2009, at 7:50 AM, mase wrote: > > Fine with me. >> >> Regards. >> Kenichi >> >> At 15:38 09/10/28, Ryuji Wakikawa wrote: >> >>> o if you think that the WG should proceed with draft-ietf-autoconf- >>> adhoc-addr-model >>> as a baseline, say so! >>> >> >> >> > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > --001485f1d9585a74940476fa84fc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I suppose I should also mention I support=A0draft-ietf-autoconf- adhoc-addr= -model as baseline.=A0<div>Emmanuel<br><br><div class=3D"gmail_quote">On We= d, Oct 28, 2009 at 8:09 AM, Thomas Heide Clausen <span dir=3D"ltr"><<a h= ref=3D"mailto:ietf@thomasclausen.org">ietf@thomasclausen.org</a>></span>= wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;">I guess it's hardly a surprise that I a= lso support this document as baseline..<br><font color=3D"#888888"> <br> Thomas</font><div><div></div><div class=3D"h5"><br> <br> On Oct 28, 2009, at 7:50 AM, mase wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Fine with me.<br> <br> Regards.<br> Kenichi<br> <br> At 15:38 09/10/28, Ryuji Wakikawa wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> o if you think that the WG should proceed with draft-ietf-autoconf- adhoc-a= ddr-model<br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 as a baseline, say so!<br> </blockquote> <br> <br> </blockquote> <br> _______________________________________________<br> Autoconf mailing list<br> <a href=3D"mailto:Autoconf@ietf.org" target=3D"_blank">Autoconf@ietf.org</a= ><br> <a href=3D"https://www.ietf.org/mailman/listinfo/autoconf" target=3D"_blank= ">https://www.ietf.org/mailman/listinfo/autoconf</a><br> </div></div></blockquote></div><br></div> --001485f1d9585a74940476fa84fc-- From teco@inf-net.nl Wed Oct 28 01:32:43 2009 Return-Path: <teco@inf-net.nl> 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 03B973A6931 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 01:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=0.459, 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 aZRzSRWXwSsT for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 01:32:42 -0700 (PDT) Received: from CPSMTPM-EML107.kpnxchange.com (Cpsmtpm-eml107.kpnxchange.com [195.121.3.11]) by core3.amsl.com (Postfix) with ESMTP id 00CA83A6891 for <autoconf@ietf.org>; Wed, 28 Oct 2009 01:32:41 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML107.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Wed, 28 Oct 2009 09:32:52 +0100 From: "Teco Boot" <teco@inf-net.nl> To: "'Thomas Heide Clausen'" <thomas@thomasclausen.org> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.com> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <25c114b90910270135i788a8a45oc0ac5cf87e2ae52@mail.gmail.com> <4AE6C4B5.1050309@gmail.com> <4AE71FB3.9020702@earthlink.net> <005001ca579d$0aa1fa70$1fe5ef50$@nl> <0E3D4BA4-DA3E-4AF7-95B1-133A15939239@thomasclausen.org> In-Reply-To: <0E3D4BA4-DA3E-4AF7-95B1-133A15939239@thomasclausen.org> Date: Wed, 28 Oct 2009 09:32:52 +0100 Message-ID: <005f01ca57a9$3d419c40$b7c4d4c0$@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: AcpXnU3JxLjdwClIRZmNghgjMjyGpwACoBhw Content-Language: nl X-OriginalArrivalTime: 28 Oct 2009 08:32:52.0168 (UTC) FILETIME=[3D387480:01CA57A9] Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 08:32:43 -0000 On: draft-baccelli-multi-hop-wireless-communication-02 >Thomas Heide Clausen wrote: >Can you remind me, Teco, what was wrong with "exposed node"? Figure 2 is correct now. When A sends to B, C is prohibited to send to D due to CS. But if C was not blocked, B still would receive A. So preventing C sending to D is reducing the capacity of the wireless channel (spatial reuse is less optimal). This problem has little to do with IP. Text in error: > Even > though node C cannot hear D, node D can nevertheless hear C, because > node D is outside node A's radio range. And: > the exposed node > problem is a practical example of the asymmetry Here, exposed node has little to do with asymmetry (as defined in same document. Regards, Teco From thomas@thomasclausen.org Wed Oct 28 01:42:21 2009 Return-Path: <thomas@thomasclausen.org> 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 D4EA13A67DA for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 01:42:21 -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 dXa7tsK1zkrj for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 01:42:21 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 04B7B3A67D3 for <autoconf@ietf.org>; Wed, 28 Oct 2009 01:42:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 58A9E32317AF; Wed, 28 Oct 2009 01:42:36 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-57-17.w81-249.abo.wanadoo.fr [81.249.151.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 0926732317AB; Wed, 28 Oct 2009 01:42:34 -0700 (PDT) Message-Id: <13F96869-F259-4D49-9A15-5D4F8756818A@thomasclausen.org> From: Thomas Heide Clausen <thomas@thomasclausen.org> To: "Teco Boot" <teco@inf-net.nl> In-Reply-To: <005f01ca57a9$3d419c40$b7c4d4c0$@nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 28 Oct 2009 09:42:32 +0100 References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.com> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <25c114b90910270135i788a8a45oc0ac5cf87e2ae52@mail.gmail.com> <4AE6C4B5.1050309@gmail.com> <4AE71FB3.9020702@earthlink.net> <005001ca579d$0aa1fa70$1fe5ef50$@nl> <0E3D4BA4-DA3E-4AF7-95B1-133A15939239@thomasclausen.org> <005f01ca57a9$3d419c40$b7c4d4c0$@nl> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org, Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr> Subject: [Autoconf] Discussion on draft-baccelli-multi-hop-wireless-communication-02 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 08:42:21 -0000 Teco, (I change the subject line, as this really is a new thread of discussion) On Oct 28, 2009, at 9:32 AM, Teco Boot wrote: > On: draft-baccelli-multi-hop-wireless-communication-02 > >> Thomas Heide Clausen wrote: >> Can you remind me, Teco, what was wrong with "exposed node"? > > Figure 2 is correct now. > When A sends to B, C is prohibited to send to D due to CS. > But if C was not blocked, B still would receive A. > So preventing C sending to D is reducing the capacity > of the wireless channel (spatial reuse is less optimal). > This problem has little to do with IP. > Alright. > Text in error: >> Even >> though node C cannot hear D, node D can nevertheless hear C, because >> node D is outside node A's radio range. > > And: >> the exposed node >> problem is a practical example of the asymmetry > Here, exposed node has little to do with asymmetry (as defined in same > document. What you say makes sense to me. I'm not an author of that document, and it's not a wg document -- but knowing Charlie/Emmanuel I'm almost willing to bet that they'd be happy to incorporate a change to reflect this (if they agree, of course). Could you propose replacement paragraphs or rewordings? Any other issues that you would like to see addressed in that document? Baccelli/Perkins, feel free to bounce an updated I-D to the list, even if it can't be submitted to the repositories just yet. In my experience, quick turn-around cycles for "alpha's" are a good way of getting both eyes on the document and making rapid progress. We can then discuss in Hiroshima what to do forward? Thanks, Thomas > > > Regards, Teco > > From teco@inf-net.nl Wed Oct 28 01:55:18 2009 Return-Path: <teco@inf-net.nl> 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 7CDBC3A692F for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 01:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=0.423, 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 ZZLvd1fGCp9N for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 01:55:17 -0700 (PDT) Received: from CPSMTPM-EML101.kpnxchange.com (cpsmtpm-eml101.kpnxchange.com [195.121.3.5]) by core3.amsl.com (Postfix) with ESMTP id 3154D3A68DB for <autoconf@ietf.org>; Wed, 28 Oct 2009 01:55:16 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML101.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Wed, 28 Oct 2009 09:55:30 +0100 From: "Teco Boot" <teco@inf-net.nl> To: "'Thomas Heide Clausen'" <thomas@thomasclausen.org> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.com> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <25c114b90910270135i788a8a45oc0ac5cf87e2ae52@mail.gmail.com> <4AE6C4B5.1050309@gmail.com> <4AE71FB3.9020702@earthlink.net> <005001ca579d$0aa1fa70$1fe5ef50$@nl> <0E3D4BA4-DA3E-4AF7-95B1-133A15939239@thomasclausen.org> <005f01ca57a9$3d419c40$b7c4d4c0$@nl> <13F96869-F259-4D49-9A15-5D4F8756818A@thomasclausen.org> In-Reply-To: <13F96869-F259-4D49-9A15-5D4F8756818A@thomasclausen.org> Date: Wed, 28 Oct 2009 09:55:30 +0100 Message-ID: <006101ca57ac$6719b590$354d20b0$@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: AcpXqpuYtk9aBlEiT8GyLRmnL0S6aQAAHi7w Content-Language: nl X-OriginalArrivalTime: 28 Oct 2009 08:55:30.0738 (UTC) FILETIME=[66FDC920:01CA57AC] Cc: autoconf@ietf.org, 'Emmanuel Baccelli' <Emmanuel.Baccelli@inria.fr> Subject: Re: [Autoconf] Discussion on draft-baccelli-multi-hop-wireless-communication-02 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 08:55:18 -0000 All, Just to repeat my responses / opinion on WG documents. I support draft-baccelli-multi-hop-wireless-communication for adoption as WG document. I know it is not our charter, but IMHO the document is very useful. Also, it (partly?) solves an open issue (MANET link model) in the baccelli-autoconf-adhoc -addr-model . I remember an AD saying we are allowed to submit an Informational Document, if it helps achieving our milestones. Did authors present this doc at an Autoconf meeting? Regards, Teco >-----Oorspronkelijk bericht----- >Van: Thomas Heide Clausen [mailto:thomas@thomasclausen.org] >Verzonden: woensdag 28 oktober 2009 9:43 >Aan: Teco Boot >CC: Charles Perkins; autoconf@ietf.org; Emmanuel Baccelli >Onderwerp: Discussion on draft-baccelli-multi-hop-wireless- >communication-02 > >Teco, > >(I change the subject line, as this really is a new thread of >discussion) > >On Oct 28, 2009, at 9:32 AM, Teco Boot wrote: > >> On: draft-baccelli-multi-hop-wireless-communication-02 >> >>> Thomas Heide Clausen wrote: >>> Can you remind me, Teco, what was wrong with "exposed node"? >> >> Figure 2 is correct now. >> When A sends to B, C is prohibited to send to D due to CS. >> But if C was not blocked, B still would receive A. >> So preventing C sending to D is reducing the capacity >> of the wireless channel (spatial reuse is less optimal). >> This problem has little to do with IP. >> > >Alright. > >> Text in error: >>> Even >>> though node C cannot hear D, node D can nevertheless hear C, because >>> node D is outside node A's radio range. >> >> And: >>> the exposed node >>> problem is a practical example of the asymmetry >> Here, exposed node has little to do with asymmetry (as defined in same >> document. > >What you say makes sense to me. > >I'm not an author of that document, and it's not a wg document -- but >knowing Charlie/Emmanuel I'm almost willing to bet that they'd be >happy to incorporate a change to reflect this (if they agree, of >course). Could you propose replacement paragraphs or rewordings? > >Any other issues that you would like to see addressed in that document? > >Baccelli/Perkins, feel free to bounce an updated I-D to the list, even >if it can't be submitted to the repositories just yet. In my >experience, quick turn-around cycles for "alpha's" are a good way of >getting both eyes on the document and making rapid progress. > >We can then discuss in Hiroshima what to do forward? > >Thanks, > >Thomas > >> >> >> Regards, Teco >> >> From alexandru.petrescu@gmail.com Wed Oct 28 01:56:27 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 053B43A6931 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 01:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.084 X-Spam-Level: X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=0.165, 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 T0Zz9VJtrDb6 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 01:56:26 -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 EE2403A67D3 for <autoconf@ietf.org>; Wed, 28 Oct 2009 01:56: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 n9S8ubha016190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Oct 2009 09:56:37 +0100 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 n9S8uan9017038; Wed, 28 Oct 2009 09:56:36 +0100 (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 n9S8uZ2a001690; Wed, 28 Oct 2009 09:56:36 +0100 Message-ID: <4AE80743.6040902@gmail.com> Date: Wed, 28 Oct 2009 09:56:35 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" <charles.perkins@earthlink.net> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A106599CC8@XCH-NW-7V2.nw.nos.boeing.com> <4AA0028C.4030505@earthlink.net> <4ABA5A8F.4020800@gmail.com> <4ABA5E20.8090608@gmail.com> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <125638 9726.5286.65.camel@ac orde.it.uc3m.es> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <1256634091.5090.4.camel@acorde.it.uc3m.es> <4AE6C4C7.5000803@gmail.com> <4AE72001.5040102@earthlink.net> <4AE7283F.9040600@gmail.com> <4AE72902.9010104@earthlink.net> <4AE72F60.50006@gmail .com> <4AE736B9.2060009@earthlink.net> <1256668663.5090.148.camel@acorde.it.uc3m.es> <4AE74350.4010304@earthlink.net> In-Reply-To: <4AE74350.4010304@earthlink.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 08:56:27 -0000 YEs, I support this draft draft-bernardos-manet-autoconf-survey-04 to become a WG item. It is a comprehensive overview of past descriptions of autoconfiguration mechanisms. Once it is a WG item I will have more remarks on it. I will not condition the adoption of this WG item by the deadline of when we start to work because this WG already has many WG items about which I am not sure whether they have been adopted or not by the WG. This draft is good work which should be adopted. It should have been adopted long time in the past. If this WG wanted to deliver only _one_ WG item then I'd prefer it to be this draft. Alex Charles E. Perkins a écrit : > > Hello Carlos, > > Yes, it is the same protocol that you described in your draft. > I think you draft should be considered important background > material for understanding the issues. > > Once we get to work, that is. > > Regards, > Charlie P. > > > Carlos Jesús Bernardos Cano wrote: >> (text skipped) >> >>>> I have to read that solution now. Where is it? >>>> >>>> >>> I'm having a little trouble finding my old documents. >>> This is work done well over five years ago. >>> >>> I'll send another message when I find them. >>> >> >> Maybe it is included in the survey draft we wrote in the past: >> >> http://tools.ietf.org/html/draft-bernardos-manet-autoconf-survey-04 >> >> :-) >> >> Otherwise, let me know to include it in future revisions of the draft. >> >> Thanks, >> >> Carlos >> >> >>> Regards, >>> Charlie P. >>> >>> >>> >>> > > From alexandru.petrescu@gmail.com Wed Oct 28 01:59:06 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 4184C3A6920 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 01:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.786 X-Spam-Level: X-Spam-Status: No, score=-1.786 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_52=0.6] 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-uQBQPhCNW3 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 01:59:05 -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 274F03A682C for <autoconf@ietf.org>; Wed, 28 Oct 2009 01:59:04 -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 n9S8xIJu019462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Oct 2009 09:59:18 +0100 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 n9S8xHoi017864; Wed, 28 Oct 2009 09:59:17 +0100 (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 n9S8xGRV002774; Wed, 28 Oct 2009 09:59:17 +0100 Message-ID: <4AE807E5.6030301@gmail.com> Date: Wed, 28 Oct 2009 09:59:17 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ryuji Wakikawa <ryuji.wakikawa@gmail.com> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <C228A97A-1D28-43CE-8BA4-07A9C7BD3AC5@gmail.com> In-Reply-To: <C228A97A-1D28-43CE-8BA4-07A9C7BD3AC5@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 08:59:06 -0000 Ryuji Wakikawa a écrit : > Hi all, > > Reminder, we currently solicit your opinion. > The deadline is Thursday. We only have few reply from WG. Ryuji - how can you ask opinion on something you've already done? This draft _is_ a WG item. It's called draft-ietf-autoconf-adhoc-addr-model I propose you first retire it. Alex > > thanks > ryuji > > On 2009/10/21, at 16:49, Thomas Heide Clausen wrote: > >> All, >> >> It appeared to the chairs that the comments raised at the Stockholm >> IETF, as well as on the list subsequently, concerning the document: >> >> http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model >> >> had been addressed fully by the editors, and to the WGs satisfaction - >> at least, there were no issue raised to the latter/latest version >> hereof. The chairs therefore found it a good idea to move the document >> forward as a WG document, and progress this document as such. We >> therefore approved for publication: >> >> http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model >> >> We (the chairs) still believe that this is the proper approach in >> order to make progress for the WG. >> >> Do note that the WG is 7 months past the milestone for initial >> document submission, and 1 month past the milestone for having >> progressed the document to the IESG and/or closed up shop! And, there >> has been no discussions (in meetings or on this list) on alternative >> candidate documents for the work item which [autoconf] is chartered to >> accomplish. >> >> To put it bluntly, this WG is far far behind schedule and this >> document seemed, and still seems, by virtue of having been widely >> discussed and agreed upon, as the best shot at making progress for >> this WG. >> >> That said, we (and, this we is also the chairs) will take this >> opportunity to ask the WGs opinion on how to progress. If you have any >> opinion, please let it be known to the WG (via this mailing list) >> before 29/10/09 (i.e. Thursday next week) at noon CET. Please be >> specific and constructive, i.e., pick one of: >> >> o if you think that the WG should proceed with >> draft-ietf-autoconf-adhoc-addr-model >> as a baseline, say so! >> >> o if you think there're cardinal (but fixable) issues missing or wrong >> with >> draft-ietf-autoconf-adhoc-addr-model, then let the WG know >> what these >> issues are, and propose a solution before the deadline. >> The Editors >> will certainly do their best to address the issues. >> >> o if you think that draft-ietf-autoconf-adhoc-addr-model is beyond hope, >> let the WG know explicitly how you suggest that we >> progress at this point -- >> considering the current timeline!! >> >> Cheers, >> >> Ryuji & Thomas >> _______________________________________________ >> 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 ulrich@herberg.name Wed Oct 28 02:01:44 2009 Return-Path: <ulrich@herberg.name> 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 EE1D13A68DB for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 02:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.722 X-Spam-Level: X-Spam-Status: No, score=-0.722 tagged_above=-999 required=5 tests=[AWL=-0.705, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96] 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 4axu8oVMlslC for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 02:01:43 -0700 (PDT) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 6D0D63A68A5 for <autoconf@ietf.org>; Wed, 28 Oct 2009 02:01:43 -0700 (PDT) Received: by bwz23 with SMTP id 23so690373bwz.29 for <autoconf@ietf.org>; Wed, 28 Oct 2009 02:01:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.2.73 with SMTP id 9mr3938532bki.159.1256720514856; Wed, 28 Oct 2009 02:01:54 -0700 (PDT) In-Reply-To: <006101ca57ac$6719b590$354d20b0$@nl> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <25c114b90910270135i788a8a45oc0ac5cf87e2ae52@mail.gmail.com> <4AE6C4B5.1050309@gmail.com> <4AE71FB3.9020702@earthlink.net> <005001ca579d$0aa1fa70$1fe5ef50$@nl> <0E3D4BA4-DA3E-4AF7-95B1-133A15939239@thomasclausen.org> <005f01ca57a9$3d419c40$b7c4d4c0$@nl> <13F96869-F259-4D49-9A15-5D4F8756818A@thomasclausen.org> <006101ca57ac$6719b590$354d20b0$@nl> Date: Wed, 28 Oct 2009 10:01:54 +0100 Message-ID: <25c114b90910280201p6c59c94bg40731ea420e5f6ab@mail.gmail.com> From: Ulrich Herberg <ulrich@herberg.name> To: Teco Boot <teco@inf-net.nl> Content-Type: multipart/alternative; boundary=0015174c4580deba750476fb0b64 Cc: autoconf@ietf.org, Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>, Thomas Heide Clausen <thomas@thomasclausen.org> Subject: Re: [Autoconf] Discussion on draft-baccelli-multi-hop-wireless-communication-02 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 09:01:45 -0000 --0015174c4580deba750476fb0b64 Content-Type: text/plain; charset=ISO-8859-1 Hi, On Wed, Oct 28, 2009 at 9:55 AM, Teco Boot <teco@inf-net.nl> wrote: > All, > > Just to repeat my responses / opinion on WG documents. > > I support draft-baccelli-multi-hop-wireless-communication for > adoption as WG document. I know it is not our charter, but > IMHO the document is very useful. Also, it (partly?) solves > an open issue (MANET link model) in the baccelli-autoconf-adhoc > -addr-model . > I remember an AD saying we are allowed to submit an Informational > Document, if it helps achieving our milestones. > I agree with Teco that the baccelli/perkins document is useful and should become a WG document. However, I am undecided whether this should happen _now_ or only after progressing with an address model draft first. I am not sure whether the IESG would appreciate having a second document right now... If Teco is right, and the AD agrees on having an informational draft, and if that draft helps us to progress, we might publish it now (after some rework, as suggested by Teco in a previous mail). Ulrich > > Did authors present this doc at an Autoconf meeting? > > Regards, Teco > > > > > >-----Oorspronkelijk bericht----- > >Van: Thomas Heide Clausen [mailto:thomas@thomasclausen.org] > >Verzonden: woensdag 28 oktober 2009 9:43 > >Aan: Teco Boot > >CC: Charles Perkins; autoconf@ietf.org; Emmanuel Baccelli > >Onderwerp: Discussion on draft-baccelli-multi-hop-wireless- > >communication-02 > > > >Teco, > > > >(I change the subject line, as this really is a new thread of > >discussion) > > > >On Oct 28, 2009, at 9:32 AM, Teco Boot wrote: > > > >> On: draft-baccelli-multi-hop-wireless-communication-02 > >> > >>> Thomas Heide Clausen wrote: > >>> Can you remind me, Teco, what was wrong with "exposed node"? > >> > >> Figure 2 is correct now. > >> When A sends to B, C is prohibited to send to D due to CS. > >> But if C was not blocked, B still would receive A. > >> So preventing C sending to D is reducing the capacity > >> of the wireless channel (spatial reuse is less optimal). > >> This problem has little to do with IP. > >> > > > >Alright. > > > >> Text in error: > >>> Even > >>> though node C cannot hear D, node D can nevertheless hear C, because > >>> node D is outside node A's radio range. > >> > >> And: > >>> the exposed node > >>> problem is a practical example of the asymmetry > >> Here, exposed node has little to do with asymmetry (as defined in same > >> document. > > > >What you say makes sense to me. > > > >I'm not an author of that document, and it's not a wg document -- but > >knowing Charlie/Emmanuel I'm almost willing to bet that they'd be > >happy to incorporate a change to reflect this (if they agree, of > >course). Could you propose replacement paragraphs or rewordings? > > > >Any other issues that you would like to see addressed in that document? > > > >Baccelli/Perkins, feel free to bounce an updated I-D to the list, even > >if it can't be submitted to the repositories just yet. In my > >experience, quick turn-around cycles for "alpha's" are a good way of > >getting both eyes on the document and making rapid progress. > > > >We can then discuss in Hiroshima what to do forward? > > > >Thanks, > > > >Thomas > > > >> > >> > >> Regards, Teco > >> > >> > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > --0015174c4580deba750476fb0b64 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,<br><br><br><div class=3D"gmail_quote">On Wed, Oct 28, 2009 at 9:55 AM, = Teco Boot <span dir=3D"ltr"><<a href=3D"mailto:teco@inf-net.nl">teco@inf= -net.nl</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D= "border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padd= ing-left: 1ex;"> All,<br> <br> Just to repeat my responses / opinion on WG documents.<br> <br> I support draft-baccelli-multi-hop-wireless-communication for<br> adoption as WG document. I know it is not our charter, but<br> IMHO the document is very useful. Also, it (partly?) solves<br> an open issue (MANET link model) in the baccelli-autoconf-adhoc<br> -addr-model .<br> I remember an AD saying we are allowed to submit an Informational<br> Document, if it helps achieving our milestones.<br></blockquote><div><br><b= r>I agree with Teco that the baccelli/perkins document is useful and should become a WG document. However, I am undecided whether this should happen _now_ or only after progressing with an address model draft first. I am not sure whether the IESG would appreciate having a second docu= ment right now... If Teco is right, and the AD agrees on having an informat= ional draft, and if that draft helps us to progress, we might publish it no= w (after some rework, as suggested by Teco in a previous mail). <br> <br><br>Ulrich<br><br>=A0</div><blockquote class=3D"gmail_quote" style=3D"b= order-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; paddin= g-left: 1ex;"> <br> Did authors present this doc at an Autoconf meeting?<br> <br> Regards, Teco<br> <br> <br> <br> <br> >-----Oorspronkelijk bericht-----<br> >Van: Thomas Heide Clausen [mailto:<a href=3D"mailto:thomas@thomasclause= n.org">thomas@thomasclausen.org</a>]<br> >Verzonden: woensdag 28 oktober 2009 9:43<br> >Aan: Teco Boot<br> >CC: Charles Perkins; <a href=3D"mailto:autoconf@ietf.org">autoconf@ietf= .org</a>; Emmanuel Baccelli<br> >Onderwerp: Discussion on draft-baccelli-multi-hop-wireless-<br> <div><div></div><div class=3D"h5">>communication-02<br> ><br> >Teco,<br> ><br> >(I change the subject line, as this really is a new thread of<br> >discussion)<br> ><br> >On Oct 28, 2009, at 9:32 AM, Teco Boot wrote:<br> ><br> >> On: draft-baccelli-multi-hop-wireless-communication-02<br> >><br> >>> Thomas Heide Clausen wrote:<br> >>> Can you remind me, Teco, what was wrong with "exposed nod= e"?<br> >><br> >> Figure 2 is correct now.<br> >> When A sends to B, C is prohibited to send to D due to CS.<br> >> But if C was not blocked, B still would receive A.<br> >> So preventing C sending to D is reducing the capacity<br> >> of the wireless channel (spatial reuse is less optimal).<br> >> This problem has little to do with IP.<br> >><br> ><br> >Alright.<br> ><br> >> Text in error:<br> >>> Even<br> >>> though node C cannot hear D, node D can nevertheless hear C, b= ecause<br> >>> node D is outside node A's radio range.<br> >><br> >> And:<br> >>> the exposed node<br> >>> problem is a practical example of the asymmetry<br> >> Here, exposed node has little to do with asymmetry (as defined in = same<br> >> document.<br> ><br> >What you say makes sense to me.<br> ><br> >I'm not an author of that document, and it's not a wg document = -- but<br> >knowing Charlie/Emmanuel I'm almost willing to bet that they'd = be<br> >happy to incorporate a change to reflect this (if they agree, of<br> >course). Could you propose replacement paragraphs or rewordings?<br> ><br> >Any other issues that you would like to see addressed in that document?= <br> ><br> >Baccelli/Perkins, feel free to bounce an updated I-D to the list, even<= br> >if it can't be submitted to the repositories just yet. In my<br> >experience, quick turn-around cycles for "alpha's" are a = good way of<br> >getting both eyes on the document and making rapid progress.<br> ><br> >We can then discuss in Hiroshima what to do forward?<br> ><br> >Thanks,<br> ><br> >Thomas<br> ><br> >><br> >><br> >> Regards, Teco<br> >><br> >><br> <br> _______________________________________________<br> Autoconf mailing list<br> <a href=3D"mailto:Autoconf@ietf.org">Autoconf@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/autoconf" target=3D"_blank= ">https://www.ietf.org/mailman/listinfo/autoconf</a><br> </div></div></blockquote></div><br> --0015174c4580deba750476fb0b64-- From thomas@thomasclausen.org Wed Oct 28 02:15:30 2009 Return-Path: <thomas@thomasclausen.org> 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 61F993A699D for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 02:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_52=0.6] 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 XE+Svc4a6AZo for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 02:15:29 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 930C03A6980 for <autoconf@ietf.org>; Wed, 28 Oct 2009 02:15:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id D5A5132317AF; Wed, 28 Oct 2009 02:15:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-57-17.w81-249.abo.wanadoo.fr [81.249.151.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 3D43832317AE; Wed, 28 Oct 2009 02:15:43 -0700 (PDT) Message-Id: <6C98117C-5C99-4548-94A8-E4ADFB0CBF35@thomasclausen.org> From: Thomas Heide Clausen <thomas@thomasclausen.org> To: "Teco Boot" <teco@inf-net.nl> In-Reply-To: <006101ca57ac$6719b590$354d20b0$@nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 28 Oct 2009 10:15:40 +0100 References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.com> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <25c114b90910270135i788a8a45oc0ac5cf87e2ae52@mail.gmail.com> <4AE6C4B5.1050309@gmail.com> <4AE71FB3.9020702@earthlink.net> <005001ca579d$0aa1fa70$1fe5ef50$@nl> <0E3D4BA4-DA3E-4AF7-95B1-133A15939239@thomasclausen.org> <005f01ca57a9$3d419c40$b7c4d4c0$@nl> <13F96869-F259-4D49-9A15-5D4F8756818A@thomasclausen.org> <006101ca57ac$6719b590$354d20b0$@nl> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org, 'Emmanuel Baccelli' <Emmanuel.Baccelli@inria.fr> Subject: Re: [Autoconf] Discussion on draft-baccelli-multi-hop-wireless-communication-02 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 09:15:30 -0000 Teco, Thanks for the support. <wg-chair-hat-on> I think that the first steps should be revival of draft-baccelli-multi- hop-wireless-communication (if the authors are willing - it's an individual I-D), to bring it up to date, incorporating comments etc. I also think that if I propose to our AD to add further documents as wg documents, he'll look at me weirdly and ask 'so where are we with the addressing model, then, the current wg charter item'? If my answer is "we're making great progress, the addressing model actually uses this/these other documents, go look at them on this URL, but I feel we're ready to submit to the IESG within a month", then he'll probably be quite receptive to the idea. Otherwise, I doubt he'll be enthusiastic, considering our spectacular record of not making measurable progress thus far. Therefore, my immediate concern is to get the wg charter item in shape. If this -- or any other document -- is needed for that end, let's advance those as individuals for now. When the WG is certain that there's a strong case for asking the AD to allow us to accept further documents, I'll make that case to the AD. I think that there're no inconveniences to this approach, considering that I think that Baccelli/Perkins are receptive to WG input. To answer your question, I do not think that this document has been presented at an autoconf meeting. Should the authors be interested in doing so in Hiroshima, and should the WG think that it would help, then I don't see any problems in having a slot during the autoconf session for that. Cheers, Thomas On Oct 28, 2009, at 9:55 AM, Teco Boot wrote: > All, > > Just to repeat my responses / opinion on WG documents. > > I support draft-baccelli-multi-hop-wireless-communication for > adoption as WG document. I know it is not our charter, but > IMHO the document is very useful. Also, it (partly?) solves > an open issue (MANET link model) in the baccelli-autoconf-adhoc > -addr-model . > I remember an AD saying we are allowed to submit an Informational > Document, if it helps achieving our milestones. > > Did authors present this doc at an Autoconf meeting? > > Regards, Teco > > > > >> -----Oorspronkelijk bericht----- >> Van: Thomas Heide Clausen [mailto:thomas@thomasclausen.org] >> Verzonden: woensdag 28 oktober 2009 9:43 >> Aan: Teco Boot >> CC: Charles Perkins; autoconf@ietf.org; Emmanuel Baccelli >> Onderwerp: Discussion on draft-baccelli-multi-hop-wireless- >> communication-02 >> >> Teco, >> >> (I change the subject line, as this really is a new thread of >> discussion) >> >> On Oct 28, 2009, at 9:32 AM, Teco Boot wrote: >> >>> On: draft-baccelli-multi-hop-wireless-communication-02 >>> >>>> Thomas Heide Clausen wrote: >>>> Can you remind me, Teco, what was wrong with "exposed node"? >>> >>> Figure 2 is correct now. >>> When A sends to B, C is prohibited to send to D due to CS. >>> But if C was not blocked, B still would receive A. >>> So preventing C sending to D is reducing the capacity >>> of the wireless channel (spatial reuse is less optimal). >>> This problem has little to do with IP. >>> >> >> Alright. >> >>> Text in error: >>>> Even >>>> though node C cannot hear D, node D can nevertheless hear C, >>>> because >>>> node D is outside node A's radio range. >>> >>> And: >>>> the exposed node >>>> problem is a practical example of the asymmetry >>> Here, exposed node has little to do with asymmetry (as defined in >>> same >>> document. >> >> What you say makes sense to me. >> >> I'm not an author of that document, and it's not a wg document -- but >> knowing Charlie/Emmanuel I'm almost willing to bet that they'd be >> happy to incorporate a change to reflect this (if they agree, of >> course). Could you propose replacement paragraphs or rewordings? >> >> Any other issues that you would like to see addressed in that >> document? >> >> Baccelli/Perkins, feel free to bounce an updated I-D to the list, >> even >> if it can't be submitted to the repositories just yet. In my >> experience, quick turn-around cycles for "alpha's" are a good way of >> getting both eyes on the document and making rapid progress. >> >> We can then discuss in Hiroshima what to do forward? >> >> Thanks, >> >> Thomas >> >>> >>> >>> Regards, Teco >>> >>> > From thomas@thomasclausen.org Wed Oct 28 02:22:48 2009 Return-Path: <thomas@thomasclausen.org> 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 DD6EF28B797 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 02:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 fyBVXVRG6f3L for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 02:22:47 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 765B83A67E4 for <autoconf@ietf.org>; Wed, 28 Oct 2009 02:22:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id DAB8C32317AE for <autoconf@ietf.org>; Wed, 28 Oct 2009 02:23:02 -0700 (PDT) X-Quarantine-ID: <QMnfbMQNU8rn> X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net X-Amavis-Alert: BAD HEADER Header line longer than 998 characters: References: <D5...\n Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-57-17.w81-249.abo.wanadoo.fr [81.249.151.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 21D8932317AD for <autoconf@ietf.org>; Wed, 28 Oct 2009 02:23:01 -0700 (PDT) Message-Id: <0E40A7E6-F40B-4210-8811-1277E588744B@thomasclausen.org> From: Thomas Heide Clausen <thomas@thomasclausen.org> To: autoconf@ietf.org In-Reply-To: <4AE80743.6040902@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, 28 Oct 2009 10:23:00 +0100 References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A106599CC8@XCH-NW-7V2.nw.nos.boeing.com> <4AA0028C.4030505@earthlink.net> <4ABA5A8F.4020800@gmail.com> <4ABA5E20.8090608@gmail.com> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <125638 9726.5286.65.camel@ac orde.it.uc3m.es> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <1256634091.5090.4.camel@acorde.it.uc3m.es> <4AE6C4C7.5000803@gmail.com> <4AE72001.5040102@earthlink.net> <4AE7283F.9040600@gmail.com> <4AE72902.9010104@earthlink.net> <4AE72F60.50006@gmail .com> <4AE736B9.2060009@earthlink.net> <1256668663.5090.148.camel@acorde.it.uc3m.es> <4AE74350.4010304@earthlink.net> <4A E80743.6040902@gmail.com> X-Mailer: Apple Mail (2.936) Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 09:22:49 -0000 Without making any comments on the quality and interest in general of =20= raft-bernardos-manet-autoconf-survey, the [autoconf] wg is not =20 chartered to provide a survey of protocols representing a "snapshot at =20= a given time". We're at a juncture where the choices are either (a) pulling the plug =20= on the WG or (b) making progress on the charter item. Note that "adopting new work directions" are not among the choices. Thomas On Oct 28, 2009, at 9:56 AM, Alexandru Petrescu wrote: > YEs, I support this draft draft-bernardos-manet-autoconf-survey-04 =20 > to become a WG item. > > It is a comprehensive overview of past descriptions of =20 > autoconfiguration mechanisms. > > Once it is a WG item I will have more remarks on it. > > I will not condition the adoption of this WG item by the deadline of =20= > when we start to work because this WG already has many WG items =20 > about which I am not sure whether they have been adopted or not by =20 > the WG. > > This draft is good work which should be adopted. It should have =20 > been adopted long time in the past. If this WG wanted to deliver =20 > only _one_ WG item then I'd prefer it to be this draft. > > Alex > > Charles E. Perkins a =E9crit : >> Hello Carlos, >> Yes, it is the same protocol that you described in your draft. >> I think you draft should be considered important background >> material for understanding the issues. >> Once we get to work, that is. >> Regards, >> Charlie P. >> Carlos Jes=FAs Bernardos Cano wrote: >>> (text skipped) >>> >>>>> I have to read that solution now. Where is it? >>>>> >>>>> >>>> I'm having a little trouble finding my old documents. >>>> This is work done well over five years ago. >>>> >>>> I'll send another message when I find them. >>>> >>> >>> Maybe it is included in the survey draft we wrote in the past: >>> >>> http://tools.ietf.org/html/draft-bernardos-manet-autoconf-survey-04 >>> >>> :-) >>> >>> Otherwise, let me know to include it in future revisions of the =20 >>> draft. >>> >>> Thanks, >>> >>> Carlos >>> >>> >>>> Regards, >>>> Charlie P. >>>> >>>> >>>> >>>> > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From charles.perkins@earthlink.net Wed Oct 28 02:22:54 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B972228C0EE for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 02:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 onGApDMbJ0Qt for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 02:22:54 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id EFD9D28C0E5 for <autoconf@ietf.org>; Wed, 28 Oct 2009 02:22:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=c6Rbdx1I+XmaA9iqicBsbu1rFq/mV/bPo9kYK3mNPeb4ps0KS8lYlqDzZYlbt6/2; 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-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N34kH-0000Xh-3u; Wed, 28 Oct 2009 04:23:09 -0500 Message-ID: <4AE80D7C.8020200@earthlink.net> Date: Wed, 28 Oct 2009 02:23:08 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <C228A97A-1D28-43CE-8BA4-07A9C7BD3AC5@gmail.com> <4AE807E5.6030301@gmail.com> In-Reply-To: <4AE807E5.6030301@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52ba787854e8668bc00bd16be7fc86ca12350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 09:22:54 -0000 Hello Alex, Alexandru Petrescu wrote: > Ryuji Wakikawa a écrit : >> Hi all, >> >> Reminder, we currently solicit your opinion. >> The deadline is Thursday. We only have few reply from WG. > > Ryuji - how can you ask opinion on something you've already done? > > This draft _is_ a WG item. > > It's called draft-ietf-autoconf-adhoc-addr-model > > I propose you first retire it. There is no procedure for "retiring" a draft. This seems like obstructionism to me. The chairs thought there was enough consensus to adopt the draft and get moving. There were objections. The chairs now, it seems to me, are asking to verify whether there is enough consensus to confirm the adoption of the draft. What's so hard about that? Regards, Charlie P. From cjbc@it.uc3m.es Wed Oct 28 02:51:39 2009 Return-Path: <cjbc@it.uc3m.es> 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 C83DE3A659B for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 02:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.588 X-Spam-Level: X-Spam-Status: No, score=-5.588 tagged_above=-999 required=5 tests=[AWL=0.111, 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 MmKIrG723Wfw for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 02:51:38 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 8532F28C0DF for <autoconf@ietf.org>; Wed, 28 Oct 2009 02:51:38 -0700 (PDT) Received: from [10.1.5.135] (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 8ABCBBA7BED; Wed, 28 Oct 2009 10:51:50 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano <cjbc@it.uc3m.es> To: "Charles E. Perkins" <charles.perkins@earthlink.net> In-Reply-To: <4AE4ED72.9000707@earthlink.net> References: <20091019233002.15F4328C164@core3.amsl.com> <4ADF8046.8040504@gmail.com> <4ADF9464.9060409@earthlink.net> <1256170228.12205.20.camel@acorde.it.uc3m.es> <4AE090FE.3000001@earthlink.net> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <B4DD4464-E3AF-452B-9BF4-59412C311A0F@thomasclausen.org> <1256493151.4766.58.camel@acorde.it.uc3m.es> <4AE4997E.6090705@earthlink.net> <1256514067.4766.171.camel@acorde.it.uc3m.es> <4AE4ED72.9000707@earthlink.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Z2D9C++34qzNEa0t+9aF" Organization: Universidad Carlos III de Madrid Date: Wed, 28 Oct 2009 10:51:22 +0100 Message-Id: <1256723482.8155.17.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16974.006 Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt 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 <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 09:51:40 -0000 --=-Z2D9C++34qzNEa0t+9aF Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Charlie, On Sun, 2009-10-25 at 17:29 -0700, Charles E. Perkins wrote:=20 > Hello Carlos, >=20 > Carlos Jes=FAs Bernardos Cano wrote: > > > >> Your statement is valid for networks with conformant hosts using > >> IEEE MAC addresses -- but not for all network nodes within the > >> intended sphere of applicability for IPv6 address. > >> =20 > > > > True, for those not using MAC addresses, I think using random iids will > > just make the work OK. > > > > =20 >=20 > Actually, not. >=20 > Please see my other message. >=20 > But, one more thing. >=20 > This philosophy is especially bad because you > will, statistically, _never_ encounter any bugs in > your lab networks. >=20 > Then when your bug shows up in a network > with ten million nodes, you might never find it. >=20 > Never. >=20 > But maybe you would claim that we must then > rely on the small size of ad hoc networks. > At least it would be easier to find your bug, but > it would be extremely tedious and difficult to > trust any debugging tools or your intuition. >=20 > We can't eliminate the need for address > uniqueness by waving the wand of randomness. One question? what is less likely to happen? two IPv6 addresses with iids randomly generated to be unique or that the DAD message (NS sent to the solicited-node multicast address of the target address) is not received (when sent over wireless)? I just want to understand how good is current DAD in current non-MANET wireless networks. Thanks, Carlos >=20 > Regards, > Charlie P. >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-Z2D9C++34qzNEa0t+9aF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkroFBoACgkQNdy6TdFwT2dzgQCeI/+cfGkdBFHCbT9TOtuV/NQg nEwAnRoVOGmqhF7xMKWEF2RYHu/9KG78 =Bels -----END PGP SIGNATURE----- --=-Z2D9C++34qzNEa0t+9aF-- From ulrich@herberg.name Wed Oct 28 02:59:56 2009 Return-Path: <ulrich@herberg.name> 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 D2E3F3A6920 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 02:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[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 VZhCwix8Eqke for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 02:59:56 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by core3.amsl.com (Postfix) with ESMTP id CB6163A68BA for <autoconf@ietf.org>; Wed, 28 Oct 2009 02:59:55 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so1552089fgg.13 for <autoconf@ietf.org>; Wed, 28 Oct 2009 03:00:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.175.80 with SMTP id w16mr3505348bkz.207.1256724007456; Wed, 28 Oct 2009 03:00:07 -0700 (PDT) In-Reply-To: <1256723482.8155.17.camel@acorde.it.uc3m.es> References: <20091019233002.15F4328C164@core3.amsl.com> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <B4DD4464-E3AF-452B-9BF4-59412C311A0F@thomasclausen.org> <1256493151.4766.58.camel@acorde.it.uc3m.es> <4AE4997E.6090705@earthlink.net> <1256514067.4766.171.camel@acorde.it.uc3m.es> <4AE4ED72.9000707@earthlink.net> <1256723482.8155.17.camel@acorde.it.uc3m.es> Date: Wed, 28 Oct 2009 11:00:06 +0100 Message-ID: <25c114b90910280300o4ba93b86g8619eec4916649b2@mail.gmail.com> From: Ulrich Herberg <ulrich@herberg.name> To: cjbc@it.uc3m.es Content-Type: multipart/alternative; boundary=00032555b93a0b90e80476fbdce9 Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 09:59:56 -0000 --00032555b93a0b90e80476fbdce9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Carlos, 2009/10/28 Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es> > [...] > > > One question? what is less likely to happen? two IPv6 addresses with > iids randomly generated to be unique or that the DAD message (NS sent to > the solicited-node multicast address of the target address) is not > received (when sent over wireless)? > The answer is: it depends. ;-) If you have a good random number generator (i.e. using an unambiguous seed), then the collision probability is extremely low. (I let you calculate it using the birthday theorem). However= , if you have small embedded devices, without persistent memory, good random number generator, etc., you can have collisions with a much higher probability. Ulrich > > I just want to understand how good is current DAD in current non-MANET > wireless networks. > > Thanks, > > --00032555b93a0b90e80476fbdce9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Carlos,<br><br><div class=3D"gmail_quote">2009/10/28 Carlos Jes=FAs Bernard= os Cano <span dir=3D"ltr"><<a href=3D"mailto:cjbc@it.uc3m.es">cjbc@it.uc= 3m.es</a>></span><br><blockquote class=3D"gmail_quote" style=3D"border-l= eft: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left:= 1ex;"> [...]<div class=3D"im"> <br> </div><br>One question? what is less likely to happen? two IPv6 addresses w= ith<br> iids randomly generated to be unique or that the DAD message (NS sent to<br= > the solicited-node multicast address of the target address) is not<br> received (when sent over wireless)?<br></blockquote><div><br>The answer is:= it depends. ;-) If you have a good random number generator (i.e. using an = unambiguous seed), then the collision probability is extremely low. (I let = you calculate it using the birthday theorem). However, if you have small em= bedded devices, without persistent memory, good random number generator, et= c., you can have collisions with a much higher probability. =A0 <br> <br>Ulrich<br><br>=A0</div><blockquote class=3D"gmail_quote" style=3D"borde= r-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-le= ft: 1ex;"> <br> I just want to understand how good is current DAD in current non-MANET<br> wireless networks.<br> <div><div></div><div class=3D"h5"><br> Thanks,<br> <br></div></div></blockquote></div> --00032555b93a0b90e80476fbdce9-- From alexandru.petrescu@gmail.com Wed Oct 28 03:08:11 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 58E843A67B3 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 03:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[AWL=0.164, 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 8dAtOnT7znor for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 03:08:10 -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 5339F3A6920 for <autoconf@ietf.org>; Wed, 28 Oct 2009 03:08:10 -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 n9SA8Oil000982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Oct 2009 11:08:24 +0100 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 n9SA8NE9006893; Wed, 28 Oct 2009 11:08:24 +0100 (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 n9SA8NTi031756; Wed, 28 Oct 2009 11:08:23 +0100 Message-ID: <4AE81817.5040603@gmail.com> Date: Wed, 28 Oct 2009 11:08:23 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen <thomas@thomasclausen.org> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.com> <4ABA5A8F.4020800@gmail.com> <4ABA5E20.8090608@gmail.com> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <125638 9726.5286.65.camel@ac orde.it.uc3m.es> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <1256634091.5090.4.camel@acorde.it.uc3m.es> <4AE6C4C7.5000803@gmail.com> <4AE72001.5040102@earthlink.net> <4AE7283F.9040600@gmail.com> <4AE72902.9010104@earthlink.net> <4AE72F60.50006@gmail .com> <4AE736B9.2060009@earthlink.net> <1256668663.5090.148.camel@acorde.it.uc3m.es> <4AE74350.4010304@earthlink.net> <4A E80743.6040902@gmail.com> <0E40A7E6-F40B-4210-8811-1277E588744B@thomasclausen.org> In-Reply-To: <0E40A7E6-F40B-4210-8811-1277E588744B@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 10:08:11 -0000 Thomas Heide Clausen a écrit : > Without making any comments on the quality and interest in general of > raft-bernardos-manet-autoconf-survey, the [autoconf] wg is not chartered > to provide a survey of protocols representing a "snapshot at a given time". I agree it is not now. If, in the future. > We're at a juncture where the choices are either (a) pulling the plug on > the WG or (b) making progress on the charter item. I believe making progress on charter item has started badly. > Note that "adopting new work directions" are not among the choices. Ok, not now. Alex > > Thomas > > On Oct 28, 2009, at 9:56 AM, Alexandru Petrescu wrote: > >> YEs, I support this draft draft-bernardos-manet-autoconf-survey-04 to >> become a WG item. >> >> It is a comprehensive overview of past descriptions of >> autoconfiguration mechanisms. >> >> Once it is a WG item I will have more remarks on it. >> >> I will not condition the adoption of this WG item by the deadline of >> when we start to work because this WG already has many WG items about >> which I am not sure whether they have been adopted or not by the WG. >> >> This draft is good work which should be adopted. It should have been >> adopted long time in the past. If this WG wanted to deliver only >> _one_ WG item then I'd prefer it to be this draft. >> >> Alex >> >> Charles E. Perkins a écrit : >>> Hello Carlos, >>> Yes, it is the same protocol that you described in your draft. >>> I think you draft should be considered important background >>> material for understanding the issues. >>> Once we get to work, that is. >>> Regards, >>> Charlie P. >>> Carlos Jesús Bernardos Cano wrote: >>>> (text skipped) >>>> >>>>>> I have to read that solution now. Where is it? >>>>>> >>>>>> >>>>> I'm having a little trouble finding my old documents. >>>>> This is work done well over five years ago. >>>>> >>>>> I'll send another message when I find them. >>>>> >>>> >>>> Maybe it is included in the survey draft we wrote in the past: >>>> >>>> http://tools.ietf.org/html/draft-bernardos-manet-autoconf-survey-04 >>>> >>>> :-) >>>> >>>> Otherwise, let me know to include it in future revisions of the draft. >>>> >>>> Thanks, >>>> >>>> Carlos >>>> >>>> >>>>> Regards, >>>>> Charlie P. >>>>> >>>>> >>>>> >>>>> >> >> >> _______________________________________________ >> 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 tazaki@sfc.wide.ad.jp Wed Oct 28 03:11:59 2009 Return-Path: <tazaki@sfc.wide.ad.jp> 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 541A73A67BD for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 03:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] 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 zQkQP205tbrg for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 03:11:58 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 6553C3A6889 for <autoconf@ietf.org>; Wed, 28 Oct 2009 03:11:58 -0700 (PDT) Received: from saturn.local.sfc.wide.ad.jp (188.Red-88-14-45.dynamicIP.rima-tde.net [88.14.45.188]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 4ACBC4C0A1; Wed, 28 Oct 2009 19:12:03 +0900 (JST) Date: Wed, 28 Oct 2009 10:11:59 +0000 Message-ID: <m27hufbzf4.wl@sfc.wide.ad.jp> From: Hajime Tazaki<tazaki@sfc.wide.ad.jp> To: ryuji.wakikawa@gmail.com In-Reply-To: <C228A97A-1D28-43CE-8BA4-07A9C7BD3AC5@gmail.com> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <C228A97A-1D28-43CE-8BA4-07A9C7BD3AC5@gmail.com> User-Agent: Wanderlust/2.15.6 (Almost Unreal) Emacs/22.2 Mule/5.0 (SAKAKI) X-Face: "+?b:_s\r$dbBx'Ur*k#`5|~\>v~i`PzaxANTx_S?J>:mTQrtm:c7'f5b~W2eX~Fl[0Pw, 0bow)8r8Z5, D&>]C/'ujqr:fbY>]/52T^Q~cX*y5\?!"i<^Vp=zCNguAeyPH$`ZTv{di25X8, %@! MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 10:11:59 -0000 Hi Chairs, I also support this draft as a baseline. regards, hajime At Tue, 27 Oct 2009 23:38:32 -0700, Ryuji Wakikawa wrote: > >Hi all, > >Reminder, we currently solicit your opinion. >The deadline is Thursday. We only have few reply from WG. > >thanks >ryuji > >On 2009/10/21, at 16:49, Thomas Heide Clausen wrote: > >> All, >> >> It appeared to the chairs that the comments raised at the Stockholm >> IETF, as well as on the list subsequently, concerning the document: >> >> http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model >> >> had been addressed fully by the editors, and to the WGs satisfaction >> - at least, there were no issue raised to the latter/latest version >> hereof. The chairs therefore found it a good idea to move the >> document forward as a WG document, and progress this document as >> such. We therefore approved for publication: >> >> http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model >> >> We (the chairs) still believe that this is the proper approach in >> order to make progress for the WG. >> >> Do note that the WG is 7 months past the milestone for initial >> document submission, and 1 month past the milestone for having >> progressed the document to the IESG and/or closed up shop! And, >> there has been no discussions (in meetings or on this list) on >> alternative candidate documents for the work item which [autoconf] >> is chartered to accomplish. >> >> To put it bluntly, this WG is far far behind schedule and this >> document seemed, and still seems, by virtue of having been widely >> discussed and agreed upon, as the best shot at making progress for >> this WG. >> >> That said, we (and, this we is also the chairs) will take this >> opportunity to ask the WGs opinion on how to progress. If you have >> any opinion, please let it be known to the WG (via this mailing >> list) before 29/10/09 (i.e. Thursday next week) at noon CET. Please >> be specific and constructive, i.e., pick one of: >> >> o if you think that the WG should proceed with draft-ietf-autoconf- >> adhoc-addr-model >> as a baseline, say so! >> >> o if you think there're cardinal (but fixable) issues missing or >> wrong with >> draft-ietf-autoconf-adhoc-addr-model, then let the WG know what >> these >> issues are, and propose a solution before the deadline. The Editors >> will certainly do their best to address the issues. >> >> o if you think that draft-ietf-autoconf-adhoc-addr-model is beyond >> hope, >> let the WG know explicitly how you suggest that we progress at >> this point -- >> considering the current timeline!! >> >> Cheers, >> >> Ryuji & Thomas >> _______________________________________________ >> 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 alexandru.petrescu@gmail.com Wed Oct 28 03:12:24 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 C3C843A67D4 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 03:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[AWL=0.163, 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 CG3vDJukRG5w for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 03:12:24 -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 C3E7C3A68B3 for <autoconf@ietf.org>; Wed, 28 Oct 2009 03:12:23 -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 n9SACZHg024323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Oct 2009 11:12:35 +0100 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 n9SACZQQ008258; Wed, 28 Oct 2009 11:12:35 +0100 (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 n9SACYXI001237; Wed, 28 Oct 2009 11:12:35 +0100 Message-ID: <4AE81912.4040409@gmail.com> Date: Wed, 28 Oct 2009 11:12:34 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" <charles.perkins@earthlink.net> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <C228A97A-1D28-43CE-8BA4-07A9C7BD3AC5@gmail.com> <4AE807E5.6030301@gmail.com> <4AE80D7C.8020200@earthlink.net> In-Reply-To: <4AE80D7C.8020200@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 10:12:24 -0000 Charles E. Perkins a écrit : > > Hello Alex, > > Alexandru Petrescu wrote: >> Ryuji Wakikawa a écrit : >>> Hi all, >>> >>> Reminder, we currently solicit your opinion. >>> The deadline is Thursday. We only have few reply from WG. >> >> Ryuji - how can you ask opinion on something you've already done? >> >> This draft _is_ a WG item. >> >> It's called draft-ietf-autoconf-adhoc-addr-model >> >> I propose you first retire it. > > There is no procedure for "retiring" a draft. Yes, I believe so. I think we may need to propose one. Our Chairs and DT have brought us to a situation unseen before: ask for consensus _after_ having supposed that consensus existed, and _after_ having acted as if that consensus existed - they submitted and approved submission of a WG item. If we realize that was wrong, then we need a procedure to deal with that. Ideas feel free to express how to deal with it. Maybe a new option at tools.ietf.org? > This seems like obstructionism to me. No, not obstructionism - realism. I can also call your action of submitting without WG approval as non-legitimacy, but I won't go that far. > The chairs thought there was enough consensus to adopt the > draft and get moving. There were objections. The chairs now, > it seems to me, are asking to verify whether there is enough > consensus to confirm the adoption of the draft. > > What's so hard about that? Charles - that is your interpretation. I have never seen any other time where people submit WG items before having consensus on the WG. Have you seen? Alex > > Regards, > Charlie P. > > > From teco@inf-net.nl Wed Oct 28 03:23:27 2009 Return-Path: <teco@inf-net.nl> 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 04B893A688E for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 03:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.206 X-Spam-Level: X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=0.393, 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 s+bqXdb4inH7 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 03:23:25 -0700 (PDT) Received: from CPSMTPM-EML102.kpnxchange.com (cpsmtpm-eml102.kpnxchange.com [195.121.3.6]) by core3.amsl.com (Postfix) with ESMTP id 676A33A679C for <autoconf@ietf.org>; Wed, 28 Oct 2009 03:23:24 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML102.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Wed, 28 Oct 2009 11:23:35 +0100 From: "Teco Boot" <teco@inf-net.nl> To: "'Ulrich Herberg'" <ulrich@herberg.name> References: <20091019233002.15F4328C164@core3.amsl.com> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <B4DD4464-E3AF-452B-9BF4-59412C311A0F@thomasclausen.org> <1256493151.4766.58.camel@acorde.it.uc3m.es> <4AE4997E.6090705@earthlink.net> <1256514067.4766.171.camel@acorde.it.uc3m.es> <4AE4ED72.9000707@earthlink.net> <1256723482.8155.17.camel@acorde.it.uc3m.es> <25c114b90910280300o4ba93b86g8619eec4916649b2@mail.gmail.com> In-Reply-To: <25c114b90910280300o4ba93b86g8619eec4916649b2@mail.gmail.com> Date: Wed, 28 Oct 2009 11:23:35 +0100 Message-ID: <008201ca57b8$b53615a0$1fa240e0$@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: AcpXtYXcHzR5+lgEQBionFe8Vv7ixAAAfYEA Content-Language: nl X-OriginalArrivalTime: 28 Oct 2009 10:23:35.0644 (UTC) FILETIME=[B50A71C0:01CA57B8] Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 10:23:27 -0000 Ulrich Herberg wrote: >>One question? what is less likely to happen? two IPv6 addresses with >>iids randomly generated to be unique or that the DAD message (NS sent = to >>the solicited-node multicast address of the target address) is not >>received (when sent over wireless)? >The answer is: it depends. ;-) If you have a good random number=20 >generator (i.e. using an unambiguous seed), then the collision=20 >probability is extremely low. (I let you calculate it using the=20 >birthday theorem).=20 Are birthdays random ?? >However, if you have small embedded devices, without persistent=20 >memory, good random number generator, etc., you can have collisions >with a much higher probability. =A0=20 Why?=20 It is easy to build a pretty good PRN generator with radio HW. I would say it is much, much, much, much easier than uniqueness guarantee with try and error duplicate detection. Not even mentioning total network meltdowns after a first MANET merge. And I don't have those devices, I want to stay far, far from them. And I don't want to run protocols for it in my MANETs. Please provide refs to equipment that you have in mind. First, I'll check why good PRN can't be supported. If not, I can stay=20 far away from these (also having security in mind). Still waiting on answers on DHCP DUID, key generation etc. Regards, Teco From alexandru.petrescu@gmail.com Wed Oct 28 03:54:00 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 75ED13A6883 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 03:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[AWL=0.162, 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 i8UKmndShtZn for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 03:53:59 -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 781E03A659C for <autoconf@ietf.org>; Wed, 28 Oct 2009 03:53:59 -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 n9SAsC5V012011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Oct 2009 11:54:12 +0100 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 n9SAsBqp020480; Wed, 28 Oct 2009 11:54:12 +0100 (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 n9SAsB4t004787; Wed, 28 Oct 2009 11:54:11 +0100 Message-ID: <4AE822D3.2030304@gmail.com> Date: Wed, 28 Oct 2009 11:54:11 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Teco Boot <teco@inf-net.nl> References: <20091019233002.15F4328C164@core3.amsl.com> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <B4DD4464-E3AF-452B-9BF4-59412C311A0F@thomasclausen.org> <1256493151.4766.58.camel@acorde.it.uc3m.es> <4AE4997E.6090705@earthlink.net> <1256514067.4766.171.camel@acorde.it.uc3m.es> <4AE4ED72.9000707@earthlink.net> <1256723482.8155.17.camel@acorde.it.uc3m.es> <25c114b90910280300o4ba93b86g8619eec4916649b2@mail.gmail.com> <008201ca57b8$b53615a0$1fa240e0$@nl> In-Reply-To: <008201ca57b8$b53615a0$1fa240e0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 10:54:00 -0000 Teco Boot a écrit : > Ulrich Herberg wrote: > >>> One question? what is less likely to happen? two IPv6 addresses with >>> iids randomly generated to be unique or that the DAD message (NS sent to >>> the solicited-node multicast address of the target address) is not >>> received (when sent over wireless)? > >> The answer is: it depends. ;-) If you have a good random number >> generator (i.e. using an unambiguous seed), then the collision >> probability is extremely low. (I let you calculate it using the >> birthday theorem). > > Are birthdays random ?? > > >> However, if you have small embedded devices, without persistent >> memory, good random number generator, etc., you can have collisions >> with a much higher probability. > > Why? > It is easy to build a pretty good PRN generator with radio HW. > I would say it is much, much, much, much easier than uniqueness > guarantee with try and error duplicate detection. I agree. Moreover, there is an RFC talking how to select good entropy sources such that the PRN generator is good. (small embedded devices, such as sensors, can constitute good sources of randomness when sampling the temperature, for example - that RFC says). Alex > Not even > mentioning total network meltdowns after a first MANET merge. > > And I don't have those devices, I want to stay far, far from them. > And I don't want to run protocols for it in my MANETs. > Please provide refs to equipment that you have in mind. First, > I'll check why good PRN can't be supported. If not, I can stay > far away from these (also having security in mind). > > Still waiting on answers on DHCP DUID, key generation etc. > > > Regards, Teco > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From jari.arkko@piuha.net Wed Oct 28 04:13:02 2009 Return-Path: <jari.arkko@piuha.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76A793A6774 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 04:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 8BrQAyEPMtld for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 04:13:01 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id E170F3A6954 for <autoconf@ietf.org>; Wed, 28 Oct 2009 04:12:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C6DA1D49AC; Wed, 28 Oct 2009 13:13:14 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2R6bTaYLWYPx; Wed, 28 Oct 2009 13:13:14 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 2E763D49A7; Wed, 28 Oct 2009 13:13:14 +0200 (EET) Message-ID: <4AE82749.4090504@piuha.net> Date: Wed, 28 Oct 2009 13:13:13 +0200 From: Jari Arkko <jari.arkko@piuha.net> User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Thomas Heide Clausen <thomas@thomasclausen.org> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.com> <4ABA5A8F.4020800@gmail.com> <4ABA5E20.8090608@gmail.com> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <125638 9726.5286.65.camel@ac orde.it.uc3m.es> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <1256634091.5090.4.camel@acorde.it.uc3m.es> <4AE6C4C7.5000803@gmail.com> <4AE72001.5040102@earthlink.net> <4AE7283F.9040600@gmail.com> <4AE72902.9010104@earthlink.net> <4AE72F60.50006@gmail .com> <4AE736B9.2060009@earthlink.net> <1256668663.5090.148.camel@acorde.it.uc3m.es> <4AE74350.4010304@earthlink.net> <4A E80743.6040902@gmail.com> <0E40A7E6-F40B-4210-8811-1277E588744B@thomasclausen.org> In-Reply-To: <0E40A7E6-F40B-4210-8811-1277E588744B@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 11:13:02 -0000 > Without making any comments on the quality and interest in general of > raft-bernardos-manet-autoconf-survey, the [autoconf] wg is not > chartered to provide a survey of protocols representing a "snapshot at > a given time". > > We're at a juncture where the choices are either (a) pulling the plug > on the WG or (b) making progress on the charter item. > > Note that "adopting new work directions" are not among the choices. Thomas is correct in the above. You REALLY need to complete the architecture document. Jari From jari.arkko@piuha.net Wed Oct 28 04:20:47 2009 Return-Path: <jari.arkko@piuha.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 719143A67D3 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 04:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 TjWK+jihL1MK for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 04:20:43 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 2A8373A68BA for <autoconf@ietf.org>; Wed, 28 Oct 2009 04:20:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 0E714D49C7; Wed, 28 Oct 2009 13:20:58 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uhx4-hVKaYgC; Wed, 28 Oct 2009 13:20:56 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id B53D0D49A7; Wed, 28 Oct 2009 13:20:56 +0200 (EET) Message-ID: <4AE82918.7070007@piuha.net> Date: Wed, 28 Oct 2009 13:20:56 +0200 From: Jari Arkko <jari.arkko@piuha.net> User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <C228A97A-1D28-43CE-8BA4-07A9C7BD3AC5@gmail.com> <7.0.0.16.2.20091028154932.06352778@ie.niigata-u.ac.jp> <37D2EFED-EAE1-41A3-880D-FC143C9E84C5@thomasclausen.org> <be8c8d780910280123v633e06a1u4e0f4d876e89684a@mail.gmail.com> In-Reply-To: <be8c8d780910280123v633e06a1u4e0f4d876e89684a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress anddraft-ietf-autoconf-adhoc-addr-model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 11:20:47 -0000 I would also like to see the document adopted by the WG. I have read the document today and I'm quite happy with the contents. Jari Emmanuel Baccelli wrote: > I suppose I should also mention I support draft-ietf-autoconf- > adhoc-addr-model as baseline. > Emmanuel > > On Wed, Oct 28, 2009 at 8:09 AM, Thomas Heide Clausen > <ietf@thomasclausen.org <mailto:ietf@thomasclausen.org>> wrote: > > I guess it's hardly a surprise that I also support this document > as baseline.. > > Thomas > > > On Oct 28, 2009, at 7:50 AM, mase wrote: > > Fine with me. > > Regards. > Kenichi > > At 15:38 09/10/28, Ryuji Wakikawa wrote: > > o if you think that the WG should proceed with > draft-ietf-autoconf- adhoc-addr-model > as a baseline, say so! > > > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org <mailto:Autoconf@ietf.org> > https://www.ietf.org/mailman/listinfo/autoconf > > > ------------------------------------------------------------------------ > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From cjbc@it.uc3m.es Wed Oct 28 04:35:05 2009 Return-Path: <cjbc@it.uc3m.es> 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 B32983A68F6 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 04:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=0.100, 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 5WYwKU-jYNn8 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 04:35:04 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id C222C3A67DD for <autoconf@ietf.org>; Wed, 28 Oct 2009 04:35:04 -0700 (PDT) Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id DA455BA7C3E; Wed, 28 Oct 2009 12:35:17 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano <cjbc@it.uc3m.es> To: autoconf@ietf.org Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-aXUeg9lnxeBDpyW+TJgh" Organization: Universidad Carlos III de Madrid Date: Wed, 28 Oct 2009 12:35:19 +0100 Message-Id: <1256729719.8155.80.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16974.007 Subject: [Autoconf] draft-bernardos-autoconf-addressing-model-01.txt 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 <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 11:35:05 -0000 --=-aXUeg9lnxeBDpyW+TJgh Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi all, I guess we have never formally announced our draft on the mailing list. So here it is :) http://www.ietf.org/internet-drafts/draft-bernardos-autoconf-addressing-mod= el-01.txt Please, consider it as work-in-progress. More comments on the draft would be appreciated. We think this would help the WG accomplishing our goal. Thanks, Ronald and Carlos --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-aXUeg9lnxeBDpyW+TJgh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkroLHcACgkQNdy6TdFwT2fkhACeK2Vm8pmvxR624n5WdYetcD0g H44AnjfJQKgg7rtxHN/dqi5/vNV9CxDW =i25o -----END PGP SIGNATURE----- --=-aXUeg9lnxeBDpyW+TJgh-- From cjbc@it.uc3m.es Wed Oct 28 04:36:45 2009 Return-Path: <cjbc@it.uc3m.es> 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 402373A6945 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 04:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.608 X-Spam-Level: X-Spam-Status: No, score=-5.608 tagged_above=-999 required=5 tests=[AWL=0.091, 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 ZgsE1bweuv-h for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 04:36:44 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 572BF3A67DD for <autoconf@ietf.org>; Wed, 28 Oct 2009 04:36:44 -0700 (PDT) Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 5DEF672C510; Wed, 28 Oct 2009 12:36:58 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano <cjbc@it.uc3m.es> To: Jari Arkko <jari.arkko@piuha.net> In-Reply-To: <4AE82918.7070007@piuha.net> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <C228A97A-1D28-43CE-8BA4-07A9C7BD3AC5@gmail.com> <7.0.0.16.2.20091028154932.06352778@ie.niigata-u.ac.jp> <37D2EFED-EAE1-41A3-880D-FC143C9E84C5@thomasclausen.org> <be8c8d780910280123v633e06a1u4e0f4d876e89684a@mail.gmail.com> <4AE82918.7070007@piuha.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-hKq/tx0+XAOggGQB0L0o" Organization: Universidad Carlos III de Madrid Date: Wed, 28 Oct 2009 12:37:00 +0100 Message-Id: <1256729820.8155.82.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16974.007 Cc: autoconf@ietf.org, Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr> Subject: Re: [Autoconf] On WG progress anddraft-ietf-autoconf-adhoc-addr-model 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 <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 11:36:45 -0000 --=-hKq/tx0+XAOggGQB0L0o Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Jari, did you have the chance to take a look at draft-bernardos-autoconf-addressing-model-01.txt? Your feedback would be highly appreciated. Thanks, Carlos On Wed, 2009-10-28 at 13:20 +0200, Jari Arkko wrote: > I would also like to see the document adopted by the WG. >=20 > I have read the document today and I'm quite happy with the contents. >=20 > Jari >=20 > Emmanuel Baccelli wrote: > > I suppose I should also mention I support draft-ietf-autoconf-=20 > > adhoc-addr-model as baseline.=20 > > Emmanuel > > > > On Wed, Oct 28, 2009 at 8:09 AM, Thomas Heide Clausen=20 > > <ietf@thomasclausen.org <mailto:ietf@thomasclausen.org>> wrote: > > > > I guess it's hardly a surprise that I also support this document > > as baseline.. > > > > Thomas > > > > > > On Oct 28, 2009, at 7:50 AM, mase wrote: > > > > Fine with me. > > > > Regards. > > Kenichi > > > > At 15:38 09/10/28, Ryuji Wakikawa wrote: > > > > o if you think that the WG should proceed with > > draft-ietf-autoconf- adhoc-addr-model > > as a baseline, say so! > > > > > > > > > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org <mailto:Autoconf@ietf.org> > > https://www.ietf.org/mailman/listinfo/autoconf > > > > > > -----------------------------------------------------------------------= - > > > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www.ietf.org/mailman/listinfo/autoconf > > =20 >=20 > _______________________________________________ > 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 --=-hKq/tx0+XAOggGQB0L0o Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkroLNwACgkQNdy6TdFwT2dYVgCfWutUkWH0kmCW2xY7RojlqSht TEkAoJrTUPFjg+SwZOZy/K8HCvY7wxQI =jRNj -----END PGP SIGNATURE----- --=-hKq/tx0+XAOggGQB0L0o-- From j.a.cordero@gmail.com Wed Oct 28 04:39:53 2009 Return-Path: <j.a.cordero@gmail.com> 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 193713A67D3 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 04:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, 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 5gst33P1m6yC for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 04:39:52 -0700 (PDT) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id EAF9B3A67DD for <autoconf@ietf.org>; Wed, 28 Oct 2009 04:39:51 -0700 (PDT) Received: by qyk41 with SMTP id 41so422275qyk.29 for <autoconf@ietf.org>; Wed, 28 Oct 2009 04:40:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ne47ixQ4+IJgIUw+IKl756fn8q+4N3mGHeifzQxTrRk=; b=WuUXpkFb3kbZ3ZnTvc7oEUWhdS7CzpMCmGEGtK1GRbtpOQ8n6W0HCs/JEUzsC1tnFv Y0W/I6wHLkND14TCXzRKOS4qpPUYao+cg00I5Cl/eV3tt4zROpboYt/ApDO3K2HjuZll RI+JET8n5hxZalpBU2T8nSp3hXBIKC3zllLNE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CwxUiYeJnKCUBPl3u4kd5yQH6dr2F+6gUOU3xkTfg7dZCw1O0RsRcGZ2s8u5RafY/k flIiFucEBqxME82ir2V2MxKL5KwzvQk//eAEZscK3tNjwilT28nerv2RZw1Z+2j0xFvY ARfulRVU4hv3DtICaJMczksZXO5FgPAezSarg= MIME-Version: 1.0 Received: by 10.220.124.13 with SMTP id s13mr1609977vcr.119.1256730004337; Wed, 28 Oct 2009 04:40:04 -0700 (PDT) In-Reply-To: <4AE82918.7070007@piuha.net> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <C228A97A-1D28-43CE-8BA4-07A9C7BD3AC5@gmail.com> <7.0.0.16.2.20091028154932.06352778@ie.niigata-u.ac.jp> <37D2EFED-EAE1-41A3-880D-FC143C9E84C5@thomasclausen.org> <be8c8d780910280123v633e06a1u4e0f4d876e89684a@mail.gmail.com> <4AE82918.7070007@piuha.net> Date: Wed, 28 Oct 2009 12:40:04 +0100 Message-ID: <23a55e240910280440y6f0d076fnce2234f693202688@mail.gmail.com> From: Juan Antonio Cordero Fuertes <j.a.cordero@gmail.com> To: Jari Arkko <jari.arkko@piuha.net> Content-Type: multipart/alternative; boundary=001636c5a6b27cb58a0476fd4159 Cc: autoconf@ietf.org, Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr> Subject: Re: [Autoconf] On WG progress anddraft-ietf-autoconf-adhoc-addr-model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 11:39:53 -0000 --001636c5a6b27cb58a0476fd4159 Content-Type: text/plain; charset=ISO-8859-1 Having read the draft and tried to follow (with partial success...) the whole discussion, it seems to me that the proposed document is a quite reasonable approach to begin with, in particular considering the need of abstraction and the huge diversity of MANET-like situations to deal with; so I also support the adoption as WG document. Regards, Juan Antonio Cordero 2009/10/28 Jari Arkko <jari.arkko@piuha.net> > I would also like to see the document adopted by the WG. > > I have read the document today and I'm quite happy with the contents. > > Jari > > Emmanuel Baccelli wrote: > >> I suppose I should also mention I support draft-ietf-autoconf- >> adhoc-addr-model as baseline. Emmanuel >> >> On Wed, Oct 28, 2009 at 8:09 AM, Thomas Heide Clausen < >> ietf@thomasclausen.org <mailto:ietf@thomasclausen.org>> wrote: >> >> I guess it's hardly a surprise that I also support this document >> as baseline.. >> >> Thomas >> >> >> On Oct 28, 2009, at 7:50 AM, mase wrote: >> >> Fine with me. >> >> Regards. >> Kenichi >> >> At 15:38 09/10/28, Ryuji Wakikawa wrote: >> >> o if you think that the WG should proceed with >> draft-ietf-autoconf- adhoc-addr-model >> as a baseline, say so! >> >> >> >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org <mailto: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 > --001636c5a6b27cb58a0476fd4159 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Having read the draft and tried to follow (with partial success...) the who= le discussion, it seems to me that the proposed document is a quite reasona= ble approach to begin with, in particular considering the need of abstracti= on and the huge diversity of MANET-like situations to deal with; so I also = support the adoption as WG document.<br> =A0<br>Regards,<br>=A0<br>Juan Antonio Cordero<br><br> <div class=3D"gmail_quote">2009/10/28 Jari Arkko <span dir=3D"ltr"><<a h= ref=3D"mailto:jari.arkko@piuha.net">jari.arkko@piuha.net</a>></span><br> <blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0= px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">I would also like to see the doc= ument adopted by the WG.<br><br>I have read the document today and I'm = quite happy with the contents.<br> <br>Jari<br><br>Emmanuel Baccelli wrote:<br> <blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0= px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"> <div class=3D"im">I suppose I should also mention I support draft-ietf-auto= conf- adhoc-addr-model as baseline. Emmanuel<br><br></div> <div class=3D"im">On Wed, Oct 28, 2009 at 8:09 AM, Thomas Heide Clausen <= ;<a href=3D"mailto:ietf@thomasclausen.org" target=3D"_blank">ietf@thomascla= usen.org</a> <mailto:<a href=3D"mailto:ietf@thomasclausen.org" target=3D= "_blank">ietf@thomasclausen.org</a>>> wrote:<br> <br>=A0 =A0I guess it's hardly a surprise that I also support this docu= ment<br>=A0 =A0as baseline..<br><br>=A0 =A0Thomas<br><br><br>=A0 =A0On Oct = 28, 2009, at 7:50 AM, mase wrote:<br><br>=A0 =A0 =A0 =A0Fine with me.<br><b= r>=A0 =A0 =A0 =A0Regards.<br> =A0 =A0 =A0 =A0Kenichi<br><br>=A0 =A0 =A0 =A0At 15:38 09/10/28, Ryuji Wakik= awa wrote:<br><br>=A0 =A0 =A0 =A0 =A0 =A0o if you think that the WG should = proceed with<br>=A0 =A0 =A0 =A0 =A0 =A0draft-ietf-autoconf- adhoc-addr-mode= l<br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0as = a baseline, say so!<br> <br><br><br><br>=A0 =A0_______________________________________________<br>= =A0 =A0Autoconf mailing list<br></div>=A0 =A0<a href=3D"mailto:Autoconf@iet= f.org" target=3D"_blank">Autoconf@ietf.org</a> <mailto:<a href=3D"mailto= :Autoconf@ietf.org" target=3D"_blank">Autoconf@ietf.org</a>>=20 <div class=3D"im"><br>=A0 =A0<a href=3D"https://www.ietf.org/mailman/listin= fo/autoconf" target=3D"_blank">https://www.ietf.org/mailman/listinfo/autoco= nf</a><br><br><br></div>---------------------------------------------------= ---------------------=20 <div class=3D"im"><br><br>_______________________________________________<b= r>Autoconf mailing list<br><a href=3D"mailto:Autoconf@ietf.org" target=3D"_= blank">Autoconf@ietf.org</a><br><a href=3D"https://www.ietf.org/mailman/lis= tinfo/autoconf" target=3D"_blank">https://www.ietf.org/mailman/listinfo/aut= oconf</a><br> =A0<br></div></blockquote> <div> <div></div> <div class=3D"h5"><br>_______________________________________________<br>Au= toconf mailing list<br><a href=3D"mailto:Autoconf@ietf.org" target=3D"_blan= k">Autoconf@ietf.org</a><br><a href=3D"https://www.ietf.org/mailman/listinf= o/autoconf" target=3D"_blank">https://www.ietf.org/mailman/listinfo/autocon= f</a><br> </div></div></blockquote></div><br> --001636c5a6b27cb58a0476fd4159-- From alexandru.petrescu@gmail.com Wed Oct 28 04:41:26 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 625AB3A6945 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 04:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=0.160, 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 jV9Q-FSDPBB8 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 04:41:25 -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 36EB43A6908 for <autoconf@ietf.org>; Wed, 28 Oct 2009 04:41:25 -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 n9SBfdnO022733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Oct 2009 12:41:39 +0100 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 n9SBfcJ0028755; Wed, 28 Oct 2009 12:41:39 +0100 (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 n9SBfcVU031302; Wed, 28 Oct 2009 12:41:38 +0100 Message-ID: <4AE82DF2.6000408@gmail.com> Date: Wed, 28 Oct 2009 12:41:38 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jari Arkko <jari.arkko@piuha.net> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.com> <4ABA5A8F.4020800@gmail.com> <4ABA5E20.8090608@gmail.com> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <125638 9726.5286.65.camel@ac orde.it.uc3m.es> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <1256634091.5090.4.camel@acorde.it.uc3m.es> <4AE6C4C7.5000803@gmail.com> <4AE72001.5040102@earthlink.net> <4AE7283F.9040600@gmail.com> <4AE72902.9010104@earthlink.net> <4AE72F60.50006@gmail .com> <4AE736B9.2060009@earthlink.net> <1256668663.5090.148.camel@acorde.it.uc3m.es> <4AE74350.4010304@earthlink.net> <4A E80743.6040902@gmail.com> <0E40A7E6-F40B-4210-8811-1277E588744B@thomasclausen.org> <4AE82749.4090504@piu! ha.net> In-Reply-To: <4AE82749.4090504@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, Thomas Heide Clausen <thomas@thomasclausen.org> Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 11:41:26 -0000 Jari Arkko a écrit : > >> Without making any comments on the quality and interest in general of >> raft-bernardos-manet-autoconf-survey, the [autoconf] wg is not >> chartered to provide a survey of protocols representing a "snapshot at >> a given time". >> >> We're at a juncture where the choices are either (a) pulling the plug >> on the WG or (b) making progress on the charter item. >> >> Note that "adopting new work directions" are not among the choices. > > Thomas is correct in the above. You REALLY need to complete the > architecture document. Jari, please allow me to suggest correction to you. We talk about an addressing model document, not the architecture document. I am saying so because there is also an AUTOCONF architecture document "Mobile Ad hoc Network Architecture" - which I think is not what you mean(?). Alex > > Jari > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From ulrich@herberg.name Wed Oct 28 04:42:53 2009 Return-Path: <ulrich@herberg.name> 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 E07A13A6945 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 04:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[AWL=0.329, 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 Z6r3YmF0+MSO for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 04:42:52 -0700 (PDT) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 6A5313A6982 for <autoconf@ietf.org>; Wed, 28 Oct 2009 04:42:52 -0700 (PDT) Received: by bwz23 with SMTP id 23so874009bwz.29 for <autoconf@ietf.org>; Wed, 28 Oct 2009 04:43:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.162.204 with SMTP id w12mr707720bkx.18.1256730184511; Wed, 28 Oct 2009 04:43:04 -0700 (PDT) In-Reply-To: <4AE822D3.2030304@gmail.com> References: <20091019233002.15F4328C164@core3.amsl.com> <B4DD4464-E3AF-452B-9BF4-59412C311A0F@thomasclausen.org> <1256493151.4766.58.camel@acorde.it.uc3m.es> <4AE4997E.6090705@earthlink.net> <1256514067.4766.171.camel@acorde.it.uc3m.es> <4AE4ED72.9000707@earthlink.net> <1256723482.8155.17.camel@acorde.it.uc3m.es> <25c114b90910280300o4ba93b86g8619eec4916649b2@mail.gmail.com> <008201ca57b8$b53615a0$1fa240e0$@nl> <4AE822D3.2030304@gmail.com> Date: Wed, 28 Oct 2009 12:43:04 +0100 Message-ID: <25c114b90910280443q43d0f4b0n3fd8840fff61261@mail.gmail.com> From: Ulrich Herberg <ulrich@herberg.name> To: Alexandru Petrescu <alexandru.petrescu@gmail.com> Content-Type: multipart/alternative; boundary=00032555a49639f37f0476fd4c8d Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 11:42:54 -0000 --00032555a49639f37f0476fd4c8d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alex, Teco, On Wed, Oct 28, 2009 at 11:54 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Teco Boot a =E9crit : > > [..] >>> >>> The answer is: it depends. ;-) If you have a good random number generat= or >>> (i.e. using an unambiguous seed), then the collision probability is >>> extremely low. (I let you calculate it using the birthday theorem). >>> >> >> Are birthdays random ?? >> > Probably not... I can imagine that there are some peeks 9 months after extremely cold and rainy days ;-) I will not dig deeper into this issue :-) > >> >> However, if you have small embedded devices, without persistent memory, >>> good random number generator, etc., you can have collisions >>> with a much higher probability. >>> >> >> Why? It is easy to build a pretty good PRN generator with radio HW. >> I would say it is much, much, much, much easier than uniqueness >> guarantee with try and error duplicate detection. >> > > I agree. Moreover, there is an RFC talking how to select good entropy > sources such that the PRN generator is good. > Do you mean RFC 4086? Yes, as you say, but all depends on selecting a good entropy source. The RFC says: "Is there any hope for true, strong, portable randomness in the future? There might be. All that's needed is a physical source of unpredictable numbers." It also says that if no good hardware entropy sources are available, "there are other possibilities. These include system clocks, system or input/outpu= t buffers, user/system/hardware/network serial numbers or addresses and timing, and user input. Unfortunately, each of these sources can produce very limited or predictable values under some circumstances." So it really depends on the kind of hardware we are talking about. I could imagine very small sensors without persistent state or other hardware sourc= e such as mentioned in the RFC. Using such a device could lead to collisions when calculating random numbers. > (small embedded devices, such as sensors, can constitute good sources of > randomness when sampling the temperature, for example - that RFC says). > yes. But can we guarantee that each MANET router has a good entropy source? Please point me to some reference saying that each device that can be used in a MANET must have a good entropy source. Ulrich > Alex > > Not even >> mentioning total network meltdowns after a first MANET merge. >> >> And I don't have those devices, I want to stay far, far from them. >> And I don't want to run protocols for it in my MANETs. >> Please provide refs to equipment that you have in mind. First, >> I'll check why good PRN can't be supported. If not, I can stay far away >> from these (also having security in mind). >> >> Still waiting on answers on DHCP DUID, key generation etc. >> >> >> Regards, Teco >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >> >> > > --00032555a49639f37f0476fd4c8d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alex, Teco,<br><br><div class=3D"gmail_quote">On Wed, Oct 28, 2009 at 11:54= AM, Alexandru Petrescu <span dir=3D"ltr"><<a href=3D"mailto:alexandru.p= etrescu@gmail.com">alexandru.petrescu@gmail.com</a>></span> wrote:<br><b= lockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 20= 4, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Teco Boot a =E9crit :<div class=3D"im"><br> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> [..]<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(2= 04, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> The answer is: it depends. ;-) If you have a good random number generator (= i.e. using an unambiguous seed), then the collision probability is extremel= y low. (I let you calculate it using the birthday theorem). <br> </blockquote> <br> Are birthdays random ??<br></blockquote></div></blockquote><div><br><br>Pro= bably not... I can imagine that there are some peeks 9 months after extreme= ly cold and rainy days ;-) I will not dig deeper into this issue :-)<br> <br>=A0</div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px so= lid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div= class=3D"im"><blockquote class=3D"gmail_quote" style=3D"border-left: 1px s= olid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <br> <br> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> However, if you have small embedded devices, without persistent memory, goo= d random number generator, etc., you can have collisions<br> with a much higher probability. =A0 <br> </blockquote> <br> Why? It is easy to build a pretty good PRN generator with radio HW.<br> I would say it is much, much, much, much easier than uniqueness<br> guarantee with try and error duplicate detection.<br> </blockquote> <br></div> I agree. =A0Moreover, there is an RFC talking how to select good entropy so= urces such that the PRN generator is good.<br></blockquote><div><br>Do you = mean RFC 4086? Yes, as you say, but all depends on selecting a good entropy= source. The RFC says:<br> <br>"<span style=3D"font-family: courier new,monospace;">Is there any = hope for true, strong, portable randomness in the future? There might be. = All that's needed is a physical source of unpredictable numbers.</span= >"<br> <br>It also says that if no good hardware entropy sources are available, &q= uot;<span style=3D"font-family: courier new,monospace;">there are other p= ossibilities. These include system clocks, system or input/output buffers, = user/system/hardware/network serial numbers or addresses and timing, and us= er input. Unfortunately, each of these sources can produce very limited or= predictable values under some circumstances.</span>"<font face=3D"ari= al,helvetica,sans-serif"><br> <br>So it really depends on the kind of hardware we are talking about. I co= uld imagine very small sensors without persistent state or other hardware s= ource such as mentioned in the RFC. Using such a device could lead to colli= sions when calculating random numbers.<br> </font><br><br></div><blockquote class=3D"gmail_quote" style=3D"border-left= : 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1e= x;"> <br> (small embedded devices, such as sensors, can constitute good sources of<br= > =A0randomness when sampling the temperature, for example - that RFC says).<= br></blockquote><div><br>yes. But can we guarantee that each MANET router h= as a good entropy source? Please point me to some reference saying that eac= h device that can be used in a MANET must have a good entropy source.<br> <br>Ulrich<br><br><br><br></div><blockquote class=3D"gmail_quote" style=3D"= border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; paddi= ng-left: 1ex;"> <br> Alex<br> <br> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class=3D"im"= > Not even<br> mentioning total network meltdowns after a first MANET merge.<br> <br> And I don't have those devices, I want to stay far, far from them.<br> And I don't want to run protocols for it in my MANETs.<br> Please provide refs to equipment that you have in mind. First,<br> I'll check why good PRN can't be supported. If not, I can stay far = away from these (also having security in mind).<br> <br> Still waiting on answers on DHCP DUID, key generation etc.<br> <br> <br> Regards, Teco<br> <br></div><div class=3D"im"> _______________________________________________<br> Autoconf mailing list<br> <a href=3D"mailto:Autoconf@ietf.org" target=3D"_blank">Autoconf@ietf.org</a= ><br> <a href=3D"https://www.ietf.org/mailman/listinfo/autoconf" target=3D"_blank= ">https://www.ietf.org/mailman/listinfo/autoconf</a><br> <br> </div></blockquote> <br> <br> </blockquote></div><br> --00032555a49639f37f0476fd4c8d-- From jari.arkko@piuha.net Wed Oct 28 04:48:44 2009 Return-Path: <jari.arkko@piuha.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2937228C0DF for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 04:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 Wkd0p+1SKAOw for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 04:48:43 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 3CB3C28C0DE for <autoconf@ietf.org>; Wed, 28 Oct 2009 04:48:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2405DD499C; Wed, 28 Oct 2009 13:48:58 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGEN5jaWjSGF; Wed, 28 Oct 2009 13:48:57 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 7AFC2D4997; Wed, 28 Oct 2009 13:48:57 +0200 (EET) Message-ID: <4AE82FA8.2020401@piuha.net> Date: Wed, 28 Oct 2009 13:48:56 +0200 From: Jari Arkko <jari.arkko@piuha.net> User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: ryuji@sfc.wide.ad.jp, Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <4ADF863E.8040408@gmail.com> <6B0ACB39-C603-48FA-89FC-8A887BD1BC7D@gmail.com> <4AE0521C.4090005@gmail.com> <84840efa0910240223r5c9ac9ccrc5553102449da26e@mail.gmail.com> In-Reply-To: <84840efa0910240223r5c9ac9ccrc5553102449da26e@mail.gmail.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "autoconf@ietf.org" <autoconf@ietf.org> Subject: Re: [Autoconf] Procedure X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 11:48:44 -0000 There is no requirement to run an explicit consensus call, if the chairs can determine through discussion or other means that there's widespread support for adoption. Of course, sometimes doing things in the formal way helps you if someone disagrees with the decision, as happened here. I see that Thomas and Ryuji are now doing a formal call -- that's fine. In any case, please, lets not run processes for the sake of the process itself. Lets stop discussing the process and get back to the reason why we are doing this work to begin with. I have not read all mail on the mailing list, but there seemed to be at least a fair amount of support for the current document. Naturally with some people in opposition, and with some alternative suggestions as well. From my point of view, the bottom line is: does someone believe that adoption is unreasonable, given the opinions in the group and the state of the document? If not, lets move on to some more useful discussions. If yes, please speak up now! Jari From alexandru.petrescu@gmail.com Wed Oct 28 04:48:57 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 135B128C0DE for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 04:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[AWL=0.159, 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 SOz64p8waWJ0 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 04:48:56 -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 F40EC28C102 for <autoconf@ietf.org>; Wed, 28 Oct 2009 04:48:55 -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 n9SBn8W7030716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Oct 2009 12:49:08 +0100 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 n9SBn8vd029603; Wed, 28 Oct 2009 12:49:08 +0100 (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 n9SBn7kN000335; Wed, 28 Oct 2009 12:49:08 +0100 Message-ID: <4AE82FB3.9050601@gmail.com> Date: Wed, 28 Oct 2009 12:49:07 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ulrich Herberg <ulrich@herberg.name> References: <20091019233002.15F4328C164@core3.amsl.com> <B4DD4464-E3AF-452B-9BF4-59412C311A0F@thomasclausen.org> <1256493151.4766.58.camel@acorde.it.uc3m.es> <4AE4997E.6090705@earthlink.net> <1256514067.4766.171.camel@acorde.it.uc3m.es> <4AE4ED72.9000707@earthlink.net> <1256723482.8155.17.camel@acorde.it.uc3m.es> <25c114b90910280300o4ba93b86g8619eec4916649b2@mail.gmail.com> <008201ca57b8$b53615a0$1fa240e0$@nl> <4AE822D3.2030304@gmail.com> <25c114b90910280443q43d0f4b0n3fd8840fff61261@mail.gmail.com> In-Reply-To: <25c114b90910280443q43d0f4b0n3fd8840fff61261@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 11:48:57 -0000 Ulrich Herberg a écrit : > Alex, Teco, > > On Wed, Oct 28, 2009 at 11:54 AM, Alexandru Petrescu > <alexandru.petrescu@gmail.com <mailto:alexandru.petrescu@gmail.com>> wrote: > > Teco Boot a écrit : > > [..] > > The answer is: it depends. ;-) If you have a good random > number generator (i.e. using an unambiguous seed), then the > collision probability is extremely low. (I let you calculate > it using the birthday theorem). > > > Are birthdays random ?? > > > > Probably not... I can imagine that there are some peeks 9 months after > extremely cold and rainy days ;-) I will not dig deeper into this issue :-) > > > > > > However, if you have small embedded devices, without > persistent memory, good random number generator, etc., you > can have collisions > with a much higher probability. > > > Why? It is easy to build a pretty good PRN generator with radio HW. > I would say it is much, much, much, much easier than uniqueness > guarantee with try and error duplicate detection. > > > I agree. Moreover, there is an RFC talking how to select good > entropy sources such that the PRN generator is good. > > > Do you mean RFC 4086? Yes, as you say, but all depends on selecting a > good entropy source. The RFC says: > > "Is there any hope for true, strong, portable randomness in the future? > There might be. All that's needed is a physical source of unpredictable > numbers." > > It also says that if no good hardware entropy sources are available, > "there are other possibilities. These include system clocks, system or > input/output buffers, user/system/hardware/network serial numbers or > addresses and timing, and user input. Unfortunately, each of these > sources can produce very limited or predictable values under some > circumstances." > > So it really depends on the kind of hardware we are talking about. Yes, certainly. > I could imagine very small sensors without persistent state or other > hardware source such as mentioned in the RFC. Using such a device > could lead to collisions when calculating random numbers. > > > > (small embedded devices, such as sensors, can constitute good sources of > randomness when sampling the temperature, for example - that RFC says). > > > yes. But can we guarantee that each MANET router has a good entropy > source? Please point me to some reference saying that each device that > can be used in a MANET must have a good entropy source. Well, if there is one, then use it. Just don't discourage them. Alex > > Ulrich > > > > > Alex > > Not even > mentioning total network meltdowns after a first MANET merge. > > And I don't have those devices, I want to stay far, far from them. > And I don't want to run protocols for it in my MANETs. > Please provide refs to equipment that you have in mind. First, > I'll check why good PRN can't be supported. If not, I can stay > far away from these (also having security in mind). > > Still waiting on answers on DHCP DUID, key generation etc. > > > Regards, Teco > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org <mailto:Autoconf@ietf.org> > https://www.ietf.org/mailman/listinfo/autoconf > > > > From alexandru.petrescu@gmail.com Wed Oct 28 04:50:37 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 B506D3A68BA for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 04:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=0.158, 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 mCcQ0n3940Ql for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 04:50:37 -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 BBA4E3A6784 for <autoconf@ietf.org>; Wed, 28 Oct 2009 04:50:36 -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 n9SBoo5Y031665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Oct 2009 12:50:50 +0100 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 n9SBooU2029887; Wed, 28 Oct 2009 12:50:50 +0100 (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 n9SBoneC000764; Wed, 28 Oct 2009 12:50:50 +0100 Message-ID: <4AE83019.5030601@gmail.com> Date: Wed, 28 Oct 2009 12:50:49 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jari Arkko <jari.arkko@piuha.net> References: <4ADF863E.8040408@gmail.com> <6B0ACB39-C603-48FA-89FC-8A887BD1BC7D@gmail.com> <4AE0521C.4090005@gmail.com> <84840efa0910240223r5c9ac9ccrc5553102449da26e@mail.gmail.com> <4AE82FA8.2020401@piuha.net> In-Reply-To: <4AE82FA8.2020401@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "autoconf@ietf.org" <autoconf@ietf.org>, ryuji@sfc.wide.ad.jp Subject: Re: [Autoconf] Procedure X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 11:50:37 -0000 Jari Arkko a écrit : > There is no requirement to run an explicit consensus call, if the chairs > can determine through discussion or other means that there's widespread > support for adoption. Of course, sometimes doing things in the formal > way helps you if someone disagrees with the decision, as happened here. > I see that Thomas and Ryuji are now doing a formal call -- that's fine. > > In any case, please, lets not run processes for the sake of the process > itself. Lets stop discussing the process and get back to the reason why > we are doing this work to begin with. I have not read all mail on the > mailing list, but there seemed to be at least a fair amount of support > for the current document. Naturally with some people in opposition, and > with some alternative suggestions as well. From my point of view, the > bottom line is: does someone believe that adoption is unreasonable, > given the opinions in the group and the state of the document? If not, > lets move on to some more useful discussions. If yes, please speak up now! YEs I believe it is unreasonable to adopt that single document when a competitor document exists and which is technically more inline with what I think. Alex > > Jari > > From jari.arkko@piuha.net Wed Oct 28 04:54:34 2009 Return-Path: <jari.arkko@piuha.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E4793A67DD for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 04:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 Lu-wGnxW9jQS for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 04:54:34 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 94B283A67D3 for <autoconf@ietf.org>; Wed, 28 Oct 2009 04:54:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7D002D493F; Wed, 28 Oct 2009 13:54:48 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCNKIFNna43W; Wed, 28 Oct 2009 13:54:48 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 0E666D4900; Wed, 28 Oct 2009 13:54:48 +0200 (EET) Message-ID: <4AE83107.1070608@piuha.net> Date: Wed, 28 Oct 2009 13:54:47 +0200 From: Jari Arkko <jari.arkko@piuha.net> User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.com> <4ABA5E20.8090608@gmail.com> <4AE08D52.60101@earthlink.net> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <125638 9726.5286.65.camel@ac orde.it.uc3m.es> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <1256634091.5090.4.camel@acorde.it.uc3m.es> <4AE6C4C7.5000803@gmail.com> <4AE72001.5040102@earthlink.net> <4AE7283F.9040600@gmail.com> <4AE72902.9010104@earthlink.net> <4AE72F60.50006@gmail .com> <4AE736B9.2060009@earthlink.net> <1256668663.5090.148.camel@acorde.it.uc3m.es> <4AE74350.4010304@earthlink.net> <4A E80743.6040902@gmail.com> <0E40A7E6-F40B-4210-8811-1277E588744B@thomasclausen.org> <4AE82749.4090504@piu! ha.net> <4AE82DF2.6000408@gma il.com> In-Reply-To: <4AE82DF2.6000408@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org, Thomas Heide Clausen <thomas@thomasclausen.org> Subject: Re: [Autoconf] DAD, link-locals, two drafts and making up my mind X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 11:54:34 -0000 Alex - yes I did mean the addressing model document. Sorry for the confusion. Jari From jari.arkko@piuha.net Wed Oct 28 04:57:24 2009 Return-Path: <jari.arkko@piuha.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAA8828C0FE for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 04:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 UJ+FWmfS5T1t for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 04:57:24 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 361C63A694C for <autoconf@ietf.org>; Wed, 28 Oct 2009 04:57:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2053ED4904; Wed, 28 Oct 2009 13:57:39 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gWlU2rZEE3J; Wed, 28 Oct 2009 13:57:38 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 98527D4900; Wed, 28 Oct 2009 13:57:38 +0200 (EET) Message-ID: <4AE831B2.3040304@piuha.net> Date: Wed, 28 Oct 2009 13:57:38 +0200 From: Jari Arkko <jari.arkko@piuha.net> User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <4ADF863E.8040408@gmail.com> <6B0ACB39-C603-48FA-89FC-8A887BD1BC7D@gmail.com> <4AE0521C.4090005@gmail.com> <84840efa0910240223r5c9ac9ccrc5553102449da26e@mail.gmail.com> <4AE82FA8.2020401@piuha.net> <4AE83019.5030601@gmail.com> In-Reply-To: <4AE83019.5030601@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "autoconf@ietf.org" <autoconf@ietf.org>, ryuji@sfc.wide.ad.jp Subject: Re: [Autoconf] Procedure X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 11:57:25 -0000 Alex, > YEs I believe it is unreasonable to adopt that single document when a > competitor document exists and which is technically more inline with > what I think. I am aware that you wanted to see the other document adopted instead. But note that I said "given the opinions in the group" and not any individual's opinion. We all know that there is no unanimous agreement about this, but I was curious if someone thought that the chairs had somehow missed that a large part of the group disagreed with the idea of adopting the DT document. Jari From teco@inf-net.nl Wed Oct 28 05:12:58 2009 Return-Path: <teco@inf-net.nl> 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 30D153A697D for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 05:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=0.367, 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 IlSWNOtb424x for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 05:12:57 -0700 (PDT) Received: from CPSMTPM-EML107.kpnxchange.com (Cpsmtpm-eml107.kpnxchange.com [195.121.3.11]) by core3.amsl.com (Postfix) with ESMTP id AE8133A69D6 for <autoconf@ietf.org>; Wed, 28 Oct 2009 05:12:55 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML107.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Wed, 28 Oct 2009 13:13:09 +0100 From: "Teco Boot" <teco@inf-net.nl> To: "'Ulrich Herberg'" <ulrich@herberg.name> References: <20091019233002.15F4328C164@core3.amsl.com> <B4DD4464-E3AF-452B-9BF4-59412C311A0F@thomasclausen.org> <1256493151.4766.58.camel@acorde.it.uc3m.es> <4AE4997E.6090705@earthlink.net> <1256514067.4766.171.camel@acorde.it.uc3m.es> <4AE4ED72.9000707@earthlink.net> <1256723482.8155.17.camel@acorde.it.uc3m.es> <25c114b90910280300o4ba93b86g8619eec4916649b2@mail.gmail.com> <008201ca57b8$b53615a0$1fa240e0$@nl> <4AE822D3.2030304@gmail.com> <25c114b90910280443q43d0f4b0n3fd8840fff61261@mail.gmail.com> In-Reply-To: <25c114b90910280443q43d0f4b0n3fd8840fff61261@mail.gmail.com> Date: Wed, 28 Oct 2009 13:13:09 +0100 Message-ID: <00ad01ca57c8$03a0b560$0ae22020$@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: AcpXw9GW+YY7Hi1rRbCPzJqw9vvjVQAAtoGw Content-Language: nl X-OriginalArrivalTime: 28 Oct 2009 12:13:09.0637 (UTC) FILETIME=[03722B50:01CA57C8] Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 12:12:58 -0000 Hi Ulrich, Few things. Please realize your rich text mails is becoming a mess, when=20 replied with other tools. This troubles the already troubled discussion. I stop cleaning up. Then on the small stuff: we are working on MANET stuff, OK? We have a radio, right? We can use this radio for catching background noise, right? This is either thermal noise, human made noise, interference, timing,=20 timing of packets received, just to come up with a few. Please let me know this does not make sense. Because then, I want to be warned and want to stay far, far away from such devices. You were active on MANET and security. Spend some cycles on PRN for small embedded devices with radios? I don't want to push you, but it would help us if you do. Regards, Teco Van: Ulrich Herberg [mailto:ulrich@herberg.name]=20 Verzonden: woensdag 28 oktober 2009 12:43 Aan: Alexandru Petrescu CC: Teco Boot; autoconf@ietf.org Onderwerp: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt Alex, Teco, On Wed, Oct 28, 2009 at 11:54 AM, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote: Teco Boot a =E9crit : [..] The answer is: it depends. ;-) If you have a good random number = generator (i.e. using an unambiguous seed), then the collision probability is extremely low. (I let you calculate it using the birthday theorem).=20 Are birthdays random ?? Probably not... I can imagine that there are some peeks 9 months after extremely cold and rainy days ;-) I will not dig deeper into this issue = :-) =A0 However, if you have small embedded devices, without persistent memory, = good random number generator, etc., you can have collisions with a much higher probability. =A0=20 Why? It is easy to build a pretty good PRN generator with radio HW. I would say it is much, much, much, much easier than uniqueness guarantee with try and error duplicate detection. I agree. =A0Moreover, there is an RFC talking how to select good entropy sources such that the PRN generator is good. Do you mean RFC 4086? Yes, as you say, but all depends on selecting a = good entropy source. The RFC says: "Is there any hope for true, strong, portable randomness in the future? There might be. All that's needed is a physical source of unpredictable numbers." It also says that if no good hardware entropy sources are available, = "there are other possibilities. These include system clocks, system or = input/output buffers, user/system/hardware/network serial numbers or addresses and timing, and user input. Unfortunately, each of these sources can produce very limited or predictable values under some circumstances." So it really depends on the kind of hardware we are talking about. I = could imagine very small sensors without persistent state or other hardware = source such as mentioned in the RFC. Using such a device could lead to = collisions when calculating random numbers. (small embedded devices, such as sensors, can constitute good sources of =A0randomness when sampling the temperature, for example - that RFC = says). yes. But can we guarantee that each MANET router has a good entropy = source? Please point me to some reference saying that each device that can be = used in a MANET must have a good entropy source. Ulrich Alex Not even mentioning total network meltdowns after a first MANET merge. And I don't have those devices, I want to stay far, far from them. And I don't want to run protocols for it in my MANETs. Please provide refs to equipment that you have in mind. First, I'll check why good PRN can't be supported. If not, I can stay far away = from these (also having security in mind). Still waiting on answers on DHCP DUID, key generation etc. Regards, Teco _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From Cedric.Adjih@INRIA.fr Wed Oct 28 05:13:01 2009 Return-Path: <Cedric.Adjih@INRIA.fr> 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 57AB228C10D for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 05:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_52=0.6, 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 0sW8zFdUpFvS for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 05:13:00 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id DAB9128C0F1 for <autoconf@ietf.org>; Wed, 28 Oct 2009 05:12:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,639,1249250400"; d="scan'208";a="39091968" Received: from canith.inria.fr (HELO [128.93.17.134]) ([128.93.17.134]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Oct 2009 13:13:13 +0100 Message-ID: <4AE83500.40606@INRIA.fr> Date: Wed, 28 Oct 2009 13:11:44 +0100 From: Cedric Adjih <Cedric.Adjih@INRIA.fr> User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: autoconf@ietf.org References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <C228A97A-1D28-43CE-8BA4-07A9C7BD3AC5@gmail.com> In-Reply-To: <C228A97A-1D28-43CE-8BA4-07A9C7BD3AC5@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 12:13:01 -0000 My opinion is that the WG should proceed with draft-ietf-autoconf-adhoc-addr-model as a baseline. -- Cedric Ryuji Wakikawa wrote: > Hi all, > > Reminder, we currently solicit your opinion. > The deadline is Thursday. We only have few reply from WG. > > thanks > ryuji > > On 2009/10/21, at 16:49, Thomas Heide Clausen wrote: > >> All, >> >> It appeared to the chairs that the comments raised at the Stockholm >> IETF, as well as on the list subsequently, concerning the document: >> >> http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model >> >> had been addressed fully by the editors, and to the WGs satisfaction - >> at least, there were no issue raised to the latter/latest version >> hereof. The chairs therefore found it a good idea to move the document >> forward as a WG document, and progress this document as such. We >> therefore approved for publication: >> >> http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model >> >> We (the chairs) still believe that this is the proper approach in >> order to make progress for the WG. >> >> Do note that the WG is 7 months past the milestone for initial >> document submission, and 1 month past the milestone for having >> progressed the document to the IESG and/or closed up shop! And, there >> has been no discussions (in meetings or on this list) on alternative >> candidate documents for the work item which [autoconf] is chartered to >> accomplish. >> >> To put it bluntly, this WG is far far behind schedule and this >> document seemed, and still seems, by virtue of having been widely >> discussed and agreed upon, as the best shot at making progress for >> this WG. >> >> That said, we (and, this we is also the chairs) will take this >> opportunity to ask the WGs opinion on how to progress. If you have any >> opinion, please let it be known to the WG (via this mailing list) >> before 29/10/09 (i.e. Thursday next week) at noon CET. Please be >> specific and constructive, i.e., pick one of: >> >> o if you think that the WG should proceed with >> draft-ietf-autoconf-adhoc-addr-model >> as a baseline, say so! >> >> o if you think there're cardinal (but fixable) issues missing or wrong >> with >> draft-ietf-autoconf-adhoc-addr-model, then let the WG know >> what these >> issues are, and propose a solution before the deadline. >> The Editors >> will certainly do their best to address the issues. >> >> o if you think that draft-ietf-autoconf-adhoc-addr-model is beyond hope, >> let the WG know explicitly how you suggest that we >> progress at this point -- >> considering the current timeline!! >> >> Cheers, >> >> Ryuji & Thomas >> _______________________________________________ >> 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 jari.arkko@piuha.net Wed Oct 28 05:13:42 2009 Return-Path: <jari.arkko@piuha.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFA503A69C6 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 05:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 4GCH1LXyRBnh for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 05:13:42 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id CEA543A69BD for <autoconf@ietf.org>; Wed, 28 Oct 2009 05:13:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id BB51DD4924; Wed, 28 Oct 2009 14:13:56 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWPImwJYVrau; Wed, 28 Oct 2009 14:13:56 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 25266D491D; Wed, 28 Oct 2009 14:13:56 +0200 (EET) Message-ID: <4AE83583.7090906@piuha.net> Date: Wed, 28 Oct 2009 14:13:55 +0200 From: Jari Arkko <jari.arkko@piuha.net> User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <C228A97A-1D28-43CE-8BA4-07A9C7BD3AC5@gmail.com> <7.0.0.16.2.20091028154932.06352778@ie.niigata-u.ac.jp> <37D2EFED-EAE1-41A3-880D-FC143C9E84C5@thomasclausen.org> <be8c8d780910280123v633e06a1u4e0f4d876e89684a@mail.gmail.com> <4AE82918.7070007@piuha.net> <1256729820.8155.82.camel@acorde.it.uc3m.es> In-Reply-To: <1256729820.8155.82.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org, Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr> Subject: [Autoconf] draft-bernardos-autoconf-addressing-model (Was: Re: On WG progress anddraft-ietf-autoconf-adhoc-addr-model) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 12:13:42 -0000 Carlos, > did you have the chance to take a look at > draft-bernardos-autoconf-addressing-model-01.txt? Your feedback would be > highly appreciated. > I had not read it before, but I did read (quickly) now. Its well written and I saw no major problems. If I compare your draft to the DT draft, yours is attempting to cover a more general case, allowing for different prefix lengths, etc. For what it is worth, my goals for the working group document were that it would be very specific, provide a concrete and workable configuration model and avoid saying something that might be ripped to pieces on closer analysis by some non-AUTOCONF folk. For these goals, the DT document is a pretty perfect match. I still prefer to adopt the DT document for the WG document. Jari From thomas@thomasclausen.org Wed Oct 28 05:15:01 2009 Return-Path: <thomas@thomasclausen.org> 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 D675F3A681D for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 05:15:01 -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 oT+JLfpFNoVC for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 05:15:01 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 0FC893A67DD for <autoconf@ietf.org>; Wed, 28 Oct 2009 05:15:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 8D5A432317AD; Wed, 28 Oct 2009 05:15:16 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by hgblob.tigertech.net (Postfix) with ESMTP id 787DC32317B3; Wed, 28 Oct 2009 05:15:16 -0700 (PDT) Received: by hgblob.tigertech.net (Postfix, from userid 516) id 6C03F32317AD; Wed, 28 Oct 2009 05:15:16 -0700 (PDT) Received: from 81.249.151.17 (SquirrelMail authenticated user mailbox@thomasclausen.net) by mail.tigertech.net with HTTP; Wed, 28 Oct 2009 05:15:16 -0700 (PDT) Message-ID: <64476.81.249.151.17.1256732116.squirrel@mail.tigertech.net> Date: Wed, 28 Oct 2009 05:15:16 -0700 (PDT) From: "Thomas Heide Clausen" <thomas@thomasclausen.org> To: "Jari Arkko" <jari.arkko@piuha.net> User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit Cc: "autoconf@ietf.org" <autoconf@ietf.org>, ryuji@sfc.wide.ad.jp Subject: Re: [Autoconf] Procedure X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 12:15:01 -0000 On Wed, October 28, 2009 4:57 am, Jari Arkko wrote: > Alex, > > >> YEs I believe it is unreasonable to adopt that single document when a >> competitor document exists and which is technically more inline with what >> I think. >> > Also, duly note that the draft-bernardos-autoconf-addressing-model document did not exist and the chairs (and the WG) were not made aware that it was under development, at the time of approval of draft-ietf-autoconf-... Your opinion is, however, noted. Thomas > I am aware that you wanted to see the other document adopted instead. > But note that I said "given the opinions in the group" and not any > individual's opinion. We all know that there is no unanimous agreement > about this, but I was curious if someone thought that the chairs had > somehow missed that a large part of the group disagreed with the idea of > adopting the DT document. > > Jari > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From cjbc@it.uc3m.es Wed Oct 28 05:26:18 2009 Return-Path: <cjbc@it.uc3m.es> 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 18A3E3A68E6 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 05:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.616 X-Spam-Level: X-Spam-Status: No, score=-5.616 tagged_above=-999 required=5 tests=[AWL=0.083, 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 EH1zEMUid4+W for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 05:26:17 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id DE7033A68C1 for <autoconf@ietf.org>; Wed, 28 Oct 2009 05:26:16 -0700 (PDT) Received: from [163.117.81.215] (wifi-81-215.uc3m.es [163.117.81.215]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 60431731B56; Wed, 28 Oct 2009 13:26:30 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano <cjbc@it.uc3m.es> To: Thomas Heide Clausen <thomas@thomasclausen.org> In-Reply-To: <64476.81.249.151.17.1256732116.squirrel@mail.tigertech.net> References: <64476.81.249.151.17.1256732116.squirrel@mail.tigertech.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Z02Nlp5vFGPpzok2nn67" Organization: Universidad Carlos III de Madrid Date: Wed, 28 Oct 2009 13:26:31 +0100 Message-Id: <1256732791.8155.95.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16974.007 Cc: "autoconf@ietf.org" <autoconf@ietf.org>, ryuji@sfc.wide.ad.jp Subject: Re: [Autoconf] Procedure 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 <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 12:26:18 -0000 --=-Z02Nlp5vFGPpzok2nn67 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Thomas, On Wed, 2009-10-28 at 05:15 -0700, Thomas Heide Clausen wrote: > On Wed, October 28, 2009 4:57 am, Jari Arkko wrote: >=20 > > Alex, > > > > > >> YEs I believe it is unreasonable to adopt that single document when a > >> competitor document exists and which is technically more inline with w= hat > >> I think. > >> > > >=20 > Also, duly note that the draft-bernardos-autoconf-addressing-model > document did not exist and the chairs (and the WG) were not made aware > that it was under development, at the time of approval of > draft-ietf-autoconf-... True, we have been working on this since last IETF meeting. Had we (the authors) known that we were about to adopt a document as WG draft, we would have submitted it earlier. As I mentioned in a previous e-mail, I think it'd be better to have a discussion on the content of both drafts before really deciding on which one should be taken as baseline, but this is my personal opinion. Sorry, but after 5 years working on this (and I've been contributing to the WG since the very beginning) I don't buy the "we are in a hurry" argument :-). Discussing both drafts in Hiroshima would not harm and may be help. Thanks, Carlos >=20 > Your opinion is, however, noted. >=20 > Thomas >=20 > > I am aware that you wanted to see the other document adopted instead. > > But note that I said "given the opinions in the group" and not any > > individual's opinion. We all know that there is no unanimous agreement > > about this, but I was curious if someone thought that the chairs had > > somehow missed that a large part of the group disagreed with the idea o= f > > adopting the DT document. > > > > Jari > > > > > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www.ietf.org/mailman/listinfo/autoconf >=20 >=20 > _______________________________________________ > 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 --=-Z02Nlp5vFGPpzok2nn67 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkroOHcACgkQNdy6TdFwT2e6ugCgvu1li3QC0khHu9l1pKA5r21z /8sAoKyL+Qtbjo61crGSR5A9t5kiK2If =Wh54 -----END PGP SIGNATURE----- --=-Z02Nlp5vFGPpzok2nn67-- From cjbc@it.uc3m.es Wed Oct 28 05:29:14 2009 Return-Path: <cjbc@it.uc3m.es> 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 D7AFE3A68E6 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 05:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.924 X-Spam-Level: X-Spam-Status: No, score=-4.924 tagged_above=-999 required=5 tests=[AWL=-0.621, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, 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 Tq-1Nn85PLds for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 05:29:14 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 9FB333A68F3 for <autoconf@ietf.org>; Wed, 28 Oct 2009 05:29:13 -0700 (PDT) Received: from [163.117.81.215] (wifi-81-215.uc3m.es [163.117.81.215]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 8B23B6C19E2; Wed, 28 Oct 2009 13:29:27 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano <cjbc@it.uc3m.es> To: Jari Arkko <jari.arkko@piuha.net> In-Reply-To: <4AE83583.7090906@piuha.net> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <C228A97A-1D28-43CE-8BA4-07A9C7BD3AC5@gmail.com> <7.0.0.16.2.20091028154932.06352778@ie.niigata-u.ac.jp> <37D2EFED-EAE1-41A3-880D-FC143C9E84C5@thomasclausen.org> <be8c8d780910280123v633e06a1u4e0f4d876e89684a@mail.gmail.com> <4AE82918.7070007@piuha.net> <1256729820.8155.82.camel@acorde.it.uc3m.es> <4AE83583.7090906@piuha.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-n9OPrfL3Qx5QGmLceS5/" Organization: Universidad Carlos III de Madrid Date: Wed, 28 Oct 2009 13:29:28 +0100 Message-Id: <1256732968.8155.98.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16974.007 Cc: autoconf@ietf.org, Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr> Subject: Re: [Autoconf] draft-bernardos-autoconf-addressing-model (Was: Re: On WG progress anddraft-ietf-autoconf-adhoc-addr-model) 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 <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 12:29:14 -0000 --=-n9OPrfL3Qx5QGmLceS5/ Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Jari, On Wed, 2009-10-28 at 14:13 +0200, Jari Arkko wrote: > Carlos, >=20 > > did you have the chance to take a look at > > draft-bernardos-autoconf-addressing-model-01.txt? Your feedback would b= e > > highly appreciated. > > =20 >=20 > I had not read it before, but I did read (quickly) now. >=20 > Its well written and I saw no major problems. If I compare your draft to=20 > the DT draft, yours is attempting to cover a more general case, allowing=20 > for different prefix lengths, etc. For what it is worth, my goals for=20 > the working group document were that it would be very specific, provide=20 > a concrete and workable configuration model and avoid saying something=20 > that might be ripped to pieces on closer analysis by some non-AUTOCONF=20 > folk. For these goals, the DT document is a pretty perfect match. I=20 > still prefer to adopt the DT document for the WG document. Thanks for your feedback. My fear/concerns with draft-baccelli is that exactly that, it is too much specific, IMHO. We can risk ending up with a practical model that is impractical because restricts too much the things that can be done (no LLs -- this might avoid many protocols to be run in MANETs -- only /128s and /32s, etc). Thanks, Carlos >=20 > Jari >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-n9OPrfL3Qx5QGmLceS5/ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkroOSgACgkQNdy6TdFwT2emmgCffNiq80uC6u3FjZvyCf9VUJOi fhsAn0lvUZAa3x8lfd4N+UyniyUWyULl =2Wpt -----END PGP SIGNATURE----- --=-n9OPrfL3Qx5QGmLceS5/-- From thomas@thomasclausen.org Wed Oct 28 05:31:33 2009 Return-Path: <thomas@thomasclausen.org> 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 77E1928C10D for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 05:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] 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 oel3wtkrrAta for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 05:31:32 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id BCED328C125 for <autoconf@ietf.org>; Wed, 28 Oct 2009 05:31:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 4AC6432317B0; Wed, 28 Oct 2009 05:31:48 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by hgblob.tigertech.net (Postfix) with ESMTP id 3537632317B1; Wed, 28 Oct 2009 05:31:48 -0700 (PDT) Received: by hgblob.tigertech.net (Postfix, from userid 516) id 3315E32317B0; Wed, 28 Oct 2009 05:31:48 -0700 (PDT) Received: from 81.249.151.17 (SquirrelMail authenticated user mailbox@thomasclausen.net) by mail.tigertech.net with HTTP; Wed, 28 Oct 2009 05:31:48 -0700 (PDT) Message-ID: <65259.81.249.151.17.1256733108.squirrel@mail.tigertech.net> In-Reply-To: <1256732791.8155.95.camel@acorde.it.uc3m.es> References: <64476.81.249.151.17.1256732116.squirrel@mail.tigertech.net> <1256732791.8155.95.camel@acorde.it.uc3m.es> Date: Wed, 28 Oct 2009 05:31:48 -0700 (PDT) From: "Thomas Heide Clausen" <thomas@thomasclausen.org> To: cjbc@it.uc3m.es User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit Cc: "autoconf@ietf.org" <autoconf@ietf.org>, Thomas Heide Clausen <thomas@thomasclausen.org>, ryuji@sfc.wide.ad.jp Subject: Re: [Autoconf] Procedure X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 12:31:33 -0000 Carlos, Ok, let's try this, then, to see how much of a hurry we're really in: o Jari, can we have our milestone moved another 5 years into the future? ;) Thomas On Wed, October 28, 2009 5:26 am, Carlos Jesús Bernardos Cano wrote: > Hi Thomas, > > > On Wed, 2009-10-28 at 05:15 -0700, Thomas Heide Clausen wrote: > >> On Wed, October 28, 2009 4:57 am, Jari Arkko wrote: >> >> >>> Alex, >>> >>> >>> >>>> YEs I believe it is unreasonable to adopt that single document when >>>> a competitor document exists and which is technically more inline >>>> with what I think. >>>> >>>> >>> >> >> Also, duly note that the draft-bernardos-autoconf-addressing-model >> document did not exist and the chairs (and the WG) were not made aware >> that it was under development, at the time of approval of >> draft-ietf-autoconf-... > > True, we have been working on this since last IETF meeting. Had we (the > authors) known that we were about to adopt a document as WG draft, we would > have submitted it earlier. > > As I mentioned in a previous e-mail, I think it'd be better to have a > discussion on the content of both drafts before really deciding on which > one should be taken as baseline, but this is my personal opinion. Sorry, > but after 5 years working on this (and I've been contributing to the WG > since the very beginning) I don't buy the "we are in a hurry" argument > :-). Discussing both drafts in Hiroshima would not harm and may > be help. > > Thanks, > > > Carlos > > >> >> Your opinion is, however, noted. >> >> >> Thomas >> >> >>> I am aware that you wanted to see the other document adopted instead. >>> But note that I said "given the opinions in the group" and not any >>> individual's opinion. We all know that there is no unanimous agreement >>> about this, but I was curious if someone thought that the chairs had >>> somehow missed that a large part of the group disagreed with the >>> idea of adopting the DT document. >>> >>> Jari >>> >>> >>> >>> _______________________________________________ >>> 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 >> > -- > Carlos Jesús Bernardos Cano http://www.netcoms.net > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > From cjbc@it.uc3m.es Wed Oct 28 05:45:22 2009 Return-Path: <cjbc@it.uc3m.es> 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 291DB3A696F for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 05:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.578 X-Spam-Level: X-Spam-Status: No, score=-5.578 tagged_above=-999 required=5 tests=[AWL=0.121, 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 cyfv2woNvnBY for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 05:45:21 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id BB43C3A67D1 for <autoconf@ietf.org>; Wed, 28 Oct 2009 05:45:20 -0700 (PDT) Received: from [163.117.81.215] (wifi-81-215.uc3m.es [163.117.81.215]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id D7655BA5CD4; Wed, 28 Oct 2009 13:45:33 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano <cjbc@it.uc3m.es> To: Thomas Heide Clausen <thomas@thomasclausen.org> In-Reply-To: <65259.81.249.151.17.1256733108.squirrel@mail.tigertech.net> References: <64476.81.249.151.17.1256732116.squirrel@mail.tigertech.net> <1256732791.8155.95.camel@acorde.it.uc3m.es> <65259.81.249.151.17.1256733108.squirrel@mail.tigertech.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-of/Nq+1D+I6fn5vpyBji" Organization: Universidad Carlos III de Madrid Date: Wed, 28 Oct 2009 13:45:35 +0100 Message-Id: <1256733935.8155.115.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16974.007 Cc: "autoconf@ietf.org" <autoconf@ietf.org>, ryuji@sfc.wide.ad.jp Subject: Re: [Autoconf] Procedure 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 <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 12:45:22 -0000 --=-of/Nq+1D+I6fn5vpyBji Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Sorry Thomas, I don't get this joke, especially if coming from one WG chair. I'm talking about serious things here. Thanks, Carlos On Wed, 2009-10-28 at 05:31 -0700, Thomas Heide Clausen wrote: > Carlos, >=20 > Ok, let's try this, then, to see how much of a hurry we're really in: >=20 > o Jari, can we have our milestone moved another 5 years > into the future? >=20 > ;) >=20 > Thomas >=20 > On Wed, October 28, 2009 5:26 am, Carlos Jes=FAs Bernardos Cano wrote: >=20 > > Hi Thomas, > > > > > > On Wed, 2009-10-28 at 05:15 -0700, Thomas Heide Clausen wrote: > > > >> On Wed, October 28, 2009 4:57 am, Jari Arkko wrote: > >> > >> > >>> Alex, > >>> > >>> > >>> > >>>> YEs I believe it is unreasonable to adopt that single document when > >>>> a competitor document exists and which is technically more inline > >>>> with what I think. > >>>> > >>>> > >>> > >> > >> Also, duly note that the draft-bernardos-autoconf-addressing-model > >> document did not exist and the chairs (and the WG) were not made aware > >> that it was under development, at the time of approval of > >> draft-ietf-autoconf-... > > > > True, we have been working on this since last IETF meeting. Had we (the > > authors) known that we were about to adopt a document as WG draft, we w= ould > > have submitted it earlier. > > > > As I mentioned in a previous e-mail, I think it'd be better to have a > > discussion on the content of both drafts before really deciding on whic= h > > one should be taken as baseline, but this is my personal opinion. Sorry= , > > but after 5 years working on this (and I've been contributing to the WG > > since the very beginning) I don't buy the "we are in a hurry" argument > > :-). Discussing both drafts in Hiroshima would not harm and may > > be help. > > > > Thanks, > > > > > > Carlos > > > > > >> > >> Your opinion is, however, noted. > >> > >> > >> Thomas > >> > >> > >>> I am aware that you wanted to see the other document adopted instead. > >>> But note that I said "given the opinions in the group" and not any > >>> individual's opinion. We all know that there is no unanimous agreemen= t > >>> about this, but I was curious if someone thought that the chairs had > >>> somehow missed that a large part of the group disagreed with the > >>> idea of adopting the DT document. > >>> > >>> Jari > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > >> > > -- > > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > > >=20 >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-of/Nq+1D+I6fn5vpyBji Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkroPO8ACgkQNdy6TdFwT2fXvgCbBVjmsmjEbZ5SezWb2QW8kPCu GWYAoIWGMiqFTAenbq38nkWwQ8YMErGO =Jfp9 -----END PGP SIGNATURE----- --=-of/Nq+1D+I6fn5vpyBji-- From alexandru.petrescu@gmail.com Wed Oct 28 05:49:34 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 B3D503A69AB for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 05:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[AWL=0.157, 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 srzedjxOeU4n for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 05:49:34 -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 B48F73A69C6 for <autoconf@ietf.org>; Wed, 28 Oct 2009 05:49:33 -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 n9SCnl2r012616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Oct 2009 13:49:47 +0100 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 n9SCnlaZ009022; Wed, 28 Oct 2009 13:49:47 +0100 (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 n9SCnkU6001856; Wed, 28 Oct 2009 13:49:47 +0100 Message-ID: <4AE83DEA.3020604@gmail.com> Date: Wed, 28 Oct 2009 13:49:46 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jari Arkko <jari.arkko@piuha.net> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <C228A97A-1D28-43CE-8BA4-07A9C7BD3AC5@gmail.com> <7.0.0.16.2.20091028154932.06352778@ie.niigata-u.ac.jp> <37D2EFED-EAE1-41A3-880D-FC143C9E84C5@thomasclausen.org> <be8c8d780910280123v633e06a1u4e0f4d876e89684a@mail.gmail.com> <4AE82918.7070007@piuha.net> <1256729820.8155.82.camel@acorde.it.uc3m.es> <4AE83583.7090906@piuha.net> In-Reply-To: <4AE83583.7090906@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr> Subject: Re: [Autoconf] draft-bernardos-autoconf-addressing-model (Was: Re: On WG progress anddraft-ietf-autoconf-adhoc-addr-model) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 12:49:34 -0000 Jari Arkko a écrit : > Carlos, > >> did you have the chance to take a look at >> draft-bernardos-autoconf-addressing-model-01.txt? Your feedback >> would be highly appreciated. >> > > I had not read it before, but I did read (quickly) now. > > Its well written and I saw no major problems. If I compare your draft > to the DT draft, yours is attempting to cover a more general case, > allowing for different prefix lengths, etc. For what it is worth, my > goals for the working group document were that it would be very > specific, Let me assure you that it is not specific at all - it deals with unknown network environments. > provide a concrete and workable configuration model and avoid saying > something that might be ripped to pieces on closer analysis by some > non-AUTOCONF folk. For these goals, the DT document is a pretty > perfect match. I still prefer to adopt the DT document for the WG > document. Jari - I fully disagree with that preference. The bernardos document is more inline with what I think about link-local addresses. I prefer the bernardos document. Alex > > Jari > > _______________________________________________ Autoconf mailing list > Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf > From emmanuel.baccelli@gmail.com Wed Oct 28 05:52:26 2009 Return-Path: <emmanuel.baccelli@gmail.com> 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 877EC3A69C6 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 05:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.535 X-Spam-Level: X-Spam-Status: No, score=-1.535 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6] 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 c6esheU+0jwZ for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 05:52:25 -0700 (PDT) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 482193A69AB for <autoconf@ietf.org>; Wed, 28 Oct 2009 05:52:25 -0700 (PDT) Received: by yxe30 with SMTP id 30so685744yxe.29 for <autoconf@ietf.org>; Wed, 28 Oct 2009 05:52:37 -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=QlLD/lHNN8I0N2Ou7fD5nbHKdpEDcSgjh02ZKrjSj2Q=; b=dEVBDXvT6sLGVQ716vI9v7EoyMLaSkhIJ9B4gvIaH3L/u7hDKfbV7sAp+fDbyBcCQD PEHOj1JPMF0k1LAP1Etn8kVz0QDMoFsnoUA7ZKCcmltS43XCZLfzkDDB7dEJWgmJ7mbH +SFGjgzON+y6Ih6ubrYDruqaa+FzIL7fDruYs= 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=V0EqnBHTuwjLnnGyeOr44C+u+TKDVctvhAGXfSuEvWWkplX4XMBbjWxjcyEw0jRvxq zRbrQEikROGPzphNbuLyHeLMR365OhoFaXUDhVjC/AbkacJ6ezKdXfN4cuafax/5e7ya NTqW5KnpBlYN3WXbP1pkBC6QJ6Rfvrn/Drhhg= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.90.210.20 with SMTP id i20mr3975779agg.32.1256734354393; Wed, 28 Oct 2009 05:52:34 -0700 (PDT) In-Reply-To: <1256733935.8155.115.camel@acorde.it.uc3m.es> References: <64476.81.249.151.17.1256732116.squirrel@mail.tigertech.net> <1256732791.8155.95.camel@acorde.it.uc3m.es> <65259.81.249.151.17.1256733108.squirrel@mail.tigertech.net> <1256733935.8155.115.camel@acorde.it.uc3m.es> From: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr> Date: Wed, 28 Oct 2009 13:52:14 +0100 X-Google-Sender-Auth: e5cfb9b2a820b79f Message-ID: <be8c8d780910280552l6a5fd642j5d9cd344488f9633@mail.gmail.com> To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=001636310141c597700476fe44dc Subject: Re: [Autoconf] Procedure X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 12:52:26 -0000 --001636310141c597700476fe44dc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Carlos, maybe there is very simple reason why you don't get the joke: there is no joke, unfortunately. Emmanuel 2009/10/28 Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es> > Sorry Thomas, I don't get this joke, especially if coming from one WG > chair. > > I'm talking about serious things here. > > Thanks, > > Carlos > > On Wed, 2009-10-28 at 05:31 -0700, Thomas Heide Clausen wrote: > > Carlos, > > > > Ok, let's try this, then, to see how much of a hurry we're really in: > > > > o Jari, can we have our milestone moved another 5 years > > into the future? > > > > ;) > > > > Thomas > > > > On Wed, October 28, 2009 5:26 am, Carlos Jes=FAs Bernardos Cano wrote: > > > > > Hi Thomas, > > > > > > > > > On Wed, 2009-10-28 at 05:15 -0700, Thomas Heide Clausen wrote: > > > > > >> On Wed, October 28, 2009 4:57 am, Jari Arkko wrote: > > >> > > >> > > >>> Alex, > > >>> > > >>> > > >>> > > >>>> YEs I believe it is unreasonable to adopt that single document whe= n > > >>>> a competitor document exists and which is technically more inline > > >>>> with what I think. > > >>>> > > >>>> > > >>> > > >> > > >> Also, duly note that the draft-bernardos-autoconf-addressing-model > > >> document did not exist and the chairs (and the WG) were not made awa= re > > >> that it was under development, at the time of approval of > > >> draft-ietf-autoconf-... > > > > > > True, we have been working on this since last IETF meeting. Had we (t= he > > > authors) known that we were about to adopt a document as WG draft, we > would > > > have submitted it earlier. > > > > > > As I mentioned in a previous e-mail, I think it'd be better to have a > > > discussion on the content of both drafts before really deciding on > which > > > one should be taken as baseline, but this is my personal opinion. > Sorry, > > > but after 5 years working on this (and I've been contributing to the = WG > > > since the very beginning) I don't buy the "we are in a hurry" argumen= t > > > :-). Discussing both drafts in Hiroshima would not harm and may > > > be help. > > > > > > Thanks, > > > > > > > > > Carlos > > > > > > > > >> > > >> Your opinion is, however, noted. > > >> > > >> > > >> Thomas > > >> > > >> > > >>> I am aware that you wanted to see the other document adopted instea= d. > > >>> But note that I said "given the opinions in the group" and not any > > >>> individual's opinion. We all know that there is no unanimous > agreement > > >>> about this, but I was curious if someone thought that the chairs h= ad > > >>> somehow missed that a large part of the group disagreed with the > > >>> idea of adopting the DT document. > > >>> > > >>> Jari > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> 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 > > >> > > > -- > > > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > > > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > > > > > > > > -- > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > > --001636310141c597700476fe44dc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Carlos,<div><br><div>maybe there is very simple reason why you don't= get the joke: there is no joke, unfortunately.</div><div><br></div><div>Em= manuel</div><div><br><br><div class=3D"gmail_quote">2009/10/28 Carlos Jes= =FAs Bernardos Cano <span dir=3D"ltr"><<a href=3D"mailto:cjbc@it.uc3m.es= ">cjbc@it.uc3m.es</a>></span><br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;">Sorry Thomas, I don't get this joke, es= pecially if coming from one WG<br> chair.<br> <br> I'm talking about serious things here.<br> <br> Thanks,<br> <font color=3D"#888888"><br> Carlos<br> </font><div><div></div><div class=3D"h5"><br> On Wed, 2009-10-28 at 05:31 -0700, Thomas Heide Clausen wrote:<br> > Carlos,<br> ><br> > Ok, let's try this, then, to see how much of a hurry we're rea= lly in:<br> ><br> > =A0 o Jari, can we have our milestone moved another 5 years<br> > =A0 =A0 into the future?<br> ><br> > ;)<br> ><br> > Thomas<br> ><br> > On Wed, October 28, 2009 5:26 am, Carlos Jes=FAs Bernardos Cano wrote:= <br> ><br> > > Hi Thomas,<br> > ><br> > ><br> > > On Wed, 2009-10-28 at 05:15 -0700, Thomas Heide Clausen wrote:<br= > > ><br> > >> On Wed, October 28, 2009 4:57 am, Jari Arkko wrote:<br> > >><br> > >><br> > >>> Alex,<br> > >>><br> > >>><br> > >>><br> > >>>> YEs I believe it is unreasonable to adopt that single= document when<br> > >>>> a competitor document exists and which is technically= more inline<br> > >>>> with what I think.<br> > >>>><br> > >>>><br> > >>><br> > >><br> > >> Also, duly note that the draft-bernardos-autoconf-addressing-= model<br> > >> document did not exist and the chairs (and the WG) were not m= ade aware<br> > >> that it was under development, at the time of approval of<br> > >> draft-ietf-autoconf-...<br> > ><br> > > True, we have been working on this since last IETF meeting. Had w= e (the<br> > > authors) known that we were about to adopt a document as WG draft= , we would<br> > > have submitted it earlier.<br> > ><br> > > As I mentioned in a previous e-mail, I think it'd be better t= o have a<br> > > discussion on the content of both drafts before really deciding o= n which<br> > > one should be taken as baseline, but this is my personal opinion.= Sorry,<br> > > but after 5 years working on this (and I've been contributing= to the WG<br> > > since the very beginning) I don't buy the "we are in a h= urry" argument<br> > > :-). Discussing both drafts in Hiroshima would not harm and may<b= r> > > be help.<br> > ><br> > > Thanks,<br> > ><br> > ><br> > > Carlos<br> > ><br> > ><br> > >><br> > >> Your opinion is, however, noted.<br> > >><br> > >><br> > >> Thomas<br> > >><br> > >><br> > >>> I am aware that you wanted to see the other document adop= ted instead.<br> > >>> =A0But note that I said "given the opinions in the g= roup" and not any<br> > >>> individual's opinion. We all know that there is no un= animous agreement<br> > >>> =A0about this, but I was curious if someone thought that = the chairs had<br> > >>> =A0somehow missed that a large part of the group disagree= d with the<br> > >>> idea of adopting the DT document.<br> > >>><br> > >>> Jari<br> > >>><br> > >>><br> > >>><br> > >>> _______________________________________________<br> > >>> Autoconf mailing list<br> > >>> <a href=3D"mailto:Autoconf@ietf.org">Autoconf@ietf.org</a= ><br> > >>> <a href=3D"https://www.ietf.org/mailman/listinfo/autoconf= " target=3D"_blank">https://www.ietf.org/mailman/listinfo/autoconf</a><br> > >>><br> > >><br> > >><br> > >> _______________________________________________<br> > >> Autoconf mailing list<br> > >> <a href=3D"mailto:Autoconf@ietf.org">Autoconf@ietf.org</a><br= > > >> <a href=3D"https://www.ietf.org/mailman/listinfo/autoconf" ta= rget=3D"_blank">https://www.ietf.org/mailman/listinfo/autoconf</a><br> > >><br> > > --<br> > > Carlos Jes=FAs Bernardos Cano =A0 =A0 <a href=3D"http://www.netco= ms.net" target=3D"_blank">http://www.netcoms.net</a><br> > > GPG FP: D29B 0A6A 639A A561 93CA =A04D55 35DC BA4D D170 4F67<br> > ><br> ><br> ><br> </div></div>--<br> <div><div></div><div class=3D"h5">Carlos Jes=FAs Bernardos Cano =A0 =A0 <a = href=3D"http://www.netcoms.net" target=3D"_blank">http://www.netcoms.net</a= ><br> GPG FP: D29B 0A6A 639A A561 93CA =A04D55 35DC BA4D D170 4F67<br> </div></div><br>_______________________________________________<br> Autoconf mailing list<br> <a href=3D"mailto:Autoconf@ietf.org">Autoconf@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/autoconf" target=3D"_blank= ">https://www.ietf.org/mailman/listinfo/autoconf</a><br> <br></blockquote></div><br></div></div> --001636310141c597700476fe44dc-- From alexandru.petrescu@gmail.com Wed Oct 28 05:52:40 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 33BA128C16B for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 05:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.794 X-Spam-Level: X-Spam-Status: No, score=-1.794 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_21=0.6] 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 WtZ4lsZEAHeD for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 05:52:39 -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 21D4728C10D for <autoconf@ietf.org>; Wed, 28 Oct 2009 05:52:38 -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 n9SCqqjd006796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Oct 2009 13:52:52 +0100 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 n9SCqpGS010000; Wed, 28 Oct 2009 13:52:51 +0100 (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 n9SCqoBq003063; Wed, 28 Oct 2009 13:52:51 +0100 Message-ID: <4AE83EA2.1080704@gmail.com> Date: Wed, 28 Oct 2009 13:52:50 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen <thomas@thomasclausen.org> References: <64476.81.249.151.17.1256732116.squirrel@mail.tigertech.net> <1256732791.8155.95.camel@acorde.it.uc3m.es> <65259.81.249.151.17.1256733108.squirrel@mail.tigertech.net> In-Reply-To: <65259.81.249.151.17.1256733108.squirrel@mail.tigertech.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "autoconf@ietf.org" <autoconf@ietf.org>, ryuji@sfc.wide.ad.jp Subject: Re: [Autoconf] Procedure X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 12:52:40 -0000 Thomas Heide Clausen a écrit : > Carlos, > > Ok, let's try this, then, to see how much of a hurry we're really in: > > o Jari, can we have our milestone moved another 5 years > into the future? Thomas - can we have agenda requests for the meeting in advance? Or are you going to decide only the DT document gets presented - despite the discussion on the draft-bernardos? I noticed there's a deadline this midnight for the draft agenda. This group never submitted agenda in advance, let alone the slides. Can we follow - not the procedure - but some widely used IETF manners in this WG too? Alex > > ;) > > Thomas > > On Wed, October 28, 2009 5:26 am, Carlos Jesús Bernardos Cano wrote: > >> Hi Thomas, >> >> >> On Wed, 2009-10-28 at 05:15 -0700, Thomas Heide Clausen wrote: >> >>> On Wed, October 28, 2009 4:57 am, Jari Arkko wrote: >>> >>> >>>> Alex, >>>> >>>> >>>> >>>>> YEs I believe it is unreasonable to adopt that single document when >>>>> a competitor document exists and which is technically more inline >>>>> with what I think. >>>>> >>>>> >>> Also, duly note that the draft-bernardos-autoconf-addressing-model >>> document did not exist and the chairs (and the WG) were not made aware >>> that it was under development, at the time of approval of >>> draft-ietf-autoconf-... >> True, we have been working on this since last IETF meeting. Had we (the >> authors) known that we were about to adopt a document as WG draft, we would >> have submitted it earlier. >> >> As I mentioned in a previous e-mail, I think it'd be better to have a >> discussion on the content of both drafts before really deciding on which >> one should be taken as baseline, but this is my personal opinion. Sorry, >> but after 5 years working on this (and I've been contributing to the WG >> since the very beginning) I don't buy the "we are in a hurry" argument >> :-). Discussing both drafts in Hiroshima would not harm and may >> be help. >> >> Thanks, >> >> >> Carlos >> >> >>> Your opinion is, however, noted. >>> >>> >>> Thomas >>> >>> >>>> I am aware that you wanted to see the other document adopted instead. >>>> But note that I said "given the opinions in the group" and not any >>>> individual's opinion. We all know that there is no unanimous agreement >>>> about this, but I was curious if someone thought that the chairs had >>>> somehow missed that a large part of the group disagreed with the >>>> idea of adopting the DT document. >>>> >>>> Jari >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> -- >> Carlos Jesús Bernardos Cano http://www.netcoms.net >> GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 >> > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From alexandru.petrescu@gmail.com Wed Oct 28 05:53:29 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 76A1D3A69C6 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 05:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[AWL=0.157, 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 6tI4bvDe+r+R for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 05:53:28 -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 8AD0C3A69AB for <autoconf@ietf.org>; Wed, 28 Oct 2009 05:53:28 -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 n9SCrfEv013405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <autoconf@ietf.org>; Wed, 28 Oct 2009 13:53:41 +0100 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 n9SCre1r010190 for <autoconf@ietf.org>; Wed, 28 Oct 2009 13:53:41 +0100 (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 n9SCrejA003285 for <autoconf@ietf.org>; Wed, 28 Oct 2009 13:53:40 +0100 Message-ID: <4AE83ED4.3040409@gmail.com> Date: Wed, 28 Oct 2009 13:53:40 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "autoconf@ietf.org" <autoconf@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Autoconf] Agenda? X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 12:53:29 -0000 What's the agenda of the next meeting? Alex From jari.arkko@piuha.net Wed Oct 28 05:55:03 2009 Return-Path: <jari.arkko@piuha.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B0EE28C0DD for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 05:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 fRKJWVk3fpMj for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 05:55:02 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 3B1DD3A6808 for <autoconf@ietf.org>; Wed, 28 Oct 2009 05:55:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 01DD7D4938; Wed, 28 Oct 2009 14:55:14 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCvUdaODhpVB; Wed, 28 Oct 2009 14:55:13 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 45B08D491D; Wed, 28 Oct 2009 14:55:13 +0200 (EET) Message-ID: <4AE83F30.1010304@piuha.net> Date: Wed, 28 Oct 2009 14:55:12 +0200 From: Jari Arkko <jari.arkko@piuha.net> User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <64476.81.249.151.17.1256732116.squirrel@mail.tigertech.net> <1256732791.8155.95.camel@acorde.it.uc3m.es> In-Reply-To: <1256732791.8155.95.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: "autoconf@ietf.org" <autoconf@ietf.org> Subject: Re: [Autoconf] Procedure X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 12:55:03 -0000 Carlos, > I don't buy the "we are in a hurry" argument :-) I don't mind discussing both documents in Hiroshima -- even if (hopefully) one is a WG document, I'm sure discussion of both can be useful for the WG, and improves both documents. At least the discussion is on-topic for the working group's #1 deliverable. However, you ARE in a hurry. Precisely because its already taken so many years. We really need to see short-term result from the addressing model document, or we must question how useful it is for all of us to put cycles into this working group. Its really publish-or-perish for the WG, quite literally :-) Jari From thomas@thomasclausen.org Wed Oct 28 06:05:11 2009 Return-Path: <thomas@thomasclausen.org> 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 C275D3A68E9 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 06:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] 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 Mic2XNCMt4X4 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 06:05:10 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id D48903A68E6 for <autoconf@ietf.org>; Wed, 28 Oct 2009 06:05:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 630BF32317AF; Wed, 28 Oct 2009 06:05:26 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by hgblob.tigertech.net (Postfix) with ESMTP id 3836432317B5; Wed, 28 Oct 2009 06:05:26 -0700 (PDT) Received: by hgblob.tigertech.net (Postfix, from userid 516) id 35C8532317AF; Wed, 28 Oct 2009 06:05:26 -0700 (PDT) Received: from 81.249.151.17 (SquirrelMail authenticated user mailbox@thomasclausen.net) by mail.tigertech.net with HTTP; Wed, 28 Oct 2009 06:05:26 -0700 (PDT) Message-ID: <65440.81.249.151.17.1256735126.squirrel@mail.tigertech.net> In-Reply-To: <4AE83EA2.1080704@gmail.com> References: <64476.81.249.151.17.1256732116.squirrel@mail.tigertech.net> <1256732791.8155.95.camel@acorde.it.uc3m.es> <65259.81.249.151.17.1256733108.squirrel@mail.tigertech.net> <4AE83EA2.1080704@gmail.com> Date: Wed, 28 Oct 2009 06:05:26 -0700 (PDT) From: "Thomas Heide Clausen" <thomas@thomasclausen.org> To: "Alexandru Petrescu" <alexandru.petrescu@gmail.com> User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit Cc: "autoconf@ietf.org" <autoconf@ietf.org>, Thomas Heide Clausen <thomas@thomasclausen.org>, ryuji@sfc.wide.ad.jp Subject: Re: [Autoconf] Procedure X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 13:05:11 -0000 On Wed, October 28, 2009 5:52 am, Alexandru Petrescu wrote: > Thomas Heide Clausen a écrit : > >> Carlos, >> >> >> Ok, let's try this, then, to see how much of a hurry we're really in: >> >> >> o Jari, can we have our milestone moved another 5 years into the future? >> > > Thomas - can we have agenda requests for the meeting in advance? > > > Or are you going to decide only the DT document gets presented - despite > the discussion on the draft-bernardos? > The working-group is on a tight schedule, and we have specific work to do. I therefore would suggest that we do not open up for any odd presentation -- we won't have time for that. However... There have been, as I count it, three documents discussed on the list recently: the Baccelli/Townsley address model document, the Perkins/Baccelli "link model" document and the Carlos/Ronald address model document. The two latter have emerged in the discussions only recently, but appear to be useful for the WG to have presented. My *personal* suggestion would be to ask the authors of each of these three documents to present, and if they're willing to do so of course have those on the agenda. As for slides in advance, we always try to get them on-line before the WG sessions, but as there often is a lot of work ongoing and discussions happening between WG participants during the IETF week that is being reflected in the presentations, I'm not sure we can reasonably do much earlier than that. Thomas > I noticed there's a deadline this midnight for the draft agenda. > > > This group never submitted agenda in advance, let alone the slides. > > > Can we follow - not the procedure - but some widely used IETF manners in > this WG too? > > Alex > > >> >> ;) >> >> >> Thomas >> >> >> On Wed, October 28, 2009 5:26 am, Carlos Jesús Bernardos Cano wrote: >> >> >>> Hi Thomas, >>> >>> >>> >>> On Wed, 2009-10-28 at 05:15 -0700, Thomas Heide Clausen wrote: >>> >>> >>>> On Wed, October 28, 2009 4:57 am, Jari Arkko wrote: >>>> >>>> >>>> >>>>> Alex, >>>>> >>>>> >>>>> >>>>> >>>>>> YEs I believe it is unreasonable to adopt that single document >>>>>> when a competitor document exists and which is technically more >>>>>> inline with what I think. >>>>>> >>>>>> >>>> Also, duly note that the draft-bernardos-autoconf-addressing-model >>>> document did not exist and the chairs (and the WG) were not made >>>> aware that it was under development, at the time of approval of >>>> draft-ietf-autoconf-... >>> True, we have been working on this since last IETF meeting. Had we >>> (the >>> authors) known that we were about to adopt a document as WG draft, we >>> would have submitted it earlier. >>> >>> As I mentioned in a previous e-mail, I think it'd be better to have a >>> discussion on the content of both drafts before really deciding on >>> which one should be taken as baseline, but this is my personal >>> opinion. Sorry, but after 5 years working on this (and I've been >>> contributing to the WG since the very beginning) I don't buy the "we >>> are in a hurry" argument :-). Discussing both drafts in Hiroshima >>> would not harm and may be help. >>> >>> Thanks, >>> >>> >>> >>> Carlos >>> >>> >>> >>>> Your opinion is, however, noted. >>>> >>>> >>>> >>>> Thomas >>>> >>>> >>>> >>>>> I am aware that you wanted to see the other document adopted >>>>> instead. But note that I said "given the opinions in the group" >>>>> and not any individual's opinion. We all know that there is no >>>>> unanimous agreement about this, but I was curious if someone >>>>> thought that the chairs had somehow missed that a large part of >>>>> the group disagreed with the idea of adopting the DT document. >>>>> >>>>> Jari >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>> -- >>> Carlos Jesús Bernardos Cano http://www.netcoms.net >>> GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 >>> >>> >> >> >> _______________________________________________ >> 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 ulrich@herberg.name Wed Oct 28 06:06:57 2009 Return-Path: <ulrich@herberg.name> 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 DDFDB3A682D for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 06:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.671 X-Spam-Level: X-Spam-Status: No, score=-1.671 tagged_above=-999 required=5 tests=[AWL=0.305, 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 jrNYIXWEPiRv for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 06:06:56 -0700 (PDT) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id DD2013A67DB for <autoconf@ietf.org>; Wed, 28 Oct 2009 06:06:55 -0700 (PDT) Received: by bwz23 with SMTP id 23so969181bwz.29 for <autoconf@ietf.org>; Wed, 28 Oct 2009 06:07:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.155.90 with SMTP id r26mr5478821bkw.81.1256735227254; Wed, 28 Oct 2009 06:07:07 -0700 (PDT) In-Reply-To: <00ad01ca57c8$03a0b560$0ae22020$@nl> References: <20091019233002.15F4328C164@core3.amsl.com> <4AE4997E.6090705@earthlink.net> <1256514067.4766.171.camel@acorde.it.uc3m.es> <4AE4ED72.9000707@earthlink.net> <1256723482.8155.17.camel@acorde.it.uc3m.es> <25c114b90910280300o4ba93b86g8619eec4916649b2@mail.gmail.com> <008201ca57b8$b53615a0$1fa240e0$@nl> <4AE822D3.2030304@gmail.com> <25c114b90910280443q43d0f4b0n3fd8840fff61261@mail.gmail.com> <00ad01ca57c8$03a0b560$0ae22020$@nl> Date: Wed, 28 Oct 2009 14:07:06 +0100 Message-ID: <25c114b90910280607x66c7aa46yfc048b0490b54c16@mail.gmail.com> From: Ulrich Herberg <ulrich@herberg.name> To: Teco Boot <teco@inf-net.nl> Content-Type: multipart/alternative; boundary=0015175cfa6ccc18f00476fe783c Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 13:06:58 -0000 --0015175cfa6ccc18f00476fe783c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Teco, On Wed, Oct 28, 2009 at 1:13 PM, Teco Boot <teco@inf-net.nl> wrote: > Hi Ulrich, > > Few things. > > Please realize your rich text mails is becoming a mess, when > replied with other tools. This troubles the already troubled > discussion. I stop cleaning up. > I did not realize that. If I just answer like now (without changing the font), is it readable? If not, I can also change to plain text for future mails. > > Then on the small stuff: we are working on MANET stuff, OK? > I hope so :-) > We have a radio, right? > yes > We can use this radio for catching background noise, right? > yes > This is either thermal noise, human made noise, interference, timing, > timing of packets received, just to come up with a few. > Yes, I am aware that a radio can be good enough as entropy source. The question is: can we _always_ assume that it is good enough (or accessible t= o the device)? Is there an RFC that claims something like: "All devices that are used in a MANET MUST be able to provide a sufficiently good entropy source". (for whatever meaning of "sufficient") Because, if we don't have that, I am not sure we can rely on good random numbers. Maybe we want to add this somewhere, or we have a common understanding that all devices have a good enough entropy source. > Please let me know this does not make sense. Because then, I want > to be warned and want to stay far, far away from such devices. > And still such devices might exist if we don't exclude their use in MANETs. > > You were active on MANET and security. Spend some cycles on > PRN for small embedded devices with radios? I don't want to push you, > but it would help us if you do. > For security purposes, evidently the requirements for PRNs are very high. I admit that I am not an expert on PRNs, so I cannot tell you much. I will tr= y to ask our cryptographers in the department, hopefully they can enlighten this issue. To my knowledge, there are sufficiently good PRNs (even for small embedded devices), but they depend on very good entropy sources. So when specifying, say, a security extension to a MANET routing protocol, that document should probably mention some requirements of the entropy source and the PRN. Ulrich > > > Regards, Teco > > > > > > Van: Ulrich Herberg [mailto:ulrich@herberg.name] > Verzonden: woensdag 28 oktober 2009 12:43 > Aan: Alexandru Petrescu > CC: Teco Boot; autoconf@ietf.org > Onderwerp: Re: [Autoconf] I-D > Action:draft-bernardos-autoconf-addressing-model-00.txt > > Alex, Teco, > On Wed, Oct 28, 2009 at 11:54 AM, Alexandru Petrescu > <alexandru.petrescu@gmail.com> wrote: > Teco Boot a =E9crit : > > [..] > The answer is: it depends. ;-) If you have a good random number generator > (i.e. using an unambiguous seed), then the collision probability is > extremely low. (I let you calculate it using the birthday theorem). > > Are birthdays random ?? > > > Probably not... I can imagine that there are some peeks 9 months after > extremely cold and rainy days ;-) I will not dig deeper into this issue := -) > > > > However, if you have small embedded devices, without persistent memory, > good > random number generator, etc., you can have collisions > with a much higher probability. > > Why? It is easy to build a pretty good PRN generator with radio HW. > I would say it is much, much, much, much easier than uniqueness > guarantee with try and error duplicate detection. > > I agree. Moreover, there is an RFC talking how to select good entropy > sources such that the PRN generator is good. > > Do you mean RFC 4086? Yes, as you say, but all depends on selecting a goo= d > entropy source. The RFC says: > > "Is there any hope for true, strong, portable randomness in the future? > There might be. All that's needed is a physical source of unpredictable > numbers." > > It also says that if no good hardware entropy sources are available, "the= re > are other possibilities. These include system clocks, system or > input/output > buffers, user/system/hardware/network serial numbers or addresses and > timing, and user input. Unfortunately, each of these sources can produce > very limited or predictable values under some circumstances." > > So it really depends on the kind of hardware we are talking about. I coul= d > imagine very small sensors without persistent state or other hardware > source > such as mentioned in the RFC. Using such a device could lead to collision= s > when calculating random numbers. > > > (small embedded devices, such as sensors, can constitute good sources of > randomness when sampling the temperature, for example - that RFC says). > > yes. But can we guarantee that each MANET router has a good entropy sourc= e? > Please point me to some reference saying that each device that can be use= d > in a MANET must have a good entropy source. > > Ulrich > > > > Alex > Not even > mentioning total network meltdowns after a first MANET merge. > > And I don't have those devices, I want to stay far, far from them. > And I don't want to run protocols for it in my MANETs. > Please provide refs to equipment that you have in mind. First, > I'll check why good PRN can't be supported. If not, I can stay far away > from > these (also having security in mind). > > Still waiting on answers on DHCP DUID, key generation etc. > > > Regards, Teco > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > > > > --0015175cfa6ccc18f00476fe783c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Teco,<br><br><div class=3D"gmail_quote">On Wed, Oct 28, 2009 at 1:13 PM,= Teco Boot <span dir=3D"ltr"><<a href=3D"mailto:teco@inf-net.nl">teco@in= f-net.nl</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; p= adding-left: 1ex;"> Hi Ulrich,<br> <br> Few things.<br> <br> Please realize your rich text mails is becoming a mess, when<br> replied with other tools. This troubles the already troubled<br> discussion. I stop cleaning up.<br></blockquote><div><br><br>I did not real= ize that. If I just answer like now (without changing the font), is it read= able? If not, I can also change to plain text for future mails.<br>=A0</div= > <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <br> Then on the small stuff: we are working on MANET stuff, OK?<br></blockquote= ><div><br>I hope so :-)<br>=A0</div><blockquote class=3D"gmail_quote" style= =3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; p= adding-left: 1ex;"> We have a radio, right?<br></blockquote><div><br>yes<br>=A0<br></div><block= quote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 2= 04); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> We can use this radio for catching background noise, right?<br></blockquote= ><div><br>yes<br>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"bo= rder-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding= -left: 1ex;"> This is either thermal noise, human made noise, interference, timing,<br> timing of packets received, just to come up with a few.<br></blockquote><di= v><br>Yes, I am aware that a radio can be good enough as entropy source. Th= e question is: can we _always_ assume that it is good enough (or accessible= to the device)? Is there an RFC that claims something like: "All devi= ces that are used in a MANET MUST be able to provide a sufficiently good en= tropy source". (for whatever meaning of "sufficient")<br> <br>Because, if we don't have that, I am not sure we can rely on good r= andom numbers. Maybe we want to add this somewhere, or we have a common und= erstanding that all devices have a good enough entropy source.<br><br>=A0</= div> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Please let me know this does not make sense. Because then, I want<br> to be warned and want to stay far, far away from such devices.<br></blockqu= ote><div><br>And still such devices might exist if we don't exclude the= ir use in MANETs.<br>=A0</div><blockquote class=3D"gmail_quote" style=3D"bo= rder-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding= -left: 1ex;"> <br> You were active on MANET and security. Spend some cycles on<br> PRN for small embedded devices with radios? I don't want to push you,<b= r> but it would help us if you do.<br></blockquote><div><br><br>For security p= urposes, evidently the requirements for PRNs are very high. I admit that I = am not an expert on PRNs, so I cannot tell you much. I will try to ask our = cryptographers in the department, hopefully they can enlighten this issue.<= br> To my knowledge, there are sufficiently good PRNs (even for small embedded = devices), but they depend on very good entropy sources. So when specifying,= say, a security extension to a MANET routing protocol, that document shoul= d probably mention some requirements of the entropy source and the PRN.<br> <br><br>Ulrich<br><br>=A0</div><blockquote class=3D"gmail_quote" style=3D"b= order-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; paddin= g-left: 1ex;"> <br> <br> Regards, Teco<br> <br> <br> <br> <br> <br> Van: Ulrich Herberg [mailto:<a href=3D"mailto:ulrich@herberg.name">ulrich@h= erberg.name</a>]<br> Verzonden: woensdag 28 oktober 2009 12:43<br> Aan: Alexandru Petrescu<br> <div class=3D"im">CC: Teco Boot; <a href=3D"mailto:autoconf@ietf.org">autoc= onf@ietf.org</a><br> </div><div class=3D"im">Onderwerp: Re: [Autoconf] I-D<br> </div>Action:draft-bernardos-autoconf-addressing-model-00.txt<br> <div><div></div><div class=3D"h5"><br> Alex, Teco,<br> On Wed, Oct 28, 2009 at 11:54 AM, Alexandru Petrescu<br> <<a href=3D"mailto:alexandru.petrescu@gmail.com">alexandru.petrescu@gmai= l.com</a>> wrote:<br> Teco Boot a =E9crit :<br> <br> [..]<br> The answer is: it depends. ;-) If you have a good random number generator<b= r> (i.e. using an unambiguous seed), then the collision probability is<br> extremely low. (I let you calculate it using the birthday theorem).<br> <br> Are birthdays random ??<br> <br> <br> Probably not... I can imagine that there are some peeks 9 months after<br> extremely cold and rainy days ;-) I will not dig deeper into this issue :-)= <br> <br> =A0<br> <br> However, if you have small embedded devices, without persistent memory, goo= d<br> random number generator, etc., you can have collisions<br> with a much higher probability. =A0<br> <br> Why? It is easy to build a pretty good PRN generator with radio HW.<br> I would say it is much, much, much, much easier than uniqueness<br> guarantee with try and error duplicate detection.<br> <br> I agree. =A0Moreover, there is an RFC talking how to select good entropy<br= > sources such that the PRN generator is good.<br> <br> Do you mean RFC 4086? Yes, as you say, but all depends on selecting a good<= br> entropy source. The RFC says:<br> <br> "Is there any hope for true, strong, portable randomness in the future= ?<br> There might be. All that's needed is a physical source of unpredictable= <br> numbers."<br> <br> It also says that if no good hardware entropy sources are available, "= there<br> are other possibilities. These include system clocks, system or input/outpu= t<br> buffers, user/system/hardware/network serial numbers or addresses and<br> timing, and user input. Unfortunately, each of these sources can produce<br= > very limited or predictable values under some circumstances."<br> <br> So it really depends on the kind of hardware we are talking about. I could<= br> imagine very small sensors without persistent state or other hardware sourc= e<br> such as mentioned in the RFC. Using such a device could lead to collisions<= br> when calculating random numbers.<br> <br> <br> (small embedded devices, such as sensors, can constitute good sources of<br= > =A0randomness when sampling the temperature, for example - that RFC says).<= br> <br> yes. But can we guarantee that each MANET router has a good entropy source?= <br> Please point me to some reference saying that each device that can be used<= br> in a MANET must have a good entropy source.<br> <br> Ulrich<br> <br> <br> <br> Alex<br> Not even<br> mentioning total network meltdowns after a first MANET merge.<br> <br> And I don't have those devices, I want to stay far, far from them.<br> And I don't want to run protocols for it in my MANETs.<br> Please provide refs to equipment that you have in mind. First,<br> I'll check why good PRN can't be supported. If not, I can stay far = away from<br> these (also having security in mind).<br> <br> Still waiting on answers on DHCP DUID, key generation etc.<br> <br> <br> Regards, Teco<br> _______________________________________________<br> Autoconf mailing list<br> <a href=3D"mailto:Autoconf@ietf.org">Autoconf@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/autoconf" target=3D"_blank= ">https://www.ietf.org/mailman/listinfo/autoconf</a><br> <br> <br> <br> </div></div></blockquote></div><br> --0015175cfa6ccc18f00476fe783c-- From alexandru.petrescu@gmail.com Wed Oct 28 06:09:26 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 1335B3A68E6 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 06:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AWL=0.155, 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 I47qEudWLJWk for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 06:09: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 158043A682D for <autoconf@ietf.org>; Wed, 28 Oct 2009 06:09:24 -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 n9SD9dQF025054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Oct 2009 14:09:39 +0100 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 n9SD9c1a014466; Wed, 28 Oct 2009 14:09:39 +0100 (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 n9SD9bxT009095; Wed, 28 Oct 2009 14:09:38 +0100 Message-ID: <4AE84291.3090905@gmail.com> Date: Wed, 28 Oct 2009 14:09:37 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jari Arkko <jari.arkko@piuha.net> References: <64476.81.249.151.17.1256732116.squirrel@mail.tigertech.net> <1256732791.8155.95.camel@acorde.it.uc3m.es> <4AE83F30.1010304@piuha.net> In-Reply-To: <4AE83F30.1010304@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "autoconf@ietf.org" <autoconf@ietf.org> Subject: Re: [Autoconf] Procedure X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 13:09:26 -0000 Jari Arkko a écrit : > Carlos, > >> I don't buy the "we are in a hurry" argument :-) > > I don't mind discussing both documents in Hiroshima -- even if > (hopefully) one is a WG document, I'm sure discussion of both can be > useful for the WG, and improves both documents. At least the discussion > is on-topic for the working group's #1 deliverable. > > However, you ARE in a hurry. Precisely because its already taken so many > years. We really need to see short-term result from the addressing model > document, or we must question how useful it is for all of us to put > cycles into this working group. Its really publish-or-perish for the WG, > quite literally :-) Jari, I do not accept this pressure. It's not my fault these years of non-achievements - I wasn't in AUTOCONF. One would better try to identify _why_ there are non-productive AUTOCONF years of reasons behind us. See how the same lack of procedure (no agenda, no formal calls, secrecy, and more) is in action now. Putting pressure is not solving the problem - moreover it scares people away. If there is such pressure one would also consider the AD sponsoring way, why not(?) Alex > > Jari > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From alexandru.petrescu@gmail.com Wed Oct 28 06:14:02 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 8BD2B3A69B9 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 06:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_21=0.6] 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 UGrx0shcz2+Y for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 06:14:01 -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 98B433A698B for <autoconf@ietf.org>; Wed, 28 Oct 2009 06:14:00 -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 n9SDEEPW004086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Oct 2009 14:14:14 +0100 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 n9SDED4r015704; Wed, 28 Oct 2009 14:14:14 +0100 (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 n9SDEC8h025446; Wed, 28 Oct 2009 14:14:13 +0100 Message-ID: <4AE843A4.2050600@gmail.com> Date: Wed, 28 Oct 2009 14:14:12 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen <thomas@thomasclausen.org> References: <64476.81.249.151.17.1256732116.squirrel@mail.tigertech.net> <1256732791.8155.95.camel@acorde.it.uc3m.es> <65259.81.249.151.17.1256733108.squirrel@mail.tigertech.net> <4AE83EA2.1080704@gmail.com> <65440.81.249.151.17.1256735126.squirrel@mail.tigertech.net> In-Reply-To: <65440.81.249.151.17.1256735126.squirrel@mail.tigertech.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "autoconf@ietf.org" <autoconf@ietf.org>, ryuji@sfc.wide.ad.jp Subject: Re: [Autoconf] Procedure X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 13:14:02 -0000 Thomas Heide Clausen a écrit : > On Wed, October 28, 2009 5:52 am, Alexandru Petrescu wrote: > >> Thomas Heide Clausen a écrit : >> >>> Carlos, >>> >>> >>> Ok, let's try this, then, to see how much of a hurry we're really >>> in: >>> >>> >>> o Jari, can we have our milestone moved another 5 years into the >>> future? >>> >> Thomas - can we have agenda requests for the meeting in advance? >> >> >> Or are you going to decide only the DT document gets presented - >> despite the discussion on the draft-bernardos? >> > > The working-group is on a tight schedule, and we have specific work > to do. I therefore would suggest that we do not open up for any odd > presentation -- we won't have time for that. > > However... > > There have been, as I count it, three documents discussed on the list > recently: the Baccelli/Townsley address model document, the > Perkins/Baccelli "link model" document and the Carlos/Ronald address > model document. > > The two latter have emerged in the discussions only recently, but > appear to be useful for the WG to have presented. > > My *personal* suggestion would be to ask the authors of each of these > three documents to present, and if they're willing to do so of > course have those on the agenda. Thomas I agree with your personal suggestion - make now a request for agenda items. Your draft agenda is due this midnight - are you ready for it? Are you going to act under pressure - again? And please publish here the draft agenda tomorrow, thank you. > As for slides in advance, we always try to get them on-line before > the WG sessions, but as there often is a lot of work ongoing and > discussions happening between WG participants during the IETF week > that is being reflected in the presentations, I'm not sure we can > reasonably do much earlier than that. I agree mostly. Some groups manage to get the slides well in advance. Why not AUTOCONF? It is useful for people wondering whether attending or not, be it locally or remotely. Alex > > Thomas > >> I noticed there's a deadline this midnight for the draft agenda. >> >> >> This group never submitted agenda in advance, let alone the slides. >> >> >> >> Can we follow - not the procedure - but some widely used IETF >> manners in this WG too? >> >> Alex >> >> >>> ;) >>> >>> >>> Thomas >>> >>> >>> On Wed, October 28, 2009 5:26 am, Carlos Jesús Bernardos Cano >>> wrote: >>> >>> >>>> Hi Thomas, >>>> >>>> >>>> >>>> On Wed, 2009-10-28 at 05:15 -0700, Thomas Heide Clausen wrote: >>>> >>>> >>>>> On Wed, October 28, 2009 4:57 am, Jari Arkko wrote: >>>>> >>>>> >>>>> >>>>>> Alex, >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> YEs I believe it is unreasonable to adopt that single >>>>>>> document when a competitor document exists and which is >>>>>>> technically more inline with what I think. >>>>>>> >>>>>>> >>>>> Also, duly note that the >>>>> draft-bernardos-autoconf-addressing-model document did not >>>>> exist and the chairs (and the WG) were not made aware that it >>>>> was under development, at the time of approval of >>>>> draft-ietf-autoconf-... >>>> True, we have been working on this since last IETF meeting. Had >>>> we (the authors) known that we were about to adopt a document >>>> as WG draft, we would have submitted it earlier. >>>> >>>> As I mentioned in a previous e-mail, I think it'd be better to >>>> have a discussion on the content of both drafts before really >>>> deciding on which one should be taken as baseline, but this is >>>> my personal opinion. Sorry, but after 5 years working on this >>>> (and I've been contributing to the WG since the very beginning) >>>> I don't buy the "we are in a hurry" argument :-). Discussing >>>> both drafts in Hiroshima would not harm and may be help. >>>> >>>> Thanks, >>>> >>>> >>>> >>>> Carlos >>>> >>>> >>>> >>>>> Your opinion is, however, noted. >>>>> >>>>> >>>>> >>>>> Thomas >>>>> >>>>> >>>>> >>>>>> I am aware that you wanted to see the other document >>>>>> adopted instead. But note that I said "given the opinions >>>>>> in the group" and not any individual's opinion. We all know >>>>>> that there is no unanimous agreement about this, but I was >>>>>> curious if someone thought that the chairs had somehow >>>>>> missed that a large part of the group disagreed with the >>>>>> idea of adopting the DT document. >>>>>> >>>>>> Jari >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ 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 >>>>> >>>>> >>>> -- Carlos Jesús Bernardos Cano http://www.netcoms.net GPG >>>> FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 >>>> >>>> >>> >>> _______________________________________________ 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 alexandru.petrescu@gmail.com Wed Oct 28 06:22:35 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 54DEE3A697E for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 06:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AWL=0.155, 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 tIynWQ86E2tz for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 06:22:34 -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 D185B3A68F9 for <autoconf@ietf.org>; Wed, 28 Oct 2009 06:22:33 -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 n9SDMkUd014825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Oct 2009 14:22:46 +0100 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 n9SDMkft017866; Wed, 28 Oct 2009 14:22:46 +0100 (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 n9SDMjlx013392; Wed, 28 Oct 2009 14:22:46 +0100 Message-ID: <4AE845A5.6090106@gmail.com> Date: Wed, 28 Oct 2009 14:22:45 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ulrich Herberg <ulrich@herberg.name> References: <20091019233002.15F4328C164@core3.amsl.com> <4AE4997E.6090705@earthlink.net> <1256514067.4766.171.camel@acorde.it.uc3m.es> <4AE4ED72.9000707@earthlink.net> <1256723482.8155.17.camel@acorde.it.uc3m.es> <25c114b90910280300o4ba93b86g8619eec4916649b2@mail.gmail.com> <008201ca57b8$b53615a0$1fa240e0$@nl> <4AE822D3.2030304@gmail.com> <25c114b90910280443q43d0f4b0n3fd8840fff61261@mail.gmail.com> <00ad01ca57c8$03a0b560$0ae22020$@nl> <25c114b90910280607x66c7aa46yfc048b0490b54c16@mail.gmail.com> In-Reply-To: <25c114b90910280607x66c7aa46yfc048b0490b54c16@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] mail formatting (was: I-D Action:draft-bernardos-autoconf-addressing-model-00.txt) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 13:22:35 -0000 Ulrich Herberg a écrit : > Hi Teco, > > On Wed, Oct 28, 2009 at 1:13 PM, Teco Boot <teco@inf-net.nl > <mailto:teco@inf-net.nl>> wrote: > > Hi Ulrich, > > Few things. > > Please realize your rich text mails is becoming a mess, when > replied with other tools. This troubles the already troubled > discussion. I stop cleaning up. > > > > I did not realize that. If I just answer like now (without changing the > font), is it readable? If not, I can also change to plain text for > future mails. Ulrich - I see your mails are in variable-size font format, including this one. (and not fixed-font like Courrier). Also, I see a strange "|" citation sign instead of the usual ">". This makes me incapable of properly citing your messages. Now, looking at the source code of your messages it seems that you use MIME and: > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable Not using MIME at all would help (although there may be Transfer-Encoding schemes other than quoted-printable which may allow to still use MIME yet not have this problem) Could you please try to fix this? (I can help) - it should happen via the list, though. Alex > > > > Then on the small stuff: we are working on MANET stuff, OK? > > > I hope so :-) > > > We have a radio, right? > > > yes > > > We can use this radio for catching background noise, right? > > > yes > > > This is either thermal noise, human made noise, interference, timing, > timing of packets received, just to come up with a few. > > > Yes, I am aware that a radio can be good enough as entropy source. The > question is: can we _always_ assume that it is good enough (or > accessible to the device)? Is there an RFC that claims something like: > "All devices that are used in a MANET MUST be able to provide a > sufficiently good entropy source". (for whatever meaning of "sufficient") > > Because, if we don't have that, I am not sure we can rely on good random > numbers. Maybe we want to add this somewhere, or we have a common > understanding that all devices have a good enough entropy source. > > > > Please let me know this does not make sense. Because then, I want > to be warned and want to stay far, far away from such devices. > > > And still such devices might exist if we don't exclude their use in MANETs. > > > > You were active on MANET and security. Spend some cycles on > PRN for small embedded devices with radios? I don't want to push you, > but it would help us if you do. > > > > For security purposes, evidently the requirements for PRNs are very > high. I admit that I am not an expert on PRNs, so I cannot tell you > much. I will try to ask our cryptographers in the department, hopefully > they can enlighten this issue. > To my knowledge, there are sufficiently good PRNs (even for small > embedded devices), but they depend on very good entropy sources. So when > specifying, say, a security extension to a MANET routing protocol, that > document should probably mention some requirements of the entropy source > and the PRN. > > > Ulrich > > > > > > Regards, Teco > > > > > > Van: Ulrich Herberg [mailto:ulrich@herberg.name > <mailto:ulrich@herberg.name>] > Verzonden: woensdag 28 oktober 2009 12:43 > Aan: Alexandru Petrescu > CC: Teco Boot; autoconf@ietf.org <mailto:autoconf@ietf.org> > Onderwerp: Re: [Autoconf] I-D > Action:draft-bernardos-autoconf-addressing-model-00.txt > > Alex, Teco, > On Wed, Oct 28, 2009 at 11:54 AM, Alexandru Petrescu > <alexandru.petrescu@gmail.com <mailto:alexandru.petrescu@gmail.com>> > wrote: > Teco Boot a écrit : > > [..] > The answer is: it depends. ;-) If you have a good random number > generator > (i.e. using an unambiguous seed), then the collision probability is > extremely low. (I let you calculate it using the birthday theorem). > > Are birthdays random ?? > > > Probably not... I can imagine that there are some peeks 9 months after > extremely cold and rainy days ;-) I will not dig deeper into this > issue :-) > > > > However, if you have small embedded devices, without persistent > memory, good > random number generator, etc., you can have collisions > with a much higher probability. > > Why? It is easy to build a pretty good PRN generator with radio HW. > I would say it is much, much, much, much easier than uniqueness > guarantee with try and error duplicate detection. > > I agree. Moreover, there is an RFC talking how to select good entropy > sources such that the PRN generator is good. > > Do you mean RFC 4086? Yes, as you say, but all depends on selecting > a good > entropy source. The RFC says: > > "Is there any hope for true, strong, portable randomness in the future? > There might be. All that's needed is a physical source of unpredictable > numbers." > > It also says that if no good hardware entropy sources are available, > "there > are other possibilities. These include system clocks, system or > input/output > buffers, user/system/hardware/network serial numbers or addresses and > timing, and user input. Unfortunately, each of these sources can produce > very limited or predictable values under some circumstances." > > So it really depends on the kind of hardware we are talking about. I > could > imagine very small sensors without persistent state or other > hardware source > such as mentioned in the RFC. Using such a device could lead to > collisions > when calculating random numbers. > > > (small embedded devices, such as sensors, can constitute good sources of > randomness when sampling the temperature, for example - that RFC says). > > yes. But can we guarantee that each MANET router has a good entropy > source? > Please point me to some reference saying that each device that can > be used > in a MANET must have a good entropy source. > > Ulrich > > > > Alex > Not even > mentioning total network meltdowns after a first MANET merge. > > And I don't have those devices, I want to stay far, far from them. > And I don't want to run protocols for it in my MANETs. > Please provide refs to equipment that you have in mind. First, > I'll check why good PRN can't be supported. If not, I can stay far > away from > these (also having security in mind). > > Still waiting on answers on DHCP DUID, key generation etc. > > > Regards, Teco > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org <mailto:Autoconf@ietf.org> > https://www.ietf.org/mailman/listinfo/autoconf > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From teco@inf-net.nl Wed Oct 28 06:26:58 2009 Return-Path: <teco@inf-net.nl> 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 2FE783A687C for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 06:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=0.344, 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 TIjgVHZd5Y3G for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 06:26:57 -0700 (PDT) Received: from CPSMTPM-EML104.kpnxchange.com (cpsmtpm-eml104.kpnxchange.com [195.121.3.8]) by core3.amsl.com (Postfix) with ESMTP id CE89C3A6802 for <autoconf@ietf.org>; Wed, 28 Oct 2009 06:26:56 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML104.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Wed, 28 Oct 2009 14:27:06 +0100 From: "Teco Boot" <teco@inf-net.nl> To: "'Ulrich Herberg'" <ulrich@herberg.name> References: <20091019233002.15F4328C164@core3.amsl.com> <4AE4997E.6090705@earthlink.net> <1256514067.4766.171.camel@acorde.it.uc3m.es> <4AE4ED72.9000707@earthlink.net> <1256723482.8155.17.camel@acorde.it.uc3m.es> <25c114b90910280300o4ba93b86g8619eec4916649b2@mail.gmail.com> <008201ca57b8$b53615a0$1fa240e0$@nl> <4AE822D3.2030304@gmail.com> <25c114b90910280443q43d0f4b0n3fd8840fff61261@mail.gmail.com> <00ad01ca57c8$03a0b560$0ae22020$@nl> <25c114b90910280607x66c7aa46yfc048b0490b54c16@mail.gmail.com> In-Reply-To: <25c114b90910280607x66c7aa46yfc048b0490b54c16@mail.gmail.com> Date: Wed, 28 Oct 2009 14:27:07 +0100 Message-ID: <00e001ca57d2$58c20760$0a461620$@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: AcpXz45BDhm7u3f4SmKm/ccnvi/V5QAAPFSg Content-Language: nl X-OriginalArrivalTime: 28 Oct 2009 13:27:07.0020 (UTC) FILETIME=[585514C0:01CA57D2] Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 13:26:58 -0000 Hi Ulrich, Van: Ulrich Herberg [mailto:ulrich@herberg.name]=20 Verzonden: woensdag 28 oktober 2009 14:07 Aan: Teco Boot CC: autoconf@ietf.org Onderwerp: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt Hi Teco, On Wed, Oct 28, 2009 at 1:13 PM, Teco Boot <teco@inf-net.nl> wrote: Hi Ulrich, Few things. Please realize your rich text mails is becoming a mess, when replied with other tools. This troubles the already troubled discussion. I stop cleaning up. I did not realize that. If I just answer like now (without changing the font), is it readable? If not, I can also change to plain text for = future mails. T: Please use ascii and > prefix character=20 =A0 Then on the small stuff: we are working on MANET stuff, OK? I hope so :-) =A0 We have a radio, right? yes =A0 We can use this radio for catching background noise, right? yes =A0 This is either thermal noise, human made noise, interference, timing, timing of packets received, just to come up with a few. Yes, I am aware that a radio can be good enough as entropy source. The question is: can we _always_ assume that it is good enough (or = accessible to the device)? Is there an RFC that claims something like: "All devices = that are used in a MANET MUST be able to provide a sufficiently good entropy source". (for whatever meaning of "sufficient") T: No-one ever claimed a protocol works in all cases. I have MANET = products nearby that cannot support OLSR. Or Java. Do I discourage those?? Because, if we don't have that, I am not sure we can rely on good random numbers. T: If PRN is good, we can rely. Why not? Maybe we want to add this somewhere, or we have a common understanding = that all devices have a good enough entropy source. T: Not again the "all". And yes, I say a radio is typically a pretty = good entropy source. So we are lucky this time. =A0 Please let me know this does not make sense. Because then, I want to be warned and want to stay far, far away from such devices. And still such devices might exist if we don't exclude their use in = MANETs. =A0 You were active on MANET and security. Spend some cycles on PRN for small embedded devices with radios? I don't want to push you, but it would help us if you do. For security purposes, evidently the requirements for PRNs are very = high. I admit that I am not an expert on PRNs, so I cannot tell you much. I will = try to ask our cryptographers in the department, hopefully they can = enlighten this issue. To my knowledge, there are sufficiently good PRNs (even for small = embedded devices), but they depend on very good entropy sources. So when = specifying, say, a security extension to a MANET routing protocol, that document = should probably mention some requirements of the entropy source and the PRN. T: I'm pretty sure your cryptographers will tell you that if the radio / demodulator ADC provides digitized thermal noise, and the implementation = for getting a PRN is OK, you are done. But I can tell you key generation is = a somewhat dark area. Extreme highly unique address generation in open standards is doable. Regards, Teco From ulrich@herberg.name Wed Oct 28 06:27:47 2009 Return-Path: <ulrich@herberg.name> 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 54DB13A687C for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 06:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.692 X-Spam-Level: X-Spam-Status: No, score=-1.692 tagged_above=-999 required=5 tests=[AWL=0.285, 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 hzKv7Vk24nPa for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 06:27:46 -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 D22E43A6802 for <autoconf@ietf.org>; Wed, 28 Oct 2009 06:27:45 -0700 (PDT) Received: by bwz19 with SMTP id 19so959028bwz.28 for <autoconf@ietf.org>; Wed, 28 Oct 2009 06:27:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.34.13 with SMTP id j13mr1827319bkd.32.1256736477288; Wed, 28 Oct 2009 06:27:57 -0700 (PDT) In-Reply-To: <4AE845A5.6090106@gmail.com> References: <20091019233002.15F4328C164@core3.amsl.com> <4AE4ED72.9000707@earthlink.net> <1256723482.8155.17.camel@acorde.it.uc3m.es> <25c114b90910280300o4ba93b86g8619eec4916649b2@mail.gmail.com> <008201ca57b8$b53615a0$1fa240e0$@nl> <4AE822D3.2030304@gmail.com> <25c114b90910280443q43d0f4b0n3fd8840fff61261@mail.gmail.com> <00ad01ca57c8$03a0b560$0ae22020$@nl> <25c114b90910280607x66c7aa46yfc048b0490b54c16@mail.gmail.com> <4AE845A5.6090106@gmail.com> Date: Wed, 28 Oct 2009 14:27:57 +0100 Message-ID: <25c114b90910280627g2a102ca8jfb38c831570f2ab0@mail.gmail.com> From: Ulrich Herberg <ulrich@herberg.name> To: Alexandru Petrescu <alexandru.petrescu@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: autoconf@ietf.org Subject: Re: [Autoconf] mail formatting (was: I-D Action:draft-bernardos-autoconf-addressing-model-00.txt) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 13:27:47 -0000 Alex, I use the Google mail interface (I know, now you can blame me for trusting Google my mails ;-) This email is written in plain text. Better now? Otherwise, I can also try to use Thunderbird, the Mac mail program etc for mails to IETF lists. Ulrich On Wed, Oct 28, 2009 at 2:22 PM, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote: > > Ulrich Herberg a =E9crit : >> >> Hi Teco, >> >> On Wed, Oct 28, 2009 at 1:13 PM, Teco Boot <teco@inf-net.nl <mailto:teco= @inf-net.nl>> wrote: >> >> =A0 =A0Hi Ulrich, >> >> =A0 =A0Few things. >> >> =A0 =A0Please realize your rich text mails is becoming a mess, when >> =A0 =A0replied with other tools. This troubles the already troubled >> =A0 =A0discussion. I stop cleaning up. >> >> >> >> I did not realize that. If I just answer like now (without changing the = font), is it readable? If not, I can also change to plain text for future m= ails. > > Ulrich - I see your mails are in variable-size font format, including thi= s one. (and not fixed-font like Courrier). =A0Also, I see a strange "|" cit= ation sign instead of the usual ">". =A0This makes me incapable of properly= citing your messages. > > Now, looking at the source code of your messages it seems that you use MI= ME and: >> >> Content-Type: text/plain; charset=3DISO-8859-1 >> Content-Transfer-Encoding: quoted-printable > > Not using MIME at all would help (although there may be Transfer-Encoding= schemes other than quoted-printable which may allow to still use MIME yet = not have this problem) > > Could you please try to fix this? =A0(I can help) - it should happen via = the list, though. > > Alex > > >> >> >> =A0 =A0Then on the small stuff: we are working on MANET stuff, OK? >> >> >> I hope so :-) >> >> =A0 =A0We have a radio, right? >> >> >> yes >> >> =A0 =A0We can use this radio for catching background noise, right? >> >> >> yes >> >> =A0 =A0This is either thermal noise, human made noise, interference, tim= ing, >> =A0 =A0timing of packets received, just to come up with a few. >> >> >> Yes, I am aware that a radio can be good enough as entropy source. The q= uestion is: can we _always_ assume that it is good enough (or accessible to= the device)? Is there an RFC that claims something like: "All devices that= are used in a MANET MUST be able to provide a sufficiently good entropy so= urce". (for whatever meaning of "sufficient") >> >> Because, if we don't have that, I am not sure we can rely on good random= numbers. Maybe we want to add this somewhere, or we have a common understa= nding that all devices have a good enough entropy source. >> >> >> =A0 =A0Please let me know this does not make sense. Because then, I want >> =A0 =A0to be warned and want to stay far, far away from such devices. >> >> >> And still such devices might exist if we don't exclude their use in MANE= Ts. >> >> >> =A0 =A0You were active on MANET and security. Spend some cycles on >> =A0 =A0PRN for small embedded devices with radios? I don't want to push = you, >> =A0 =A0but it would help us if you do. >> >> >> >> For security purposes, evidently the requirements for PRNs are very high= . I admit that I am not an expert on PRNs, so I cannot tell you much. I wil= l try to ask our cryptographers in the department, hopefully they can enlig= hten this issue. >> To my knowledge, there are sufficiently good PRNs (even for small embedd= ed devices), but they depend on very good entropy sources. So when specifyi= ng, say, a security extension to a MANET routing protocol, that document sh= ould probably mention some requirements of the entropy source and the PRN. >> >> >> Ulrich >> >> >> >> >> =A0 =A0Regards, Teco >> >> >> >> >> >> =A0 =A0Van: Ulrich Herberg [mailto:ulrich@herberg.name >> =A0 =A0<mailto:ulrich@herberg.name>] >> =A0 =A0Verzonden: woensdag 28 oktober 2009 12:43 >> =A0 =A0Aan: Alexandru Petrescu >> =A0 =A0CC: Teco Boot; autoconf@ietf.org <mailto:autoconf@ietf.org> >> =A0 =A0Onderwerp: Re: [Autoconf] I-D >> =A0 =A0Action:draft-bernardos-autoconf-addressing-model-00.txt >> >> =A0 =A0Alex, Teco, >> =A0 =A0On Wed, Oct 28, 2009 at 11:54 AM, Alexandru Petrescu >> =A0 =A0<alexandru.petrescu@gmail.com <mailto:alexandru.petrescu@gmail.co= m>> >> =A0 =A0wrote: >> =A0 =A0Teco Boot a =E9crit : >> >> =A0 =A0[..] >> =A0 =A0The answer is: it depends. ;-) If you have a good random number >> =A0 =A0generator >> =A0 =A0(i.e. using an unambiguous seed), then the collision probability = is >> =A0 =A0extremely low. (I let you calculate it using the birthday theorem= ). >> >> =A0 =A0Are birthdays random ?? >> >> >> =A0 =A0Probably not... I can imagine that there are some peeks 9 months = after >> =A0 =A0extremely cold and rainy days ;-) I will not dig deeper into this >> =A0 =A0issue :-) >> >> >> =A0 =A0However, if you have small embedded devices, without persistent >> =A0 =A0memory, good >> =A0 =A0random number generator, etc., you can have collisions >> =A0 =A0with a much higher probability. >> =A0 =A0Why? It is easy to build a pretty good PRN generator with radio H= W. >> =A0 =A0I would say it is much, much, much, much easier than uniqueness >> =A0 =A0guarantee with try and error duplicate detection. >> >> =A0 =A0I agree. =A0Moreover, there is an RFC talking how to select good = entropy >> =A0 =A0sources such that the PRN generator is good. >> >> =A0 =A0Do you mean RFC 4086? Yes, as you say, but all depends on selecti= ng >> =A0 =A0a good >> =A0 =A0entropy source. The RFC says: >> >> =A0 =A0"Is there any hope for true, strong, portable randomness in the f= uture? >> =A0 =A0There might be. All that's needed is a physical source of unpredi= ctable >> =A0 =A0numbers." >> >> =A0 =A0It also says that if no good hardware entropy sources are availab= le, >> =A0 =A0"there >> =A0 =A0are other possibilities. These include system clocks, system or >> =A0 =A0input/output >> =A0 =A0buffers, user/system/hardware/network serial numbers or addresses= and >> =A0 =A0timing, and user input. Unfortunately, each of these sources can = produce >> =A0 =A0very limited or predictable values under some circumstances." >> >> =A0 =A0So it really depends on the kind of hardware we are talking about= . I >> =A0 =A0could >> =A0 =A0imagine very small sensors without persistent state or other >> =A0 =A0hardware source >> =A0 =A0such as mentioned in the RFC. Using such a device could lead to >> =A0 =A0collisions >> =A0 =A0when calculating random numbers. >> >> >> =A0 =A0(small embedded devices, such as sensors, can constitute good sou= rces of >> =A0 =A0 randomness when sampling the temperature, for example - that RFC= says). >> >> =A0 =A0yes. But can we guarantee that each MANET router has a good entro= py >> =A0 =A0source? >> =A0 =A0Please point me to some reference saying that each device that ca= n >> =A0 =A0be used >> =A0 =A0in a MANET must have a good entropy source. >> >> =A0 =A0Ulrich >> >> >> >> =A0 =A0Alex >> =A0 =A0Not even >> =A0 =A0mentioning total network meltdowns after a first MANET merge. >> >> =A0 =A0And I don't have those devices, I want to stay far, far from them= . >> =A0 =A0And I don't want to run protocols for it in my MANETs. >> =A0 =A0Please provide refs to equipment that you have in mind. First, >> =A0 =A0I'll check why good PRN can't be supported. If not, I can stay fa= r >> =A0 =A0away from >> =A0 =A0these (also having security in mind). >> >> =A0 =A0Still waiting on answers on DHCP DUID, key generation etc. >> >> >> =A0 =A0Regards, Teco >> =A0 =A0_______________________________________________ >> =A0 =A0Autoconf mailing list >> =A0 =A0Autoconf@ietf.org <mailto:Autoconf@ietf.org> >> =A0 =A0https://www.ietf.org/mailman/listinfo/autoconf >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > From alexandru.petrescu@gmail.com Wed Oct 28 07:25:32 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 68A0628C17D for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 07:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AWL=0.153, 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 UlfRBN8cXkXq for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 07:25:31 -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 D468128C18B for <autoconf@ietf.org>; Wed, 28 Oct 2009 07:25:30 -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 n9SEPhtH019535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Oct 2009 15:25:43 +0100 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 n9SEPhII005439; Wed, 28 Oct 2009 15:25:43 +0100 (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 n9SEPg67021180; Wed, 28 Oct 2009 15:25:43 +0100 Message-ID: <4AE85466.3090702@gmail.com> Date: Wed, 28 Oct 2009 15:25:42 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ulrich Herberg <ulrich@herberg.name> References: <20091019233002.15F4328C164@core3.amsl.com> <4AE4ED72.9000707@earthlink.net> <1256723482.8155.17.camel@acorde.it.uc3m.es> <25c114b90910280300o4ba93b86g8619eec4916649b2@mail.gmail.com> <008201ca57b8$b53615a0$1fa240e0$@nl> <4AE822D3.2030304@gmail.com> <25c114b90910280443q43d0f4b0n3fd8840fff61261@mail.gmail.com> <00ad01ca57c8$03a0b560$0ae22020$@nl> <25c114b90910280607x66c7aa46yfc048b0490b54c16@mail.gmail.com> <4AE845A5.6090106@gmail.com> <25c114b90910280627g2a102ca8jfb38c831570f2ab0@mail.gmail.com> In-Reply-To: <25c114b90910280627g2a102ca8jfb38c831570f2ab0@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] mail formatting X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 14:25:32 -0000 Ulrich Herberg a écrit : > Alex, > > I use the Google mail interface (I know, now you can blame me for > trusting Google my mails ;-) > This email is written in plain text. Better now? Otherwise, I can also > try to use Thunderbird, the Mac mail program etc for mails to IETF > lists. Yes Ulrich, this is much better, thank you. I believe in this way we can better understand each other, easier to cite text and follow discussion. Alex > > > Ulrich > > On Wed, Oct 28, 2009 at 2:22 PM, Alexandru Petrescu > <alexandru.petrescu@gmail.com> wrote: >> Ulrich Herberg a écrit : >>> Hi Teco, >>> >>> On Wed, Oct 28, 2009 at 1:13 PM, Teco Boot <teco@inf-net.nl <mailto:teco@inf-net.nl>> wrote: >>> >>> Hi Ulrich, >>> >>> Few things. >>> >>> Please realize your rich text mails is becoming a mess, when >>> replied with other tools. This troubles the already troubled >>> discussion. I stop cleaning up. >>> >>> >>> >>> I did not realize that. If I just answer like now (without changing the font), is it readable? If not, I can also change to plain text for future mails. >> Ulrich - I see your mails are in variable-size font format, including this one. (and not fixed-font like Courrier). Also, I see a strange "|" citation sign instead of the usual ">". This makes me incapable of properly citing your messages. >> >> Now, looking at the source code of your messages it seems that you use MIME and: >>> Content-Type: text/plain; charset=ISO-8859-1 >>> Content-Transfer-Encoding: quoted-printable >> Not using MIME at all would help (although there may be Transfer-Encoding schemes other than quoted-printable which may allow to still use MIME yet not have this problem) >> >> Could you please try to fix this? (I can help) - it should happen via the list, though. >> >> Alex >> >> >>> >>> Then on the small stuff: we are working on MANET stuff, OK? >>> >>> >>> I hope so :-) >>> >>> We have a radio, right? >>> >>> >>> yes >>> >>> We can use this radio for catching background noise, right? >>> >>> >>> yes >>> >>> This is either thermal noise, human made noise, interference, timing, >>> timing of packets received, just to come up with a few. >>> >>> >>> Yes, I am aware that a radio can be good enough as entropy source. The question is: can we _always_ assume that it is good enough (or accessible to the device)? Is there an RFC that claims something like: "All devices that are used in a MANET MUST be able to provide a sufficiently good entropy source". (for whatever meaning of "sufficient") >>> >>> Because, if we don't have that, I am not sure we can rely on good random numbers. Maybe we want to add this somewhere, or we have a common understanding that all devices have a good enough entropy source. >>> >>> >>> Please let me know this does not make sense. Because then, I want >>> to be warned and want to stay far, far away from such devices. >>> >>> >>> And still such devices might exist if we don't exclude their use in MANETs. >>> >>> >>> You were active on MANET and security. Spend some cycles on >>> PRN for small embedded devices with radios? I don't want to push you, >>> but it would help us if you do. >>> >>> >>> >>> For security purposes, evidently the requirements for PRNs are very high. I admit that I am not an expert on PRNs, so I cannot tell you much. I will try to ask our cryptographers in the department, hopefully they can enlighten this issue. >>> To my knowledge, there are sufficiently good PRNs (even for small embedded devices), but they depend on very good entropy sources. So when specifying, say, a security extension to a MANET routing protocol, that document should probably mention some requirements of the entropy source and the PRN. >>> >>> >>> Ulrich >>> >>> >>> >>> >>> Regards, Teco >>> >>> >>> >>> >>> >>> Van: Ulrich Herberg [mailto:ulrich@herberg.name >>> <mailto:ulrich@herberg.name>] >>> Verzonden: woensdag 28 oktober 2009 12:43 >>> Aan: Alexandru Petrescu >>> CC: Teco Boot; autoconf@ietf.org <mailto:autoconf@ietf.org> >>> Onderwerp: Re: [Autoconf] I-D >>> Action:draft-bernardos-autoconf-addressing-model-00.txt >>> >>> Alex, Teco, >>> On Wed, Oct 28, 2009 at 11:54 AM, Alexandru Petrescu >>> <alexandru.petrescu@gmail.com <mailto:alexandru.petrescu@gmail.com>> >>> wrote: >>> Teco Boot a écrit : >>> >>> [..] >>> The answer is: it depends. ;-) If you have a good random number >>> generator >>> (i.e. using an unambiguous seed), then the collision probability is >>> extremely low. (I let you calculate it using the birthday theorem). >>> >>> Are birthdays random ?? >>> >>> >>> Probably not... I can imagine that there are some peeks 9 months after >>> extremely cold and rainy days ;-) I will not dig deeper into this >>> issue :-) >>> >>> >>> However, if you have small embedded devices, without persistent >>> memory, good >>> random number generator, etc., you can have collisions >>> with a much higher probability. >>> Why? It is easy to build a pretty good PRN generator with radio HW. >>> I would say it is much, much, much, much easier than uniqueness >>> guarantee with try and error duplicate detection. >>> >>> I agree. Moreover, there is an RFC talking how to select good entropy >>> sources such that the PRN generator is good. >>> >>> Do you mean RFC 4086? Yes, as you say, but all depends on selecting >>> a good >>> entropy source. The RFC says: >>> >>> "Is there any hope for true, strong, portable randomness in the future? >>> There might be. All that's needed is a physical source of unpredictable >>> numbers." >>> >>> It also says that if no good hardware entropy sources are available, >>> "there >>> are other possibilities. These include system clocks, system or >>> input/output >>> buffers, user/system/hardware/network serial numbers or addresses and >>> timing, and user input. Unfortunately, each of these sources can produce >>> very limited or predictable values under some circumstances." >>> >>> So it really depends on the kind of hardware we are talking about. I >>> could >>> imagine very small sensors without persistent state or other >>> hardware source >>> such as mentioned in the RFC. Using such a device could lead to >>> collisions >>> when calculating random numbers. >>> >>> >>> (small embedded devices, such as sensors, can constitute good sources of >>> randomness when sampling the temperature, for example - that RFC says). >>> >>> yes. But can we guarantee that each MANET router has a good entropy >>> source? >>> Please point me to some reference saying that each device that can >>> be used >>> in a MANET must have a good entropy source. >>> >>> Ulrich >>> >>> >>> >>> Alex >>> Not even >>> mentioning total network meltdowns after a first MANET merge. >>> >>> And I don't have those devices, I want to stay far, far from them. >>> And I don't want to run protocols for it in my MANETs. >>> Please provide refs to equipment that you have in mind. First, >>> I'll check why good PRN can't be supported. If not, I can stay far >>> away from >>> these (also having security in mind). >>> >>> Still waiting on answers on DHCP DUID, key generation etc. >>> >>> >>> Regards, Teco >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org <mailto:Autoconf@ietf.org> >>> https://www.ietf.org/mailman/listinfo/autoconf >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf >> > From charles.perkins@earthlink.net Wed Oct 28 08:51:09 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D302A28C1D5 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 08:51:09 -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 S923Cx42U8hq for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 08:51:08 -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 C0A2028C1CE for <autoconf@ietf.org>; Wed, 28 Oct 2009 08:51:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=O+D4XO70JZW1NM4A6Jle6QowT3BMU3B3mLLaIMTSOmGOBjn+gmHkh5B0pYiN6L25; 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 <charles.perkins@earthlink.net>) id 1N3Anz-0005J8-Th; Wed, 28 Oct 2009 11:51:24 -0400 Message-ID: <4AE8687A.7070704@earthlink.net> Date: Wed, 28 Oct 2009 08:51:22 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <C228A97A-1D28-43CE-8BA4-07A9C7BD3AC5@gmail.com> <4AE807E5.6030301@gmail.com> <4AE80D7C.8020200@earthlink.net> <4AE81912.4040409@gmail.com> In-Reply-To: <4AE81912.4040409@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52f29c7054f8bcdaa896380883ebe1bdbb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 15:51:10 -0000 Hello Alex, Alexandru Petrescu wrote: > >> >> There is no procedure for "retiring" a draft. > > Yes, I believe so. I think we may need to propose one. That would be in a different group, concerned with process details. > > Our Chairs and DT have brought us to a situation unseen before: ask > for consensus _after_ having supposed that consensus existed, and > _after_ having acted as if that consensus existed - they submitted and > approved submission of a WG item. Or, more likely, they gauged consensus based on their reading of the megabytes of discussion on the list. > > If we realize that was wrong, then we need a procedure to deal with > that. Ideas feel free to express how to deal with it. My suggestion would be to ask your contacts on the IESG about which working group would be appropriate for this work. > > Maybe a new option at tools.ietf.org? > >> This seems like obstructionism to me. > > No, not obstructionism - realism. I'm a realist. I don't perceive your characterizations as realistic. > > I can also call your action of submitting without WG approval as > non-legitimacy, but I won't go that far. You can call my action anything you want, but I had no role in the decision to accept that document as a WG item. > >> The chairs thought there was enough consensus to adopt the >> draft and get moving. There were objections. The chairs now, >> it seems to me, are asking to verify whether there is enough >> consensus to confirm the adoption of the draft. >> >> What's so hard about that? > > Charles - that is your interpretation. To use your words, my description is realism. > > I have never seen any other time where people submit WG items before > having consensus on the WG. You might want to check on that. The process for adopting WG items has by no means always been so nitpicky as you seem to suggest. Regards, Charlie P. From charles.perkins@earthlink.net Wed Oct 28 08:55:50 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65DA73A68ED for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 08:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 JQ-xxpaKUzxm for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 08:55:49 -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 919DB3A67A3 for <autoconf@ietf.org>; Wed, 28 Oct 2009 08:55:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=exIW+wZ+dM2iLySfhz0GM3KETH86h1fLBP+lZVGhVG3gPJBfKol+THIqDaZAG4kV; 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-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N3AsU-0002ka-Bj; Wed, 28 Oct 2009 11:56:02 -0400 Message-ID: <4AE86992.903@earthlink.net> Date: Wed, 28 Oct 2009 08:56:02 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Teco Boot <teco@inf-net.nl> References: <20091019233002.15F4328C164@core3.amsl.com> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <B4DD4464-E3AF-452B-9BF4-59412C311A0F@thomasclausen.org> <1256493151.4766.58.camel@acorde.it.uc3m.es> <4AE4997E.6090705@earthlink.net> <1256514067.4766.171.camel@acorde.it.uc3m.es> <4AE4ED72.9000707@earthlink.net> <1256723482.8155.17.camel@acorde.it.uc3m.es> <25c114b90910280300o4ba93b86g8619eec4916649b2@mail.gmail.com> <008201ca57b8$b53615a0$1fa240e0$@nl> In-Reply-To: <008201ca57b8$b53615a0$1fa240e0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52ac668026b745b8a886cd086720bd29e4350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: [Autoconf] answers on DHCP DUID, key generation etc. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 15:55:50 -0000 Hello Teco, Teco Boot wrote: > > Still waiting on answers on DHCP DUID, key generation etc. > Your wait is over, at least for my answer. - DHCP DUID isn't going to help if you don't already have DHCP. My strong recommendation, for scalability and robustness, would be to avoid any requirement for DHCP. - For key distribution, you didn't like my long key? Why not? Well then, pick a shorter one. It becomes a matter of engineering. - For "etc." -- I don't think there were any other open issues in my queue. Regards, Charlie P. From charles.perkins@earthlink.net Wed Oct 28 09:01:53 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E98323A6882 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 09:01:53 -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 AMxE00sNp0MJ for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 09:01:51 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 746133A67F1 for <autoconf@ietf.org>; Wed, 28 Oct 2009 09:01:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=QUFQhOMqT6qAQyaTxqxwwPjaEd3CykixHK1/zPNJjNjMAACJ/rEsetWDu9UCyDuZ; 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-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N3AyM-000693-GD; Wed, 28 Oct 2009 12:02:06 -0400 Message-ID: <4AE86AFE.4070602@earthlink.net> Date: Wed, 28 Oct 2009 09:02:06 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <20091019233002.15F4328C164@core3.amsl.com> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <B4DD4464-E3AF-452B-9BF4-59412C311A0F@thomasclausen.org> <1256493151.4766.58.camel@acorde.it.uc3m.es> <4AE4997E.6090705@earthlink.net> <1256514067.4766.171.camel@acorde.it.uc3m.es> <4AE4ED72.9000707@earthlink.net> <1256723482.8155.17.camel@acorde.it.uc3m.es> <25c114b90910280300o4ba93b86g8619eec4916649b2@mail.gmail.com> <008201ca57b8$b53615a0$1fa240e0$@nl> <4AE822D3.2030304@gmail.com> In-Reply-To: <4AE822D3.2030304@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5225de496f594b688fe4ee1e211416c938350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-bernardos-autoconf-addressing-model-00.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 16:01:54 -0000 Hello Alex, Alexandru Petrescu wrote: > >> >> Why? It is easy to build a pretty good PRN generator with radio HW. >> I would say it is much, much, much, much easier than uniqueness >> guarantee with try and error duplicate detection. > > I agree. Moreover, there is an RFC talking how to select good entropy > sources such that the PRN generator is good. > > (small embedded devices, such as sensors, can constitute good sources of > randomness when sampling the temperature, for example - that RFC says). Maybe it is time for an "Errata" for the RFC? Of course it depends on the temperature sensitivity of, say, the accelerometer or moisture sensor. And if there are people who are only interested in solutions utilizing such randomizations, maybe they should first propose a new look at the entire IPv6 protocol design for address uniqueness. Maybe the state of the are has progressed sufficiently that the previous discussions have lost some of their validity. In the meantime, can we go forward here? Regards, Charlie P. From teco@inf-net.nl Wed Oct 28 09:14:07 2009 Return-Path: <teco@inf-net.nl> 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 32BE13A690B for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 09:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.275 X-Spam-Level: X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=0.324, 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 5s69OVS6DfsG for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 09:14:06 -0700 (PDT) Received: from CPSMTPM-EML103.kpnxchange.com (cpsmtpm-eml103.kpnxchange.com [195.121.3.7]) by core3.amsl.com (Postfix) with ESMTP id 287973A6847 for <autoconf@ietf.org>; Wed, 28 Oct 2009 09:14:05 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML103.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Wed, 28 Oct 2009 17:14:20 +0100 From: "Teco Boot" <teco@inf-net.nl> To: "'Charles E. Perkins'" <charles.perkins@earthlink.net> References: <20091019233002.15F4328C164@core3.amsl.com> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <B4DD4464-E3AF-452B-9BF4-59412C311A0F@thomasclausen.org> <1256493151.4766.58.camel@acorde.it.uc3m.es> <4AE4997E.6090705@earthlink.net> <1256514067.4766.171.camel@acorde.it.uc3m.es> <4AE4ED72.9000707@earthlink.net> <1256723482.8155.17.camel@acorde.it.uc3m.es> <25c114b90910280300o4ba93b86g8619eec4916649b2@mail.gmail.com> <008201ca57b8$b53615a0$1fa240e0$@nl> <4AE86992.903@earthlink.net> In-Reply-To: <4AE86992.903@earthlink.net> Date: Wed, 28 Oct 2009 17:14:20 +0100 Message-ID: <011a01ca57e9$b49ac9c0$1dd05d40$@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: AcpX5y2+TWhyxDtwTkqyWxGQ16MbQAAAX2PA Content-Language: nl X-OriginalArrivalTime: 28 Oct 2009 16:14:20.0711 (UTC) FILETIME=[B4E0D370:01CA57E9] Cc: autoconf@ietf.org Subject: Re: [Autoconf] answers on DHCP DUID, key generation etc. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 16:14:07 -0000 Hi Charlie, >- DHCP DUID isn't going to help if you don't already have DHCP. > My strong recommendation, for scalability and robustness, would > be to avoid any requirement for DHCP. I guess you understand my point very well. There are IETF protocols that assume nodes have a unique ID, and there was no discussion on getting the id that I can remember. But I was not there, I assume. I hope your recommendation applies only for MANETs. I think DHCP can be very useful for attached MANETs, for getting "additional information", i.e. other than addresses. >- For key distribution, you didn't like my long key? Why not? > Well then, pick a shorter one. It becomes a matter of engineering. Some do not like pre-shared keys. And if it was a private, a good PRN can be generated very easily. Or just pre-load a guaranteed unique global address. Regards, Teco From alexandru.petrescu@gmail.com Wed Oct 28 09:21:14 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 AD23A28C1E1 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 09:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=0.152, 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 jg6i6d2KiAF5 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 09:21:14 -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 A874028C212 for <autoconf@ietf.org>; Wed, 28 Oct 2009 09:21:13 -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 n9SGLQx1021239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Oct 2009 17:21:26 +0100 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 n9SGLPsd010741; Wed, 28 Oct 2009 17:21:26 +0100 (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 n9SGLNxg002885; Wed, 28 Oct 2009 17:21:25 +0100 Message-ID: <4AE86F83.3000005@gmail.com> Date: Wed, 28 Oct 2009 17:21:23 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" <charles.perkins@earthlink.net> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <C228A97A-1D28-43CE-8BA4-07A9C7BD3AC5@gmail.com> <4AE807E5.6030301@gmail.com> <4AE80D7C.8020200@earthlink.net> <4AE81912.4040409@gmail.com> <4AE8687A.7070704@earthlink.net> In-Reply-To: <4AE8687A.7070704@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 16:21:14 -0000 Hi Charles, I think you're right about new processes being discussed elsewhere in other WGs. Existing process could be discussed here though, I believe. Charles E. Perkins a écrit : [...] >> If we realize that was wrong, then we need a procedure to deal with >> that. Ideas feel free to express how to deal with it. > > My suggestion would be to ask your contacts on the IESG about which > working group would be appropriate for this work. Hmmm... let me think... who do I know in IESG... Otherwise, let's see what we can do process-wise here in AUTOCONF. How about asking the Chairs to ask the Group to send their requests for agenda items soon? This is also a sort of process, or ways I see happening already in many WGs, and not in AUTOCONF :-( If we do that agenda stuff now, then there'll be less surprise later during the meeting. Or you prefer to be surprised? [...] >> I have never seen any other time where people submit WG items >> before having consensus on the WG. > > You might want to check on that. Well I checked recently 6MAN, NETEXT, MEXT, ROLL, 6LoWPAN - the 5 had calls for WG item adoption. Often there was call for adoption of the DT output too. > The process for adopting WG items has by no means always been so > nitpicky as you seem to suggest. Hmmm... I am curious about the WGs where WG item adoption isn't usually happening with a call - please enlighten. I am not nitpickying sorry. I have already discussed twice offline with somebody else surprised how we don't see agenda, no item adoption call, on this WG. Let alone the non-use of the issue tracker. You might find all those to be obstacles to finishing the DT draft, I know - ok. I personally can not go any further without such processes. Let us finish here about process and say we don't agree. I will read your post about this, but not reply unless you ask me explicitely to reply. Alex > > Regards, Charlie P. > > From charles.perkins@earthlink.net Wed Oct 28 09:29:10 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF5F728C1E1 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 09:29:10 -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 dMCW2uEGoRow for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 09:29:09 -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 9743D28C219 for <autoconf@ietf.org>; Wed, 28 Oct 2009 09:29:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=a/uKZLIEzof0L3E5yOlojmkvnZERu9cGDY4bRs6/4GeMrsZLwoS1dxg1E33EPrhZ; 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 <charles.perkins@earthlink.net>) id 1N3BOk-0001cy-P2; Wed, 28 Oct 2009 12:29:22 -0400 Message-ID: <4AE87162.1040002@earthlink.net> Date: Wed, 28 Oct 2009 09:29:22 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <C228A97A-1D28-43CE-8BA4-07A9C7BD3AC5@gmail.com> <4AE807E5.6030301@gmail.com> <4AE80D7C.8020200@earthlink.net> <4AE81912.4040409@gmail.com> <4AE8687A.7070704@earthlink.net> <4AE86F83.3000005@gmail.com> In-Reply-To: <4AE86F83.3000005@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f522393bf21836e506134ef2a2461c4bca7350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 16:29:10 -0000 Hello Alex, Alexandru Petrescu wrote: > >>> If we realize that was wrong, then we need a procedure to deal with >>> that. Ideas feel free to express how to deal with it. >> >> My suggestion would be to ask your contacts on the IESG about which >> working group would be appropriate for this work. > > Hmmm... let me think... who do I know in IESG... They have colorful dots and love to spend time on process details :-) > > Otherwise, let's see what we can do process-wise here in AUTOCONF. Indeed. I'd suggest promulgating the draft after verifying consensus. > > How about asking the Chairs to ask the Group to send their requests for > agenda items soon? I thought that was already done, at your instigation. > > This is also a sort of process, or ways I see happening already in > many WGs, and not in AUTOCONF :-( Yes, I see many working groups making progress. > > If we do that agenda stuff now, then there'll be less surprise later > during the meeting. > > Or you prefer to be surprised? I'm already surprised, but of course setting the agenda soon would be a good idea. And in other emails I see that some agenda topics were identified. > > [...] > >>> I have never seen any other time where people submit WG items >>> before having consensus on the WG. >> >> You might want to check on that. > > Well I checked recently 6MAN, NETEXT, MEXT, ROLL, 6LoWPAN - the 5 had > calls for WG item adoption. Often there was call for adoption of the > DT output too. I think Jari Arkko had email relevant to this topic. > > > I am not nitpickying sorry. I have already discussed twice offline > with somebody else surprised how we don't see agenda, no item adoption > call, on this WG. > > Let alone the non-use of the issue tracker. This is a good point. The issue tracker is terribly underutilized in most working groups, as I found out to my surprise when I was trying to learn to use it. Regards, Charlie P. From charles.perkins@earthlink.net Wed Oct 28 09:33:26 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7175828C1DC for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 09:33:26 -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 pFx+shzkd-R9 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 09:33:25 -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 9460F28C1C7 for <autoconf@ietf.org>; Wed, 28 Oct 2009 09:33:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=MntliwHzjJCVin8EqV4th9OZ1olL7Q9UJgD1SROaIE2BM8LXa48vMH6U9njPDsIu; 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 <charles.perkins@earthlink.net>) id 1N3BSu-0004XR-6t; Wed, 28 Oct 2009 12:33:40 -0400 Message-ID: <4AE87264.60506@earthlink.net> Date: Wed, 28 Oct 2009 09:33:40 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Teco Boot <teco@inf-net.nl> References: <20091019233002.15F4328C164@core3.amsl.com> <1256237606.5373.22.camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> <1256491742.4766.35.camel@acorde.it.uc3m.es> <B4DD4464-E3AF-452B-9BF4-59412C311A0F@thomasclausen.org> <1256493151.4766.58.camel@acorde.it.uc3m.es> <4AE4997E.6090705@earthlink.net> <1256514067.4766.171.camel@acorde.it.uc3m.es> <4AE4ED72.9000707@earthlink.net> <1256723482.8155.17.camel@acorde.it.uc3m.es> <25c114b90910280300o4ba93b86g8619eec4916649b2@mail.gmail.com> <008201ca57b8$b53615a0$1fa240e0$@nl> <4AE86992.903@earthlink.net> <011a01ca57e9$b49ac9c0$1dd05d40$@nl> In-Reply-To: <011a01ca57e9$b49ac9c0$1dd05d40$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5213cfbde98158c45747a169dc2035f403350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] answers on DHCP DUID, key generation etc. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 16:33:26 -0000 Hello Teco, Teco Boot wrote: > Hi Charlie, > > >> - DHCP DUID isn't going to help if you don't already have DHCP. >> My strong recommendation, for scalability and robustness, would >> be to avoid any requirement for DHCP. >> > > I guess you understand my point very well. There are IETF protocols that > assume nodes have a unique ID, and there was no discussion on getting the > id that I can remember. But I was not there, I assume. > > I hope your recommendation applies only for MANETs. > Yes. Obviously DHCP has a strong role in the administration of fixed networks and even infrastructure-based networks with mobile nodes. > I think DHCP can be very useful for attached MANETs, for getting > "additional information", i.e. other than addresses. > I agree. I just don't think it fits very well in networks composed of highly mobile wireless nodes, especially when the network has no point of attachment to the Internet. > > >> - For key distribution, you didn't like my long key? Why not? >> Well then, pick a shorter one. It becomes a matter of engineering. >> > > Some do not like pre-shared keys. > And if it was a private, a good PRN can be generated very easily. > Or just pre-load a guaranteed unique global address. > The latter choice makes the whole discussion moot, but of course when that is available I think it is the right thing to do. Regards, Charlie P. From ryuji.wakikawa@gmail.com Wed Oct 28 11:33:07 2009 Return-Path: <ryuji.wakikawa@gmail.com> 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 31B2B28C20B for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 11:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.525 X-Spam-Level: X-Spam-Status: No, score=-1.525 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_37=0.6] 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 xhAb0Nwz3+jH for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 11:33:06 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id CE07B28C192 for <autoconf@ietf.org>; Wed, 28 Oct 2009 11:33:05 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so1759152fgg.13 for <autoconf@ietf.org>; Wed, 28 Oct 2009 11:33:17 -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=FP2qFB+2IlyccWQFxQzmtS4p4bXvY1UEjvtSmMfT6qo=; b=q6OMikBFUXtaK4pKfIQ3gKyhoYjF3GRi+FqzinoUbHBtlpUPOSBZTcSHsfLEEAa98o YuShS3qWuMVAluBOAMI5XL9Cr5Zxbc0Q+6wbEcRqPmqcgo4F4pqwLsWu3QKitwJ9ncXA UrMhpaQgiCjN+ubGUXf6trgE7GvLBmauEa1Pk= 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=b+zqv41wpIROCsKyLG7CyoHjXjfyIjDoDEL4tOWEfBvuQzRV/rt9Ul0xNDQVFOKwK9 lA0tv4kCQlCzTOrq+I5lUzW/w9UGridU0qd2I1ClJfd7+sq015qYcQA5/320p3XflORe kSjI4/iZtS4LDiLaFO6C81yUecSmI/St/y9fI= Received: by 10.86.13.36 with SMTP id 36mr1014892fgm.25.1256754796912; Wed, 28 Oct 2009 11:33:16 -0700 (PDT) Received: from macbookpro-ryuji.paloalto.toyota-itc.com ([206.132.173.18]) by mx.google.com with ESMTPS id d6sm2970675fga.10.2009.10.28.11.33.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 28 Oct 2009 11:33:16 -0700 (PDT) From: Ryuji Wakikawa <ryuji.wakikawa@gmail.com> To: Alexandru Petrescu <alexandru.petrescu@gmail.com> In-Reply-To: <4AE843A4.2050600@gmail.com> References: <64476.81.249.151.17.1256732116.squirrel@mail.tigertech.net> <1256732791.8155.95.camel@acorde.it.uc3m.es> <65259.81.249.151.17.1256733108.squirrel@mail.tigertech.net> <4AE83EA2.1080704@gmail.com> <65440.81.249.151.17.1256735126.squirrel@mail.tigertech.net> <4AE843A4.2050600@gmail.com> Message-Id: <86A14029-6E5F-4425-8D3D-5B40625407F6@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 28 Oct 2009 11:33:12 -0700 X-Mailer: Apple Mail (2.936) Cc: "autoconf@ietf.org" <autoconf@ietf.org>, Thomas Heide Clausen <thomas@thomasclausen.org> Subject: Re: [Autoconf] Procedure X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 18:33:07 -0000 Hi Alex, On 2009/10/28, at 6:14, Alexandru Petrescu wrote: > Thomas Heide Clausen a =C3=A9crit : >> On Wed, October 28, 2009 5:52 am, Alexandru Petrescu wrote: >>> Thomas Heide Clausen a =C3=A9crit : >>>> Carlos, >>>> Ok, let's try this, then, to see how much of a hurry we're really >>>> in: >>>> o Jari, can we have our milestone moved another 5 years into the >>>> future? >>> Thomas - can we have agenda requests for the meeting in advance? >>> Or are you going to decide only the DT document gets presented - >>> despite the discussion on the draft-bernardos? >> The working-group is on a tight schedule, and we have specific work >> to do. I therefore would suggest that we do not open up for any odd >> presentation -- we won't have time for that. >> However... >> There have been, as I count it, three documents discussed on the list >> recently: the Baccelli/Townsley address model document, the Perkins/=20= >> Baccelli "link model" document and the Carlos/Ronald address >> model document. >> The two latter have emerged in the discussions only recently, but >> appear to be useful for the WG to have presented. >> My *personal* suggestion would be to ask the authors of each of these >> three documents to present, and if they're willing to do so of >> course have those on the agenda. > > Thomas I agree with your personal suggestion - make now a request =20 > for agenda items. > > Your draft agenda is due this midnight - are you ready for it? Are =20= > you > going to act under pressure - again? > > And please publish here the draft agenda tomorrow, thank you. We've published the draft agenda. http://www.ietf.org/proceedings/09nov/agenda/autoconf.txt The agenda is still tentative one,because we want to take further =20 action/decision after we collect all the WG opinions (due is tomorrow). There is another deadline (11/2) for the final WG agenda. We will =20 deliver you the final one before that date. >> As for slides in advance, we always try to get them on-line before >> the WG sessions, but as there often is a lot of work ongoing and >> discussions happening between WG participants during the IETF week >> that is being reflected in the presentations, I'm not sure we can >> reasonably do much earlier than that. > > I agree mostly. Some groups manage to get the slides well in advance. > Why not AUTOCONF? > > It is useful for people wondering whether attending or not, be it > locally or remotely. Agree, it is useful to have slides at the right time. However, AUTOCONF is currently running the adaption call. The chairs =20 wait for all the WG opinions. As soon as we will fix the agenda, we will solicit the slides to the =20 presenters. You can ask presenters to upload the slide on time with certain =20 pressure;-) cheers, ryuji > > Alex > > >> Thomas >>> I noticed there's a deadline this midnight for the draft agenda. >>> This group never submitted agenda in advance, let alone the slides. >>> Can we follow - not the procedure - but some widely used IETF >>> manners in this WG too? >>> Alex >>>> ;) >>>> Thomas >>>> On Wed, October 28, 2009 5:26 am, Carlos Jes=C3=BAs Bernardos Cano >>>> wrote: >>>>> Hi Thomas, >>>>> On Wed, 2009-10-28 at 05:15 -0700, Thomas Heide Clausen wrote: >>>>>> On Wed, October 28, 2009 4:57 am, Jari Arkko wrote: >>>>>>> Alex, >>>>>>>> YEs I believe it is unreasonable to adopt that single >>>>>>>> document when a competitor document exists and which is >>>>>>>> technically more inline with what I think. >>>>>> Also, duly note that the >>>>>> draft-bernardos-autoconf-addressing-model document did not >>>>>> exist and the chairs (and the WG) were not made aware that it >>>>>> was under development, at the time of approval of draft-ietf-=20 >>>>>> autoconf-... >>>>> True, we have been working on this since last IETF meeting. Had >>>>> we (the authors) known that we were about to adopt a document >>>>> as WG draft, we would have submitted it earlier. >>>>> As I mentioned in a previous e-mail, I think it'd be better to >>>>> have a discussion on the content of both drafts before really >>>>> deciding on which one should be taken as baseline, but this is >>>>> my personal opinion. Sorry, but after 5 years working on this >>>>> (and I've been contributing to the WG since the very beginning) >>>>> I don't buy the "we are in a hurry" argument :-). Discussing >>>>> both drafts in Hiroshima would not harm and may be help. >>>>> Thanks, >>>>> Carlos >>>>>> Your opinion is, however, noted. >>>>>> Thomas >>>>>>> I am aware that you wanted to see the other document >>>>>>> adopted instead. But note that I said "given the opinions >>>>>>> in the group" and not any individual's opinion. We all know >>>>>>> that there is no unanimous agreement about this, but I was >>>>>>> curious if someone thought that the chairs had somehow >>>>>>> missed that a large part of the group disagreed with the >>>>>>> idea of adopting the DT document. >>>>>>> Jari >>>>>>> _______________________________________________ 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 >>>>> -- Carlos Jes=C3=BAs Bernardos Cano http://www.netcoms.net GPG >>>>> FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 >>>> _______________________________________________ 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/=20 >>> autoconf > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From Fred.L.Templin@boeing.com Wed Oct 28 11:33:25 2009 Return-Path: <Fred.L.Templin@boeing.com> 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 255903A6867 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 11:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 x2q1AVVqNE27 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 11:33:24 -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 38D333A6A41 for <autoconf@ietf.org>; Wed, 28 Oct 2009 11:33:24 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n9SIXWPW026285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 28 Oct 2009 11:33:33 -0700 (PDT) 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 n9SIXW6o003434; Wed, 28 Oct 2009 13:33:32 -0500 (CDT) Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n9SIXHFs002864 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 28 Oct 2009 13:33:32 -0500 (CDT) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Wed, 28 Oct 2009 11:33:30 -0700 From: "Templin, Fred L" <Fred.L.Templin@boeing.com> To: "Charles E. Perkins" <charles.perkins@earthlink.net>, Teco Boot <teco@inf-net.nl> Date: Wed, 28 Oct 2009 11:33:28 -0700 Thread-Topic: [Autoconf] answers on DHCP DUID, key generation etc. Thread-Index: AcpX7HlzpAcSiMymTQe3IXByYH1BwgADkD6g Message-ID: <12F4112206976147A34FEC0277597CCF27A41F9723@XCH-NW-15V.nw.nos.boeing.com> References: <20091019233002.15F4328C164@core3.amsl.com> <1256237606.5373.22. camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> < 1256491742.4766.35.camel@acorde.it.uc3m.es> <B4DD4464-E3AF-452B-9BF4-59412C 311A0F@thomasclausen.org> <1256493151.4766.58.camel@acorde.it.uc3m.es> <4AE 4997E.6090705@earthlink.net> <1256514067.4766.171.camel@acorde.it.uc3m.es> <4AE4ED72.9000707@earthlink.net> <1256723482.8155.17.camel@acorde.it.uc3m.e s> <25c114b90910280300o4ba93b86g8619eec4916649b2@mail.gmail.com><008201ca57 b8$b53615a0$1fa240e0$@nl> <4AE86992.903@earthlink.net><011a01ca57e9$b49ac9c0$1dd05d40$@nl> <4AE87264.60506@earthlink.net> In-Reply-To: <4AE87264.60506@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" <autoconf@ietf.org> Subject: Re: [Autoconf] answers on DHCP DUID, key generation etc. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 18:33:25 -0000 > -----Original Message----- > From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On Beh= alf Of Charles E. Perkins > Sent: Wednesday, October 28, 2009 9:34 AM > To: Teco Boot > Cc: autoconf@ietf.org > Subject: Re: [Autoconf] answers on DHCP DUID, key generation etc. >=20 >=20 > Hello Teco, >=20 > Teco Boot wrote: > > Hi Charlie, > > > > > >> - DHCP DUID isn't going to help if you don't already have DHCP. > >> My strong recommendation, for scalability and robustness, would > >> be to avoid any requirement for DHCP. > >> > > > > I guess you understand my point very well. There are IETF protocols tha= t > > assume nodes have a unique ID, and there was no discussion on getting t= he > > id that I can remember. But I was not there, I assume. > > > > I hope your recommendation applies only for MANETs. > > >=20 > Yes. Obviously DHCP has a strong role in the administration > of fixed networks and even infrastructure-based networks with > mobile nodes. DHCP is for enterprise networks in which there is some modicum of distributed network administration and a commonality of interests (which may be as basic as the collaborative provisioning of connectivity itself). This model fits well not only with infrastructure-based networks but also with many MANET scenarios with which I am familiar.=20 =20 > > I think DHCP can be very useful for attached MANETs, for getting > > "additional information", i.e. other than addresses. > > >=20 > I agree. I just don't think it fits very well in networks composed > of highly mobile wireless nodes, especially when the network has > no point of attachment to the Internet. Like maybe me and a couple of buddies going to a remote ski area with hand-held multi-hop walkie-talkies when there is no cellular coverage? Even then, unless we all get together beforehand and key our L2 access codes what we get is "anarchy-net", and anyone can crash the party. > >> - For key distribution, you didn't like my long key? Why not? > >> Well then, pick a shorter one. It becomes a matter of engineering. > >> > > > > Some do not like pre-shared keys. > > And if it was a private, a good PRN can be generated very easily. > > Or just pre-load a guaranteed unique global address. > > >=20 > The latter choice makes the whole discussion moot, > but of course when that is available I think it is the right > thing to do. This brings up again a point which I have made in the past=20 that this group could significantly benefit from a detailed MANET use-case analysis before saying what the addressing architecture for *all* MANETs ought to look like. Fred fred.l.templin@boeing.com > Regards, > Charlie P. >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From ryuji.wakikawa@gmail.com Wed Oct 28 11:44:01 2009 Return-Path: <ryuji.wakikawa@gmail.com> 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 9FBD828C1CB for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 11:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, J_CHICKENPOX_52=0.6] 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 c5dga60jstDs for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 11:44:00 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id 1A45528C1C5 for <autoconf@ietf.org>; Wed, 28 Oct 2009 11:43:59 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so1763479fgg.13 for <autoconf@ietf.org>; Wed, 28 Oct 2009 11:44:10 -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=fbYEWxFRogYQr6HTEVMFZ57fIhtjHZdjvp9Y++xDe1s=; b=a0oxfm6Sc3iOZmsby5X5XnG2L3VHE6jyAOKv/Auz2C/dK3Fx6wv78g9LMYUYkf0zM6 DIl4RGVJgzD+MS+dlfQauAAluh9XSbsVJ2gPfAbr25/CZfYdxR0WEYKkrLeEsBgW9lEI lt+7IRgHmQq2J00+3iFjA+PXhGyYRCT38oTRk= 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=IgXg54oKoUBeK1S++EFF5kyFe6jyEDmsuaaZcNgpZ+HnDbSZ4MsfoT9I3BqF2m7T0Q ezjxZoMIZkZz3qSRxUjz3l+G5+He14GPSW5c4Exf7i1AZQdRehqLUEPGfod6Kra/Q53n Vrw4dnjyVVxJLMQVlJnKXRKva+itcpYIxIATA= Received: by 10.87.63.3 with SMTP id q3mr10206163fgk.30.1256755450203; Wed, 28 Oct 2009 11:44:10 -0700 (PDT) Received: from macbookpro-ryuji.paloalto.toyota-itc.com ([206.132.173.18]) by mx.google.com with ESMTPS id 3sm3008968fge.14.2009.10.28.11.44.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 28 Oct 2009 11:44:09 -0700 (PDT) From: Ryuji Wakikawa <ryuji.wakikawa@gmail.com> To: Thomas Heide Clausen <Thomas@ThomasClausen.org> In-Reply-To: <6C98117C-5C99-4548-94A8-E4ADFB0CBF35@thomasclausen.org> References: <D54F0B48-25BB-41CD-A16C-637DA65A4ECA@gmail.com> <4AE09DC1.2080307@gmail.com> <4AE0A7BA.2060002@earthlink.net> <B314228D-5EAD-422B-8DB9-A7BB1F3C7AF4@gmail.com> <4AE2D5AD.6090701@gmail.com> <B223D3F1-3EEB-4A79-B54E-299FB320E54E@gmail.com> <001501ca549f$a9015310$fb03f930$@nl> <AE929909-9238-4BC7-9464-CAAFC6688904@gmail.com> <25EB00CA-F1EE-4793-AC14-0BC9929A980D@gmail.com> <01f901ca56db$5f4bf340$1de3d9c0$@nl> <25c114b90910270135i788a8a45oc0ac5cf87e2ae52@mail.gmail.com> <4AE6C4B5.1050309@gmail.com> <4AE71FB3.9020702@earthlink.net> <005001ca579d$0aa1fa70$1fe5ef50$@nl> <0E3D4BA4-DA3E-4AF7-95B1-133A15939239@thomasclausen.org> <005f01ca57a9$3d419c40$b7c4d4c0$@nl> <13F96869-F259-4D49-9A15-5D4F8756818A@thomasclausen.org> <006101ca57ac$6719b590$354d20b0$@nl> <6C98117C-5C99-4548-94A8-E4ADFB0CBF35@thomasclausen.org> Message-Id: <248F9EFB-018F-4AFD-96F8-AF7E80932554@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 28 Oct 2009 11:44:05 -0700 X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org, 'Emmanuel Baccelli' <Emmanuel.Baccelli@inria.fr> Subject: Re: [Autoconf] Discussion on draft-baccelli-multi-hop-wireless-communication-02 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 18:44:01 -0000 Hi all, On 2009/10/28, at 2:15, Thomas Heide Clausen wrote: > Teco, > > Thanks for the support. > > <wg-chair-hat-on> > > I think that the first steps should be revival of draft-baccelli- > multi-hop-wireless-communication (if the authors are willing - it's > an individual I-D), to bring it up to date, incorporating comments > etc. > > I also think that if I propose to our AD to add further documents as > wg documents, he'll look at me weirdly and ask 'so where are we with > the addressing model, then, the current wg charter item'? > > If my answer is "we're making great progress, the addressing model > actually uses this/these other documents, go look at them on this > URL, but I feel we're ready to submit to the IESG within a month", > then he'll probably be quite receptive to the idea. Otherwise, I > doubt he'll be enthusiastic, considering our spectacular record of > not making measurable progress thus far. > > Therefore, my immediate concern is to get the wg charter item in > shape. If this -- or any other document -- is needed for that end, > let's advance those as individuals for now. When the WG is certain > that there's a strong case for asking the AD to allow us to accept > further documents, I'll make that case to the AD. > > I think that there're no inconveniences to this approach, > considering that I think that Baccelli/Perkins are receptive to WG > input. > > To answer your question, I do not think that this document has been > presented at an autoconf meeting. Should the authors be interested > in doing so in Hiroshima, and should the WG think that it would > help, then I don't see any problems in having a slot during the > autoconf session for that. I agree with Thomas, we should first focus on the addressing model and complete the only one WG item. I would like to focus on the one AUTOCONF WG item at this moment. According to the ML discussion, there are certain interests from WG and relationship to the addressing model document. I am fine with a presentation slot for this work at Hiroshima if authors can incorporate the recent WG discussion in the presentation. The document is also expired a month ago. regards, ryuji > Cheers, > > Thomas > > On Oct 28, 2009, at 9:55 AM, Teco Boot wrote: > >> All, >> >> Just to repeat my responses / opinion on WG documents. >> >> I support draft-baccelli-multi-hop-wireless-communication for >> adoption as WG document. I know it is not our charter, but >> IMHO the document is very useful. Also, it (partly?) solves >> an open issue (MANET link model) in the baccelli-autoconf-adhoc >> -addr-model . >> I remember an AD saying we are allowed to submit an Informational >> Document, if it helps achieving our milestones. >> >> Did authors present this doc at an Autoconf meeting? >> >> Regards, Teco >> >> >> >> >>> -----Oorspronkelijk bericht----- >>> Van: Thomas Heide Clausen [mailto:thomas@thomasclausen.org] >>> Verzonden: woensdag 28 oktober 2009 9:43 >>> Aan: Teco Boot >>> CC: Charles Perkins; autoconf@ietf.org; Emmanuel Baccelli >>> Onderwerp: Discussion on draft-baccelli-multi-hop-wireless- >>> communication-02 >>> >>> Teco, >>> >>> (I change the subject line, as this really is a new thread of >>> discussion) >>> >>> On Oct 28, 2009, at 9:32 AM, Teco Boot wrote: >>> >>>> On: draft-baccelli-multi-hop-wireless-communication-02 >>>> >>>>> Thomas Heide Clausen wrote: >>>>> Can you remind me, Teco, what was wrong with "exposed node"? >>>> >>>> Figure 2 is correct now. >>>> When A sends to B, C is prohibited to send to D due to CS. >>>> But if C was not blocked, B still would receive A. >>>> So preventing C sending to D is reducing the capacity >>>> of the wireless channel (spatial reuse is less optimal). >>>> This problem has little to do with IP. >>>> >>> >>> Alright. >>> >>>> Text in error: >>>>> Even >>>>> though node C cannot hear D, node D can nevertheless hear C, >>>>> because >>>>> node D is outside node A's radio range. >>>> >>>> And: >>>>> the exposed node >>>>> problem is a practical example of the asymmetry >>>> Here, exposed node has little to do with asymmetry (as defined in >>>> same >>>> document. >>> >>> What you say makes sense to me. >>> >>> I'm not an author of that document, and it's not a wg document -- >>> but >>> knowing Charlie/Emmanuel I'm almost willing to bet that they'd be >>> happy to incorporate a change to reflect this (if they agree, of >>> course). Could you propose replacement paragraphs or rewordings? >>> >>> Any other issues that you would like to see addressed in that >>> document? >>> >>> Baccelli/Perkins, feel free to bounce an updated I-D to the list, >>> even >>> if it can't be submitted to the repositories just yet. In my >>> experience, quick turn-around cycles for "alpha's" are a good way of >>> getting both eyes on the document and making rapid progress. >>> >>> We can then discuss in Hiroshima what to do forward? >>> >>> Thanks, >>> >>> Thomas >>> >>>> >>>> >>>> Regards, Teco >>>> >>>> >> > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From ryuji.wakikawa@gmail.com Wed Oct 28 11:59:21 2009 Return-Path: <ryuji.wakikawa@gmail.com> 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 86E9628C0E7 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 11:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.466, 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 uDxticAyG2VE for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 11:59:20 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id 544AC3A689D for <autoconf@ietf.org>; Wed, 28 Oct 2009 11:59:20 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so529433fga.13 for <autoconf@ietf.org>; Wed, 28 Oct 2009 11:59:32 -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=F/FDVqNaZuQYJaJtCxxPWAR0wtEYi81xW5rJAGO8YHM=; b=N1r7EVEFpp0oIRKURmF605TvoTsVRLEu4dtpm5uiEdo/2Ao+g/Vom2kjP0+loByRbO JnlvBlITphPenzYT0+n6B/2ldG4qIsfAGalvDqc/s/PuEMxEfPma02GstWRwWlPuhufn uWnZdpcEnMg5rUndsPXpVRy3Zc/gJyLxvCkb4= 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=Hz6ltBwK77uc+lmcvOI2wfBpslhNI4K1I0EmhTlaHiDhhoMEn3YW7VpY/Lvp8viXYW GWhQV6lxHys1Om47dpzN6LtMIAtv4W+j5t9ie8+qbJgywgp5lJy716ZX5R2t28QjJ63d yPlh8/N0ilMiJygfDcvng36s0LHxhE/6BCqL4= Received: by 10.86.221.25 with SMTP id t25mr2826191fgg.19.1256756372774; Wed, 28 Oct 2009 11:59:32 -0700 (PDT) Received: from macbookpro-ryuji.paloalto.toyota-itc.com ([206.132.173.18]) by mx.google.com with ESMTPS id e20sm3021324fga.5.2009.10.28.11.59.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 28 Oct 2009 11:59:32 -0700 (PDT) From: Ryuji Wakikawa <ryuji.wakikawa@gmail.com> To: Alexandru Petrescu <alexandru.petrescu@gmail.com> In-Reply-To: <4AE81912.4040409@gmail.com> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <C228A97A-1D28-43CE-8BA4-07A9C7BD3AC5@gmail.com> <4AE807E5.6030301@gmail.com> <4AE80D7C.8020200@earthlink.net> <4AE81912.4040409@gmail.com> Message-Id: <9A410E5F-D117-4C41-940B-9B8A30120581@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, 28 Oct 2009 11:59:28 -0700 X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 18:59:21 -0000 Hi Alex, There is a case to adapt a DT document in WG without adaption call. Did you remember we had an adaption call for NEMO-BS? The PMIP IPv4 support doc was published as a WG doc from the =20 beginning, because the NETLMM WG formed DT. In AUTOCONF WG, we have decided to publish the first DT doc as an =20 individual document. After 6 months, authors reflects WG agreement to the document (well =20 maybe not your opinion though). I am not repeating the same reasons why we adapt this doc here again. =20= You can refer to other mails from us. anyway, the adaption call is still open. We cannot retire the WG doc, but we can replace it if that is the WG =20 consensus. regards, ryuji On 2009/10/28, at 3:12, Alexandru Petrescu wrote: > Charles E. Perkins a =E9crit : >> Hello Alex, >> Alexandru Petrescu wrote: >>> Ryuji Wakikawa a =E9crit : >>>> Hi all, >>>> >>>> Reminder, we currently solicit your opinion. >>>> The deadline is Thursday. We only have few reply from WG. >>> >>> Ryuji - how can you ask opinion on something you've already done? >>> >>> This draft _is_ a WG item. >>> >>> It's called draft-ietf-autoconf-adhoc-addr-model >>> >>> I propose you first retire it. >> There is no procedure for "retiring" a draft. > > Yes, I believe so. I think we may need to propose one. > > Our Chairs and DT have brought us to a situation unseen before: ask =20= > for consensus _after_ having supposed that consensus existed, and =20 > _after_ having acted as if that consensus existed - they submitted =20 > and approved submission of a WG item. > > If we realize that was wrong, then we need a procedure to deal with =20= > that. Ideas feel free to express how to deal with it. > > Maybe a new option at tools.ietf.org? > >> This seems like obstructionism to me. > > No, not obstructionism - realism. > > I can also call your action of submitting without WG approval as non-=20= > legitimacy, but I won't go that far. > >> The chairs thought there was enough consensus to adopt the >> draft and get moving. There were objections. The chairs now, >> it seems to me, are asking to verify whether there is enough >> consensus to confirm the adoption of the draft. >> What's so hard about that? > > Charles - that is your interpretation. > > I have never seen any other time where people submit WG items before =20= > having consensus on the WG. > > Have you seen? > > Alex > >> Regards, >> Charlie P. > > From alexandru.petrescu@gmail.com Wed Oct 28 12:01:54 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 06EDE3A6778 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 12:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.324 X-Spam-Level: X-Spam-Status: No, score=-1.324 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_21=0.6, J_CHICKENPOX_37=0.6] 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 Mk5Upk4VC6iu for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 12:01:52 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id DDAFF3A6836 for <autoconf@ietf.org>; Wed, 28 Oct 2009 12:01:45 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 8881DD48145; Wed, 28 Oct 2009 20:01:54 +0100 (CET) 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 2A4FAD48012; Wed, 28 Oct 2009 20:01:52 +0100 (CET) Message-ID: <4AE8951D.9060605@gmail.com> Date: Wed, 28 Oct 2009 20:01:49 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ryuji Wakikawa <ryuji.wakikawa@gmail.com> References: <64476.81.249.151.17.1256732116.squirrel@mail.tigertech.net> <1256732791.8155.95.camel@acorde.it.uc3m.es> <65259.81.249.151.17.1256733108.squirrel@mail.tigertech.net> <4AE83EA2.1080704@gmail.com> <65440.81.249.151.17.1256735126.squirrel@mail.tigertech.net> <4AE843A4.2050600@gmail.com> <86A14029-6E5F-4425-8D3D-5B40625407F6@gmail.com> In-Reply-To: <86A14029-6E5F-4425-8D3D-5B40625407F6@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091028-0, 28/10/2009), Outbound message X-Antivirus-Status: Clean Cc: "autoconf@ietf.org" <autoconf@ietf.org>, Thomas Heide Clausen <thomas@thomasclausen.org> Subject: Re: [Autoconf] Agenda (was: Procedure) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 19:01:54 -0000 Ryuji Wakikawa a écrit : > Hi Alex, > > On 2009/10/28, at 6:14, Alexandru Petrescu wrote: > >> Thomas Heide Clausen a écrit : >>> On Wed, October 28, 2009 5:52 am, Alexandru Petrescu wrote: >>>> Thomas Heide Clausen a écrit : >>>>> Carlos, >>>>> Ok, let's try this, then, to see how much of a hurry we're really >>>>> in: >>>>> o Jari, can we have our milestone moved another 5 years into the >>>>> future? >>>> Thomas - can we have agenda requests for the meeting in advance? >>>> Or are you going to decide only the DT document gets presented - >>>> despite the discussion on the draft-bernardos? >>> The working-group is on a tight schedule, and we have specific work >>> to do. I therefore would suggest that we do not open up for any odd >>> presentation -- we won't have time for that. >>> However... >>> There have been, as I count it, three documents discussed on the list >>> recently: the Baccelli/Townsley address model document, the >>> Perkins/Baccelli "link model" document and the Carlos/Ronald address >>> model document. >>> The two latter have emerged in the discussions only recently, but >>> appear to be useful for the WG to have presented. >>> My *personal* suggestion would be to ask the authors of each of these >>> three documents to present, and if they're willing to do so of >>> course have those on the agenda. >> >> Thomas I agree with your personal suggestion - make now a request for >> agenda items. >> >> Your draft agenda is due this midnight - are you ready for it? Are you >> going to act under pressure - again? >> >> And please publish here the draft agenda tomorrow, thank you. > > We've published the draft agenda. > http://www.ietf.org/proceedings/09nov/agenda/autoconf.txt Thanks! Do you know whether there's anybody else who would wish to present topics around the practical addressing model? > The agenda is still tentative one,because we want to take further > action/decision after we collect all the WG opinions (due is tomorrow). Yes, this night 24pm GMT - is a "draft agenda" deadline of IETF: http://www.ietf.org/meeting/cutoff-dates.html#76 > There is another deadline (11/2) for the final WG agenda. We will > deliver you the final one before that date. Yes, please announce the final agenda to the group thank you. Alex > >>> As for slides in advance, we always try to get them on-line before >>> the WG sessions, but as there often is a lot of work ongoing and >>> discussions happening between WG participants during the IETF week >>> that is being reflected in the presentations, I'm not sure we can >>> reasonably do much earlier than that. >> >> I agree mostly. Some groups manage to get the slides well in advance. >> Why not AUTOCONF? >> >> It is useful for people wondering whether attending or not, be it >> locally or remotely. > > Agree, it is useful to have slides at the right time. > However, AUTOCONF is currently running the adaption call. The chairs > wait for all the WG opinions. > > As soon as we will fix the agenda, we will solicit the slides to the > presenters. > You can ask presenters to upload the slide on time with certain pressure;-) > > cheers, > ryuji > > > >> >> Alex >> >> >>> Thomas >>>> I noticed there's a deadline this midnight for the draft agenda. >>>> This group never submitted agenda in advance, let alone the slides. >>>> Can we follow - not the procedure - but some widely used IETF >>>> manners in this WG too? >>>> Alex >>>>> ;) >>>>> Thomas >>>>> On Wed, October 28, 2009 5:26 am, Carlos Jesús Bernardos Cano >>>>> wrote: >>>>>> Hi Thomas, >>>>>> On Wed, 2009-10-28 at 05:15 -0700, Thomas Heide Clausen wrote: >>>>>>> On Wed, October 28, 2009 4:57 am, Jari Arkko wrote: >>>>>>>> Alex, >>>>>>>>> YEs I believe it is unreasonable to adopt that single >>>>>>>>> document when a competitor document exists and which is >>>>>>>>> technically more inline with what I think. >>>>>>> Also, duly note that the >>>>>>> draft-bernardos-autoconf-addressing-model document did not >>>>>>> exist and the chairs (and the WG) were not made aware that it >>>>>>> was under development, at the time of approval of >>>>>>> draft-ietf-autoconf-... >>>>>> True, we have been working on this since last IETF meeting. Had >>>>>> we (the authors) known that we were about to adopt a document >>>>>> as WG draft, we would have submitted it earlier. >>>>>> As I mentioned in a previous e-mail, I think it'd be better to >>>>>> have a discussion on the content of both drafts before really >>>>>> deciding on which one should be taken as baseline, but this is >>>>>> my personal opinion. Sorry, but after 5 years working on this >>>>>> (and I've been contributing to the WG since the very beginning) >>>>>> I don't buy the "we are in a hurry" argument :-). Discussing >>>>>> both drafts in Hiroshima would not harm and may be help. >>>>>> Thanks, >>>>>> Carlos >>>>>>> Your opinion is, however, noted. >>>>>>> Thomas >>>>>>>> I am aware that you wanted to see the other document >>>>>>>> adopted instead. But note that I said "given the opinions >>>>>>>> in the group" and not any individual's opinion. We all know >>>>>>>> that there is no unanimous agreement about this, but I was >>>>>>>> curious if someone thought that the chairs had somehow >>>>>>>> missed that a large part of the group disagreed with the >>>>>>>> idea of adopting the DT document. >>>>>>>> Jari >>>>>>>> _______________________________________________ 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 >>>>>> -- Carlos Jesús Bernardos Cano http://www.netcoms.net GPG >>>>>> FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 >>>>> _______________________________________________ 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 > > From charles.perkins@earthlink.net Wed Oct 28 12:06:56 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5692D3A687E for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 12:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 HKoYUTuiflat for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 12:06:55 -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 588C13A67F3 for <autoconf@ietf.org>; Wed, 28 Oct 2009 12:06:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=HAqYSbFIbfB67pa5ZOoPJWJANR8dvdqujBP4Sl5c9CKY9cF1WJcWX0PNy8LyKz25; 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-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N3DrN-0003Jv-Te; Wed, 28 Oct 2009 15:07:06 -0400 Message-ID: <4AE89659.5000607@earthlink.net> Date: Wed, 28 Oct 2009 12:07:05 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Templin, Fred L" <Fred.L.Templin@boeing.com> References: <20091019233002.15F4328C164@core3.amsl.com> <1256237606.5373.22. camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> < 1256491742.4766.35.camel@acorde.it.uc3m.es> <B4DD4464-E3AF-452B-9BF4-59412C 311A0F@thomasclausen.org> <1256493151.4766.58.camel@acorde.it.uc3m.es> <4AE 4997E.6090705@earthlink.net> <1256514067.4766.171.camel@acorde.it.uc3m.es> <4AE4ED72.9000707@earthlink.net> <1256723482.8155.17.camel@acorde.it.uc3m.e s> <25c114b90910280300o4ba93b86g8619eec4916649b2@mail.gmail.com><008201ca57 b8$b53615a0$1fa240e0$@nl> <4AE86992.903@earthlink.net><011a01ca57e9$b49ac9c0$1dd05d40$@nl> <4AE87264.60506@earthlink.net> <12F4112206976147A34FEC0277597CCF27A41F9723@XCH-NW-15V.nw.nos.boeing.com> In-Reply-To: <12F4112206976147A34FEC0277597CCF27A41F9723@XCH-NW-15V.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52d079ea1a7e0146916ecd455704979273350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: "autoconf@ietf.org" <autoconf@ietf.org> Subject: Re: [Autoconf] answers on DHCP DUID, key generation etc. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 19:06:56 -0000 Hello Fred, Comments below... Templin, Fred L wrote: >> >> Yes. Obviously DHCP has a strong role in the administration >> of fixed networks and even infrastructure-based networks with >> mobile nodes. >> > > DHCP is for enterprise networks in which there is some > modicum of distributed network administration and a > commonality of interests (which may be as basic as the > collaborative provisioning of connectivity itself). This > model fits well not only with infrastructure-based > networks but also with many MANET scenarios with which > I am familiar. > I agree there are wireless mobile networks that support DHCP. It's nicer, however, when the server and the relays have stable availability and connectivity. > > >>> I think DHCP can be very useful for attached MANETs, for getting >>> "additional information", i.e. other than addresses. >>> >>> >> I agree. I just don't think it fits very well in networks composed >> of highly mobile wireless nodes, especially when the network has >> no point of attachment to the Internet. >> > > Like maybe me and a couple of buddies going to a remote > ski area with hand-held multi-hop walkie-talkies when > there is no cellular coverage? Even then, unless we all > get together beforehand and key our L2 access codes what > we get is "anarchy-net", and anyone can crash the party. > As you know, even enterprise DHCP had security problems for a really long time. There are many flavors of ad hoc networks between the ski-slope anarchy-net and the attached wireless stubs most conducive to supporting DHCP. My main point is that we can't just wave the DHCP wand and declare mission accomplished. But as an interesting point of distraction, consider: (a) mutual face-to-face setup of security association (cellphones are cool) and (b) terabytes of storage in your snowboard. > > This brings up again a point which I have made in the past > that this group could significantly benefit from a detailed > MANET use-case analysis before saying what the addressing > architecture for *all* MANETs ought to look like. > But nobody is doing that, Fred. Right now we have just about the most minimalistic document you could imagine. Other more specialized applications should be derivable from the general model hypothesizing appropriate characterizations for the more specialized model. For instance, if we have a system that works when there aren't any guaranteed unique MAC addresses, then that system CAN be specialized to the case of unique MAC addresses. The other way around, is often impossible. It is unlikely that you would be able to generalize a guaranteed-unique MAC address solution to fit the needs of systems that do not guarantee such uniqueness. Frankly, I think this should be considered very obvious. Too bad we've been bogged down for years now explaining it over and over again. It's like claiming that we cannot go about designing solutions for x+y = 4 because a lot of times x is equal to 0. Regards, Charlie P. From ryuji.wakikawa@gmail.com Wed Oct 28 12:09:33 2009 Return-Path: <ryuji.wakikawa@gmail.com> 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 8CA273A69A1 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 12:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_37=0.6] 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 kmF1yDf8BtZa for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 12:09:32 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id 08BFF3A687E for <autoconf@ietf.org>; Wed, 28 Oct 2009 12:09:31 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so533328fga.13 for <autoconf@ietf.org>; Wed, 28 Oct 2009 12:09:44 -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=DB/CEptBJ2qH2F6g/iORgC1U6c4iNeI+tW7H2rIVMGs=; b=CrU+ex0PnEKy61iWyltHWVsPbar1hSR0/OSlMP6Lef8JdUaectG+aqtQYyxjYY92Xf tpm2kJkuLzVnoOJmGEyzlrTxSBGz89aTc5zMXcB3MpMhWpMV2dgDF59opLHmQOUlMLzh vn13jGRnqt7GI3ODq1Xt00H6PCEVzxpUO199g= 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=lOzkXbJLr9J/Faglk9oT1E87DsX1v4VF+qK1VHrKyEYnt2WzCH9XEOJ0SZBWu6idqz ogvvyPWhrElAXg8dGsmLTJ3MulOv1AQNeZ0S4oI9DDMnRhXlce+LRSJDRqYZukRdDdqt XkzSGZUzNVlWCxQdD2Knx4AvE5dFcYx3f6Niw= Received: by 10.86.195.26 with SMTP id s26mr5918713fgf.23.1256756984499; Wed, 28 Oct 2009 12:09:44 -0700 (PDT) Received: from macbookpro-ryuji.paloalto.toyota-itc.com ([206.132.173.18]) by mx.google.com with ESMTPS id 3sm3037894fge.9.2009.10.28.12.09.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 28 Oct 2009 12:09:43 -0700 (PDT) From: Ryuji Wakikawa <ryuji.wakikawa@gmail.com> To: Alexandru Petrescu <alexandru.petrescu@gmail.com> In-Reply-To: <4AE8951D.9060605@gmail.com> References: <64476.81.249.151.17.1256732116.squirrel@mail.tigertech.net> <1256732791.8155.95.camel@acorde.it.uc3m.es> <65259.81.249.151.17.1256733108.squirrel@mail.tigertech.net> <4AE83EA2.1080704@gmail.com> <65440.81.249.151.17.1256735126.squirrel@mail.tigertech.net> <4AE843A4.2050600@gmail.com> <86A14029-6E5F-4425-8D3D-5B40625407F6@gmail.com> <4AE8951D.9060605@gmail.com> Message-Id: <9B3AB84B-EBC8-473F-8BA7-87F08238D621@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 28 Oct 2009 12:09:39 -0700 X-Mailer: Apple Mail (2.936) Cc: "autoconf@ietf.org" <autoconf@ietf.org>, Thomas Heide Clausen <thomas@thomasclausen.org> Subject: Re: [Autoconf] Agenda (was: Procedure) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 19:09:33 -0000 Hi Alex, On 2009/10/28, at 12:01, Alexandru Petrescu wrote: > Ryuji Wakikawa a =C3=A9crit : >> Hi Alex, >> On 2009/10/28, at 6:14, Alexandru Petrescu wrote: >>> Thomas Heide Clausen a =C3=A9crit : >>>> On Wed, October 28, 2009 5:52 am, Alexandru Petrescu wrote: >>>>> Thomas Heide Clausen a =C3=A9crit : >>>>>> Carlos, >>>>>> Ok, let's try this, then, to see how much of a hurry we're really >>>>>> in: >>>>>> o Jari, can we have our milestone moved another 5 years into the >>>>>> future? >>>>> Thomas - can we have agenda requests for the meeting in advance? >>>>> Or are you going to decide only the DT document gets presented - >>>>> despite the discussion on the draft-bernardos? >>>> The working-group is on a tight schedule, and we have specific work >>>> to do. I therefore would suggest that we do not open up for any odd >>>> presentation -- we won't have time for that. >>>> However... >>>> There have been, as I count it, three documents discussed on the =20= >>>> list >>>> recently: the Baccelli/Townsley address model document, the =20 >>>> Perkins/Baccelli "link model" document and the Carlos/Ronald =20 >>>> address >>>> model document. >>>> The two latter have emerged in the discussions only recently, but >>>> appear to be useful for the WG to have presented. >>>> My *personal* suggestion would be to ask the authors of each of =20 >>>> these >>>> three documents to present, and if they're willing to do so of >>>> course have those on the agenda. >>> >>> Thomas I agree with your personal suggestion - make now a request =20= >>> for agenda items. >>> >>> Your draft agenda is due this midnight - are you ready for it? =20 >>> Are you >>> going to act under pressure - again? >>> >>> And please publish here the draft agenda tomorrow, thank you. >> We've published the draft agenda. >> http://www.ietf.org/proceedings/09nov/agenda/autoconf.txt > > Thanks! > > Do you know whether there's anybody else who would wish to present =20 > topics around the practical addressing model? Chairs has decided not to open the presentation at this time, since we =20= will certainly spend plenty of time on the current issues. This is still tentative one. If there is enough discussion for the =20 other topics in the ML before Hiroshima, we will consider to give a =20 slot. >> The agenda is still tentative one,because we want to take further =20 >> action/decision after we collect all the WG opinions (due is =20 >> tomorrow). > > Yes, this night 24pm GMT - is a "draft agenda" deadline of IETF: > http://www.ietf.org/meeting/cutoff-dates.html#76 > >> There is another deadline (11/2) for the final WG agenda. We will =20= >> deliver you the final one before that date. > > Yes, please announce the final agenda to the group thank you. We will! thanks ryuji > > Alex > >>>> As for slides in advance, we always try to get them on-line before >>>> the WG sessions, but as there often is a lot of work ongoing and >>>> discussions happening between WG participants during the IETF week >>>> that is being reflected in the presentations, I'm not sure we can >>>> reasonably do much earlier than that. >>> >>> I agree mostly. Some groups manage to get the slides well in =20 >>> advance. >>> Why not AUTOCONF? >>> >>> It is useful for people wondering whether attending or not, be it >>> locally or remotely. >> Agree, it is useful to have slides at the right time. >> However, AUTOCONF is currently running the adaption call. The =20 >> chairs wait for all the WG opinions. >> As soon as we will fix the agenda, we will solicit the slides to =20 >> the presenters. >> You can ask presenters to upload the slide on time with certain =20 >> pressure;-) >> cheers, >> ryuji >>> >>> Alex >>> >>> >>>> Thomas >>>>> I noticed there's a deadline this midnight for the draft agenda. >>>>> This group never submitted agenda in advance, let alone the =20 >>>>> slides. >>>>> Can we follow - not the procedure - but some widely used IETF >>>>> manners in this WG too? >>>>> Alex >>>>>> ;) >>>>>> Thomas >>>>>> On Wed, October 28, 2009 5:26 am, Carlos Jes=C3=BAs Bernardos = Cano >>>>>> wrote: >>>>>>> Hi Thomas, >>>>>>> On Wed, 2009-10-28 at 05:15 -0700, Thomas Heide Clausen wrote: >>>>>>>> On Wed, October 28, 2009 4:57 am, Jari Arkko wrote: >>>>>>>>> Alex, >>>>>>>>>> YEs I believe it is unreasonable to adopt that single >>>>>>>>>> document when a competitor document exists and which is >>>>>>>>>> technically more inline with what I think. >>>>>>>> Also, duly note that the >>>>>>>> draft-bernardos-autoconf-addressing-model document did not >>>>>>>> exist and the chairs (and the WG) were not made aware that it >>>>>>>> was under development, at the time of approval of draft-ietf-=20= >>>>>>>> autoconf-... >>>>>>> True, we have been working on this since last IETF meeting. Had >>>>>>> we (the authors) known that we were about to adopt a document >>>>>>> as WG draft, we would have submitted it earlier. >>>>>>> As I mentioned in a previous e-mail, I think it'd be better to >>>>>>> have a discussion on the content of both drafts before really >>>>>>> deciding on which one should be taken as baseline, but this is >>>>>>> my personal opinion. Sorry, but after 5 years working on this >>>>>>> (and I've been contributing to the WG since the very beginning) >>>>>>> I don't buy the "we are in a hurry" argument :-). Discussing >>>>>>> both drafts in Hiroshima would not harm and may be help. >>>>>>> Thanks, >>>>>>> Carlos >>>>>>>> Your opinion is, however, noted. >>>>>>>> Thomas >>>>>>>>> I am aware that you wanted to see the other document >>>>>>>>> adopted instead. But note that I said "given the opinions >>>>>>>>> in the group" and not any individual's opinion. We all know >>>>>>>>> that there is no unanimous agreement about this, but I was >>>>>>>>> curious if someone thought that the chairs had somehow >>>>>>>>> missed that a large part of the group disagreed with the >>>>>>>>> idea of adopting the DT document. >>>>>>>>> Jari >>>>>>>>> _______________________________________________ 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 >>>>>>> -- Carlos Jes=C3=BAs Bernardos Cano http://www.netcoms.net = GPG >>>>>>> FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 >>>>>> _______________________________________________ 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 > From Fred.L.Templin@boeing.com Wed Oct 28 12:23:59 2009 Return-Path: <Fred.L.Templin@boeing.com> 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 74E9D28C1E4 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 12:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.534 X-Spam-Level: X-Spam-Status: No, score=-6.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 LNwfJdIZGKUG for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 12:23:58 -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 8C30028C110 for <autoconf@ietf.org>; Wed, 28 Oct 2009 12:23:58 -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 n9SJO5LA000420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Oct 2009 14:24:05 -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 n9SJO4Pw005760; Wed, 28 Oct 2009 12:24:04 -0700 (PDT) Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n9SJO4FH005750 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 28 Oct 2009 12:24:04 -0700 (PDT) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Wed, 28 Oct 2009 12:24:03 -0700 From: "Templin, Fred L" <Fred.L.Templin@boeing.com> To: "Charles E. Perkins" <charles.perkins@earthlink.net> Date: Wed, 28 Oct 2009 12:24:02 -0700 Thread-Topic: [Autoconf] answers on DHCP DUID, key generation etc. Thread-Index: AcpYAfwJ+QV0IHmARnuxV5BReIhfIgAAc+aA Message-ID: <12F4112206976147A34FEC0277597CCF27A41F9764@XCH-NW-15V.nw.nos.boeing.com> References: <20091019233002.15F4328C164@core3.amsl.com> <1256237606.5373.22. camel@acorde.it.uc3m.es> <359CB0E6-FDF3-4308-BEEF-F97F46131529@gmail.com> < 1256491742.4766.35.camel@acorde.it.uc3m.es> <B4DD4464-E3AF-452B-9BF4-5941 2C 311A0F@thomasclausen.org> <1256493151.4766.58.camel@acorde.it.uc3m.es> < 4AE 4997E.6090705@earthlink.net> <1256514067.4766.171.camel@acorde.it.uc3m. es> <4AE4ED72.9000707@earthlink.net> <1256723482.8155.17.camel@acorde.it.u c3m.e s> <25c114b90910280300o4ba93b86g8619eec4916649b2@mail.gmail.com><0082 01ca57 b8$b53615a0$1fa240e0$@nl> <4AE86992.903@earthlink.net><011a01ca57e9$b49ac9c0$1dd05d40$@nl> <4AE87264.60506@earthlink.net> <12F4112206976147A34FEC0277597CCF27A41F9723@XCH-NW-15V.nw.nos.boeing.com> <4AE89659.5000607@earthlink.net> In-Reply-To: <4AE89659.5000607@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" <autoconf@ietf.org> Subject: Re: [Autoconf] answers on DHCP DUID, key generation etc. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 19:23:59 -0000 Charlie, > > This brings up again a point which I have made in the past > > that this group could significantly benefit from a detailed > > MANET use-case analysis before saying what the addressing > > architecture for *all* MANETs ought to look like. > > >=20 > But nobody is doing that, Fred. Use case documents aren't all that hard to write; in fact, here is one now: http://tools.ietf.org/html/draft-russert-rangers-01 Fred fred.l.templin@boeing.com From alexandru.petrescu@gmail.com Wed Oct 28 13:04:55 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 D33603A6843 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 13:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[AWL=0.331, 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 gUEqVm34fRSj for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 13:04:55 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id D35003A63EC for <autoconf@ietf.org>; Wed, 28 Oct 2009 13:04:53 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 947D9D4804C; Wed, 28 Oct 2009 21:05:04 +0100 (CET) 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 48F32D481D5; Wed, 28 Oct 2009 21:05:01 +0100 (CET) Message-ID: <4AE8A3EA.4020807@gmail.com> Date: Wed, 28 Oct 2009 21:04:58 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ryuji Wakikawa <ryuji.wakikawa@gmail.com> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <C228A97A-1D28-43CE-8BA4-07A9C7BD3AC5@gmail.com> <4AE807E5.6030301@gmail.com> <4AE80D7C.8020200@earthlink.net> <4AE81912.4040409@gmail.com> <9A410E5F-D117-4C41-940B-9B8A30120581@gmail.com> In-Reply-To: <9A410E5F-D117-4C41-940B-9B8A30120581@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 091028-0, 28/10/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] issues with draft-baccelli address model (was: On WG progress and draft-ietf-autoconf-adhoc-addr-model) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 20:04:55 -0000 Ryuji wrote in another longer mail: > We cannot retire the WG doc, but we can replace it if that is the WG > consensus. There are number of issues which have been discussed recently about each document. I know for my own point, but not sure how to re-make it. If I make it again and gets lost then it's a waste of time. http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model-03 1. I think Charles had text proposal to me and onlist about replacing "undetermined properties" and that proposal sounded better to me, except that he assumed that an LL address is derived from link-layer characteristics (the MAC adddress), and thus he discarded LLs; at which point I disagreed saying that not discard LL, because LL can be like fe80::1. I think he got tired of me at that point so we left it there. LAter Charles repeatedly said he had nothing particular against LLs. In retrospective I think it was a good direction, overall. 2. Also - I strongly oppose "discouraging LL IPv4" which the current baccelli draft says. Just type ifconfig or ipconfig on your offtheshelf machine with wireless interfaces and see the IPv4 LL in action. I think that's support enough. 3. I also oppose in draft-baccelli the exclusive use of /128 prefixes, it makes no sense, I could explain further if listened, or noted in an issue tracker. For draft-bernardos addressing model I still have to read it fully, other than LLs. Alex From alexandru.petrescu@gmail.com Wed Oct 28 13:15:40 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 66F0228C1CB for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 13:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[AWL=0.324, 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 gfPtCgexS0Ip for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 13:15:39 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 465F828C141 for <autoconf@ietf.org>; Wed, 28 Oct 2009 13:15:37 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 6FA8AD481AF; Wed, 28 Oct 2009 21:15:47 +0100 (CET) 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 4AAE0D48145; Wed, 28 Oct 2009 21:15:45 +0100 (CET) Message-ID: <4AE8A66E.4080106@gmail.com> Date: Wed, 28 Oct 2009 21:15:42 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ryuji Wakikawa <ryuji.wakikawa@gmail.com> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <C228A97A-1D28-43CE-8BA4-07A9C7BD3AC5@gmail.com> <4AE807E5.6030301@gmail.com> <4AE80D7C.8020200@earthlink.net> <4AE81912.4040409@gmail.com> <9A410E5F-D117-4C41-940B-9B8A30120581@gmail.com> In-Reply-To: <9A410E5F-D117-4C41-940B-9B8A30120581@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091028-0, 28/10/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 20:15:40 -0000 Ryuji Wakikawa a écrit : > Hi Alex, > > There is a case to adapt a DT document in WG without adaption call. > Did you remember we had an adaption call for NEMO-BS? I think we did, if I remember correctly (you correct me). I do remember though that there was a call about whether or not a NEMO DT had to be formed or not. That was long ago. Nowadays one goes through call after call. There is also this thing that sometimes people take votes in the WG meeting and sometimes avoid (or forget?) to confirm on the list - it sometimes sounds ok. But here this time it was like no call neither f2f, neither on the list - nowhere, just a pressure to go fast. > The PMIP IPv4 support doc was published as a WG doc from the > beginning, because the NETLMM WG formed DT. There was a call on PMIPv6 DT output though (the most important output of the group), I am not sure about the PMIP IPv4 support. Long ago I considered even NETLMM to be badly run - I got kicked off it :-) > In AUTOCONF WG, we have decided to publish the first DT doc as an > individual document. That was good. > After 6 months, authors reflects WG agreement to the document (well > maybe not your opinion though). > > I am not repeating the same reasons why we adapt this doc here again. > You can refer to other mails from us. anyway, the adaption call is > still open. We cannot retire the WG doc, but we can replace it if > that is the WG consensus. Ok, let's wait (until which date?) to see how much support is for one draft and for another. Alex From charles.perkins@earthlink.net Wed Oct 28 13:21:19 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE74D28C186 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 13:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 8QbRkV9HzMor for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 13:21:19 -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 038AB3A687F for <autoconf@ietf.org>; Wed, 28 Oct 2009 13:21:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=L1R880wM2480V3gtMYVw+wb9SscpGwESp8JLiXSUzxD1DdpxKLGzxZNQClXwxrvi; 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-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N3F1S-0006ar-B4; Wed, 28 Oct 2009 16:21:34 -0400 Message-ID: <4AE8A7CD.3030502@earthlink.net> Date: Wed, 28 Oct 2009 13:21:33 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <C228A97A-1D28-43CE-8BA4-07A9C7BD3AC5@gmail.com> <4AE807E5.6030301@gmail.com> <4AE80D7C.8020200@earthlink.net> <4AE81912.4040409@gmail.com> <9A410E5F-D117-4C41-940B-9B8A30120581@gmail.com> <4AE8A3EA.4020807@gmail.com> In-Reply-To: <4AE8A3EA.4020807@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5299c8dca2f875ec8ee92bfacbcedefec2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] issues with draft-baccelli address model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 20:21:20 -0000 Hello Alex, Some comments and corrections below... Alexandru Petrescu wrote: > > There are number of issues which have been discussed recently about each > document. > > I know for my own point, but not sure how to re-make it. If I make it > again and gets lost then it's a waste of time. > > http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model-03 > > 1. I think Charles had text proposal to me and onlist about replacing > "undetermined properties" and that proposal sounded better to me, except > that he assumed that an LL address is derived from link-layer > characteristics (the MAC adddress), I did not assume this. > and thus he discarded LLs I did not discard LLs > ; at which > point I disagreed saying that not discard LL, because LL can be like > fe80::1. I pointed out that this was totally irrelevant. > I think he got tired of me at that point so we > left it there. If I stopped discussing when I was tired, you might not have heard from me for many many months. > LAter Charles repeatedly said he had nothing particular against LLs. Later, and earlier, and even earlier, and ... > > 2. Also - I strongly oppose "discouraging LL IPv4" which the current > baccelli draft says. Just type ifconfig or ipconfig on your offtheshelf > machine with wireless interfaces and see the IPv4 LL in action. I > think that's support enough. Is that a valid metric for utility in a wireless ad hoc network? > > > 3. I also oppose in draft-baccelli the exclusive use of /128 prefixes, > it makes no sense, I could explain further if listened, or noted in an > issue tracker. It makes a lot of sense. In fact it makes enough sense so that the multiplicity of early proposed solutions to the problem could be developed into standards. If only. Regards, Charlie P. From alexandru.petrescu@gmail.com Wed Oct 28 13:55:45 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 4D2A23A68A6 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 13:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=0.317, 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 Zda-Bz+mglMm for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 13:55: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 3C1C83A686C for <autoconf@ietf.org>; Wed, 28 Oct 2009 13:55:42 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id F352ED48061; Wed, 28 Oct 2009 21:55:53 +0100 (CET) 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 9872DD4813F; Wed, 28 Oct 2009 21:55:50 +0100 (CET) Message-ID: <4AE8AFD4.4050706@gmail.com> Date: Wed, 28 Oct 2009 21:55:48 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" <charles.perkins@earthlink.net> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <C228A97A-1D28-43CE-8BA4-07A9C7BD3AC5@gmail.com> <4AE807E5.6030301@gmail.com> <4AE80D7C.8020200@earthlink.net> <4AE81912.4040409@gmail.com> <9A410E5F-D117-4C41-940B-9B8A30120581@gmail.com> <4AE8A3EA.4020807@gmail.com> <4AE8A7CD.3030502@earthlink.net> In-Reply-To: <4AE8A7CD.3030502@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091028-0, 28/10/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] issues with draft-baccelli address model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 20:55:45 -0000 Charles E. Perkins a écrit : > > Hello Alex, > > Some comments and corrections below... > > Alexandru Petrescu wrote: >> >> There are number of issues which have been discussed recently about each >> document. >> >> I know for my own point, but not sure how to re-make it. If I make it >> again and gets lost then it's a waste of time. >> >> http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model-03 >> >> 1. I think Charles had text proposal to me and onlist about replacing >> "undetermined properties" and that proposal sounded better to me, except >> that he assumed that an LL address is derived from link-layer >> characteristics (the MAC adddress), > I did not assume this. >> and thus he discarded LLs > I did not discard LLs >> ; at which >> point I disagreed saying that not discard LL, because LL can be like >> fe80::1. > I pointed out that this was totally irrelevant. > >> I think he got tired of me at that point so we >> left it there. > If I stopped discussing when I was tired, you might > not have heard from me for many many months. > >> LAter Charles repeatedly said he had nothing particular against LLs. > Later, and earlier, and even earlier, and ... You have nothing against IPv6 LLs or nothing against IPv4 LLs or both? BEcause current draft still says "discourage IPv4 LL". Or when you have nothing against something it means that you actually discourage it? >> 2. Also - I strongly oppose "discouraging LL IPv4" which the current >> baccelli draft says. Just type ifconfig or ipconfig on your offtheshelf >> machine with wireless interfaces and see the IPv4 LL in action. I >> think that's support enough. > > Is that a valid metric for utility in a wireless ad hoc network? It's wireless links for adhoc networks - yes. It's 169.254. yes. It's widely spread on your off-the-shelf machines - yes. >> 3. I also oppose in draft-baccelli the exclusive use of /128 prefixes, >> it makes no sense, I could explain further if listened, or noted in an >> issue tracker. > > It makes a lot of sense. In fact it makes enough sense so that > the multiplicity of early proposed solutions to the problem could > be developed into standards. Do we make 3 issues out of these or should I consider that you convinced me and I give up? Alex > > If only. > > > > Regards, > Charlie P. > > From charles.perkins@earthlink.net Wed Oct 28 14:20:43 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FF103A6810 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 14:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 LhwYw7Y7bp77 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 14:20:42 -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 A5B5F3A67E1 for <autoconf@ietf.org>; Wed, 28 Oct 2009 14:20:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=a0uH2iqbhB985jKTNOkGvx21PVDJIA6cWlmdcY9H+v8mMmhScGAktZXty1NXrtnd; 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 <charles.perkins@earthlink.net>) id 1N3Fwv-0002UN-Ss; Wed, 28 Oct 2009 17:20:58 -0400 Message-ID: <4AE8B5B9.5070204@earthlink.net> Date: Wed, 28 Oct 2009 14:20:57 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <C228A97A-1D28-43CE-8BA4-07A9C7BD3AC5@gmail.com> <4AE807E5.6030301@gmail.com> <4AE80D7C.8020200@earthlink.net> <4AE81912.4040409@gmail.com> <9A410E5F-D117-4C41-940B-9B8A30120581@gmail.com> <4AE8A3EA.4020807@gmail.com> <4AE8A7CD.3030502@earthlink.net> <4AE8AFD4.4050706@gmail.com> In-Reply-To: <4AE8AFD4.4050706@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52e0be9b1d6d6707f44981e04e6f3b98de350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] issues with draft-baccelli address model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 21:20:43 -0000 Hello Alex, Alexandru Petrescu wrote: > >> >>> LAter Charles repeatedly said he had nothing particular against LLs. >> Later, and earlier, and even earlier, and ... > > You have nothing against IPv6 LLs or nothing against IPv4 LLs or both? > > BEcause current draft still says "discourage IPv4 LL". > > Or when you have nothing against something it means that you actually > discourage it? I am fine if the draft discourages LL. I am fine if the draft does not discourage LL. I only expect that the draft should make it clear that solutions are acceptable if they do not use nor assign link-local addresses. Why do I have to say this so many times? > >>> 2. Also - I strongly oppose "discouraging LL IPv4" which the current >>> baccelli draft says. Just type ifconfig or ipconfig on your >>> offtheshelf >>> machine with wireless interfaces and see the IPv4 LL in action. I >>> think that's support enough. >> >> Is that a valid metric for utility in a wireless ad hoc network? > > It's wireless links for adhoc networks - yes. It's 169.254. yes. > It's widely spread on your off-the-shelf machines - yes. It generally works in nonspecialized ad hoc networks - no. > >>> 3. I also oppose in draft-baccelli the exclusive use of /128 prefixes, >>> it makes no sense, I could explain further if listened, or noted in an >>> issue tracker. >> >> It makes a lot of sense. In fact it makes enough sense so that >> the multiplicity of early proposed solutions to the problem could >> be developed into standards. > > Do we make 3 issues out of these or should I consider that you > convinced me and I give up? It's not a matter of convincing. It's a matter of exploring the facts. The only person who could possibly convince you is you yourself. I do not see that happening for a very long time. Regards, Charlie P. From alexandru.petrescu@gmail.com Wed Oct 28 14:26:05 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 CA4D128C14E for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 14:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=0.311, 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 tiuqHu-QxwlT for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 14:26:05 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id D392F28C1CB for <autoconf@ietf.org>; Wed, 28 Oct 2009 14:26:03 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 4023BD48102; Wed, 28 Oct 2009 22:26:12 +0100 (CET) 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 E549ED48031; Wed, 28 Oct 2009 22:26:09 +0100 (CET) Message-ID: <4AE8B6EF.2070408@gmail.com> Date: Wed, 28 Oct 2009 22:26:07 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" <charles.perkins@earthlink.net> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <C228A97A-1D28-43CE-8BA4-07A9C7BD3AC5@gmail.com> <4AE807E5.6030301@gmail.com> <4AE80D7C.8020200@earthlink.net> <4AE81912.4040409@gmail.com> <9A410E5F-D117-4C41-940B-9B8A30120581@gmail.com> <4AE8A3EA.4020807@gmail.com> <4AE8A7CD.3030502@earthlink.net> <4AE8AFD4.4050706@gmail.com> <4AE8B5B9.5070204@earthlink.net> In-Reply-To: <4AE8B5B9.5070204@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091028-0, 28/10/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] issues with draft-baccelli address model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 21:26:05 -0000 Charles E. Perkins a écrit : > > Hello Alex, > > Alexandru Petrescu wrote: >> >>> >>>> LAter Charles repeatedly said he had nothing particular against LLs. >>> Later, and earlier, and even earlier, and ... >> >> You have nothing against IPv6 LLs or nothing against IPv4 LLs or both? >> >> BEcause current draft still says "discourage IPv4 LL". >> >> Or when you have nothing against something it means that you actually >> discourage it? > > I am fine if the draft discourages LL. I am fine if the draft does > not discourage LL. > > I only expect that the draft should make it clear that solutions are > acceptable if they do not use nor assign link-local addresses. Are solutions acceptable if they do use LL addresses? (and are guaranteed unique on their respective links.) Alex > > Why do I have to say this so many times? > >> >>>> 2. Also - I strongly oppose "discouraging LL IPv4" which the current >>>> baccelli draft says. Just type ifconfig or ipconfig on your >>>> offtheshelf >>>> machine with wireless interfaces and see the IPv4 LL in action. I >>>> think that's support enough. >>> >>> Is that a valid metric for utility in a wireless ad hoc network? >> >> It's wireless links for adhoc networks - yes. It's 169.254. yes. >> It's widely spread on your off-the-shelf machines - yes. > > It generally works in nonspecialized ad hoc networks - no. > > >> >>>> 3. I also oppose in draft-baccelli the exclusive use of /128 prefixes, >>>> it makes no sense, I could explain further if listened, or noted in an >>>> issue tracker. >>> >>> It makes a lot of sense. In fact it makes enough sense so that >>> the multiplicity of early proposed solutions to the problem could >>> be developed into standards. >> >> Do we make 3 issues out of these or should I consider that you >> convinced me and I give up? > > It's not a matter of convincing. It's a matter of exploring > the facts. The only person who could possibly convince > you is you yourself. I do not see that happening for a > very long time. > > Regards, > Charlie P. > > From charles.perkins@earthlink.net Wed Oct 28 16:06:19 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 863103A68E4 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 16:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[AWL=0.101, 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 ue3Z0wP4sTux for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 16:06:18 -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 D04E23A67CC for <autoconf@ietf.org>; Wed, 28 Oct 2009 16:06:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ayrtXjbEZpBvjDd3TBP4y5RpYKKLcyJ+/lHaYsCyQuWcgQxZPfl8QOWpNjboMIOs; 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.183]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N3Hb8-0004RI-9H; Wed, 28 Oct 2009 19:06:34 -0400 Message-ID: <4AE8CE75.2060607@earthlink.net> Date: Wed, 28 Oct 2009 16:06:29 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <C228A97A-1D28-43CE-8BA4-07A9C7BD3AC5@gmail.com> <4AE807E5.6030301@gmail.com> <4AE80D7C.8020200@earthlink.net> <4AE81912.4040409@gmail.com> <9A410E5F-D117-4C41-940B-9B8A30120581@gmail.com> <4AE8A3EA.4020807@gmail.com> <4AE8A7CD.3030502@earthlink.net> <4AE8AFD4.4050706@gmail.com> <4AE8B5B9.5070204@earthlink.net> <4AE8B6EF.2070408@gmail.com> In-Reply-To: <4AE8B6EF.2070408@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f525225046b859ed713df9a654fed25cd26350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] issues with draft-baccelli address model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 28 Oct 2009 23:06:19 -0000 Alexandru Petrescu wrote: > Charles E. Perkins a écrit : >> >> >> I am fine if the draft discourages LL. I am fine if the draft does >> not discourage LL. >> >> I only expect that the draft should make it clear that solutions are >> acceptable if they do not use nor assign link-local addresses. > > Are solutions acceptable if they do use LL addresses? (and are > guaranteed unique on their respective links.) Of course! They may apply only to a restricted subset of the wireless space of interest, and thus not solve the whole problem, but why wouldn't they be acceptable for the realm of their applicability? Regards, Charlie P. From jari.arkko@piuha.net Wed Oct 28 23:51:53 2009 Return-Path: <jari.arkko@piuha.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D52593A69F3 for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 23:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 4EqtGIghixsl for <autoconf@core3.amsl.com>; Wed, 28 Oct 2009 23:51:53 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 06C733A6973 for <autoconf@ietf.org>; Wed, 28 Oct 2009 23:51:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A5FB3D492B; Thu, 29 Oct 2009 08:52:08 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAz6KWD5LIRt; Thu, 29 Oct 2009 08:52:08 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 00A06D4900; Thu, 29 Oct 2009 08:52:07 +0200 (EET) Message-ID: <4AE93B97.9020804@piuha.net> Date: Thu, 29 Oct 2009 08:52:07 +0200 From: Jari Arkko <jari.arkko@piuha.net> User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <64476.81.249.151.17.1256732116.squirrel@mail.tigertech.net> <1256732791.8155.95.camel@acorde.it.uc3m.es> <4AE83F30.1010304@piuha.net> <4AE84291.3090905@gmail.com> In-Reply-To: <4AE84291.3090905@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "autoconf@ietf.org" <autoconf@ietf.org> Subject: Re: [Autoconf] Procedure X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 06:51:53 -0000 Alex, > I do not accept this pressure. It's not my fault these years of > non-achievements - I wasn't in AUTOCONF. > > One would better try to identify _why_ there are non-productive > AUTOCONF years of reasons behind us. See how the same lack of > procedure (no agenda, no formal calls, secrecy, and more) is in action > now. No organization on this planet is willing to look at infinitely long projects. There's always a deadline. There's always other, competing things that we could be spending our time on. I have tried to identify the reasons why we have not succeeded yet in AUTOCONF. Attempting to specify the general theory of all possible configuration situations is at the top of my list. This is why the charter and myself insist on developing a practical, achievable addressing model. One way of doing that is to explain how practical networks do it. Look at the working group. It is one big brain trust - if we stay focused we CAN write one ten page document on how ad hoc networks get configured. Really. Then we can move on to more interesting stuff, like developing new protocol tools. Jari From cjbc@it.uc3m.es Thu Oct 29 01:12:32 2009 Return-Path: <cjbc@it.uc3m.es> 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 73A1C3A67E5 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 01:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.586 X-Spam-Level: X-Spam-Status: No, score=-5.586 tagged_above=-999 required=5 tests=[AWL=0.113, 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 qOtipy3wPq8u for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 01:12:31 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 0B7403A6403 for <autoconf@ietf.org>; Thu, 29 Oct 2009 01:12:29 -0700 (PDT) Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 389CA6C1AF5; Thu, 29 Oct 2009 09:12:44 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano <cjbc@it.uc3m.es> To: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr> In-Reply-To: <be8c8d780910280123v633e06a1u4e0f4d876e89684a@mail.gmail.com> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <C228A97A-1D28-43CE-8BA4-07A9C7BD3AC5@gmail.com> <7.0.0.16.2.20091028154932.06352778@ie.niigata-u.ac.jp> <37D2EFED-EAE1-41A3-880D-FC143C9E84C5@thomasclausen.org> <be8c8d780910280123v633e06a1u4e0f4d876e89684a@mail.gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-dPFZVAwUx77a9dIhQZ0k" Organization: Universidad Carlos III de Madrid Date: Thu, 29 Oct 2009 09:12:46 +0100 Message-Id: <1256803966.4195.21.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16976.003 Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress anddraft-ietf-autoconf-adhoc-addr-model 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 <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 08:12:32 -0000 --=-dPFZVAwUx77a9dIhQZ0k Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Well, since it seems that the obvious should be said (i.e. authors supporting their own documents :-) ), I think we should not proceed -- at this stage -- with draft-baccelli, and consider first all the candidate documents that are on the table (i.e., draft-bernardos, which is surprisingly more aligned with my opinion). Thanks, Carlos On Wed, 2009-10-28 at 09:23 +0100, Emmanuel Baccelli wrote: > I suppose I should also mention I support draft-ietf-autoconf- > adhoc-addr-model as baseline.=20 > Emmanuel >=20 > On Wed, Oct 28, 2009 at 8:09 AM, Thomas Heide Clausen > <ietf@thomasclausen.org> wrote: > I guess it's hardly a surprise that I also support this > document as baseline.. > =20 > Thomas > =20 > =20 > =20 > On Oct 28, 2009, at 7:50 AM, mase wrote: > =20 > Fine with me. > =20 > Regards. > Kenichi > =20 > At 15:38 09/10/28, Ryuji Wakikawa wrote: > o if you think that the WG should proceed with > draft-ietf-autoconf- adhoc-addr-model > as a baseline, say so! > =20 > =20 > =20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > =20 >=20 >=20 > _______________________________________________ > 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 --=-dPFZVAwUx77a9dIhQZ0k Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkrpTn4ACgkQNdy6TdFwT2dhJwCdFGfu9zlNxuTUb0XCbBGtWvTl JNwAnRl7W2bzc2SobZ/ANxmX8o2vRuPi =/0Lc -----END PGP SIGNATURE----- --=-dPFZVAwUx77a9dIhQZ0k-- From ulrich@herberg.name Thu Oct 29 01:44:17 2009 Return-Path: <ulrich@herberg.name> 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 1B8D23A68DF for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 01:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.709 X-Spam-Level: X-Spam-Status: No, score=-1.709 tagged_above=-999 required=5 tests=[AWL=0.268, 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 hvGnM-+0jV2R for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 01:44:16 -0700 (PDT) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 07B6E3A681C for <autoconf@ietf.org>; Thu, 29 Oct 2009 01:44:15 -0700 (PDT) Received: by bwz23 with SMTP id 23so2010994bwz.29 for <autoconf@ietf.org>; Thu, 29 Oct 2009 01:44:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.154.69 with SMTP id n5mr1634746bkw.43.1256805868229; Thu, 29 Oct 2009 01:44:28 -0700 (PDT) In-Reply-To: <4AE8CE75.2060607@earthlink.net> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <4AE80D7C.8020200@earthlink.net> <4AE81912.4040409@gmail.com> <9A410E5F-D117-4C41-940B-9B8A30120581@gmail.com> <4AE8A3EA.4020807@gmail.com> <4AE8A7CD.3030502@earthlink.net> <4AE8AFD4.4050706@gmail.com> <4AE8B5B9.5070204@earthlink.net> <4AE8B6EF.2070408@gmail.com> <4AE8CE75.2060607@earthlink.net> Date: Thu, 29 Oct 2009 09:44:28 +0100 Message-ID: <25c114b90910290144m4fcd563dw23d3cd625f6adec0@mail.gmail.com> From: Ulrich Herberg <ulrich@herberg.name> To: "Charles E. Perkins" <charles.perkins@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: autoconf@ietf.org Subject: Re: [Autoconf] issues with draft-baccelli address model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 08:44:17 -0000 On Thu, Oct 29, 2009 at 12:06 AM, Charles E. Perkins <charles.perkins@earthlink.net> wrote: > [..] > Of course! =A0They may apply only to a restricted subset of the > wireless space of interest, and thus not solve the whole problem, > but why wouldn't they be acceptable for the realm of their > applicability? I fully agree with Charlie. For a subset of deployment scenarios, we can very well use LLs (for example, if they guarantee unique MACs, or if we guarantee a good source of entropy). And this is said in the DT draft: "When more specific assumptions can be made regarding the connectivity between interfaces, these SHOULD be considered when configuring subnet prefixes." So for _specific_ settings (like Alex's testbed), using LL will work fine. However, the address model of the DT tries to be as _general_ as possible and NOT to focus on a subset with specific assumptions. Ulrich From teco@inf-net.nl Thu Oct 29 02:46:40 2009 Return-Path: <teco@inf-net.nl> 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 0346B3A6984 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 02:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.168 X-Spam-Level: X-Spam-Status: No, score=-1.168 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, 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 ypVjk9kL7sWh for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 02:46:39 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id D163F3A6855 for <autoconf@ietf.org>; Thu, 29 Oct 2009 02:46:38 -0700 (PDT) Received: (qmail 15530 invoked from network); 29 Oct 2009 10:46:47 +0100 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 29 Oct 2009 10:46:47 +0100 From: "Teco Boot" <teco@inf-net.nl> To: "'Ulrich Herberg'" <ulrich@herberg.name>, "'Charles E. Perkins'" <charles.perkins@earthlink.net> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <4AE80D7C.8020200@earthlink.net> <4AE81912.4040409@gmail.com> <9A410E5F-D117-4C41-940B-9B8A30120581@gmail.com> <4AE8A3EA.4020807@gmail.com> <4AE8A7CD.3030502@earthlink.net> <4AE8AFD4.4050706@gmail.com> <4AE8B5B9.5070204@earthlink.net> <4AE8B6EF.2070408@gmail.com> <4AE8CE75.2060607@earthlink.net> <25c114b90910290144m4fcd563dw23d3cd625f6adec0@mail.gmail.com> In-Reply-To: <25c114b90910290144m4fcd563dw23d3cd625f6adec0@mail.gmail.com> Date: Thu, 29 Oct 2009 10:46:16 +0100 Message-ID: <004101ca587c$bb5e5130$321af390$@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: AcpYdBqlrz3SGve4TVST6t/6Hd16qAAB/iwA Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] issues with draft-baccelli address model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 09:46:40 -0000 Not agreed with suggested usage of LLs. See my proposal for correction of the baccelli draft. It specifies when to use LLs and when not, and applies=20 to IPv6 in general. And hopefully, it stops the LL=20 discussion, because everybody may agree on the text. Regards, Teco >-----Oorspronkelijk bericht----- >Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] = Namens >Ulrich Herberg >Verzonden: donderdag 29 oktober 2009 9:44 >Aan: Charles E. Perkins >CC: autoconf@ietf.org >Onderwerp: Re: [Autoconf] issues with draft-baccelli address model > >On Thu, Oct 29, 2009 at 12:06 AM, Charles E. Perkins ><charles.perkins@earthlink.net> wrote: >> [..] >> Of course! =A0They may apply only to a restricted subset of the >> wireless space of interest, and thus not solve the whole problem, >> but why wouldn't they be acceptable for the realm of their >> applicability? > >I fully agree with Charlie. For a subset of deployment scenarios, we >can very well use LLs (for example, if they guarantee unique MACs, or >if we guarantee a good source of entropy). And this is said in the DT >draft: > >"When more specific assumptions can be made regarding the connectivity >between interfaces, these SHOULD be considered when configuring subnet >prefixes." > >So for _specific_ settings (like Alex's testbed), using LL will work >fine. However, the address model of the DT tries to be as _general_ as >possible and NOT to focus on a subset with specific assumptions. > >Ulrich >_______________________________________________ >Autoconf mailing list >Autoconf@ietf.org >https://www.ietf.org/mailman/listinfo/autoconf From alexandru.petrescu@gmail.com Thu Oct 29 02:51:28 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 310263A6816 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 02:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=0.151, 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 5cJNsIJzzmTc for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 02:51:27 -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 834333A6855 for <autoconf@ietf.org>; Thu, 29 Oct 2009 02:51:26 -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 n9T9pZs5011058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Oct 2009 10:51:35 +0100 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 n9T9pY4E020668; Thu, 29 Oct 2009 10:51:34 +0100 (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 n9T9pXXZ021805; Thu, 29 Oct 2009 10:51:34 +0100 Message-ID: <4AE965A5.8030704@gmail.com> Date: Thu, 29 Oct 2009 10:51:33 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ulrich Herberg <ulrich@herberg.name> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <4AE80D7C.8020200@earthlink.net> <4AE81912.4040409@gmail.com> <9A410E5F-D117-4C41-940B-9B8A30120581@gmail.com> <4AE8A3EA.4020807@gmail.com> <4AE8A7CD.3030502@earthlink.net> <4AE8AFD4.4050706@gmail.com> <4AE8B5B9.5070204@earthlink.net> <4AE8B6EF.2070408@gmail.com> <4AE8CE75.2060607@earthlink.net> <25c114b90910290144m4fcd563dw23d3cd625f6adec0@mail.gmail.com> In-Reply-To: <25c114b90910290144m4fcd563dw23d3cd625f6adec0@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] issues with draft-baccelli address model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 09:51:28 -0000 Ulrich Herberg a écrit : > On Thu, Oct 29, 2009 at 12:06 AM, Charles E. Perkins > <charles.perkins@earthlink.net> wrote: >> [..] Of course! They may apply only to a restricted subset of the >> wireless space of interest, and thus not solve the whole problem, >> but why wouldn't they be acceptable for the realm of their >> applicability? > > I fully agree with Charlie. For a subset of deployment scenarios, we > can very well use LLs (for example, if they guarantee unique MACs, or > if we guarantee a good source of entropy). And this is said in the > DT draft: > > "When more specific assumptions can be made regarding the > connectivity between interfaces, these SHOULD be considered when > configuring subnet prefixes." > > So for _specific_ settings (like Alex's testbed), using LL will work > fine. However, the address model of the DT tries to be as _general_ > as possible and NOT to focus on a subset with specific assumptions. My question is whether or not this type of use LL addresses working fine in _some_ applications (in a restricted subset of deployment scenarios in the wireless space of interest) is a valid case for AUTOCONF or not. Alex > > Ulrich > From ulrich@herberg.name Thu Oct 29 03:01:34 2009 Return-Path: <ulrich@herberg.name> 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 1D8A63A699F for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 03:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.725 X-Spam-Level: X-Spam-Status: No, score=-1.725 tagged_above=-999 required=5 tests=[AWL=0.252, 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 dmqGcd1M2NpC for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 03:01:32 -0700 (PDT) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 9AE7E3A6A55 for <autoconf@ietf.org>; Thu, 29 Oct 2009 03:01:32 -0700 (PDT) Received: by bwz23 with SMTP id 23so2090669bwz.29 for <autoconf@ietf.org>; Thu, 29 Oct 2009 03:01:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.154.69 with SMTP id n5mr1688180bkw.43.1256810505162; Thu, 29 Oct 2009 03:01:45 -0700 (PDT) In-Reply-To: <4AE965A5.8030704@gmail.com> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <9A410E5F-D117-4C41-940B-9B8A30120581@gmail.com> <4AE8A3EA.4020807@gmail.com> <4AE8A7CD.3030502@earthlink.net> <4AE8AFD4.4050706@gmail.com> <4AE8B5B9.5070204@earthlink.net> <4AE8B6EF.2070408@gmail.com> <4AE8CE75.2060607@earthlink.net> <25c114b90910290144m4fcd563dw23d3cd625f6adec0@mail.gmail.com> <4AE965A5.8030704@gmail.com> Date: Thu, 29 Oct 2009 11:01:45 +0100 Message-ID: <25c114b90910290301w4323f50fob7e9fcfb438edb7@mail.gmail.com> From: Ulrich Herberg <ulrich@herberg.name> To: Alexandru Petrescu <alexandru.petrescu@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: autoconf@ietf.org Subject: Re: [Autoconf] issues with draft-baccelli address model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 10:01:34 -0000 Alex, On Thu, Oct 29, 2009 at 10:51 AM, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote: > [...] > My question is whether or not this type of use LL addresses working fine > in _some_ applications (in a restricted subset of deployment scenarios > in the wireless space of interest) is a valid case for AUTOCONF or not. I think it is definitely interesting for AUTOCONF to solve after we have been rechartered; but not at this time. We want to produce an addressing model that covers a general case, and is not specific to certain subsets of scenarios. After finishing work on the general address model, I am not against thinking about more specific models with more assumptions (i.e. unique MAC etc.) Ulrich From teco@inf-net.nl Thu Oct 29 03:43:03 2009 Return-Path: <teco@inf-net.nl> 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 8F11F3A6884 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 03:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.192 X-Spam-Level: X-Spam-Status: No, score=-1.192 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, 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 QHJKgXGBomxz for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 03:43:02 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 66E913A6814 for <autoconf@ietf.org>; Thu, 29 Oct 2009 03:43:01 -0700 (PDT) Received: (qmail 3611 invoked from network); 29 Oct 2009 11:43:13 +0100 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 29 Oct 2009 11:43:13 +0100 From: "Teco Boot" <teco@inf-net.nl> To: "'Ulrich Herberg'" <ulrich@herberg.name> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <9A410E5F-D117-4C41-940B-9B8A30120581@gmail.com> <4AE8A3EA.4020807@gmail.com> <4AE8A7CD.3030502@earthlink.net> <4AE8AFD4.4050706@gmail.com> <4AE8B5B9.5070204@earthlink.net> <4AE8B6EF.2070408@gmail.com> <4AE8CE75.2060607@earthlink.net> <25c114b90910290144m4fcd563dw23d3cd625f6adec0@mail.gmail.com> <4AE965A5.8030704@gmail.com> <25c114b90910290301w4323f50fob7e9fcfb438edb7@mail.gmail.com> In-Reply-To: <25c114b90910290301w4323f50fob7e9fcfb438edb7@mail.gmail.com> Date: Thu, 29 Oct 2009 11:42:42 +0100 Message-ID: <004201ca5884$9d56a8b0$d803fa10$@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: AcpYftswJVX+xUONSJGiFgFG3MduKAABBZog Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] issues with draft-baccelli address model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 10:43:03 -0000 Ulrich, Again and again and again. Can you check what "practical" means? We are chartered for it. Not for "all" or "general". It happens to be that I try to get MANETs deployed. All what I have around me and venders offer have no problem with address uniqueness. To name a few problems: no standard for prefix delegation, no MANET standard protocol with link metrics, problems with scalability, multicast issues, multi-homing, security and on and on. See also Jari his last posting. This motivated me keep telling what I am doing and what the problems are. This also makes very clear we shall stop boil the ocean. Regards, Teco >-----Oorspronkelijk bericht----- >Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens >Ulrich Herberg >Verzonden: donderdag 29 oktober 2009 11:02 >Aan: Alexandru Petrescu >CC: autoconf@ietf.org >Onderwerp: Re: [Autoconf] issues with draft-baccelli address model > >Alex, > >On Thu, Oct 29, 2009 at 10:51 AM, Alexandru Petrescu ><alexandru.petrescu@gmail.com> wrote: >> [...] >> My question is whether or not this type of use LL addresses working >fine >> in _some_ applications (in a restricted subset of deployment scenarios >> in the wireless space of interest) is a valid case for AUTOCONF or >not. > >I think it is definitely interesting for AUTOCONF to solve after we >have been rechartered; but not at this time. We want to produce an >addressing model that covers a general case, and is not specific to >certain subsets of scenarios. After finishing work on the general >address model, I am not against thinking about more specific models >with more assumptions (i.e. unique MAC etc.) > >Ulrich >_______________________________________________ >Autoconf mailing list >Autoconf@ietf.org >https://www.ietf.org/mailman/listinfo/autoconf From Ronald.intVelt@tno.nl Thu Oct 29 03:56:57 2009 Return-Path: <Ronald.intVelt@tno.nl> 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 64DDC3A6889 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 03:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.494 X-Spam-Level: X-Spam-Status: No, score=0.494 tagged_above=-999 required=5 tests=[AWL=-0.999, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, MIME_QP_LONG_LINE=1.396] 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 Lt98Z4PWPQUi for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 03:56:55 -0700 (PDT) Received: from mailoutb.tno.nl (mailoutb.tno.nl [134.221.1.17]) by core3.amsl.com (Postfix) with ESMTP id 57F693A67D4 for <autoconf@ietf.org>; Thu, 29 Oct 2009 03:56:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,645,1249250400"; d="scan'208,217";a="6304084" Received: from ms-dt01thalia.tno.nl (HELO ms-dt01thalia.tsn.tno.nl) ([134.221.225.157]) by mailhost1b.tno.nl with ESMTP; 29 Oct 2009 11:57:09 +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_01CA5886.8F9BB591" Date: Thu, 29 Oct 2009 11:57:07 +0100 Message-ID: <7877C5C0B5CC894AB26113CF06CF886302C7FC76@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model Thread-Index: AcpSqSmswk4zd7I6TfGyz+HGzOCOigFzk1Mg References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> From: "Velt, R. (Ronald) in 't" <Ronald.intVelt@tno.nl> To: "Thomas Heide Clausen" <ietf@thomasclausen.org>, <autoconf@ietf.org> Subject: Re: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 10:56:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5886.8F9BB591 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thomas, Ryuji, WG members, =20 My vote below: ________________________________ From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On Behalf Of Thomas Heide Clausen Sent: donderdag 22 oktober 2009 1:50 To: autoconf@ietf.org Subject: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model =09 =09 All, It appeared to the chairs that the comments raised at the Stockholm IETF, as well as on the list subsequently, concerning the document: =09 <http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model> <http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model> http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model had been addressed fully by the editors, and to the WGs satisfaction - at least, there were no issue raised to the latter/latest version hereof. The chairs therefore found it a good idea to move the document forward as a WG document, and progress this document as such. We therefore approved for publication: http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model We (the chairs) still believe that this is the proper approach in order to make progress for the WG. Do note that the WG is 7 months past the milestone for initial document submission, and 1 month past the milestone for having progressed the document to the IESG and/or closed up shop! And, there has been no discussions (in meetings or on this list) on alternative candidate documents for the work item which [autoconf] is chartered to accomplish.=20 To put it bluntly, this WG is far far behind schedule and this document seemed, and still seems, by virtue of having been widely discussed and agreed upon, as the best shot at making progress for this WG. That said, we (and, this we is also the chairs) will take this opportunity to ask the WGs opinion on how to progress. If you have any opinion, please let it be known to the WG (via this mailing list) before 29/10/09 (i.e. Thursday next week) at noon CET. Please be specific and constructive, i.e., pick one of: o if you think that the WG should proceed with draft-ietf-autoconf-adhoc-addr-model as a baseline, say so!=20 o if you think there're cardinal (but fixable) issues missing or wrong with=20 draft-ietf-autoconf-adhoc-addr-model, then let the WG know what these=20 issues are, and propose a solution before the deadline. The Editors=20 will certainly do their best to address the issues.=20 Yes, I think there are serious, but fixable issues with draft-ietf-autoconf-adhoc-addr-model. Carlos and I wrote draft-bernardos-autoconf-addressing-model to offer a different perspective on these issues. Let me briefly summarize here our (or at least: my) main objections: =20 1. Section 1, Introduction and section 3, Applicability Statement: Nowhere in these sections is there any mention of the assumed host/router model, i.e. whether applications (including management clients) can run on routers and if they can, make use of the interfaces / addresses that are the subject of this draft OR whether applications are assumed to always separated by at least one hop from these interfaces. However, the ghost of draft-clausen-manet-autoconf-recommendations-00 seems to be hovering over this draft, so the latter is sort of implied. I would prefer that this is spelled out, as it impacts the type of addresses that need to be configured, I might not necessarily agree, but al least it would be clearer. =20 2. Section 4, IP Subnet Prefix Configuration: =20 - "Subnet prefix configuration on such interfaces must thus not make any promises in terms of direct (one hop) IP connectivity to IP addresses other than that of the interface itself." I find this unconvincing. What promise would there be, really? Imagine a wired Ethernet, with several nodes on it sharing a prefix.It would be rare for the subnet to be fully populated, even on an IPv4 /24. So if I dream up a host part / Interface ID, append it to the subnet prefix and use that as a destination address, what would be my chances of reaching another node? To be clear, I *agree* on the unique / non-overlapping subnet prefix principle stated here, but find the motivation lacking.=20 - It should say "non-overlapping", because "not the same" is not sufficient. =20 3. Section 6, Addressing Model =20 - 6.1, IPv4 Model: Disagree that the prefix length should be /32. For subnet prefixes to be unique / non-overlapping (see definition in draft-bernardos-autoconf-addressing-model), is a necessary, but also sufficient condition. I ran a MANET with 192.168.x.1/24 on the MANET interfaces for many months. I fail to see what's wrong with that. (Agree on what is said here about IPv LL's, by the way) =20 - 6.2, IPv6 Model: Strongly disagree that the prefix length should be /128. Why paint ourselves into a corner like that? I would urge the draft authors to have a look at RFC 5375, "IPv6 Unicast Address Assignment Considerations". While this is "only" an informational RFC, I think it is worth reading. When in a hurry, you can skip Appendix A, but do not skip Appendix B! Besides, there was discussion at the IETF-75 Autoconf session, see the minutes of that meeting: =20 Dave Thaler - Consistency with RFC 4291 (in particular section 2.5.1). - Do you believe you have 64-bit interface identifiers that=20 are unique within the subnet prefix? (the 64-bit part being=20 a requirement for all unicast addresses that do not begin with binary '000'). - If the answer to previous question is 'no', do you require prefixes to start with binary '000'? - If that is not the case either, shouldn't the document say that the addressing model will not be compliant with RFC4291? =20 and: =20 Dave Thaler - If you believe that you ARE compliant with RFC4291, the way to phrase it is, that you have a /64 subnet prefix, but it is only assigned to a single host. and later Thomas Narten wrote: =20 Thomas Narten (Jabber) - IMO, /128 does not conflict with existing specs. We are blurring and confusing various issues. You can have a /128 for on-link prefixes and still have a=20 64-bit Interface IDs. =20 but he did not explain this any further. So who is right: Thaler or Narten? And what ithe prefix length of a ULA assigned to an interface? /64 as far as I was able to figure out. =20 - IPv6 link-locals: (Too?) Much has been said about this already. My opinion: LL's are there, and they may be pretty hard to get rid of. I'm more concerned about existing platforms than about these new ultra-resource-starved devices that have been subject of discusion on the ML recently. You can choose to not use them for routing purposes (in the narrow definition of routing as discovering network topology and populating the RIB / FIB), but you may not be able to influence whether they are used for forwarding. I've seen neighbor solicitations being sent with LL source addresses from MANET interfaces, that also had global IPv6 addresses configured. =20 - 3rd bullet under "known limitations": routing protocol packets are sent hop-by-hop. They are intercepted. processed and possibly regenerated at each router, so limitation does not apply. =20 Oops, getting too close to deadline. This will have to do. =20 Regards, Ronald =20 =20 =09 o if you think that draft-ietf-autoconf-adhoc-addr-model is beyond hope,=20 let the WG know explicitly how you suggest that we progress at this point --=20 considering the current timeline!! Cheers, Ryuji & Thomas This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/disclaimer/email.html ------_=_NextPart_001_01CA5886.8F9BB591 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.6000.16915" name=3DGENERATOR></HEAD> <BODY=20 style=3D"WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-line-brea= k: after-white-space"> <DIV dir=3Dltr align=3Dleft><SPAN class=3D876050909-29102009><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>Thomas, Ryuji, WG members,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D876050909-29102009><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D876050909-29102009><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>My vote below:</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px soli= d; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> autoconf-bounces@ietf.org=20 [mailto:autoconf-bounces@ietf.org] <B>On Behalf Of </B>Thomas Heide=20 Clausen<BR><B>Sent:</B> donderdag 22 oktober 2009 1:50<BR><B>To:</B>=20 autoconf@ietf.org<BR><B>Subject:</B> [Autoconf] On WG progress and=20 draft-ietf-autoconf-adhoc-addr-model<BR></FONT><BR></DIV> <DIV></DIV> <DIV>All,</DIV> <DIV><BR></DIV> <DIV>It appeared to the chairs that the comments raised at the Stockholm = IETF,=20 as well as on the list subsequently, concerning the document:</DIV> <DIV><BR></DIV> <DIV><SPAN style=3D"WHITE-SPACE: pre"><A=20 href=3D"http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-mod= el"=20 target=3D_blank></A><A=20 href=3D"http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-mod= el"></A><A=20 href=3D"http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-mod= el">http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model</A>= </SPAN></DIV> <DIV><BR></DIV> <DIV>had been addressed fully by the editors, and to the WGs satisfaction= - at=20 least, there were no issue raised to the latter/latest version hereof. Th= e=20 chairs therefore found it a good idea to move the document forward as a W= G=20 document, and progress this document as such. We therefore approved for=20 publication:</DIV> <DIV><BR></DIV> <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: pre"><A=20 href=3D"http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model">= http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model</A></SPAN><= /DIV> <DIV><BR></DIV> <DIV>We (the chairs)  still believe that this is the proper approach= in=20 order to make progress for the WG.</DIV> <DIV><BR></DIV> <DIV>Do note that the WG is 7 months past the milestone for initial docum= ent=20 submission, and 1 month past the milestone for having progressed the docu= ment=20 to the IESG and/or closed up shop!  And, there has been no discussio= ns=20 (in meetings or on this list) on alternative candidate documents for the = work=20 item which [autoconf] is chartered to accomplish. </DIV> <DIV><BR></DIV> <DIV>To put it bluntly, this WG is far far behind schedule and this docum= ent=20 seemed, and still seems, by virtue of having been widely discussed and ag= reed=20 upon, as the best shot at making progress for this WG.</DIV> <DIV><BR></DIV> <DIV>That said, we (and, this we is also the chairs) will take this=20 opportunity to ask the WGs opinion on how to progress. If you have a= ny=20 opinion, please let it be known to the WG (via this mailing list)=20 before 29/10/09 (i.e. Thursday next week) at noon=20 CET. Please be specific and constructive, i.e., pick one of:</D= IV> <DIV><BR></DIV> <DIV><SPAN style=3D"WHITE-SPACE: pre"></SPAN>o<SPAN style=3D"WHITE-SPACE:= pre">=20 </SPAN>if you think that the WG should proceed with <SPAN=20 class=3DApple-tab-span=20 style=3D"WHITE-SPACE: pre">draft-ietf-autoconf-adhoc-addr-model</SPAN></D= IV> <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: pre"></SPAN><SPAN=20 class=3DApple-tab-span style=3D"WHITE-SPACE: pre"></SPAN>as a baseline,&n= bsp;say=20 so! </DIV> <DIV><BR></DIV> <DIV><SPAN style=3D"WHITE-SPACE: pre"></SPAN>o<SPAN style=3D"WHITE-SPACE:= pre">=20 </SPAN>if you think there're cardinal (but fixable) issues missing or wro= ng=20 with </DIV> <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: pre"></SPAN><SPAN=20 class=3DApple-tab-span=20 style=3D"WHITE-SPACE: pre">draft-ietf-autoconf-adhoc-addr-model</SPAN>, t= hen let=20 the WG know what these </DIV> <DIV><SPAN class=3DApple-tab-span=20 style=3D"WHITE-SPACE: pre"></SPAN>issues are, and propose a solution= before=20 the deadline. The Editors </DIV> <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: pre"></SPAN>will = certainly=20 do their best to address the issues.<SPAN class=3D876050909-29102009><FON= T=20 face=3DArial color=3D#0000ff size=3D2> </FONT></SPAN></DIV></BLOCKQU= OTE> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><FONT face=3DArial color=3D= #0000ff=20 size=3D2>Yes, I think there are serious, but fixable issues with </FON= T><SPAN=20 class=3DApple-tab-span style=3D"WHITE-SPACE: pre"><FONT face=3DArial color= =3D#0000ff=20 size=3D2>draft-ietf-autoconf-adhoc-addr-model. Carlos and I wrote=20 draft-bernardos-autoconf-addressing-model to offer a different perspective = on=20 these issues. Let me briefly summarize here our (or at least: my) main=20 objections:</FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff size=3D2>1.&n= bsp; Section=20 1, Introduction and section 3, Applicability Statement: Nowhere in these=20 sections is there any mention of the assumed host/router model, i.e. whethe= r=20 applications (including management clients) can run on routers and if = they=20 can, make use of the interfaces / addresses that are the subject of this dr= aft=20 OR whether applications are assumed to always separated by at least one hop= from=20 these interfaces. However, the ghost of <FONT face=3D"Times New Roman"=20 color=3D#000000><FONT face=3DArial=20 color=3D#0000ff>draft-clausen-manet-autoconf-recommendations-00 seems to</F= ONT>=20 <FONT face=3DArial color=3D#0000ff>be hovering over this draft, so the latt= er is=20 sort of implied. I would prefer that this is spelled out, as it impacts the= type=20 of addresses that need to be configured, I might not necessarily agree, but= al=20 least it would be clearer.</FONT></FONT></FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff size=3D2>2. S= ection 4, IP=20 Subnet Prefix Configuration:</FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff size=3D2>- "S= ubnet prefix=20 configuration on such interfaces must thus not make any promises in terms o= f=20 direct (one hop) IP connectivity to IP addresses other than that of the=20 interface itself." I find this unconvincing. What promise would there be,=20 really? Imagine a wired Ethernet, with several nodes on it sharing a prefix= .It=20 would be rare for the subnet to be fully populated, even on an IPv4 /24. So= if I=20 dream up a host part / Interface ID, append it to the subnet prefix and use= that=20 as a destination address, what would be my chances of reaching another node= ? To=20 be clear, I *agree* on the unique / non-overlapping subnet prefix principle=20 stated here, but find the motivation lacking. </FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff size=3D2>- It= should say=20 "non-overlapping", because "not the same" is not=20 sufficient.</FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff size=3D2>3. S= ection 6,=20 Addressing Model</FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff size=3D2>- 6.= 1, IPv4=20 Model: Disagree that the prefix length should be /32. For subnet prefixes t= o be=20 unique / non-overlapping (see definition in=20 draft-bernardos-autoconf-addressing-model), is a necessary, but also suffic= ient=20 condition. I ran a MANET with 192.168.x.1/24 on the MANET interfaces for ma= ny=20 months. I fail to see what's wrong with that. (Agree on what is said here a= bout=20 IPv LL's, by the way)</FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff size=3D2>- 6.= 2, IPv6=20 Model: Strongly disagree that the prefix length should be /128. Why paint=20 ourselves into a corner like that? I would urge the draft authors to have a= look=20 at RFC 5375, "IPv6 Unicast Address Assignment Considerations". While this i= s=20 "only" an informational RFC, I think it is worth reading. When in a hu= rry,=20 you can skip Appendix A, but do not skip Appendix B! Besides, there was=20 discussion at the IETF-75 Autoconf session, see the minutes of that=20 meeting:</FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial size=3D2>Dave Thaler<BR> - C= onsistency=20 with RFC 4291 (in particular section 2.5.1).<BR> - Do you believe you have=20 64-bit interface identifiers that <BR>   are unique within the subnet=20 prefix? (the 64-bit part being <BR>   a requirement for all unicast=20 addresses that do not=20 begin<BR>           =   =20 with binary '000').<BR> - If the answer to previous question is 'no', do y= ou=20 require<BR>   prefixes to start with binary '000'?<BR> - If that is = not=20 the case either, shouldn't the document say<BR>   that the addressing=20 model will not be compliant with RFC4291?</FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"></SPAN></SPAN> </DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff=20 size=3D2>and:</FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial size=3D2>Dave Thaler<BR> - I= f you=20 believe that you ARE compliant with RFC4291, the way to<BR>   phrase = it=20 is, that you have a /64 subnet prefix, but it is only<BR>   assigned = to a=20 single host.<BR></FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial size=3D2><FONT color=3D#0000f= f>and later=20 Thomas Narten wrote:</FONT></FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial size=3D2><FONT=20 color=3D#0000ff></FONT></FONT></SPAN></SPAN> </DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial><FONT size=3D2>Thomas Narten=20 (Jabber)<BR> - IMO, /128 does not conflict with existing specs. We are blu= rring=20 and confusing<BR>   various issues. You can have a /128 for on-link=20 prefixes and still have a <BR>   64-bit Interface=20 IDs.</FONT></FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial><FONT=20 size=3D2></FONT></FONT></SPAN></SPAN> </DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial><FONT color=3D#0000ff size=3D= 2>but he did=20 not explain this any further. So who is right: Thaler or Narten? And what i= the=20 prefix length of a ULA assigned to an interface? /64 as far as I was able t= o=20 figure out.</FONT></FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial><FONT color=3D#0000ff=20 size=3D2></FONT></FONT></SPAN></SPAN> </DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial><FONT color=3D#0000ff size=3D= 2>- IPv6=20 link-locals: (Too?) Much has been said about this already. My opinion: LL's= are=20 there, and they may be pretty hard to get rid of. I'm more concerned about=20 existing platforms than about these new ultra-resource-starved devices that= have=20 been subject of discusion on the ML recently. You can choose to not use the= m for=20 routing purposes (in the narrow definition of routing as discovering networ= k=20 topology and populating the RIB / FIB), but you may not be able to influenc= e=20 whether they are used for forwarding. I've seen neighbor solicitations=20 being sent with LL source addresses from MANET interfaces, that also had gl= obal=20 IPv6 addresses configured.</FONT></DIV></FONT></SPAN></SPAN> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff size=3D2>- 3r= d bullet=20 under "known limitations": routing protocol packets are sent hop-by-hop. Th= ey=20 are intercepted. processed and possibly regenerated at each router, so=20 limitation does not apply.</FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff size=3D2>Oops= , getting too=20 close to deadline. This will have to do.</FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff=20 size=3D2>Regards,</FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff=20 size=3D2>Ronald</FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-spa= n=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN></SPAN> </DIV> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px soli= d; MARGIN-RIGHT: 0px"> <DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20 class=3D876050909-29102009> </SPAN></FONT></FONT></FONT><BR></DIV> <DIV><SPAN style=3D"WHITE-SPACE: pre"></SPAN>o<SPAN style=3D"WHITE-SPACE:= pre">=20 </SPAN>if you think that <SPAN class=3DApple-tab-span=20 style=3D"WHITE-SPACE: pre">draft-ietf-autoconf-adhoc-addr-model</SPAN>&nb= sp;is=20 beyond hope, </DIV> <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: pre"></SPAN>let t= he WG=20 know explicitly how you suggest that we progress  at this point=20 -- </DIV> <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: pre"></SPAN> = ;<SPAN=20 class=3DApple-tab-span style=3D"WHITE-SPACE: pre"> </SPAN>considering the= current=20 timeline!!</DIV> <DIV><BR></DIV> <DIV>Cheers,</DIV> <DIV><BR></DIV> <DIV>Ryuji & Thomas</DIV></BLOCKQUOTE><pre>This e-mail and its conten= ts are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html </pre></BODY></HTML> ------_=_NextPart_001_01CA5886.8F9BB591-- From arjen.holtzer@tno.nl Thu Oct 29 03:59:38 2009 Return-Path: <arjen.holtzer@tno.nl> 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 59BA83A68F0 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 03:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.493 X-Spam-Level: * X-Spam-Status: No, score=1.493 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, MIME_QP_LONG_LINE=1.396] 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 OuLPQDCUuBko for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 03:59:36 -0700 (PDT) Received: from mailoutb.tno.nl (mailoutb.tno.nl [134.221.1.17]) by core3.amsl.com (Postfix) with ESMTP id 618A33A67AF for <autoconf@ietf.org>; Thu, 29 Oct 2009 03:59:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,645,1249250400"; d="scan'208,217";a="6304125" Received: from ms-dt01thalia.tno.nl (HELO ms-dt01thalia.tsn.tno.nl) ([134.221.225.157]) by mailhost1b.tno.nl with ESMTP; 29 Oct 2009 11:59:47 +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_01CA5886.EDA999FF" Date: Thu, 29 Oct 2009 11:59:46 +0100 Message-ID: <C67EC3A73E6A814B8F3FE826438C5F8C02277871@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <7877C5C0B5CC894AB26113CF06CF886302C7FC76@ms-dt01thalia.tsn.tno.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] On WG progress anddraft-ietf-autoconf-adhoc-addr-model Thread-Index: AcpSqSmswk4zd7I6TfGyz+HGzOCOigFzk1MgAAPUfYA= References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <7877C5C0B5CC894AB26113CF06CF886302C7FC76@ms-dt01thalia.tsn.tno.nl> From: "Holtzer, A.C.G. (Arjen)" <arjen.holtzer@tno.nl> To: "Velt, R. (Ronald) in 't" <Ronald.intVelt@tno.nl>, <autoconf@ietf.org> Subject: Re: [Autoconf] On WG progress anddraft-ietf-autoconf-adhoc-addr-model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 10:59:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5886.EDA999FF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 Ronald told me to say: "Me too". :) =20 Regards, Arjen =20 ________________________________ From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On Behalf Of Velt, R. (Ronald) in 't Sent: donderdag 29 oktober 2009 11:57 To: Thomas Heide Clausen; autoconf@ietf.org Subject: Re: [Autoconf] On WG progress anddraft-ietf-autoconf-adhoc-addr-model =09 =09 Thomas, Ryuji, WG members, =20 My vote below: ________________________________ From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On Behalf Of Thomas Heide Clausen Sent: donderdag 22 oktober 2009 1:50 To: autoconf@ietf.org Subject: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model =09 =09 All, It appeared to the chairs that the comments raised at the Stockholm IETF, as well as on the list subsequently, concerning the document: =09 <http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model> <http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model> http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model had been addressed fully by the editors, and to the WGs satisfaction - at least, there were no issue raised to the latter/latest version hereof. The chairs therefore found it a good idea to move the document forward as a WG document, and progress this document as such. We therefore approved for publication: =09 http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model We (the chairs) still believe that this is the proper approach in order to make progress for the WG. Do note that the WG is 7 months past the milestone for initial document submission, and 1 month past the milestone for having progressed the document to the IESG and/or closed up shop! And, there has been no discussions (in meetings or on this list) on alternative candidate documents for the work item which [autoconf] is chartered to accomplish.=20 To put it bluntly, this WG is far far behind schedule and this document seemed, and still seems, by virtue of having been widely discussed and agreed upon, as the best shot at making progress for this WG. That said, we (and, this we is also the chairs) will take this opportunity to ask the WGs opinion on how to progress. If you have any opinion, please let it be known to the WG (via this mailing list) before 29/10/09 (i.e. Thursday next week) at noon CET. Please be specific and constructive, i.e., pick one of: o if you think that the WG should proceed with draft-ietf-autoconf-adhoc-addr-model as a baseline, say so!=20 o if you think there're cardinal (but fixable) issues missing or wrong with=20 draft-ietf-autoconf-adhoc-addr-model, then let the WG know what these=20 issues are, and propose a solution before the deadline. The Editors=20 will certainly do their best to address the issues.=20 Yes, I think there are serious, but fixable issues with draft-ietf-autoconf-adhoc-addr-model. Carlos and I wrote draft-bernardos-autoconf-addressing-model to offer a different perspective on these issues. Let me briefly summarize here our (or at least: my) main objections: =20 1. Section 1, Introduction and section 3, Applicability Statement: Nowhere in these sections is there any mention of the assumed host/router model, i.e. whether applications (including management clients) can run on routers and if they can, make use of the interfaces / addresses that are the subject of this draft OR whether applications are assumed to always separated by at least one hop from these interfaces. However, the ghost of draft-clausen-manet-autoconf-recommendations-00 seems to be hovering over this draft, so the latter is sort of implied. I would prefer that this is spelled out, as it impacts the type of addresses that need to be configured, I might not necessarily agree, but al least it would be clearer. =20 2. Section 4, IP Subnet Prefix Configuration: =20 - "Subnet prefix configuration on such interfaces must thus not make any promises in terms of direct (one hop) IP connectivity to IP addresses other than that of the interface itself." I find this unconvincing. What promise would there be, really? Imagine a wired Ethernet, with several nodes on it sharing a prefix.It would be rare for the subnet to be fully populated, even on an IPv4 /24. So if I dream up a host part / Interface ID, append it to the subnet prefix and use that as a destination address, what would be my chances of reaching another node? To be clear, I *agree* on the unique / non-overlapping subnet prefix principle stated here, but find the motivation lacking.=20 - It should say "non-overlapping", because "not the same" is not sufficient. =20 3. Section 6, Addressing Model =20 - 6.1, IPv4 Model: Disagree that the prefix length should be /32. For subnet prefixes to be unique / non-overlapping (see definition in draft-bernardos-autoconf-addressing-model), is a necessary, but also sufficient condition. I ran a MANET with 192.168.x.1/24 on the MANET interfaces for many months. I fail to see what's wrong with that. (Agree on what is said here about IPv LL's, by the way) =20 - 6.2, IPv6 Model: Strongly disagree that the prefix length should be /128. Why paint ourselves into a corner like that? I would urge the draft authors to have a look at RFC 5375, "IPv6 Unicast Address Assignment Considerations". While this is "only" an informational RFC, I think it is worth reading. When in a hurry, you can skip Appendix A, but do not skip Appendix B! Besides, there was discussion at the IETF-75 Autoconf session, see the minutes of that meeting: =20 Dave Thaler - Consistency with RFC 4291 (in particular section 2.5.1). - Do you believe you have 64-bit interface identifiers that=20 are unique within the subnet prefix? (the 64-bit part being=20 a requirement for all unicast addresses that do not begin with binary '000'). - If the answer to previous question is 'no', do you require prefixes to start with binary '000'? - If that is not the case either, shouldn't the document say that the addressing model will not be compliant with RFC4291? =20 and: =20 Dave Thaler - If you believe that you ARE compliant with RFC4291, the way to phrase it is, that you have a /64 subnet prefix, but it is only assigned to a single host. =09 and later Thomas Narten wrote: =20 Thomas Narten (Jabber) - IMO, /128 does not conflict with existing specs. We are blurring and confusing various issues. You can have a /128 for on-link prefixes and still have a=20 64-bit Interface IDs. =20 but he did not explain this any further. So who is right: Thaler or Narten? And what ithe prefix length of a ULA assigned to an interface? /64 as far as I was able to figure out. =20 - IPv6 link-locals: (Too?) Much has been said about this already. My opinion: LL's are there, and they may be pretty hard to get rid of. I'm more concerned about existing platforms than about these new ultra-resource-starved devices that have been subject of discusion on the ML recently. You can choose to not use them for routing purposes (in the narrow definition of routing as discovering network topology and populating the RIB / FIB), but you may not be able to influence whether they are used for forwarding. I've seen neighbor solicitations being sent with LL source addresses from MANET interfaces, that also had global IPv6 addresses configured. =20 - 3rd bullet under "known limitations": routing protocol packets are sent hop-by-hop. They are intercepted. processed and possibly regenerated at each router, so limitation does not apply. =20 Oops, getting too close to deadline. This will have to do. =20 Regards, Ronald =20 =09 =20 o if you think that draft-ietf-autoconf-adhoc-addr-model is beyond hope,=20 let the WG know explicitly how you suggest that we progress at this point --=20 considering the current timeline!! Cheers, Ryuji & Thomas This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/disclaimer/email.html ------_=_NextPart_001_01CA5886.EDA999FF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.6000.16915" name=3DGENERATOR></HEAD> <BODY=20 style=3D"WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-line-brea= k: after-white-space"> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2><SP= AN=20 class=3D389455810-29102009>Hi all,</SPAN></FONT></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2><SP= AN=20 class=3D389455810-29102009></SPAN></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2><SP= AN=20 class=3D389455810-29102009>Ronald told me to say: "Me too". :)</SPAN></FONT= ></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2><SP= AN=20 class=3D389455810-29102009></SPAN></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2><SP= AN=20 class=3D389455810-29102009>Regards,</SPAN></FONT></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2><SP= AN=20 class=3D389455810-29102009>Arjen</SPAN></FONT></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2><SP= AN=20 class=3D389455810-29102009></SPAN></FONT> </DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px soli= d; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> autoconf-bounces@ietf.org=20 [mailto:autoconf-bounces@ietf.org] <B>On Behalf Of </B>Velt, R. (Ronald) = in=20 't<BR><B>Sent:</B> donderdag 29 oktober 2009 11:57<BR><B>To:</B> Thomas H= eide=20 Clausen; autoconf@ietf.org<BR><B>Subject:</B> Re: [Autoconf] On WG progre= ss=20 anddraft-ietf-autoconf-adhoc-addr-model<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D876050909-29102009><FONT face= =3DArial=20 color=3D#0000ff size=3D2>Thomas, Ryuji, WG members,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D876050909-29102009><FONT face= =3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D876050909-29102009><FONT face= =3DArial=20 color=3D#0000ff size=3D2>My vote below:</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px so= lid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> autoconf-bounces@ietf.org=20 [mailto:autoconf-bounces@ietf.org] <B>On Behalf Of </B>Thomas Heide=20 Clausen<BR><B>Sent:</B> donderdag 22 oktober 2009 1:50<BR><B>To:</B>=20 autoconf@ietf.org<BR><B>Subject:</B> [Autoconf] On WG progress and=20 draft-ietf-autoconf-adhoc-addr-model<BR></FONT><BR></DIV> <DIV></DIV> <DIV>All,</DIV> <DIV><BR></DIV> <DIV>It appeared to the chairs that the comments raised at the Stockhol= m=20 IETF, as well as on the list subsequently, concerning the=20 document:</DIV> <DIV><BR></DIV> <DIV><SPAN style=3D"WHITE-SPACE: pre"><A=20 href=3D"http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-m= odel"=20 target=3D_blank></A><A=20 href=3D"http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-m= odel"></A><A=20 href=3D"http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-m= odel">http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model</= A></SPAN></DIV> <DIV><BR></DIV> <DIV>had been addressed fully by the editors, and to the WGs satisfacti= on -=20 at least, there were no issue raised to the latter/latest version hereo= f.=20 The chairs therefore found it a good idea to move the document forward = as a=20 WG document, and progress this document as such. We therefore approved = for=20 publication:</DIV> <DIV><BR></DIV> <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: pre"><A=20 href=3D"http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model= ">http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model</A></SPAN= ></DIV> <DIV><BR></DIV> <DIV>We (the chairs)  still believe that this is the proper approa= ch in=20 order to make progress for the WG.</DIV> <DIV><BR></DIV> <DIV>Do note that the WG is 7 months past the milestone for initial doc= ument=20 submission, and 1 month past the milestone for having progressed the=20 document to the IESG and/or closed up shop!  And, there has been n= o=20 discussions (in meetings or on this list) on alternative candidate docu= ments=20 for the work item which [autoconf] is chartered to accomplish. </D= IV> <DIV><BR></DIV> <DIV>To put it bluntly, this WG is far far behind schedule and this doc= ument=20 seemed, and still seems, by virtue of having been widely discussed and=20 agreed upon, as the best shot at making progress for this WG.</DIV> <DIV><BR></DIV> <DIV>That said, we (and, this we is also the chairs) will take this=20 opportunity to ask the WGs opinion on how to progress. If you have= any=20 opinion, please let it be known to the WG (via this mailing list)=20 before 29/10/09 (i.e. Thursday next week) at noon=20 CET. Please be specific and constructive, i.e., pick one of:<= /DIV> <DIV><BR></DIV> <DIV><SPAN style=3D"WHITE-SPACE: pre"></SPAN>o<SPAN style=3D"WHITE-SPAC= E: pre">=20 </SPAN>if you think that the WG should proceed with <SPAN=20 class=3DApple-tab-span=20 style=3D"WHITE-SPACE: pre">draft-ietf-autoconf-adhoc-addr-model</SPAN><= /DIV> <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: pre"></SPAN><SP= AN=20 class=3DApple-tab-span style=3D"WHITE-SPACE: pre"></SPAN>as a baseline,=  say=20 so! </DIV> <DIV><BR></DIV> <DIV><SPAN style=3D"WHITE-SPACE: pre"></SPAN>o<SPAN style=3D"WHITE-SPAC= E: pre">=20 </SPAN>if you think there're cardinal (but fixable) issues missing or w= rong=20 with </DIV> <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: pre"></SPAN><SP= AN=20 class=3DApple-tab-span=20 style=3D"WHITE-SPACE: pre">draft-ietf-autoconf-adhoc-addr-model</SPAN>,= then=20 let the WG know what these </DIV> <DIV><SPAN class=3DApple-tab-span=20 style=3D"WHITE-SPACE: pre"></SPAN>issues are, and propose a soluti= on=20 before the deadline. The Editors </DIV> <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: pre"></SPAN>wil= l=20 certainly do their best to address the issues.<SPAN=20 class=3D876050909-29102009><FONT face=3DArial color=3D#0000ff=20 size=3D2> </FONT></SPAN></DIV></BLOCKQUOTE> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><FONT face=3DArial color= =3D#0000ff=20 size=3D2>Yes, I think there are serious, but fixable issues=20 with </FONT><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: pre">= <FONT=20 face=3DArial color=3D#0000ff size=3D2>draft-ietf-autoconf-adhoc-addr-mode= l. Carlos=20 and I wrote draft-bernardos-autoconf-addressing-model to offer a differen= t=20 perspective on these issues. Let me briefly summarize here our (or at lea= st:=20 my) main objections:</FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff size=3D2>1.=  =20 Section 1, Introduction and section 3, Applicability Statement: Nowhere i= n=20 these sections is there any mention of the assumed host/router model, i.e= .=20 whether applications (including management clients) can run on route= rs=20 and if they can, make use of the interfaces / addresses that are the subj= ect=20 of this draft OR whether applications are assumed to always separated by = at=20 least one hop from these interfaces. However, the ghost of <FONT=20 face=3D"Times New Roman" color=3D#000000><FONT face=3DArial=20 color=3D#0000ff>draft-clausen-manet-autoconf-recommendations-00 seems to<= /FONT>=20 <FONT face=3DArial color=3D#0000ff>be hovering over this draft, so the la= tter is=20 sort of implied. I would prefer that this is spelled out, as it impacts t= he=20 type of addresses that need to be configured, I might not necessarily agr= ee,=20 but al least it would be clearer.</FONT></FONT></FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff size=3D2>2.= Section 4,=20 IP Subnet Prefix Configuration:</FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff size=3D2>- = "Subnet=20 prefix configuration on such interfaces must thus not make any promises i= n=20 terms of direct (one hop) IP connectivity to IP addresses other than that= of=20 the interface itself." I find this unconvincing. What promise would there= be,=20 really? Imagine a wired Ethernet, with several nodes on it sharing a pref= ix.It=20 would be rare for the subnet to be fully populated, even on an IPv4 /24. = So if=20 I dream up a host part / Interface ID, append it to the subnet prefix and= use=20 that as a destination address, what would be my chances of reaching anoth= er=20 node? To be clear, I *agree* on the unique / non-overlapping subnet prefi= x=20 principle stated here, but find the motivation lacking.=20 </FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff size=3D2>- = It should say=20 "non-overlapping", because "not the same" is not=20 sufficient.</FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff size=3D2>3.= Section 6,=20 Addressing Model</FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff size=3D2>- = 6.1, IPv4=20 Model: Disagree that the prefix length should be /32. For subnet prefixes= to=20 be unique / non-overlapping (see definition in=20 draft-bernardos-autoconf-addressing-model), is a necessary, but also=20 sufficient condition. I ran a MANET with 192.168.x.1/24 on the MANET=20 interfaces for many months. I fail to see what's wrong with that. (Agree = on=20 what is said here about IPv LL's, by the way)</FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff size=3D2>- = 6.2, IPv6=20 Model: Strongly disagree that the prefix length should be /128. Why paint=20 ourselves into a corner like that? I would urge the draft authors to have= a=20 look at RFC 5375, "IPv6 Unicast Address Assignment Considerations". While= this=20 is "only" an informational RFC, I think it is worth reading. When in= a=20 hurry, you can skip Appendix A, but do not skip Appendix B! Besides, ther= e was=20 discussion at the IETF-75 Autoconf session, see the minutes of that=20 meeting:</FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial size=3D2>Dave Thaler<BR>- C= onsistency=20 with RFC 4291 (in particular section 2.5.1).<BR>- Do you believe you have=20 64-bit interface identifiers that <BR>  are unique within the subnet=20 prefix? (the 64-bit part being <BR>  a requirement for all unicast=20 addresses that do not=20 begin<BR>          &nbs= p;  =20 with binary '000').<BR>- If the answer to previous question is 'no', do y= ou=20 require<BR>  prefixes to start with binary '000'?<BR>- If that is no= t the=20 case either, shouldn't the document say<BR>  that the addressing mod= el=20 will not be compliant with RFC4291?</FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"></SPAN></SPAN> </DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff=20 size=3D2>and:</FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial size=3D2>Dave Thaler<BR>- I= f you=20 believe that you ARE compliant with RFC4291, the way to<BR>  phrase = it=20 is, that you have a /64 subnet prefix, but it is only<BR>  assigned = to a=20 single host.<BR></FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial size=3D2><FONT color=3D#000= 0ff>and later=20 Thomas Narten wrote:</FONT></FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial size=3D2><FONT=20 color=3D#0000ff></FONT></FONT></SPAN></SPAN> </DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial><FONT size=3D2>Thomas Narte= n=20 (Jabber)<BR>- IMO, /128 does not conflict with existing specs. We are blu= rring=20 and confusing<BR>  various issues. You can have a /128 for on-link=20 prefixes and still have a <BR>  64-bit Interface=20 IDs.</FONT></FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial><FONT=20 size=3D2></FONT></FONT></SPAN></SPAN> </DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial><FONT color=3D#0000ff size= =3D2>but he=20 did not explain this any further. So who is right: Thaler or Narten? And = what=20 ithe prefix length of a ULA assigned to an interface? /64 as far as I was= able=20 to figure out.</FONT></FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial><FONT color=3D#0000ff=20 size=3D2></FONT></FONT></SPAN></SPAN> </DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial><FONT color=3D#0000ff size= =3D2>- IPv6=20 link-locals: (Too?) Much has been said about this already. My opinion: LL= 's=20 are there, and they may be pretty hard to get rid of. I'm more concerned = about=20 existing platforms than about these new ultra-resource-starved devices th= at=20 have been subject of discusion on the ML recently. You can choose to not = use=20 them for routing purposes (in the narrow definition of routing as discove= ring=20 network topology and populating the RIB / FIB), but you may not be able t= o=20 influence whether they are used for forwarding. I've seen neighbor=20 solicitations being sent with LL source addresses from MANET interfaces, = that=20 also had global IPv6 addresses configured.</FONT></DIV></FONT></SPAN></SP= AN> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff size=3D2>- = 3rd bullet=20 under "known limitations": routing protocol packets are sent hop-by-hop. = They=20 are intercepted. processed and possibly regenerated at each router, so=20 limitation does not apply.</FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff size=3D2>Oo= ps, getting=20 too close to deadline. This will have to do.</FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN></SPAN> </DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff=20 size=3D2>Regards,</FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff=20 size=3D2>Ronald</FONT></SPAN></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D876050909-29102009><SPAN class=3DApple-tab-s= pan=20 style=3D"WHITE-SPACE: pre"><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></SPAN></SPAN> </DIV> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px so= lid; MARGIN-RIGHT: 0px"> <DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20 class=3D876050909-29102009></SPAN></FONT></FONT></FONT><BR> </DIV> <DIV><SPAN style=3D"WHITE-SPACE: pre"></SPAN>o<SPAN style=3D"WHITE-SPAC= E: pre">=20 </SPAN>if you think that <SPAN class=3DApple-tab-span=20 style=3D"WHITE-SPACE: pre">draft-ietf-autoconf-adhoc-addr-model</SPAN>&= nbsp;is=20 beyond hope, </DIV> <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: pre"></SPAN>let= the WG=20 know explicitly how you suggest that we progress  at this poi= nt=20 -- </DIV> <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: pre"></SPAN>&nb= sp;<SPAN=20 class=3DApple-tab-span style=3D"WHITE-SPACE: pre"> </SPAN>considering t= he=20 current timeline!!</DIV> <DIV><BR></DIV> <DIV>Cheers,</DIV> <DIV><BR></DIV> <DIV>Ryuji & Thomas</DIV></BLOCKQUOTE><PRE>This e-mail and its cont= ents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.ht= ml </PRE></BLOCKQUOTE><pre>This e-mail and its contents are subject to the DIS= CLAIMER at http://www.tno.nl/disclaimer/email.html </pre></BODY></HTML> ------_=_NextPart_001_01CA5886.EDA999FF-- From Chris.Dearlove@baesystems.com Thu Oct 29 04:24:12 2009 Return-Path: <Chris.Dearlove@baesystems.com> 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 9E1DF3A68F0 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 04:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.583 X-Spam-Level: X-Spam-Status: No, score=-1.583 tagged_above=-999 required=5 tests=[AWL=-0.473, 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 HIxQsqjvPw18 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 04:24:11 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id EF4033A6902 for <autoconf@ietf.org>; Thu, 29 Oct 2009 04:24:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,645,1249254000"; d="scan'208";a="30034270" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 29 Oct 2009 11:24:26 +0000 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 n9TBOWje013576 for <autoconf@ietf.org>; Thu, 29 Oct 2009 11:24:32 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 11:24:26 +0000 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, 29 Oct 2009 11:24:25 -0000 Message-ID: <ABE739C5ADAC9A41ACCC72DF366B719D02649C56@GLKMS2100.GREENLNK.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Support for what I hope will become rogh consensus thread-index: AcpYil8r+FYf8wxdT/ab5MXXgeublw== From: "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com> To: <autoconf@ietf.org> X-OriginalArrivalTime: 29 Oct 2009 11:24:26.0006 (UTC) FILETIME=[5F3D3B60:01CA588A] Subject: [Autoconf] Support for what I hope will become rogh consensus X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 11:24:12 -0000 Unfortunately, I won't be in Hiroshima. But in the interests of indicating one more support for what I hope will be a rough consensus (though clearly not unanimity) my views are: - The priority is to get a document agreed by the WG and then by the IESG, so the WG can get on with the real work of actually designing/specifying a protocol. This needs to be now (Hiroshima timescale). In fact we almost were there at Stockholm. - The best route to that is to accept the adoption of the Baccelli/Townsley document, and consider minor but not extensive revisions. Other documents (kept as private drafts) may inform that process. Opening up a whole debate between documents is not going to achieve the point above. - With regard to the specific issue of LL addresses, any use of LL addresses, and certainly any use in conjunction with any of the MANET WG protocols, leads to issues of possible violation of LL address locality constraints that will, in my and other people's best estimation, lead to the strong likelihood of significant delays, at best, in the draft being accepted by the IESG. - A carefully crafted (and the draft attempts this) deprecation, but not prohibition, of consideration of LL addresses should achieve this. Note that I would then expect anyone who does want to use LL addresses, considering that the non-locality issues are acceptable, will probably be able to employ some variant, or even an unchanged, version of whatever protcol is eventually worked on. But that is not however essential. -- 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 ******************************************************************** 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 Oct 29 04:56:48 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 AE3893A6817 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 04:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_52=0.6] 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 YccnykZ2I86w for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 04:56:47 -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 BB4063A659C for <autoconf@ietf.org>; Thu, 29 Oct 2009 04:56:46 -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 n9TBv1QO021967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Oct 2009 12:57:01 +0100 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 n9TBv1BD018729; Thu, 29 Oct 2009 12:57:01 +0100 (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 n9TBv0kc032398; Thu, 29 Oct 2009 12:57:00 +0100 Message-ID: <4AE9830C.8040508@gmail.com> Date: Thu, 29 Oct 2009 12:57:00 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Holtzer, A.C.G. (Arjen)" <arjen.holtzer@tno.nl> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <7877C5C0B5CC894AB26113CF06CF886302C7FC76@ms-dt01thalia.tsn.tno.nl> <C67EC3A73E6A814B8F3FE826438C5F8C02277871@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <C67EC3A73E6A814B8F3FE826438C5F8C02277871@ms-dt01thalia.tsn.tno.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 11:56:48 -0000 Hi, Me too I agree with what Ronald says below, especially the risk of painting self in a corner using /128 and /32. I hope Chairs can count this too. Alex Holtzer, A.C.G. (Arjen) a écrit : > Hi all, > > Ronald told me to say: "Me too". :) > > Regards, > Arjen > > > ------------------------------------------------------------------------ > *From:* autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] > *On Behalf Of *Velt, R. (Ronald) in 't > *Sent:* donderdag 29 oktober 2009 11:57 > *To:* Thomas Heide Clausen; autoconf@ietf.org > *Subject:* Re: [Autoconf] On WG progress > anddraft-ietf-autoconf-adhoc-addr-model > > Thomas, Ryuji, WG members, > > My vote below: > > ------------------------------------------------------------------------ > *From:* autoconf-bounces@ietf.org > [mailto:autoconf-bounces@ietf.org] *On Behalf Of *Thomas Heide > Clausen > *Sent:* donderdag 22 oktober 2009 1:50 > *To:* autoconf@ietf.org > *Subject:* [Autoconf] On WG progress and > draft-ietf-autoconf-adhoc-addr-model > > All, > > It appeared to the chairs that the comments raised at the > Stockholm IETF, as well as on the list subsequently, concerning > the document: > > <http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model> > <http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model>http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model > > had been addressed fully by the editors, and to the WGs > satisfaction - at least, there were no issue raised to the > latter/latest version hereof. The chairs therefore found it a > good idea to move the document forward as a WG document, and > progress this document as such. We therefore approved for > publication: > > http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model > > We (the chairs) still believe that this is the proper approach > in order to make progress for the WG. > > Do note that the WG is 7 months past the milestone for initial > document submission, and 1 month past the milestone for having > progressed the document to the IESG and/or closed up shop! And, > there has been no discussions (in meetings or on this list) on > alternative candidate documents for the work item which > [autoconf] is chartered to accomplish. > > To put it bluntly, this WG is far far behind schedule and this > document seemed, and still seems, by virtue of having been > widely discussed and agreed upon, as the best shot at making > progress for this WG. > > That said, we (and, this we is also the chairs) will take this > opportunity to ask the WGs opinion on how to progress. If you > have any opinion, please let it be known to the WG (via this > mailing list) before 29/10/09 (i.e. Thursday next week) at noon > CET. Please be specific and constructive, i.e., pick one of: > > o if you think that the WG should proceed > with draft-ietf-autoconf-adhoc-addr-model > as a baseline, say so! > > o if you think there're cardinal (but fixable) issues missing or > wrong with > draft-ietf-autoconf-adhoc-addr-model, then let the WG know what > these > issues are, and propose a solution before the deadline. The Editors > will certainly do their best to address the issues. > > Yes, I think there are serious, but fixable issues > with draft-ietf-autoconf-adhoc-addr-model. Carlos and I wrote > draft-bernardos-autoconf-addressing-model to offer a different > perspective on these issues. Let me briefly summarize here our (or > at least: my) main objections: > > 1. Section 1, Introduction and section 3, Applicability Statement: > Nowhere in these sections is there any mention of the assumed > host/router model, i.e. whether applications (including management > clients) can run on routers and if they can, make use of the > interfaces / addresses that are the subject of this draft OR whether > applications are assumed to always separated by at least one hop > from these interfaces. However, the ghost of > draft-clausen-manet-autoconf-recommendations-00 seems to be hovering > over this draft, so the latter is sort of implied. I would prefer > that this is spelled out, as it impacts the type of addresses that > need to be configured, I might not necessarily agree, but al least > it would be clearer. > > 2. Section 4, IP Subnet Prefix Configuration: > > - "Subnet prefix configuration on such interfaces must thus not make > any promises in terms of direct (one hop) IP connectivity to IP > addresses other than that of the interface itself." I find this > unconvincing. What promise would there be, really? Imagine a wired > Ethernet, with several nodes on it sharing a prefix.It would be rare > for the subnet to be fully populated, even on an IPv4 /24. So if I > dream up a host part / Interface ID, append it to the subnet prefix > and use that as a destination address, what would be my chances of > reaching another node? To be clear, I *agree* on the unique / > non-overlapping subnet prefix principle stated here, but find the > motivation lacking. > - It should say "non-overlapping", because "not the same" is not > sufficient. > > 3. Section 6, Addressing Model > > - 6.1, IPv4 Model: Disagree that the prefix length should be /32. > For subnet prefixes to be unique / non-overlapping (see definition > in draft-bernardos-autoconf-addressing-model), is a necessary, but > also sufficient condition. I ran a MANET with 192.168.x.1/24 on the > MANET interfaces for many months. I fail to see what's wrong with > that. (Agree on what is said here about IPv LL's, by the way) > > - 6.2, IPv6 Model: Strongly disagree that the prefix length should > be /128. Why paint ourselves into a corner like that? I would urge > the draft authors to have a look at RFC 5375, "IPv6 Unicast Address > Assignment Considerations". While this is "only" an informational > RFC, I think it is worth reading. When in a hurry, you can skip > Appendix A, but do not skip Appendix B! Besides, there was > discussion at the IETF-75 Autoconf session, see the minutes of that > meeting: > > Dave Thaler > - Consistency with RFC 4291 (in particular section 2.5.1). > - Do you believe you have 64-bit interface identifiers that > are unique within the subnet prefix? (the 64-bit part being > a requirement for all unicast addresses that do not begin > with binary '000'). > - If the answer to previous question is 'no', do you require > prefixes to start with binary '000'? > - If that is not the case either, shouldn't the document say > that the addressing model will not be compliant with RFC4291? > > and: > > Dave Thaler > - If you believe that you ARE compliant with RFC4291, the way to > phrase it is, that you have a /64 subnet prefix, but it is only > assigned to a single host. > and later Thomas Narten wrote: > > Thomas Narten (Jabber) > - IMO, /128 does not conflict with existing specs. We are blurring > and confusing > various issues. You can have a /128 for on-link prefixes and still > have a > 64-bit Interface IDs. > > but he did not explain this any further. So who is right: Thaler or > Narten? And what ithe prefix length of a ULA assigned to an > interface? /64 as far as I was able to figure out. > > - IPv6 link-locals: (Too?) Much has been said about this already. My > opinion: LL's are there, and they may be pretty hard to get rid of. > I'm more concerned about existing platforms than about these new > ultra-resource-starved devices that have been subject of discusion > on the ML recently. You can choose to not use them for routing > purposes (in the narrow definition of routing as discovering network > topology and populating the RIB / FIB), but you may not be able to > influence whether they are used for forwarding. I've seen neighbor > solicitations being sent with LL source addresses from MANET > interfaces, that also had global IPv6 addresses configured. > > - 3rd bullet under "known limitations": routing protocol packets are > sent hop-by-hop. They are intercepted. processed and possibly > regenerated at each router, so limitation does not apply. > > Oops, getting too close to deadline. This will have to do. > > Regards, > Ronald > > > > > o if you think that draft-ietf-autoconf-adhoc-addr-model is > beyond hope, > let the WG know explicitly how you suggest that we progress at > this point -- > considering the current timeline!! > > Cheers, > > Ryuji & Thomas > > This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html > > 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 From ulrich@herberg.name Thu Oct 29 05:13:40 2009 Return-Path: <ulrich@herberg.name> 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 D7F363A6A87 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 05:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.439 X-Spam-Level: X-Spam-Status: No, score=-1.439 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_52=0.6] 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 Zgdia6W4z3TX for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 05:13:39 -0700 (PDT) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 06ACC3A6A56 for <autoconf@ietf.org>; Thu, 29 Oct 2009 05:13:38 -0700 (PDT) Received: by bwz23 with SMTP id 23so2235512bwz.29 for <autoconf@ietf.org>; Thu, 29 Oct 2009 05:13:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.26.134 with SMTP id e6mr4050346bkc.87.1256818431081; Thu, 29 Oct 2009 05:13:51 -0700 (PDT) In-Reply-To: <C67EC3A73E6A814B8F3FE826438C5F8C02277871@ms-dt01thalia.tsn.tno.nl> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <7877C5C0B5CC894AB26113CF06CF886302C7FC76@ms-dt01thalia.tsn.tno.nl> <C67EC3A73E6A814B8F3FE826438C5F8C02277871@ms-dt01thalia.tsn.tno.nl> Date: Thu, 29 Oct 2009 13:13:50 +0100 Message-ID: <25c114b90910290513w462e68aen5f1fc7d73bd3e69d@mail.gmail.com> From: Ulrich Herberg <ulrich@herberg.name> To: "Holtzer, A.C.G. (Arjen)" <arjen.holtzer@tno.nl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress anddraft-ietf-autoconf-adhoc-addr-model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 12:13:40 -0000 Arjen, Ronald, I hope that Ronald did not really ask you to say "me too" but rather to state your own opinion on the list (whether that be "pro" or "against") :-) Please read draft-clausen-manet-autoconf-recommendations-00 if you did not yet. This explains the rationale for using /32 and /128 prefixes. It also explains what can go wrong when using shorter prefixes and the symptoms thereof (ICMP redirects...) Ulrich On Thu, Oct 29, 2009 at 11:59 AM, Holtzer, A.C.G. (Arjen) <arjen.holtzer@tno.nl> wrote: > Hi all, > > Ronald told me to say: "Me too". :) > > Regards, > Arjen > > > ________________________________ > From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On Beh= alf > Of Velt, R. (Ronald) in 't > Sent: donderdag 29 oktober 2009 11:57 > To: Thomas Heide Clausen; autoconf@ietf.org > Subject: Re: [Autoconf] On WG progress > anddraft-ietf-autoconf-adhoc-addr-model > > Thomas, Ryuji, WG members, > > My vote below: > > ________________________________ > From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On Beh= alf > Of Thomas Heide Clausen > Sent: donderdag 22 oktober 2009 1:50 > To: autoconf@ietf.org > Subject: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-mod= el > > All, > It appeared to the chairs that the comments raised at the Stockholm IETF,= as > well as on the list subsequently,=A0concerning the document: > http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model > had been addressed fully by the editors, and to the WGs satisfaction - at > least, there were no issue raised to the latter/latest version hereof. Th= e > chairs therefore found it a good idea to move the document forward as a W= G > document, and progress this document as such. We therefore approved for > publication: > http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model > We (the chairs) =A0still believe that this is the proper approach in orde= r to > make progress for the WG. > Do note that the WG is 7 months past the milestone for initial document > submission, and 1 month past the milestone for having progressed the > document to the IESG and/or closed up shop! =A0And, there has been no > discussions (in meetings or on this list) on alternative candidate docume= nts > for the work item which [autoconf] is chartered to accomplish. > To put it bluntly, this WG is far far behind schedule and this document > seemed, and still seems, by virtue of having been widely discussed and > agreed upon, as the best shot at making progress for this WG. > That said, we (and, this we is also the chairs) will take this opportunit= y > to ask the WGs opinion on how to progress.=A0If you have any opinion, ple= ase > let it be known to the WG (via this mailing list) before=A029/10/09 > (i.e.=A0Thursday next week) at noon CET.=A0Please=A0be specific and const= ructive, > i.e., pick one of: > o if you think that the WG should proceed > with=A0draft-ietf-autoconf-adhoc-addr-model > as a baseline,=A0say so! > o if you think there're cardinal (but fixable) issues missing or wrong wi= th > draft-ietf-autoconf-adhoc-addr-model, then let the WG know what these > issues=A0are, and propose a solution before the deadline. The Editors > will certainly do their best to address the issues. > > Yes, I think there are serious, but fixable issues > with=A0draft-ietf-autoconf-adhoc-addr-model. Carlos and I wrote > draft-bernardos-autoconf-addressing-model to offer a different perspectiv= e > on these issues. Let me briefly summarize here our (or at least: my) main > objections: > > 1.=A0 Section 1, Introduction and section 3, Applicability Statement: Now= here > in these sections is there any mention of the assumed host/router model, > i.e. whether applications (including management clients)=A0can run on rou= ters > and if they can, make use of the interfaces / addresses that are the subj= ect > of this draft OR whether applications are assumed to always separated by = at > least one hop from these interfaces. However, the ghost of > draft-clausen-manet-autoconf-recommendations-00 seems to be hovering over > this draft, so the latter is sort of implied. I would prefer that this is > spelled out, as it impacts the type of addresses that need to be configur= ed, > I might not necessarily agree, but al least it would be clearer. > > 2. Section 4, IP Subnet Prefix Configuration: > > - "Subnet prefix configuration on such interfaces must thus not make any > promises in terms of direct (one hop) IP connectivity to IP addresses oth= er > than that of the interface itself." I find this unconvincing. What promis= e > would there be, really? Imagine a wired Ethernet, with several nodes on i= t > sharing a prefix.It would be rare for the subnet to be fully populated, e= ven > on an IPv4 /24. So if I dream up a host part / Interface ID, append it to > the subnet prefix and use that as a destination address, what would be my > chances of reaching another node? To be clear, I *agree* on the unique / > non-overlapping subnet prefix principle stated here, but find the motivat= ion > lacking. > - It should say "non-overlapping", because "not the same" is not sufficie= nt. > > 3. Section 6, Addressing Model > > - 6.1, IPv4 Model: Disagree that the prefix length should be /32. For sub= net > prefixes to be unique / non-overlapping (see definition in > draft-bernardos-autoconf-addressing-model), is a necessary, but also > sufficient condition. I ran a MANET with 192.168.x.1/24 on the MANET > interfaces for many months. I fail to see what's wrong with that. (Agree = on > what is said here about IPv LL's, by the way) > > - 6.2, IPv6 Model: Strongly disagree that the prefix length should be /12= 8. > Why paint ourselves into a corner like that? I would urge the draft autho= rs > to have a look at RFC 5375, "IPv6 Unicast Address Assignment > Considerations". While this is "only" an informational RFC, I think it is > worth=A0reading. When in a hurry, you can skip Appendix A, but do not ski= p > Appendix B! Besides, there was discussion at the=A0IETF-75 Autoconf sessi= on, > see the minutes of that meeting: > > Dave Thaler > - Consistency with RFC 4291 (in particular section 2.5.1). > - Do you believe you have 64-bit interface identifiers that > =A0 are unique within the subnet prefix? (the 64-bit part being > =A0 a requirement for all unicast addresses that do not begin > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 with binary '000'). > - If the answer to previous question is 'no', do you require > =A0 prefixes to start with binary '000'? > - If that is not the case either, shouldn't the document say > =A0 that the addressing model will not be compliant with RFC4291? > > and: > > Dave Thaler > - If you believe that you ARE compliant with RFC4291, the way to > =A0 phrase it is, that you have a /64 subnet prefix, but it is only > =A0 assigned to a single host. > and later Thomas Narten wrote: > > Thomas Narten (Jabber) > - IMO, /128 does not conflict with existing specs. We are blurring and > confusing > =A0 various issues. You can have a /128 for on-link prefixes and still ha= ve a > =A0 64-bit Interface IDs. > > but he did not explain this any further. So who is right: Thaler or Narte= n? > And what ithe prefix length of a ULA assigned to an interface? /64 as far= as > I was able to figure out. > > - IPv6 link-locals: (Too?) Much has been said about this already. My > opinion: LL's are there, and they may be pretty hard to get rid of. I'm m= ore > concerned about existing platforms than about these new > ultra-resource-starved devices that have been subject of discusion on the= ML > recently. You can choose to not use them for routing purposes (in the nar= row > definition of routing as discovering network topology and populating the = RIB > / FIB), but you may not be able to influence whether they=A0are used for > forwarding. I've seen neighbor solicitations being sent with LL source > addresses from MANET interfaces, that also had global IPv6 addresses > configured. > > - 3rd bullet under "known limitations": routing protocol packets are sent > hop-by-hop. They are intercepted. processed and possibly regenerated at e= ach > router, so limitation does not apply. > > Oops, getting too close to deadline. This will have to do. > > Regards, > Ronald > > > > o if you think that=A0draft-ietf-autoconf-adhoc-addr-model=A0is beyond ho= pe, > let the WG know explicitly=A0how you suggest that we progress =A0at this = point > -- > =A0 considering the current timeline!! > Cheers, > Ryuji & Thomas > > This e-mail and its contents are subject to the DISCLAIMER at > http://www.tno.nl/disclaimer/email.html > > 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 > > From alexandru.petrescu@gmail.com Thu Oct 29 05:57:44 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 2B7083A6906 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 05:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_52=0.6] 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 oFzagkQbuFhS for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 05:57:42 -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 528473A6836 for <autoconf@ietf.org>; Thu, 29 Oct 2009 05:57:42 -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 n9TCvum9026028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Oct 2009 13:57:56 +0100 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 n9TCvuG9030471; Thu, 29 Oct 2009 13:57:56 +0100 (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 n9TCvtxu002211; Thu, 29 Oct 2009 13:57:55 +0100 Message-ID: <4AE99153.2050608@gmail.com> Date: Thu, 29 Oct 2009 13:57:55 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ulrich Herberg <ulrich@herberg.name> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <7877C5C0B5CC894AB26113CF06CF886302C7FC76@ms-dt01thalia.tsn.tno.nl> <C67EC3A73E6A814B8F3FE826438C5F8C02277871@ms-dt01thalia.tsn.tno.nl> <25c114b90910290513w462e68aen5f1fc7d73bd3e69d@mail.gmail.com> In-Reply-To: <25c114b90910290513w462e68aen5f1fc7d73bd3e69d@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress anddraft-ietf-autoconf-adhoc-addr-model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 12:57:44 -0000 Ulrich Herberg a écrit : > Arjen, Ronald, > > I hope that Ronald did not really ask you to say "me too" but rather > to state your own opinion on the list (whether that be "pro" or > "against") :-) I think it may be right to ask somebody to express an expression on the list if that somebody already thinks that way. I can tell you that there are some people around me who think the way I do with respect to AUTOCONF stuff, yet they don't post on the list. If I tell them to post, they will. They have already made up their mind. There are often cases when we see somebody vote on the list yet rarely if ever having posted previously on the list. There's one recently on your camp too. Did you tell him the same? I hope Chairs count all this in a fair manner. Alex > > Please read draft-clausen-manet-autoconf-recommendations-00 if you did > not yet. This explains the rationale for using /32 and /128 prefixes. > It also explains what can go wrong when using shorter prefixes and the > symptoms thereof (ICMP redirects...) > > Ulrich > > > On Thu, Oct 29, 2009 at 11:59 AM, Holtzer, A.C.G. (Arjen) > <arjen.holtzer@tno.nl> wrote: >> Hi all, >> >> Ronald told me to say: "Me too". :) >> >> Regards, >> Arjen >> >> >> ________________________________ >> From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On Behalf >> Of Velt, R. (Ronald) in 't >> Sent: donderdag 29 oktober 2009 11:57 >> To: Thomas Heide Clausen; autoconf@ietf.org >> Subject: Re: [Autoconf] On WG progress >> anddraft-ietf-autoconf-adhoc-addr-model >> >> Thomas, Ryuji, WG members, >> >> My vote below: >> >> ________________________________ >> From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On Behalf >> Of Thomas Heide Clausen >> Sent: donderdag 22 oktober 2009 1:50 >> To: autoconf@ietf.org >> Subject: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model >> >> All, >> It appeared to the chairs that the comments raised at the Stockholm IETF, as >> well as on the list subsequently, concerning the document: >> http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model >> had been addressed fully by the editors, and to the WGs satisfaction - at >> least, there were no issue raised to the latter/latest version hereof. The >> chairs therefore found it a good idea to move the document forward as a WG >> document, and progress this document as such. We therefore approved for >> publication: >> http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model >> We (the chairs) still believe that this is the proper approach in order to >> make progress for the WG. >> Do note that the WG is 7 months past the milestone for initial document >> submission, and 1 month past the milestone for having progressed the >> document to the IESG and/or closed up shop! And, there has been no >> discussions (in meetings or on this list) on alternative candidate documents >> for the work item which [autoconf] is chartered to accomplish. >> To put it bluntly, this WG is far far behind schedule and this document >> seemed, and still seems, by virtue of having been widely discussed and >> agreed upon, as the best shot at making progress for this WG. >> That said, we (and, this we is also the chairs) will take this opportunity >> to ask the WGs opinion on how to progress. If you have any opinion, please >> let it be known to the WG (via this mailing list) before 29/10/09 >> (i.e. Thursday next week) at noon CET. Please be specific and constructive, >> i.e., pick one of: >> o if you think that the WG should proceed >> with draft-ietf-autoconf-adhoc-addr-model >> as a baseline, say so! >> o if you think there're cardinal (but fixable) issues missing or wrong with >> draft-ietf-autoconf-adhoc-addr-model, then let the WG know what these >> issues are, and propose a solution before the deadline. The Editors >> will certainly do their best to address the issues. >> >> Yes, I think there are serious, but fixable issues >> with draft-ietf-autoconf-adhoc-addr-model. Carlos and I wrote >> draft-bernardos-autoconf-addressing-model to offer a different perspective >> on these issues. Let me briefly summarize here our (or at least: my) main >> objections: >> >> 1. Section 1, Introduction and section 3, Applicability Statement: Nowhere >> in these sections is there any mention of the assumed host/router model, >> i.e. whether applications (including management clients) can run on routers >> and if they can, make use of the interfaces / addresses that are the subject >> of this draft OR whether applications are assumed to always separated by at >> least one hop from these interfaces. However, the ghost of >> draft-clausen-manet-autoconf-recommendations-00 seems to be hovering over >> this draft, so the latter is sort of implied. I would prefer that this is >> spelled out, as it impacts the type of addresses that need to be configured, >> I might not necessarily agree, but al least it would be clearer. >> >> 2. Section 4, IP Subnet Prefix Configuration: >> >> - "Subnet prefix configuration on such interfaces must thus not make any >> promises in terms of direct (one hop) IP connectivity to IP addresses other >> than that of the interface itself." I find this unconvincing. What promise >> would there be, really? Imagine a wired Ethernet, with several nodes on it >> sharing a prefix.It would be rare for the subnet to be fully populated, even >> on an IPv4 /24. So if I dream up a host part / Interface ID, append it to >> the subnet prefix and use that as a destination address, what would be my >> chances of reaching another node? To be clear, I *agree* on the unique / >> non-overlapping subnet prefix principle stated here, but find the motivation >> lacking. >> - It should say "non-overlapping", because "not the same" is not sufficient. >> >> 3. Section 6, Addressing Model >> >> - 6.1, IPv4 Model: Disagree that the prefix length should be /32. For subnet >> prefixes to be unique / non-overlapping (see definition in >> draft-bernardos-autoconf-addressing-model), is a necessary, but also >> sufficient condition. I ran a MANET with 192.168.x.1/24 on the MANET >> interfaces for many months. I fail to see what's wrong with that. (Agree on >> what is said here about IPv LL's, by the way) >> >> - 6.2, IPv6 Model: Strongly disagree that the prefix length should be /128. >> Why paint ourselves into a corner like that? I would urge the draft authors >> to have a look at RFC 5375, "IPv6 Unicast Address Assignment >> Considerations". While this is "only" an informational RFC, I think it is >> worth reading. When in a hurry, you can skip Appendix A, but do not skip >> Appendix B! Besides, there was discussion at the IETF-75 Autoconf session, >> see the minutes of that meeting: >> >> Dave Thaler >> - Consistency with RFC 4291 (in particular section 2.5.1). >> - Do you believe you have 64-bit interface identifiers that >> are unique within the subnet prefix? (the 64-bit part being >> a requirement for all unicast addresses that do not begin >> with binary '000'). >> - If the answer to previous question is 'no', do you require >> prefixes to start with binary '000'? >> - If that is not the case either, shouldn't the document say >> that the addressing model will not be compliant with RFC4291? >> >> and: >> >> Dave Thaler >> - If you believe that you ARE compliant with RFC4291, the way to >> phrase it is, that you have a /64 subnet prefix, but it is only >> assigned to a single host. >> and later Thomas Narten wrote: >> >> Thomas Narten (Jabber) >> - IMO, /128 does not conflict with existing specs. We are blurring and >> confusing >> various issues. You can have a /128 for on-link prefixes and still have a >> 64-bit Interface IDs. >> >> but he did not explain this any further. So who is right: Thaler or Narten? >> And what ithe prefix length of a ULA assigned to an interface? /64 as far as >> I was able to figure out. >> >> - IPv6 link-locals: (Too?) Much has been said about this already. My >> opinion: LL's are there, and they may be pretty hard to get rid of. I'm more >> concerned about existing platforms than about these new >> ultra-resource-starved devices that have been subject of discusion on the ML >> recently. You can choose to not use them for routing purposes (in the narrow >> definition of routing as discovering network topology and populating the RIB >> / FIB), but you may not be able to influence whether they are used for >> forwarding. I've seen neighbor solicitations being sent with LL source >> addresses from MANET interfaces, that also had global IPv6 addresses >> configured. >> >> - 3rd bullet under "known limitations": routing protocol packets are sent >> hop-by-hop. They are intercepted. processed and possibly regenerated at each >> router, so limitation does not apply. >> >> Oops, getting too close to deadline. This will have to do. >> >> Regards, >> Ronald >> >> >> >> o if you think that draft-ietf-autoconf-adhoc-addr-model is beyond hope, >> let the WG know explicitly how you suggest that we progress at this point >> -- >> considering the current timeline!! >> Cheers, >> Ryuji & Thomas >> >> This e-mail and its contents are subject to the DISCLAIMER at >> http://www.tno.nl/disclaimer/email.html >> >> 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 >> >> > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From ulrich@herberg.name Thu Oct 29 06:05:05 2009 Return-Path: <ulrich@herberg.name> 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 66DA23A67D6 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 06:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.219 X-Spam-Level: X-Spam-Status: No, score=-0.219 tagged_above=-999 required=5 tests=[AWL=-1.275, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_XBL=3.033] 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 n5x1auuK-sqA for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 06:05:04 -0700 (PDT) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 5FF563A68F3 for <autoconf@ietf.org>; Thu, 29 Oct 2009 06:05:04 -0700 (PDT) Received: by bwz23 with SMTP id 23so2292964bwz.29 for <autoconf@ietf.org>; Thu, 29 Oct 2009 06:05:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.155.71 with SMTP id r7mr2612241bkw.164.1256821518001; Thu, 29 Oct 2009 06:05:18 -0700 (PDT) In-Reply-To: <4AE99153.2050608@gmail.com> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <7877C5C0B5CC894AB26113CF06CF886302C7FC76@ms-dt01thalia.tsn.tno.nl> <C67EC3A73E6A814B8F3FE826438C5F8C02277871@ms-dt01thalia.tsn.tno.nl> <25c114b90910290513w462e68aen5f1fc7d73bd3e69d@mail.gmail.com> <4AE99153.2050608@gmail.com> Date: Thu, 29 Oct 2009 14:05:17 +0100 Message-ID: <25c114b90910290605j243ccb77x298d69ad5d8a5c3b@mail.gmail.com> From: Ulrich Herberg <ulrich@herberg.name> To: Alexandru Petrescu <alexandru.petrescu@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress anddraft-ietf-autoconf-adhoc-addr-model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 13:05:05 -0000 Alex, On Thu, Oct 29, 2009 at 1:57 PM, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote: [..] > I think it may be right to ask somebody to express an expression on the l= ist > if that somebody already thinks that way. Everybody has the right to express his opinion (and more importantly, technical arguments) on the mailing list. > > I can tell you that there are some people around me who think the way I d= o > with respect to AUTOCONF stuff, yet they don't post on the list. =A0If I = tell > them to post, they will. =A0They have already made up their mind. > > There are often cases when we see somebody vote on the list yet rarely if > ever having posted previously on the list. =A0There's one recently on you= r > camp too. =A0Did you tell him the same? I asked my colleague to express his own opinion on this matter. I did not tell him "Please vote in favor of the DT draft". (and I am not accusing anyone of not expressing his own opinion, but the opinion of the supervisor/colleague etc.) But please, let's close this discussion. I am sorry if that diverged from the main, technical issue. > > I hope Chairs count all this in a fair manner. I am sure they will count every opinion. Ulrich From arjen.holtzer@tno.nl Thu Oct 29 06:29:07 2009 Return-Path: <arjen.holtzer@tno.nl> 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 918663A6ABE for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 06:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.492 X-Spam-Level: * X-Spam-Status: No, score=1.492 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_52=0.6, MIME_QP_LONG_LINE=1.396] 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 DoTfvuRNk+Ie for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 06:29:06 -0700 (PDT) Received: from mailouta.tno.nl (mailouta.tno.nl [134.221.1.16]) by core3.amsl.com (Postfix) with ESMTP id 875513A6ABC for <autoconf@ietf.org>; Thu, 29 Oct 2009 06:29:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,646,1249250400"; d="scan'208";a="26498807" Received: from ms-dt01thalia.tno.nl (HELO ms-dt01thalia.tsn.tno.nl) ([134.221.225.157]) by mailhost1a.tno.nl with ESMTP; 29 Oct 2009 14:29:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 Oct 2009 14:29:14 +0100 Message-ID: <C67EC3A73E6A814B8F3FE826438C5F8C02277873@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <25c114b90910290513w462e68aen5f1fc7d73bd3e69d@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] On WG progress anddraft-ietf-autoconf-adhoc-addr-model Thread-Index: AcpYkUesTYXN47B5SFqaOs2sBzULygAA0w8A References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <7877C5C0B5CC894AB26113CF06CF886302C7FC76@ms-dt01thalia.tsn.tno.nl> <C67EC3A73E6A814B8F3FE826438C5F8C02277871@ms-dt01thalia.tsn.tno.nl> <25c114b90910290513w462e68aen5f1fc7d73bd3e69d@mail.gmail.com> From: "Holtzer, A.C.G. (Arjen)" <arjen.holtzer@tno.nl> To: "Ulrich Herberg" <ulrich@herberg.name> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress anddraft-ietf-autoconf-adhoc-addr-model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 13:29:07 -0000 Hi Ulrich, Ronald, Alex, Actually, to be more specific, I agree with the text in draft-bernardos-aut= oconf-addressing-model-01 which states in section 3.2: "The use of /32 (in the IPv4 case) or /128 (in the IPv6 case) prefix lengths can be an effective way to ensure that prefixes are non-overlapping. However, it would be needlessly restrictive to mandate the use of only these prefix lengths." As far as section 4.2 of draft-clausen-manet-autoconf-recommendations-00 is= concerned: this addresses the issue with ICMP redirect messages when the a= ddresses of the nodes in the "hidden-terminal"-scenario of Figure 9 are usi= ng the same subnet prefix. I agree this is an issue and it can be solved by= using non-overlapping prefixes, not exclusively by using /32 IPv4 and /128= IPv6 prefixes. This seems unnecessarily restrictive to me. And about my opinion on the WG document: I think draft-ietf-autoconf-adhoc-= addr-model is a good point for continuation, but I think Ronald has several= good points. In general, I am, like everyone in the WG, in favour of fast = progress with the addressing model, since I am waiting for the moment to go= into solution space. Best regards, Arjen =20 > -----Original Message----- > From: Ulrich Herberg [mailto:ulrich@herberg.name]=20 > Sent: donderdag 29 oktober 2009 13:14 > To: Holtzer, A.C.G. (Arjen) > Cc: Velt, R. (Ronald) in 't; autoconf@ietf.org > Subject: Re: [Autoconf] On WG progress=20 > anddraft-ietf-autoconf-adhoc-addr-model >=20 > Arjen, Ronald, >=20 > I hope that Ronald did not really ask you to say "me too" but=20 > rather to state your own opinion on the list (whether that be "pro" or > "against") :-) >=20 > Please read draft-clausen-manet-autoconf-recommendations-00=20 > if you did not yet. This explains the rationale for using /32=20 > and /128 prefixes. > It also explains what can go wrong when using shorter=20 > prefixes and the symptoms thereof (ICMP redirects...) >=20 > Ulrich >=20 >=20 > On Thu, Oct 29, 2009 at 11:59 AM, Holtzer, A.C.G. (Arjen)=20 > <arjen.holtzer@tno.nl> wrote: > > Hi all, > > > > Ronald told me to say: "Me too". :) > > > > Regards, > > Arjen > > > > > > ________________________________ > > From: autoconf-bounces@ietf.org=20 > [mailto:autoconf-bounces@ietf.org] On=20 > > Behalf Of Velt, R. (Ronald) in 't > > Sent: donderdag 29 oktober 2009 11:57 > > To: Thomas Heide Clausen; autoconf@ietf.org > > Subject: Re: [Autoconf] On WG progress=20 > > anddraft-ietf-autoconf-adhoc-addr-model > > > > Thomas, Ryuji, WG members, > > > > My vote below: > > > > ________________________________ > > From: autoconf-bounces@ietf.org=20 > [mailto:autoconf-bounces@ietf.org] On=20 > > Behalf Of Thomas Heide Clausen > > Sent: donderdag 22 oktober 2009 1:50 > > To: autoconf@ietf.org > > Subject: [Autoconf] On WG progress and=20 > > draft-ietf-autoconf-adhoc-addr-model > > > > All, > > It appeared to the chairs that the comments raised at the Stockholm=20 > > IETF, as well as on the list subsequently,=A0concerning the document: > > http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model > > had been addressed fully by the editors, and to the WGs=20 > satisfaction -=20 > > at least, there were no issue raised to the latter/latest version=20 > > hereof. The chairs therefore found it a good idea to move=20 > the document=20 > > forward as a WG document, and progress this document as such. We=20 > > therefore approved for > > publication: > > http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model > > We (the chairs) =A0still believe that this is the proper approach in=20 > > order to make progress for the WG. > > Do note that the WG is 7 months past the milestone for initial=20 > > document submission, and 1 month past the milestone for having=20 > > progressed the document to the IESG and/or closed up shop! =A0 > And, there=20 > > has been no discussions (in meetings or on this list) on=20 > alternative=20 > > candidate documents for the work item which [autoconf] is=20 > chartered to accomplish. > > To put it bluntly, this WG is far far behind schedule and this=20 > > document seemed, and still seems, by virtue of having been widely=20 > > discussed and agreed upon, as the best shot at making=20 > progress for this WG. > > That said, we (and, this we is also the chairs) will take this=20 > > opportunity to ask the WGs opinion on how to progress.=A0If=20 > you have any=20 > > opinion, please let it be known to the WG (via this mailing list)=20 > > before=A029/10/09 (i.e.=A0Thursday next week) at noon CET.=A0Please=A0b= e=20 > > specific and constructive, i.e., pick one of: > > o if you think that the WG should proceed with=A0 > > draft-ietf-autoconf-adhoc-addr-model > > as a baseline,=A0say so! > > o if you think there're cardinal (but fixable) issues=20 > missing or wrong=20 > > with draft-ietf-autoconf-adhoc-addr-model, then let the WG=20 > know what=20 > > these issues=A0are, and propose a solution before the deadline. The=20 > > Editors will certainly do their best to address the issues. > > > > Yes, I think there are serious, but fixable issues with=A0 > > draft-ietf-autoconf-adhoc-addr-model. Carlos and I wrote=20 > > draft-bernardos-autoconf-addressing-model to offer a different=20 > > perspective on these issues. Let me briefly summarize here=20 > our (or at=20 > > least: my) main > > objections: > > > > 1.=A0 Section 1, Introduction and section 3, Applicability Statement:=20 > > Nowhere in these sections is there any mention of the assumed=20 > > host/router model, i.e. whether applications (including management=20 > > clients)=A0can run on routers and if they can, make use of the=20 > > interfaces / addresses that are the subject of this draft=20 > OR whether=20 > > applications are assumed to always separated by at least=20 > one hop from=20 > > these interfaces. However, the ghost of=20 > > draft-clausen-manet-autoconf-recommendations-00 seems to be=20 > hovering=20 > > over this draft, so the latter is sort of implied. I would=20 > prefer that=20 > > this is spelled out, as it impacts the type of addresses=20 > that need to be configured, I might not necessarily agree,=20 > but al least it would be clearer. > > > > 2. Section 4, IP Subnet Prefix Configuration: > > > > - "Subnet prefix configuration on such interfaces must thus=20 > not make=20 > > any promises in terms of direct (one hop) IP connectivity to IP=20 > > addresses other than that of the interface itself." I find this=20 > > unconvincing. What promise would there be, really? Imagine a wired=20 > > Ethernet, with several nodes on it sharing a prefix.It=20 > would be rare=20 > > for the subnet to be fully populated, even on an IPv4 /24. So if I=20 > > dream up a host part / Interface ID, append it to the subnet prefix=20 > > and use that as a destination address, what would be my chances of=20 > > reaching another node? To be clear, I *agree* on the unique /=20 > > non-overlapping subnet prefix principle stated here, but=20 > find the motivation lacking. > > - It should say "non-overlapping", because "not the same"=20 > is not sufficient. > > > > 3. Section 6, Addressing Model > > > > - 6.1, IPv4 Model: Disagree that the prefix length should=20 > be /32. For=20 > > subnet prefixes to be unique / non-overlapping (see definition in=20 > > draft-bernardos-autoconf-addressing-model), is a necessary,=20 > but also=20 > > sufficient condition. I ran a MANET with 192.168.x.1/24 on=20 > the MANET=20 > > interfaces for many months. I fail to see what's wrong with that.=20 > > (Agree on what is said here about IPv LL's, by the way) > > > > - 6.2, IPv6 Model: Strongly disagree that the prefix length=20 > should be /128. > > Why paint ourselves into a corner like that? I would urge the draft=20 > > authors to have a look at RFC 5375, "IPv6 Unicast Address=20 > Assignment=20 > > Considerations". While this is "only" an informational RFC,=20 > I think it=20 > > is worth=A0reading. When in a hurry, you can skip Appendix A,=20 > but do not=20 > > skip Appendix B! Besides, there was discussion at the=A0 > IETF-75 Autoconf=20 > > session, see the minutes of that meeting: > > > > Dave Thaler > > - Consistency with RFC 4291 (in particular section 2.5.1). > > - Do you believe you have 64-bit interface identifiers that > > =A0 are unique within the subnet prefix? (the 64-bit part being > > =A0 a requirement for all unicast addresses that do not begin > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 with binary '000'). > > - If the answer to previous question is 'no', do you require > > =A0 prefixes to start with binary '000'? > > - If that is not the case either, shouldn't the document say > > =A0 that the addressing model will not be compliant with RFC4291? > > > > and: > > > > Dave Thaler > > - If you believe that you ARE compliant with RFC4291, the way to > > =A0 phrase it is, that you have a /64 subnet prefix, but it is only > > =A0 assigned to a single host. > > and later Thomas Narten wrote: > > > > Thomas Narten (Jabber) > > - IMO, /128 does not conflict with existing specs. We are=20 > blurring and=20 > > confusing > > =A0 various issues. You can have a /128 for on-link prefixes=20 > and still=20 > > have a > > =A0 64-bit Interface IDs. > > > > but he did not explain this any further. So who is right:=20 > Thaler or Narten? > > And what ithe prefix length of a ULA assigned to an=20 > interface? /64 as=20 > > far as I was able to figure out. > > > > - IPv6 link-locals: (Too?) Much has been said about this already. My > > opinion: LL's are there, and they may be pretty hard to get rid of.=20 > > I'm more concerned about existing platforms than about these new=20 > > ultra-resource-starved devices that have been subject of=20 > discusion on=20 > > the ML recently. You can choose to not use them for routing=20 > purposes=20 > > (in the narrow definition of routing as discovering network=20 > topology=20 > > and populating the RIB / FIB), but you may not be able to influence=20 > > whether they=A0are used for forwarding. I've seen neighbor=20 > solicitations=20 > > being sent with LL source addresses from MANET interfaces,=20 > that also=20 > > had global IPv6 addresses configured. > > > > - 3rd bullet under "known limitations": routing protocol=20 > packets are=20 > > sent hop-by-hop. They are intercepted. processed and possibly=20 > > regenerated at each router, so limitation does not apply. > > > > Oops, getting too close to deadline. This will have to do. > > > > Regards, > > Ronald > > > > > > > > o if you think that=A0draft-ietf-autoconf-adhoc-addr-model=A0is beyond=20 > > hope, let the WG know explicitly=A0how you suggest that we=20 > progress =A0at=20 > > this point > > -- > > =A0 considering the current timeline!! > > Cheers, > > Ryuji & Thomas > > > > This e-mail and its contents are subject to the DISCLAIMER at=20 > > http://www.tno.nl/disclaimer/email.html > > > > This e-mail and its contents are subject to the DISCLAIMER at=20 > > http://www.tno.nl/disclaimer/email.html > > > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www.ietf.org/mailman/listinfo/autoconf > > > > >=20 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 Thu Oct 29 09:55:17 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B1F33A6986 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 09:55:17 -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.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 SP-OciixtXN0 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 09:55:16 -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 5B1293A6836 for <autoconf@ietf.org>; Thu, 29 Oct 2009 09:55:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ovGiPkccc8ckH15jzk/zR/4Esr2vPGtIvi6YQgokDARgtZh9m+w/SQ7hZNAC0tPl; 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.148]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N3YHY-000558-1T; Thu, 29 Oct 2009 12:55:28 -0400 Message-ID: <4AE9C8FF.1000603@earthlink.net> Date: Thu, 29 Oct 2009 09:55:27 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Teco Boot <teco@inf-net.nl> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <9A410E5F-D117-4C41-940B-9B8A30120581@gmail.com> <4AE8A3EA.4020807@gmail.com> <4AE8A7CD.3030502@earthlink.net> <4AE8AFD4.4050706@gmail.com> <4AE8B5B9.5070204@earthlink.net> <4AE8B6EF.2070408@gmail.com> <4AE8CE75.2060607@earthlink.net> <25c114b90910290144m4fcd563dw23d3cd625f6adec0@mail.gmail.com> <4AE965A5.8030704@gmail.com> <25c114b90910290301w4323f50fob7e9fcfb438edb7@mail.gmail.com> <004201ca5884$9d56a8b0$d803fa10$@nl> In-Reply-To: <004201ca5884$9d56a8b0$d803fa10$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52e441fafd940c415318b5d4b55eaca3aa350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] issues with draft-baccelli address model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 16:55:17 -0000 Hello Teco, Teco Boot wrote: > > Again and again and again. Can you check what "practical" > means? We are chartered for it. Not for "all" or "general". > Since a good number of solutions have been proposed that do resolve the "general" network problem, your argument loses all of its force. If there were some indication that the general case was too hard, then you might have a complaint. So far the only hard problem seems to be how to avoid squabbling over whether link-locals are needed. I am not sure why the proponents of necessity are so adept at ignoring the solutions that do not need link-locals. It is not explainable by the existence of solutions that use link-locals, because such solutions are universally acknowledged to be useful in their realm of applicability. So why do link-locals insist on "their way come hell or high water"? > > See also Jari his last posting. This motivated me keep telling > what I am doing and what the problems are. This also makes very > clear we shall stop boil the ocean. > I agree with that. Regards, Charlie P. From jdean@itd.nrl.navy.mil Thu Oct 29 08:10:32 2009 Return-Path: <jdean@itd.nrl.navy.mil> 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 DB6BC3A697B for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 08:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 ur4O4HApRUcl for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 08:10:29 -0700 (PDT) Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by core3.amsl.com (Postfix) with ESMTP id C84BD3A6942 for <autoconf@ietf.org>; Thu, 29 Oct 2009 08:10:28 -0700 (PDT) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id n9TFAcU8028545 for <autoconf@ietf.org>; Thu, 29 Oct 2009 11:10:41 -0400 Received: (from bebe [132.250.93.61]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2009102911104008184 for <autoconf@ietf.org>; Thu, 29 Oct 2009 11:10:40 -0400 From: "Justin Dean" <jdean@itd.nrl.navy.mil> To: <autoconf@ietf.org> Date: Thu, 29 Oct 2009 11:08:30 -0400 Message-ID: <004501ca58a9$acb52370$061f6a50$@nrl.navy.mil> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0046_01CA5888.25A38370" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcpYqaykEdmPrRgKTgy2J3qhIZZUgA== Content-Language: en-us X-Mailman-Approved-At: Thu, 29 Oct 2009 10:08:58 -0700 Subject: [Autoconf] Regarding draft-ietf-autoconf-adhoc-addr-model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 15:10:33 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0046_01CA5888.25A38370 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Here are some of my comments for this autoconf draft. The use of the term "DAD" in section 6.1 is undefined before use. In both sections 6.1 and 6.2 the subnet suggestions are only valid when, there are no assumptions regarding connectivity between interfaces, as stated in section 4. Section 6 states "a link with undetermined connectivity properties" I would suggest using (i.e. no assumptions can be made regarding connectivity between interfaces) The only thing I would like to see more of is a discussion on or clarity on more advanced address configuration. A statement as simple as "information obtained regarding the connectivity properties of the link can be used to better select addressing/subnets if when available." This was hinted at the end of section 4 but let me wanting a little bit more. Overall I think this document is a step in the right direction and should be moved forward within the autoconf working group. Justin Dean ------=_NextPart_000_0046_01CA5888.25A38370 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)"> <style> <!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} pre {mso-style-priority:99; mso-style-link:"HTML Preformatted Char"; margin:0in; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Courier New";} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} span.HTMLPreformattedChar {mso-style-name:"HTML Preformatted Char"; mso-style-priority:99; mso-style-link:"HTML Preformatted"; font-family:"Courier New";} .MsoChpDefault {mso-style-type:export-only;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.Section1 {page:Section1;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal>Here are some of my comments for this autoconf = draft.<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>The use of the term “DAD” in section = 6.1 is undefined before use.<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>In both sections 6.1 and 6.2 the subnet suggestions = are only valid when, there are no assumptions regarding connectivity between = interfaces, as stated in section 4.  Section 6 states “a link with = undetermined connectivity properties” I would suggest using (i.e. no = assumptions can be made regarding connectivity between interfaces)<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>The only thing I would like to see more of is a = discussion on or clarity on more advanced address configuration.  A statement = as simple as “information obtained regarding the connectivity = properties of the link can be used to better select addressing/subnets if when = available.”  This was hinted at the end of section 4 but let me wanting a little bit = more.<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>Overall I think this document is a step in the = right direction and should be moved forward within the autoconf working = group.<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal>Justin Dean<o:p></o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> </div> </body> </html> ------=_NextPart_000_0046_01CA5888.25A38370-- From charles.perkins@earthlink.net Thu Oct 29 10:44:11 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09F873A6990 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 10:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.584 X-Spam-Level: X-Spam-Status: No, score=-1.584 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, 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 6ntEROkpcnAM for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 10:44:09 -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 685793A68AC for <autoconf@ietf.org>; Thu, 29 Oct 2009 10:44:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=heYAWztwZxfOVAMu0guj3im6zkPmRn2QjpfGi63bz3UVEJcOAymaNsRJ1eUxcug5; 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.148]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N3Z2t-0001jk-Hh; Thu, 29 Oct 2009 13:44:24 -0400 Message-ID: <4AE9D473.4070001@earthlink.net> Date: Thu, 29 Oct 2009 10:44:19 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Velt, R. (Ronald) in 't" <Ronald.intVelt@tno.nl> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <7877C5C0B5CC894AB26113CF06CF886302C7FC76@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <7877C5C0B5CC894AB26113CF06CF886302C7FC76@ms-dt01thalia.tsn.tno.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f526c3e705a84a69aa4ae04c4c5048ac071350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 17:44:11 -0000 Hello Ronald, As I understand, you and several other people feel that the current document is too negative regarding the use of link-local addresses. I have tried to create some text for the document which is a little more specific about the situations when link-local addresses can be useful, which are (tautologically) the same situations when leaf-level subnets can be useful. If this text is more acceptable, maybe the document authors can use it to replace Section 4: ===================================================== 4. IP Subnet Prefix Configuration Some network interfaces obey certain configuration directives which enable useful assumptions about address uniqueness, or otherwise enable communications onto physical media which exhibit certain useful characteristics enabling address aggregation. Links connecting computers with such network interfaces are likely to support link-local communications reaching multiple computers whose addresses can be aggregated into subnet ranges. For such links, the known characteristics of the link SHOULD be considered when configuring IP subnet prefixes, and the corresponding interfaces configured with the same subnet prefix. Such subnet prefix assignment is outside the scope of this document, since it depends on the specific characteristics of the physical links and network interfaces. If, on the other hand, the link to which an interface connects enables no such assumptions of connectivity to other interfaces, the only addresses which can be assumed "on link", are the address(es) of that interface itself. Subnet prefix configuration on such interfaces, SHOULD NOT make any promises in terms of direct (one hop) IP connectivity to IP addresses other than that of the interface itself. This suggests the following principle: o two distinct such interfaces in the network SHOULD NOT be configured with the same subnet prefix. In all cases, when L2 communication is enabled between a pair of interfaces, IP packet exchange is enabled regardless of the IP subnet configuration on each of these interfaces. ================================================ I'd also be willing to go through the rest of the document text making similar revisions. Another alternative would be to strip link-locals out of the document entirely, or put all such discussion in an Appendix. This would, however, make the document seem more mysterious and arbitrary, since the fundamental reasoning and understanding leading to the recommendations would be absent. I also used "SHOULD" and "SHOULD NOT" instead of "MUSTs", since it seems to me that systems can clearly be built that do not adhere to the recommendations. Nevertheless, in the absence of system-specific assumptions, the general recommendations are expected to be followed. This last sentence is merely a regurgitation of the definition of "SHOULD". Regards, Charlie P. Velt, R. (Ronald) in 't wrote: > Thomas, Ryuji, WG members, > > My vote below: > > ------------------------------------------------------------------------ > *From:* autoconf-bounces@ietf.org > [mailto:autoconf-bounces@ietf.org] *On Behalf Of *Thomas Heide Clausen > *Sent:* donderdag 22 oktober 2009 1:50 > *To:* autoconf@ietf.org > *Subject:* [Autoconf] On WG progress and > draft-ietf-autoconf-adhoc-addr-model > > All, > > It appeared to the chairs that the comments raised at the > Stockholm IETF, as well as on the list subsequently, concerning > the document: > > http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model > > had been addressed fully by the editors, and to the WGs > satisfaction - at least, there were no issue raised to the > latter/latest version hereof. The chairs therefore found it a good > idea to move the document forward as a WG document, and progress > this document as such. We therefore approved for publication: > > http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model > > We (the chairs) still believe that this is the proper approach in > order to make progress for the WG. > > Do note that the WG is 7 months past the milestone for initial > document submission, and 1 month past the milestone for having > progressed the document to the IESG and/or closed up shop! And, > there has been no discussions (in meetings or on this list) on > alternative candidate documents for the work item which [autoconf] > is chartered to accomplish. > > To put it bluntly, this WG is far far behind schedule and this > document seemed, and still seems, by virtue of having been widely > discussed and agreed upon, as the best shot at making progress for > this WG. > > That said, we (and, this we is also the chairs) will take this > opportunity to ask the WGs opinion on how to progress. If you have > any opinion, please let it be known to the WG (via this mailing > list) before 29/10/09 (i.e. Thursday next week) at noon > CET. Please be specific and constructive, i.e., pick one of: > > o > if you think that the WG should proceed > with draft-ietf-autoconf-adhoc-addr-model > as a baseline, say so! > > o > if you think there're cardinal (but fixable) issues missing or > wrong with > draft-ietf-autoconf-adhoc-addr-model, then let the WG know what these > issues are, and propose a solution before the deadline. The Editors > will certainly do their best to address the issues. > > Yes, I think there are serious, but fixable issues > with draft-ietf-autoconf-adhoc-addr-model. Carlos and I wrote > draft-bernardos-autoconf-addressing-model to offer a different > perspective on > these issues. Let me briefly summarize here our (or at least: my) main > objections: > > 1. Section > 1, Introduction and section 3, Applicability Statement: Nowhere in these > sections is there any mention of the assumed host/router model, i.e. > whether > applications (including management clients) can run on routers and if > they > can, make use of the interfaces / addresses that are the subject of > this draft > OR whether applications are assumed to always separated by at least > one hop from > these interfaces. However, the ghost of > draft-clausen-manet-autoconf-recommendations-00 seems to > be hovering over this draft, so the latter is > sort of implied. I would prefer that this is spelled out, as it > impacts the type > of addresses that need to be configured, I might not necessarily > agree, but al > least it would be clearer. > > 2. Section 4, IP > Subnet Prefix Configuration: > > - "Subnet prefix > configuration on such interfaces must thus not make any promises in > terms of > direct (one hop) IP connectivity to IP addresses other than that of the > interface itself." I find this unconvincing. What promise would there be, > really? Imagine a wired Ethernet, with several nodes on it sharing a > prefix.It > would be rare for the subnet to be fully populated, even on an IPv4 > /24. So if I > dream up a host part / Interface ID, append it to the subnet prefix > and use that > as a destination address, what would be my chances of reaching another > node? To > be clear, I *agree* on the unique / non-overlapping subnet prefix > principle > stated here, but find the motivation lacking. > - It should say > "non-overlapping", because "not the same" is not > sufficient. > > 3. Section 6, > Addressing Model > > - 6.1, IPv4 > Model: Disagree that the prefix length should be /32. For subnet > prefixes to be > unique / non-overlapping (see definition in > draft-bernardos-autoconf-addressing-model), is a necessary, but also > sufficient > condition. I ran a MANET with 192.168.x.1/24 on the MANET interfaces > for many > months. I fail to see what's wrong with that. (Agree on what is said > here about > IPv LL's, by the way) > > - 6.2, IPv6 > Model: Strongly disagree that the prefix length should be /128. Why paint > ourselves into a corner like that? I would urge the draft authors to > have a look > at RFC 5375, "IPv6 Unicast Address Assignment Considerations". While > this is > "only" an informational RFC, I think it is worth reading. When in a > hurry, > you can skip Appendix A, but do not skip Appendix B! Besides, there was > discussion at the IETF-75 Autoconf session, see the minutes of that > meeting: > > Dave Thaler > - Consistency > with RFC 4291 (in particular section 2.5.1). > - Do you believe you have > 64-bit interface identifiers that > are unique within the subnet > prefix? (the 64-bit part being > a requirement for all unicast > addresses that do not > begin > > with binary '000'). > - If the answer to previous question is 'no', do you > require > prefixes to start with binary '000'? > - If that is not > the case either, shouldn't the document say > that the addressing > model will not be compliant with RFC4291? > > and: > > Dave Thaler > - If you > believe that you ARE compliant with RFC4291, the way to > phrase it > is, that you have a /64 subnet prefix, but it is only > assigned to a > single host. > and later > Thomas Narten wrote: > > Thomas Narten > (Jabber) > - IMO, /128 does not conflict with existing specs. We are blurring > and confusing > various issues. You can have a /128 for on-link > prefixes and still have a > 64-bit Interface > IDs. > > but he did > not explain this any further. So who is right: Thaler or Narten? And > what ithe > prefix length of a ULA assigned to an interface? /64 as far as I was > able to > figure out. > > - IPv6 > link-locals: (Too?) Much has been said about this already. My opinion: > LL's are > there, and they may be pretty hard to get rid of. I'm more concerned > about > existing platforms than about these new ultra-resource-starved devices > that have > been subject of discusion on the ML recently. You can choose to not > use them for > routing purposes (in the narrow definition of routing as discovering > network > topology and populating the RIB / FIB), but you may not be able to > influence > whether they are used for forwarding. I've seen neighbor solicitations > being sent with LL source addresses from MANET interfaces, that also > had global > IPv6 addresses configured. > > - 3rd bullet > under "known limitations": routing protocol packets are sent > hop-by-hop. They > are intercepted. processed and possibly regenerated at each router, so > limitation does not apply. > > Oops, getting too > close to deadline. This will have to do. > > Regards, > Ronald > > > > o > if you think that draft-ietf-autoconf-adhoc-addr-model is beyond > hope, > let the WG know explicitly how you suggest that we progress at > this point -- > considering the current timeline!! > > Cheers, > > Ryuji & Thomas > > 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 > From alexandru.petrescu@gmail.com Thu Oct 29 10:58:20 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 72A3C3A67F4 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 10:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=0.152, 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 V308oD2uzOPi for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 10:58:19 -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 549F43A67E2 for <autoconf@ietf.org>; Thu, 29 Oct 2009 10:58:18 -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 n9THwWR3029259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Oct 2009 18:58:32 +0100 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 n9THwWd8005976; Thu, 29 Oct 2009 18:58:32 +0100 (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 n9THwWHT006280; Thu, 29 Oct 2009 18:58:32 +0100 Message-ID: <4AE9D7C8.60707@gmail.com> Date: Thu, 29 Oct 2009 18:58:32 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" <charles.perkins@earthlink.net> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <9A410E5F-D117-4C41-940B-9B8A30120581@gmail.com> <4AE8A3EA.4020807@gmail.com> <4AE8A7CD.3030502@earthlink.net> <4AE8AFD4.4050706@gmail.com> <4AE8B5B9.5070204@earthlink.net> <4AE8B6EF.2070408@gmail.com> <4AE8CE75.2060607@earthlink.net> <25c114b90910290144m4fcd563dw23d3cd625f6adec0@mail.gmail.com> <4AE965A5.8030704@gmail.com> <25c114b90910290301w4323f50fob7e9fcfb438edb7@mail.gmail.com> <004201ca5884$9d56a8b0$d803fa10$@nl> <4AE9C8FF.1000603@earthlink.net> In-Reply-To: <4AE9C8FF.1000603@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] issues with draft-baccelli address model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 17:58:20 -0000 Charles E. Perkins a écrit : [...] > So far the only hard problem seems to be how to avoid squabbling over > whether link-locals are needed. > > I am not sure why the proponents of necessity are so adept at > ignoring the solutions that do not need link-locals. It's very simple why: I have a prototype which involves protocol extensions (RA) only on the parts of the System which use exclusively link-locals addresses. You forbidding link-local addresses equates with forbidding my protocol extensions on the core of my prototype, makes all break. (the parts of the System which use global addresses are not affected by my prototype. They are also essential and core, but to some other people.) > It is not explainable by the existence of solutions that use > link-locals, because such solutions are universally acknowledged to > be useful in their realm of applicability. Is this formulation ok, or an "only" missing somewhere? If you keep that formulation as is - I agree with it! > So why do link-locals insist on "their way come hell or high water"? BEcause I don't want my prototype discarded by an illogical sense of forbidding LLs. Alex > >> >> See also Jari his last posting. This motivated me keep telling what >> I am doing and what the problems are. This also makes very clear >> we shall stop boil the ocean. >> > > I agree with that. > > Regards, Charlie P. > > _______________________________________________ Autoconf mailing list > Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf > From charles.perkins@earthlink.net Thu Oct 29 11:07:01 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 176A83A685D for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 11:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[AWL=0.101, 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 9TLp9vujjr4k for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 11:07:00 -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 2E1653A67E2 for <autoconf@ietf.org>; Thu, 29 Oct 2009 11:07:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ltqxwyHGdHlqBjl/oqp2R1EDG8aixLRbz+BqXUWGlmRqQVCmCMJTChQ9Talxib8F; 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.148]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N3ZP0-0008MO-85; Thu, 29 Oct 2009 14:07:14 -0400 Message-ID: <4AE9D9D0.9020405@earthlink.net> Date: Thu, 29 Oct 2009 11:07:12 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <9A410E5F-D117-4C41-940B-9B8A30120581@gmail.com> <4AE8A3EA.4020807@gmail.com> <4AE8A7CD.3030502@earthlink.net> <4AE8AFD4.4050706@gmail.com> <4AE8B5B9.5070204@earthlink.net> <4AE8B6EF.2070408@gmail.com> <4AE8CE75.2060607@earthlink.net> <25c114b90910290144m4fcd563dw23d3cd625f6adec0@mail.gmail.com> <4AE965A5.8030704@gmail.com> <25c114b90910290301w4323f50fob7e9fcfb438edb7@mail.gmail.com> <004201ca5884$9d56a8b0$d803fa10$@nl> <4AE9C8FF.1000603@earthlink.net> <4AE9D7C8.60707@gmail.com> In-Reply-To: <4AE9D7C8.60707@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52fa24180343e6d29c2ccc009e86c23428350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] issues with draft-baccelli address model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 18:07:01 -0000 Hello Alex, I don't mind discussing with you. But I really don't like having to point out your false statements so often. Alexandru Petrescu wrote: > Charles E. Perkins a écrit : > [...] >> So far the only hard problem seems to be how to avoid squabbling over >> whether link-locals are needed. >> >> I am not sure why the proponents of necessity are so adept at >> ignoring the solutions that do not need link-locals. > > It's very simple why: I have a prototype which involves protocol > extensions (RA) only on the parts of the System which use exclusively > link-locals addresses. You forbidding link-local addresses equates with > forbidding my protocol extensions on the core of my prototype, makes > all break. I _do not_ forbid link-local addresses. I'm not even one of the document authors, and I didn't create that language. But the document does not forbid link-locals either. So how many times do you persist in making this false statement, and, worse, basing your repeated, iterated, verbose, relentless, and seemingly misguided objections based on the false notion that link-locals are forbidden? > > >> It is not explainable by the existence of solutions that use >> link-locals, because such solutions are universally acknowledged to >> be useful in their realm of applicability. > > Is this formulation ok, or an "only" missing somewhere? ...???... > > If you keep that formulation as is - I agree with it! > >> So why do link-locals insist on "their way come hell or high water"? > > BEcause I don't want my prototype discarded by an illogical sense of > forbidding LLs. And in what universe does that prohibition reside? Regards, Charlie P. From alexandru.petrescu@gmail.com Thu Oct 29 11:21:40 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 9C9A33A6835 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 11:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=0.151, 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 KEqToZuSBKDM for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 11:21:39 -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 A0B813A67A8 for <autoconf@ietf.org>; Thu, 29 Oct 2009 11:21:39 -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 n9TILqtH001605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Oct 2009 19:21:52 +0100 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 n9TILqkx008492; Thu, 29 Oct 2009 19:21:52 +0100 (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 n9TILpsW010682; Thu, 29 Oct 2009 19:21:52 +0100 Message-ID: <4AE9DD3F.2090506@gmail.com> Date: Thu, 29 Oct 2009 19:21:51 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" <charles.perkins@earthlink.net> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <9A410E5F-D117-4C41-940B-9B8A30120581@gmail.com> <4AE8A3EA.4020807@gmail.com> <4AE8A7CD.3030502@earthlink.net> <4AE8AFD4.4050706@gmail.com> <4AE8B5B9.5070204@earthlink.net> <4AE8B6EF.2070408@gmail.com> <4AE8CE75.2060607@earthlink.net> <25c114b90910290144m4fcd563dw23d3cd625f6adec0@mail.gmail.com> <4AE965A5.8030704@gmail.com> <25c114b90910290301w4323f50fob7e9fcfb438edb7@mail.gmail.com> <004201ca5884$9d56a8b0$d803fa10$@nl> <4AE9C8FF.1000603@earthlink.net> <4AE9D7C8.60707@gmail.com> <4AE9D9D0.9020405@earthlink.net> In-Reply-To: <4AE9D9D0.9020405@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] issues with draft-baccelli address model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 18:21:40 -0000 Charles E. Perkins a écrit : [...] > Alexandru Petrescu wrote: >> Charles E. Perkins a écrit : >> [...] >>> So far the only hard problem seems to be how to avoid squabbling over >>> whether link-locals are needed. >>> >>> I am not sure why the proponents of necessity are so adept at >>> ignoring the solutions that do not need link-locals. >> >> It's very simple why: I have a prototype which involves protocol >> extensions (RA) only on the parts of the System which use exclusively >> link-locals addresses. You forbidding link-local addresses equates with >> forbidding my protocol extensions on the core of my prototype, makes >> all break. > > I _do not_ forbid link-local addresses. I'm not even one of the > document authors, and I didn't create that language. > > But the document does not forbid link-locals either. Well it does, here is how: draft-baccelli says: > Note that while link-local addresses are assumed to be "on link", the > utility of link-local addresses is limited as described in Section 6. The word "limited" strikes. draft-baccelli says: > o A subnet prefix configured on this interface should be of length > /128. The link-local prefix of IPv6 LLs is fe80::/10, and not /128. draft-baccelli says: > o Any [IPv4] subnet prefix configured on this interface should be of length > /32. Yet the prefix of the IPv4 LL is 169.254/16, and not a /32. draft-baccelli says: > Note that the use of IPv4 link-local addresses [RFC3927] in this > context should be discouraged for most applications "Discouraged" means discouraged. And which "context"? The word "context" appears precisely once in the draft. These 4 things make me think the draft-baccelli co-authors and Editors want to forbid the LLs. How do we fix these 4 things such that I don't misunderstand them again? Alex From charles.perkins@earthlink.net Thu Oct 29 11:23:58 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B645F3A694A for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 11:23:58 -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 dTCcqqzL1xFW for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 11:23:58 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id D356C3A67A8 for <autoconf@ietf.org>; Thu, 29 Oct 2009 11:23:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Yd3Aqs2nKXX1uXhWg6Ny0dSD7+2N4lmZBWDN4zleu51oqWohZ9RhFHRDjRx60biJ; 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.148]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N3ZfP-0004Xz-1e; Thu, 29 Oct 2009 14:24:11 -0400 Message-ID: <4AE9DDC9.1060206@earthlink.net> Date: Thu, 29 Oct 2009 11:24:09 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <9A410E5F-D117-4C41-940B-9B8A30120581@gmail.com> <4AE8A3EA.4020807@gmail.com> <4AE8A7CD.3030502@earthlink.net> <4AE8AFD4.4050706@gmail.com> <4AE8B5B9.5070204@earthlink.net> <4AE8B6EF.2070408@gmail.com> <4AE8CE75.2060607@earthlink.net> <25c114b90910290144m4fcd563dw23d3cd625f6adec0@mail.gmail.com> <4AE965A5.8030704@gmail.com> <25c114b90910290301w4323f50fob7e9fcfb438edb7@mail.gmail.com> <004201ca5884$9d56a8b0$d803fa10$@nl> <4AE9C8FF.1000603@earthlink.net> <4AE9D7C8.60707@gmail.com> <4AE9D9D0.9020405@earthlink.net> <4AE9DD3F.2090506@gmail.com> In-Reply-To: <4AE9DD3F.2090506@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f523fd513a7559d590ee3f185f0ebec5066350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] issues with draft-baccelli address model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 18:23:58 -0000 Hello Alex, What do you think about my suggestion for revising Section 4? I'll wait to answer your points below until I hear back on that. Regards, Charlie P. Alexandru Petrescu wrote: > Charles E. Perkins a écrit : > [...] >> Alexandru Petrescu wrote: >>> Charles E. Perkins a écrit : >>> [...] >>>> So far the only hard problem seems to be how to avoid squabbling over >>>> whether link-locals are needed. >>>> >>>> I am not sure why the proponents of necessity are so adept at >>>> ignoring the solutions that do not need link-locals. >>> >>> It's very simple why: I have a prototype which involves protocol >>> extensions (RA) only on the parts of the System which use exclusively >>> link-locals addresses. You forbidding link-local addresses equates >>> with >>> forbidding my protocol extensions on the core of my prototype, makes >>> all break. >> >> I _do not_ forbid link-local addresses. I'm not even one of the >> document authors, and I didn't create that language. >> >> But the document does not forbid link-locals either. > > Well it does, here is how: > > draft-baccelli says: >> Note that while link-local addresses are assumed to be "on link", the >> utility of link-local addresses is limited as described in Section 6. > > The word "limited" strikes. > > draft-baccelli says: >> o A subnet prefix configured on this interface should be of length >> /128. > > The link-local prefix of IPv6 LLs is fe80::/10, and not /128. > > draft-baccelli says: >> o Any [IPv4] subnet prefix configured on this interface should be >> of length >> /32. > > Yet the prefix of the IPv4 LL is 169.254/16, and not a /32. > > draft-baccelli says: >> Note that the use of IPv4 link-local addresses [RFC3927] in this >> context should be discouraged for most applications > > "Discouraged" means discouraged. And which "context"? The word > "context" appears precisely once in the draft. > > These 4 things make me think the draft-baccelli co-authors and Editors > want to forbid the LLs. > > How do we fix these 4 things such that I don't misunderstand them again? > > Alex > > > > From sratliff@cisco.com Thu Oct 29 11:25:07 2009 Return-Path: <sratliff@cisco.com> 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 AE4D93A67A8 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 11:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.767 X-Spam-Level: X-Spam-Status: No, score=-3.767 tagged_above=-999 required=5 tests=[AWL=0.765, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 z5kK7ABABUL3 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 11:25:06 -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 8F7143A683C for <autoconf@ietf.org>; Thu, 29 Oct 2009 11:25:05 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAGN66UqtJV2c/2dsb2JhbACbLKwqmBiEPQQ X-IronPort-AV: E=Sophos;i="4.44,647,1249257600"; d="scan'208";a="65581923" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-2.cisco.com with ESMTP; 29 Oct 2009 18:25:20 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id n9TIPJtC005434; Thu, 29 Oct 2009 18:25:20 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 14:25:20 -0400 Received: from 64.102.194.239 ([64.102.194.239]) by xmb-rtp-208.amer.cisco.com ([64.102.31.43]) with Microsoft Exchange Server HTTP-DAV ; Thu, 29 Oct 2009 18:25:19 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Thu, 29 Oct 2009 14:25:18 -0400 From: sratliff <sratliff@cisco.com> To: "Charles E. Perkins" <charles.perkins@earthlink.net>, Alexandru Petrescu <alexandru.petrescu@gmail.com> Message-ID: <C70F564E.190D%sratliff@cisco.com> Thread-Topic: [Autoconf] issues with draft-baccelli address model Thread-Index: AcpYxSqZpXYiIamF302tcswjAPiE0g== In-Reply-To: <4AE9D9D0.9020405@earthlink.net> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 29 Oct 2009 18:25:20.0009 (UTC) FILETIME=[2BCC4790:01CA58C5] Cc: autoconf@ietf.org Subject: Re: [Autoconf] issues with draft-baccelli address model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 18:25:07 -0000 Charlie,=20 Absolutely correct. I agree 100%. And this is why I see this whole discussion as a tempest in a teapot. "discourage" !=3D "cannot" No one supporting the Bacelli-Townsley draft has said you can't use link-local addresses. I support the Bacelli-Townsley draft, and most of my deployments use link-local addresses. My deployments will continue to use link-local addresses. But I do see that there are deployments where use of link-local addresses is either problematic, or impossible. So I understand the draft's language concerning "discouraging" their use. But the draft DOES NOT say they CANNOT be used. That's one of the reasons I support the draft. Regards, Stan On 10/29/09 2:07 PM, "Charles E. Perkins" <charles.perkins@earthlink.net> wrote: >=20 > Hello Alex, >=20 > I don't mind discussing with you. But I really don't > like having to point out your false statements so > often. >=20 > Alexandru Petrescu wrote: >> Charles E. Perkins a =E9crit : >> [...] >>> So far the only hard problem seems to be how to avoid squabbling over >>> whether link-locals are needed. >>>=20 >>> I am not sure why the proponents of necessity are so adept at >>> ignoring the solutions that do not need link-locals. >>=20 >> It's very simple why: I have a prototype which involves protocol >> extensions (RA) only on the parts of the System which use exclusively >> link-locals addresses. You forbidding link-local addresses equates with >> forbidding my protocol extensions on the core of my prototype, makes >> all break. >=20 > I _do not_ forbid link-local addresses. I'm not even one of the > document authors, and I didn't create that language. >=20 > But the document does not forbid link-locals either. >=20 > So how many times do you persist in making this false > statement, and, worse, basing your repeated, iterated, > verbose, relentless, and seemingly misguided objections > based on the false notion that link-locals are forbidden? >=20 >>=20 >>=20 >>> It is not explainable by the existence of solutions that use >>> link-locals, because such solutions are universally acknowledged to >>> be useful in their realm of applicability. >>=20 >> Is this formulation ok, or an "only" missing somewhere? >=20 > ...???... >=20 >>=20 >> If you keep that formulation as is - I agree with it! >>=20 >>> So why do link-locals insist on "their way come hell or high water"? >>=20 >> BEcause I don't want my prototype discarded by an illogical sense of >> forbidding LLs. >=20 > And in what universe does that prohibition reside? >=20 > Regards, > Charlie P. >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From sratliff@cisco.com Thu Oct 29 11:30:41 2009 Return-Path: <sratliff@cisco.com> 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 E128D3A6A14 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 11:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.863 X-Spam-Level: X-Spam-Status: No, score=-3.863 tagged_above=-999 required=5 tests=[AWL=0.669, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 B0ghoh2BAcg6 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 11:30:40 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id B84943A6842 for <autoconf@ietf.org>; Thu, 29 Oct 2009 11:30:40 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEALt86UqrRN+K/2dsb2JhbACbLKwlmByEPQSBYg X-IronPort-AV: E=Sophos;i="4.44,647,1249257600"; d="scan'208";a="219434465" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 29 Oct 2009 18:30:57 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n9TIUuhW017166; Thu, 29 Oct 2009 18:30:57 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 14:30:56 -0400 Received: from 64.102.194.239 ([64.102.194.239]) by xmb-rtp-208.amer.cisco.com ([64.102.31.43]) with Microsoft Exchange Server HTTP-DAV ; Thu, 29 Oct 2009 18:30:56 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Thu, 29 Oct 2009 14:30:55 -0400 From: sratliff <sratliff@cisco.com> To: Alexandru Petrescu <alexandru.petrescu@gmail.com>, "Charles E. Perkins" <charles.perkins@earthlink.net> Message-ID: <C70F579F.1912%sratliff@cisco.com> Thread-Topic: [Autoconf] issues with draft-baccelli address model Thread-Index: AcpYxfN3YWSv5XvHf0+Mnr8I08OYvQ== In-Reply-To: <4AE9DD3F.2090506@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 29 Oct 2009 18:30:56.0891 (UTC) FILETIME=[F49864B0:01CA58C5] Cc: autoconf@ietf.org Subject: Re: [Autoconf] issues with draft-baccelli address model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 18:30:42 -0000 On 10/29/09 2:21 PM, "Alexandru Petrescu" <alexandru.petrescu@gmail.com> wrote: > Charles E. Perkins a =E9crit : > [...] >> Alexandru Petrescu wrote: >>> Charles E. Perkins a =E9crit : >>> [...] >>>> So far the only hard problem seems to be how to avoid squabbling over >>>> whether link-locals are needed. >>>>=20 >>>> I am not sure why the proponents of necessity are so adept at >>>> ignoring the solutions that do not need link-locals. >>>=20 >>> It's very simple why: I have a prototype which involves protocol >>> extensions (RA) only on the parts of the System which use exclusively >>> link-locals addresses. You forbidding link-local addresses equates wit= h >>> forbidding my protocol extensions on the core of my prototype, makes >>> all break. >>=20 >> I _do not_ forbid link-local addresses. I'm not even one of the >> document authors, and I didn't create that language. >>=20 >> But the document does not forbid link-locals either. >=20 > Well it does, here is how: >=20 > draft-baccelli says: >> Note that while link-local addresses are assumed to be "on link", the >> utility of link-local addresses is limited as described in Section 6. >=20 > The word "limited" strikes. Nonsense. "utility.. is limited" is not the same as "must not be used". >=20 > draft-baccelli says: >> o A subnet prefix configured on this interface should be of length >> /128. >=20 > The link-local prefix of IPv6 LLs is fe80::/10, and not /128. The key word in that sentence is SHOULD. It does not say MUST. >=20 > draft-baccelli says: >> o Any [IPv4] subnet prefix configured on this interface should be of >> length >> /32. >=20 > Yet the prefix of the IPv4 LL is 169.254/16, and not a /32. >=20 Again, the sentence says SHOULD. Not MUST. > draft-baccelli says: >> Note that the use of IPv4 link-local addresses [RFC3927] in this >> context should be discouraged for most applications >=20 > "Discouraged" means discouraged. And which "context"? The word > "context" appears precisely once in the draft. >=20 Precisely. "Discouraged" means discouraged. It doesn't mean "cannot". And again, the sentence contains the word SHOULD. It does not say MUST. Regards, Stan > These 4 things make me think the draft-baccelli co-authors and Editors > want to forbid the LLs. >=20 > How do we fix these 4 things such that I don't misunderstand them again? >=20 > Alex >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From alexandru.petrescu@gmail.com Thu Oct 29 12:23:25 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 231393A6949 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 12:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.795 X-Spam-Level: X-Spam-Status: No, score=-0.795 tagged_above=-999 required=5 tests=[AWL=-0.846, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_TOOL=2.3] 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 4Kj8OiDy+IvS for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 12:23:24 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 0CA773A6867 for <autoconf@ietf.org>; Thu, 29 Oct 2009 12:23:22 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 27E2ED481F6; Thu, 29 Oct 2009 20:23:33 +0100 (CET) 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 2238BD481E0; Thu, 29 Oct 2009 20:23:30 +0100 (CET) Message-ID: <4AE9EBAE.2000909@gmail.com> Date: Thu, 29 Oct 2009 20:23:26 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: sratliff <sratliff@cisco.com> References: <C70F579F.1912%sratliff@cisco.com> In-Reply-To: <C70F579F.1912%sratliff@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091029-0, 29/10/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] issues with draft-baccelli address model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 19:23:25 -0000 sratliff a écrit : [...] >> draft-baccelli says: >>> Note that while link-local addresses are assumed to be "on link", >>> the utility of link-local addresses is limited as described in >>> Section 6. >> The word "limited" strikes. > > Nonsense. "utility.. is limited" is not the same as "must not be > used". Would you agree to say "the utility of /128 prefixes is limited"? >> draft-baccelli says: >>> o A subnet prefix configured on this interface should be of >>> length /128. >> The link-local prefix of IPv6 LLs is fe80::/10, and not /128. > > The key word in that sentence is SHOULD. It does not say MUST. Well, LLs are a SHOULD on many interfaces. A SHOULD and and a SHOULD NOT could give a "MAY": "a /128 prefix on this interface MAY be /128". (and I invite implementers to do it and report back problems thank you). >> draft-baccelli says: >>> o Any [IPv4] subnet prefix configured on this interface should >>> be of length /32. >> Yet the prefix of the IPv4 LL is 169.254/16, and not a /32. >> > > Again, the sentence says SHOULD. Not MUST. Again, a MAY would be a better fit. >> draft-baccelli says: >>> Note that the use of IPv4 link-local addresses [RFC3927] in this >>> context should be discouraged for most applications >> "Discouraged" means discouraged. And which "context"? The word >> "context" appears precisely once in the draft. >> > > Precisely. "Discouraged" means discouraged. It doesn't mean "cannot". > And again, the sentence contains the word SHOULD. It does not say > MUST. I believe that "dicouraged" fits better the use of host-based routes (the "/128" prefix recommendation) for a variety of reasons, making them limited use too: (1) it doesn't scale to large domain, (2) can't connect to the Internet, (3) consumes more ressources than /64-or-shorter prefixes (cycles: instead of average 64 bit comparisons you use a sure 128 bit comparisons, memory: instead of one entry covering several destinations you use an entry for each destination in each router). It sounds as we have it completely reverse, and "MAY" may solve it. Alex From sratliff@cisco.com Thu Oct 29 12:49:35 2009 Return-Path: <sratliff@cisco.com> 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 5BD3B3A68FF for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 12:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.787 X-Spam-Level: X-Spam-Status: No, score=-2.787 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_00=-2.599, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 O-eXkwD6dYk2 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 12:49:34 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 811B53A6A0D for <autoconf@ietf.org>; Thu, 29 Oct 2009 12:49:32 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0EAD+P6UqtJV2d/2dsb2JhbACJVZFXrDWYFIQ9BIFi X-IronPort-AV: E=Sophos;i="4.44,648,1249257600"; d="scan'208";a="65554431" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-1.cisco.com with ESMTP; 29 Oct 2009 19:49:48 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id n9TJnlLJ025682; Thu, 29 Oct 2009 19:49:48 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 15:49:47 -0400 Received: from 64.102.194.239 ([64.102.194.239]) by xmb-rtp-208.amer.cisco.com ([64.102.31.43]) with Microsoft Exchange Server HTTP-DAV ; Thu, 29 Oct 2009 19:49:47 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Thu, 29 Oct 2009 15:49:46 -0400 From: sratliff <sratliff@cisco.com> To: Alexandru Petrescu <alexandru.petrescu@gmail.com> Message-ID: <C70F6A1A.191D%sratliff@cisco.com> Thread-Topic: [Autoconf] issues with draft-baccelli address model Thread-Index: AcpY0PddiUclkgNjEESyqsGD2qe/2g== In-Reply-To: <4AE9EBAE.2000909@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 29 Oct 2009 19:49:47.0521 (UTC) FILETIME=[F8453F10:01CA58D0] Cc: autoconf@ietf.org Subject: Re: [Autoconf] issues with draft-baccelli address model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 19:49:35 -0000 On 10/29/09 3:23 PM, "Alexandru Petrescu" <alexandru.petrescu@gmail.com> wrote: > sratliff a =E9crit : > [...] >>> draft-baccelli says: >>>> Note that while link-local addresses are assumed to be "on link", >>>> the utility of link-local addresses is limited as described in >>>> Section 6. >>> The word "limited" strikes. >>=20 >> Nonsense. "utility.. is limited" is not the same as "must not be >> used". >=20 > Would you agree to say "the utility of /128 prefixes is limited"? >=20 >>> draft-baccelli says: >>>> o A subnet prefix configured on this interface should be of >>>> length /128. >>> The link-local prefix of IPv6 LLs is fe80::/10, and not /128. >>=20 >> The key word in that sentence is SHOULD. It does not say MUST. >=20 > Well, LLs are a SHOULD on many interfaces. A SHOULD and and a SHOULD > NOT could give a "MAY": "a /128 prefix on this interface MAY be /128". > (and I invite implementers to do it and report back problems thank you). >=20 "a SHOULD and a SHOULD NOT could give a MAY"....... I don't even know how t= o begin to address this. I'm comfortable with the current state of "SHOULD/MAY/MUST" that's in the current document. As I said earlier, I think all of this is a tempest in a teapot.=20 Stan >>> draft-baccelli says: >>>> o Any [IPv4] subnet prefix configured on this interface should >>>> be of length /32. >>> Yet the prefix of the IPv4 LL is 169.254/16, and not a /32. >>>=20 >>=20 >> Again, the sentence says SHOULD. Not MUST. >=20 > Again, a MAY would be a better fit. >=20 >>> draft-baccelli says: >>>> Note that the use of IPv4 link-local addresses [RFC3927] in this >>>> context should be discouraged for most applications >>> "Discouraged" means discouraged. And which "context"? The word >>> "context" appears precisely once in the draft. >>>=20 >>=20 >> Precisely. "Discouraged" means discouraged. It doesn't mean "cannot". >> And again, the sentence contains the word SHOULD. It does not say >> MUST. >=20 > I believe that "dicouraged" fits better the use of host-based routes > (the "/128" prefix recommendation) for a variety of reasons, making them > limited use too: (1) it doesn't scale to large domain, (2) can't connect > to the Internet, (3) consumes more ressources than /64-or-shorter > prefixes (cycles: instead of average 64 bit comparisons you use a sure > 128 bit comparisons, memory: instead of one entry covering several > destinations you use an entry for each destination in each router). >=20 > It sounds as we have it completely reverse, and "MAY" may solve it. >=20 > Alex >=20 From alexandru.petrescu@gmail.com Thu Oct 29 12:58:19 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 32D533A6A19 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 12:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=0.321, 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 onnGuzL5-Mt4 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 12:58:18 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id EE09C3A69A9 for <autoconf@ietf.org>; Thu, 29 Oct 2009 12:58:16 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 2ABCFD48174; Thu, 29 Oct 2009 20:58:28 +0100 (CET) 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 BD521D48098; Thu, 29 Oct 2009 20:58:25 +0100 (CET) Message-ID: <4AE9F3DB.9030802@gmail.com> Date: Thu, 29 Oct 2009 20:58:19 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" <charles.perkins@earthlink.net> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <7877C5C0B5CC894AB26113CF06CF886302C7FC76@ms-dt01thalia.tsn.tno.nl> <4AE9D473.4070001@earthlink.net> In-Reply-To: <4AE9D473.4070001@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091029-0, 29/10/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 19:58:19 -0000 Charles E. Perkins a écrit : > > Hello Ronald, > > As I understand, you and several other people feel that the current > document is too negative regarding the use of link-local addresses. I > have tried to create some text for the document which is a little > more specific about the situations when link-local addresses can be > useful, which are (tautologically) the same situations when > leaf-level subnets can be useful. > > If this text is more acceptable, maybe the document authors can use > it to replace Section 4: > > ===================================================== > > 4. IP Subnet Prefix Configuration > > Some network interfaces obey certain configuration directives which > enable useful assumptions about address uniqueness, or otherwise > enable communications onto physical media which exhibit certain > useful characteristics enabling address aggregation. Links > connecting computers with such network interfaces are likely to > support link-local communications reaching multiple computers whose > addresses can be aggregated into subnet ranges. For such links, the > known characteristics of the link SHOULD be considered when > configuring IP subnet prefixes, and the corresponding interfaces > configured with the same subnet prefix. I agree. This section starts now with the right thing. > Such subnet prefix assignment is outside the scope of this document, > since it depends on the specific characteristics of the physical > links and network interfaces. That sounds as if you are going to be concerned (inscope of this document) with prefix assignment which does not depend on the specific characteristics of the physical links and network interfaces. DO you think it is possible to even send a message on a physical link and network interface without knowing its MTU, for example? > If, on the other hand, the link to which an interface connects > enables no such assumptions of connectivity to other interfaces, the > only addresses which can be assumed "on link", are the address(es) of > that interface itself. You are mixing interface scope with link scope. This should be kept disambiguated, scopes 2 and 1. An address "on link" assumes there is a real link out there. An address "off link" is an address absent from the node and from all the nodes on that link. An address on-interface (not sure the terminology exists) can't go on the link on which that interface attaches, because its scope is solely that interface (scope 2 in rfc4291, which does exist). It sounds as a need to define undefinable links. Let's copypaste here some relevant and recent definitions of link, if you wish. I could help. > Subnet prefix configuration on such interfaces, SHOULD NOT make any > promises in terms of direct (one hop) IP connectivity to IP addresses > I believe it's 0th hop. > other than that of the interface itself. This suggests the following > principle: Yes, the principle is that you want to define an on-interface scope. The problem with it is that it doesn't go out on a link. > o two distinct such interfaces in the network SHOULD NOT be > configured with the same subnet prefix. > > In all cases, when L2 communication is enabled between a pair of > interfaces, IP packet exchange is enabled regardless of the IP subnet > configuration on each of these interfaces. This sounds ok to me, it is very well said. Moreover, IP can run on links which have no MAC at all. > I'd also be willing to go through the rest of the document text > making similar revisions. > > Another alternative would be to strip link-locals out of the document > entirely, or put all such discussion in an Appendix. Entirely out of the document - I would agree with that. Don't mention the word link-local or link-local address anywhere throughout - I agree. > This would, however, make the document seem more mysterious and > arbitrary, since the fundamental reasoning and understanding leading > to the recommendations would be absent. I don't believe there is a coherent understanding of the link-local addresses. You simply use them to say that because most of them rely on probably-not-unique MAC, and because they are not forwarded across links - then use /128... it's completely illogic. BEtter don't mention them at all. I would agree with such a direction. > I also used "SHOULD" and "SHOULD NOT" instead of "MUSTs", since it > seems to me that systems can clearly be built that do not adhere to > the recommendations. Nevertheless, in the absence of system-specific > assumptions, the general recommendations are expected to be > followed. This last sentence is merely a regurgitation of the > definition of "SHOULD". I agree with this direction in general, when things are to be explored. In the case of LLs things are widely used already, tested, demonstrated, in a different way that you suggest. Thus I would suggest "MAY" in many places where you say link-local address, and "MAY" where you say "/128 prefix". IMHO, Alex From ulrich@herberg.name Thu Oct 29 13:02:47 2009 Return-Path: <ulrich@herberg.name> 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 268DD3A694A for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 13:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.156 X-Spam-Level: X-Spam-Status: No, score=-0.156 tagged_above=-999 required=5 tests=[AWL=-1.212, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_XBL=3.033] 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 QdxsIiFlY-C4 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 13:02:46 -0700 (PDT) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id EF0293A67F3 for <autoconf@ietf.org>; Thu, 29 Oct 2009 13:02:45 -0700 (PDT) Received: by bwz23 with SMTP id 23so2754560bwz.29 for <autoconf@ietf.org>; Thu, 29 Oct 2009 13:02:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.154.207 with SMTP id p15mr340092bkw.202.1256846579365; Thu, 29 Oct 2009 13:02:59 -0700 (PDT) In-Reply-To: <C70F564E.190D%sratliff@cisco.com> References: <4AE9D9D0.9020405@earthlink.net> <C70F564E.190D%sratliff@cisco.com> Date: Thu, 29 Oct 2009 21:02:59 +0100 Message-ID: <25c114b90910291302w1441de42s44ea0bd7ab53d6f9@mail.gmail.com> From: Ulrich Herberg <ulrich@herberg.name> To: sratliff <sratliff@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: autoconf@ietf.org Subject: Re: [Autoconf] issues with draft-baccelli address model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 20:02:47 -0000 Hi, On Thu, Oct 29, 2009 at 7:25 PM, sratliff <sratliff@cisco.com> wrote: > > Absolutely correct. I agree 100%. And this is why I see this whole > discussion as a tempest in a teapot. > > "discourage" !=3D "cannot" Absolutely! I also think that a large confusion comes from wording: I assist Charlie and Stan that you _are NOT prohibited_ to continue using your setting with LLs. Nowhere in the draft this is prohibited. Nevertheless, I hope that the revised section by Charlie can help to make that clearer. Are there any other opinions on that revised section? Ulrich > > No one supporting the Bacelli-Townsley draft has said you can't use > link-local addresses. I support the Bacelli-Townsley draft, and most of m= y > deployments use link-local addresses. My deployments will continue to use > link-local addresses. But I do see that there are deployments where use o= f > link-local addresses is either problematic, or impossible. So I understan= d > the draft's language concerning "discouraging" their use. > > But the draft DOES NOT say they CANNOT be used. That's one of the reasons= I > support the draft. > > Regards, > Stan > > > On 10/29/09 2:07 PM, "Charles E. Perkins" <charles.perkins@earthlink.net> > wrote: > >> >> Hello Alex, >> >> I don't mind discussing with you. =A0But I really don't >> like having to point out your false statements so >> often. >> >> Alexandru Petrescu wrote: >>> Charles E. Perkins a =E9crit : >>> [...] >>>> So far the only hard problem seems to be how to avoid squabbling over >>>> =A0whether link-locals are needed. >>>> >>>> I am not sure why the proponents of necessity are so adept at >>>> ignoring the solutions that do not need link-locals. >>> >>> It's very simple why: I have a prototype which involves protocol >>> extensions (RA) only on the parts of the System which use exclusively >>> link-locals addresses. =A0You forbidding link-local addresses equates w= ith >>> forbidding my protocol extensions on the core of my prototype, makes >>> all break. >> >> I _do not_ forbid link-local addresses. =A0I'm not even one of the >> document authors, and I didn't create that language. >> >> But the document does not forbid link-locals either. >> >> So how many times do you persist in making this false >> statement, and, worse, basing your repeated, iterated, >> verbose, relentless, and seemingly misguided objections >> based on the false notion that link-locals are forbidden? >> >>> >>> >>>> It is not explainable by the existence of solutions that use >>>> link-locals, because such solutions are universally acknowledged to >>>> be useful in their realm of applicability. >>> >>> Is this formulation ok, or an "only" missing somewhere? >> >> ...???... >> >>> >>> If you keep that formulation as is - I agree with it! >>> >>>> So why do link-locals insist on "their way come hell or high water"? >>> >>> BEcause I don't want my prototype discarded by an illogical sense of >>> forbidding LLs. >> >> And in what universe does that prohibition reside? >> >> Regards, >> Charlie P. >> >> >> _______________________________________________ >> 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 alexandru.petrescu@gmail.com Thu Oct 29 13:04:26 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 2A8153A6970 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 13:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.315, 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 ZnL4xxcu34Qr for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 13:04:25 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 16B693A691E for <autoconf@ietf.org>; Thu, 29 Oct 2009 13:04:23 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 21382D48037; Thu, 29 Oct 2009 21:04:34 +0100 (CET) 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 AF125D4811A; Thu, 29 Oct 2009 21:04:31 +0100 (CET) Message-ID: <4AE9F54C.9080909@gmail.com> Date: Thu, 29 Oct 2009 21:04:28 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ulrich Herberg <ulrich@herberg.name> References: <4AE9D9D0.9020405@earthlink.net> <C70F564E.190D%sratliff@cisco.com> <25c114b90910291302w1441de42s44ea0bd7ab53d6f9@mail.gmail.com> In-Reply-To: <25c114b90910291302w1441de42s44ea0bd7ab53d6f9@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091029-0, 29/10/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] issues with draft-baccelli address model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 20:04:26 -0000 Ulrich Herberg a écrit : > Hi, > > On Thu, Oct 29, 2009 at 7:25 PM, sratliff <sratliff@cisco.com> wrote: >> Absolutely correct. I agree 100%. And this is why I see this whole >> discussion as a tempest in a teapot. >> >> "discourage" != "cannot" > > Absolutely! I also think that a large confusion comes from wording: I > assist Charlie and Stan that you _are NOT prohibited_ to continue > using your setting with LLs. Nowhere in the draft this is prohibited. > Nevertheless, I hope that the revised section by Charlie can help to > make that clearer. Are there any other opinions on that revised > section? Ulrich, call this draft "discourage!=cannot" and you'll have many eyebrows raised... Alex > > Ulrich > > > >> No one supporting the Bacelli-Townsley draft has said you can't use >> link-local addresses. I support the Bacelli-Townsley draft, and most of my >> deployments use link-local addresses. My deployments will continue to use >> link-local addresses. But I do see that there are deployments where use of >> link-local addresses is either problematic, or impossible. So I understand >> the draft's language concerning "discouraging" their use. >> >> But the draft DOES NOT say they CANNOT be used. That's one of the reasons I >> support the draft. >> >> Regards, >> Stan >> >> >> On 10/29/09 2:07 PM, "Charles E. Perkins" <charles.perkins@earthlink.net> >> wrote: >> >>> Hello Alex, >>> >>> I don't mind discussing with you. But I really don't >>> like having to point out your false statements so >>> often. >>> >>> Alexandru Petrescu wrote: >>>> Charles E. Perkins a écrit : >>>> [...] >>>>> So far the only hard problem seems to be how to avoid squabbling over >>>>> whether link-locals are needed. >>>>> >>>>> I am not sure why the proponents of necessity are so adept at >>>>> ignoring the solutions that do not need link-locals. >>>> It's very simple why: I have a prototype which involves protocol >>>> extensions (RA) only on the parts of the System which use exclusively >>>> link-locals addresses. You forbidding link-local addresses equates with >>>> forbidding my protocol extensions on the core of my prototype, makes >>>> all break. >>> I _do not_ forbid link-local addresses. I'm not even one of the >>> document authors, and I didn't create that language. >>> >>> But the document does not forbid link-locals either. >>> >>> So how many times do you persist in making this false >>> statement, and, worse, basing your repeated, iterated, >>> verbose, relentless, and seemingly misguided objections >>> based on the false notion that link-locals are forbidden? >>> >>>> >>>>> It is not explainable by the existence of solutions that use >>>>> link-locals, because such solutions are universally acknowledged to >>>>> be useful in their realm of applicability. >>>> Is this formulation ok, or an "only" missing somewhere? >>> ...???... >>> >>>> If you keep that formulation as is - I agree with it! >>>> >>>>> So why do link-locals insist on "their way come hell or high water"? >>>> BEcause I don't want my prototype discarded by an illogical sense of >>>> forbidding LLs. >>> And in what universe does that prohibition reside? >>> >>> Regards, >>> Charlie P. >>> >>> >>> _______________________________________________ >>> 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 charles.perkins@earthlink.net Thu Oct 29 14:45:40 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1084F3A68E5 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 14:45:40 -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 4x8vpfZWKXQH for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 14:45:39 -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 ECE2A3A681F for <autoconf@ietf.org>; Thu, 29 Oct 2009 14:45:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ipUz51c+6u+5JPuf3lVpdNYVfdmxqTeUvmWv4GErhF1202jn36Dr1yOb+62Unp6U; 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.148]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N3cob-0005Uk-Lx; Thu, 29 Oct 2009 17:45:53 -0400 Message-ID: <4AEA0D10.2010403@earthlink.net> Date: Thu, 29 Oct 2009 14:45:52 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <7877C5C0B5CC894AB26113CF06CF886302C7FC76@ms-dt01thalia.tsn.tno.nl> <4AE9D473.4070001@earthlink.net> <4AE9F3DB.9030802@gmail.com> In-Reply-To: <4AE9F3DB.9030802@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5213d73a4626deeb48d0485e72e6496ebb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 21:45:40 -0000 Hello Alex, Alexandru Petrescu wrote: > I agree. This section starts now with the right thing. > >> Such subnet prefix assignment is outside the scope of this document, >> since it depends on the specific characteristics of the physical >> links and network interfaces. > > That sounds as if you are going to be concerned (inscope of this > document) with prefix assignment which does not depend on the specific > characteristics of the physical links and network interfaces. DO you > think it is possible to even send a message on a physical link and > network interface without knowing its MTU, for example? Yes, I do. There are minimal sizes involved as well as maximal sizes. And, I think the document should focus on prefix assignment which does not depend on the specific characteristics of the physical links and network interfaces. And, since this is very general, it would work for all links. Prefix assignment for specific link classes ought to be in a separate document. Those techniques would not work for all links. > > >> If, on the other hand, the link to which an interface connects >> enables no such assumptions of connectivity to other interfaces, the >> only addresses which can be assumed "on link", are the address(es) of >> that interface itself. > > You are mixing interface scope with link scope. This should be kept > disambiguated, scopes 2 and 1. > > An address "on link" assumes there is a real link out there. > > An address "off link" is an address absent from the node and from all > the nodes on that link. > > An address on-interface (not sure the terminology exists) can't go on > the link on which that interface attaches, because its scope is solely > that interface (scope 2 in rfc4291, which does exist). > > It sounds as a need to define undefinable links. Good luck with that! On balance, the abovementioned text is quite clear. I didn't write it, by the way. > > Let's copypaste here some relevant and recent definitions of link, if > you wish. I could help. > >> Subnet prefix configuration on such interfaces, SHOULD NOT make any >> promises in terms of direct (one hop) IP connectivity to IP addresses >> > I believe it's 0th hop. 0th hop doesn't leave the node. I think the statement above is correct. > >> other than that of the interface itself. This suggests the following >> principle: > > Yes, the principle is that you want to define an on-interface scope. > The problem with it is that it doesn't go out on a link. Your second statement is not correct. The transmission occurs on the link to the neighbor. > >> o two distinct such interfaces in the network SHOULD NOT be >> configured with the same subnet prefix. >> >> In all cases, when L2 communication is enabled between a pair of >> interfaces, IP packet exchange is enabled regardless of the IP subnet >> configuration on each of these interfaces. > > This sounds ok to me, it is very well said. Moreover, IP can run on > links which have no MAC at all. > >> I'd also be willing to go through the rest of the document text >> making similar revisions. >> >> Another alternative would be to strip link-locals out of the document >> entirely, or put all such discussion in an Appendix. > > Entirely out of the document - I would agree with that. Don't > mention the word link-local or link-local address anywhere throughout - > I agree. I think it is not the best choice, but better than dawdling for even one more month on these link-local details. > >> This would, however, make the document seem more mysterious and >> arbitrary, since the fundamental reasoning and understanding leading >> to the recommendations would be absent. > > I don't believe there is a coherent understanding of the link-local > addresses. Maybe, but I personally feel that my understanding is crystal clear. > You simply use them to say that because most of them rely on > probably-not-unique MAC, and because they are not forwarded across > links - then use /128... it's completely illogic. This statement is wrong in more than one way: - I didn't use them - That is not why they are used in the document - The proportion of them depending on probably-not-unique MAC is not evaluated - The reason for /128 is not as you suggest - The reason for /128 is not completely illogic - illogic is syntactically incorrect (I do not fault you for this one). That's a pretty impressive score for a single sentence. > > BEtter don't mention them at all. I would agree with such a direction. In my opinion it should the the last resort, and a recognition that the working group insists on making progress as slowly as possible. But still better than zero progress, so I support it as a last resort. > > >> I also used "SHOULD" and "SHOULD NOT" instead of "MUSTs", since it >> seems to me that systems can clearly be built that do not adhere to >> the recommendations. Nevertheless, in the absence of system-specific >> assumptions, the general recommendations are expected to be >> followed. This last sentence is merely a regurgitation of the >> definition of "SHOULD". > > I agree with this direction in general, when things are to be > explored. In the case of LLs things are widely used already, tested, > demonstrated, in a different way that you suggest. Thus I would > suggest "MAY" in many places where you say link-local address, and > "MAY" where you say "/128 prefix". I think you and others should form a design team to formulate an addressing model for the subnets you want. Be sure to explain why you need for the work you identify to be done within the [autoconf] working group. Maybe you will be happy with DHCP and DAD and won't need to do anything more. Regards, Charlie P. From charles.perkins@earthlink.net Thu Oct 29 15:26:10 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 034E928C0D6 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 15:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[AWL=0.094, 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 2hb-WtCG0F4r for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 15:26:09 -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 152AB3A68DE for <autoconf@ietf.org>; Thu, 29 Oct 2009 15:26:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=gKimblWIJMnBgLgvEW7qrkQBaH5vdwZX9IBvrIP8MXrNvMp/GQk6A8MU24iy9/26; 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.148]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N3dRo-0003y5-8W; Thu, 29 Oct 2009 18:26:24 -0400 Message-ID: <4AEA168E.9070502@earthlink.net> Date: Thu, 29 Oct 2009 15:26:22 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <C70F579F.1912%sratliff@cisco.com> <4AE9EBAE.2000909@gmail.com> In-Reply-To: <4AE9EBAE.2000909@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52e324848ed1372ec270e2908168361841350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] issues with draft-baccelli address model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 22:26:10 -0000 Hello Alex, Since you CC:'d me, I feel that it should be O.K. for me to supply a response. Alexandru Petrescu wrote: > >> >> Nonsense. "utility.. is limited" is not the same as "must not be >> used". > > Would you agree to say "the utility of /128 prefixes is limited"? The utility of /128 prefixes is that using them enables solutions in all circumstances. Is that limited? > > >>> draft-baccelli says: >>>> o A subnet prefix configured on this interface should be of >>>> length /128. >>> The link-local prefix of IPv6 LLs is fe80::/10, and not /128. >> >> The key word in that sentence is SHOULD. It does not say MUST. > > Well, LLs are a SHOULD on many interfaces. A SHOULD and and a SHOULD > NOT could give a "MAY": "a /128 prefix on this interface MAY be /128". > (and I invite implementers to do it and report back problems thank you). You seem to have already dismissed the experience of many implementors on this list. Moreover, as has been noted before, MAY != ("SHOULD"+"SHOULD NOT"). In fact it is not helpful at all to understand what is at issue. > >>> draft-baccelli says: >>>> o Any [IPv4] subnet prefix configured on this interface should >>>> be of length /32. >>> Yet the prefix of the IPv4 LL is 169.254/16, and not a /32. >>> >> >> Again, the sentence says SHOULD. Not MUST. > > Again, a MAY would be a better fit. MAY is completely worthless in this context. It adds almost no information, and absolutely no practical information. > >>> draft-baccelli says: >>>> Note that the use of IPv4 link-local addresses [RFC3927] in this >>>> context should be discouraged for most applications >>> "Discouraged" means discouraged. And which "context"? The word >>> "context" appears precisely once in the draft. >>> >> >> Precisely. "Discouraged" means discouraged. It doesn't mean "cannot". >> And again, the sentence contains the word SHOULD. It does not say >> MUST. > > I believe that "dicouraged" fits better the use of host-based routes > (the "/128" prefix recommendation) for a variety of reasons, making > them limited use too: > (1) it doesn't scale to large domain, How large do you need? > (2) can't connect to the Internet, Wrong. > (3) consumes more ressources than /64-or-shorter prefixes (cycles: > instead of average 64 bit comparisons you use a sure 128 bit > comparisons, memory: instead of one entry covering several > destinations you use an entry for each destination in each router). Here, I agree. Perhaps you might evaluate the cost of the memory. Compare it to the cost of imposing more DAD or NUD cycles over the air. > > > It sounds as we have it completely reverse, and "MAY" may solve it. I don't think so. Regards, Charlie P. From hasnaa.moustafa@gmail.com Thu Oct 29 15:27:12 2009 Return-Path: <hasnaa.moustafa@gmail.com> 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 CAAB828C0D6 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 15:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6] 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 KPouV4FoF-0w for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 15:27:12 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id D80C83A68DE for <autoconf@ietf.org>; Thu, 29 Oct 2009 15:27:11 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so2321347fgg.13 for <autoconf@ietf.org>; Thu, 29 Oct 2009 15:27:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=zCA5bHSs5UeAO6b/+es2fKwrEbwH3tc1wST7AhwU3kQ=; b=ZzPCDJiM0HylYD4dKwQsfpAWsfOaX6IHI4Mp5jv48unc2wBo8xcqQOcCt34BDRVS2P NJC9JONpBX8bVzL51ZZbpZ4GpnKnlDiux7qWY+Vk6g29xxDj/nRRc5ollQGRpkkZR/AF KlnWjL/lnT/TDS9tjs8L+n9N2pMwWB88QSs0A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=mKzSK427mXP2kFdss6dnLv0NMlwFkbOcJaV33S4qcznPeURQjtQHwTTJqsjTsdtUMT eTEU88njv9FcmHpaafjdc15LRC78tmZdY0si9ArxZStcGPv8U8pxW5l/XPwTqUuVefa7 +9vJVrS9iggmiqp5Mks35FJ+3VvpKzgIi7Qfk= MIME-Version: 1.0 Received: by 10.103.85.28 with SMTP id n28mr275721mul.66.1256855244895; Thu, 29 Oct 2009 15:27:24 -0700 (PDT) In-Reply-To: <mailman.3594.1256813818.4669.autoconf@ietf.org> References: <mailman.3594.1256813818.4669.autoconf@ietf.org> Date: Thu, 29 Oct 2009 23:27:24 +0100 Message-ID: <dea40f930910291527k75a96d6xb597d84510075919@mail.gmail.com> From: Hasnaa Moustafa <hasnaa.moustafa@gmail.com> To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=0016e65b62a667f52104771a6a0c Subject: Re: [Autoconf] Autoconf Digest, Vol 43, Issue 84 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 22:27:12 -0000 --0016e65b62a667f52104771a6a0c Content-Type: text/plain; charset=ISO-8859-1 I totally agree and I support --> considering all the candidate documents that are on the table and looking at draft-bernardos at this phase. Kind regards, Hassnaa > Date: Thu, 29 Oct 2009 09:12:46 +0100 > From: Carlos Jes?s Bernardos Cano <cjbc@it.uc3m.es> > Subject: Re: [Autoconf] On WG progress > anddraft-ietf-autoconf-adhoc-addr-model > To: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr> > Cc: autoconf@ietf.org > Message-ID: <1256803966.4195.21.camel@acorde.it.uc3m.es> > Content-Type: text/plain; charset="iso-8859-15" > > Well, since it seems that the obvious should be said (i.e. authors > supporting their own documents :-) ), I think we should not proceed -- > at this stage -- with draft-baccelli, and consider first all the > candidate documents that are on the table (i.e., draft-bernardos, which > is surprisingly more aligned with my opinion). > > Thanks, > > Carlos > --0016e65b62a667f52104771a6a0c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote"> <div>I totally agree and I support --></div> <div>considering=A0all the candidate documents that are on the table and lo= oking at=A0draft-bernardos at this phase.</div> <div>=A0</div> <div>Kind regards,</div> <div>Hassnaa<br></div> <div>=A0</div> <div>=A0</div> <blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0= px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Date: Thu, 29 Oct 2009 09:12:46 = +0100<br>From: Carlos Jes?s Bernardos Cano <<a href=3D"mailto:cjbc@it.uc= 3m.es">cjbc@it.uc3m.es</a>><br> Subject: Re: [Autoconf] On WG progress<br>=A0 =A0 =A0 =A0anddraft-ietf-auto= conf-adhoc-addr-model<br>To: Emmanuel Baccelli <<a href=3D"mailto:Emmanu= el.Baccelli@inria.fr">Emmanuel.Baccelli@inria.fr</a>><br>Cc: <a href=3D"= mailto:autoconf@ietf.org">autoconf@ietf.org</a><br> Message-ID: <<a href=3D"mailto:1256803966.4195.21.camel@acorde.it.uc3m.e= s">1256803966.4195.21.camel@acorde.it.uc3m.es</a>><br>Content-Type: text= /plain; charset=3D"iso-8859-15"<br><br>Well, since it seems that = the obvious should be said (i.e. authors<br> supporting their own documents :-) ), I think we should not proceed --<br>a= t this stage -- with draft-baccelli, and consider first all the<br>candidat= e documents that are on the table (i.e., draft-bernardos, which<br>is surpr= isingly more aligned with my opinion).<br> <br>Thanks,<br><br>Carlos<br></blockquote></div> --0016e65b62a667f52104771a6a0c-- From alexandru.petrescu@gmail.com Thu Oct 29 15:32:22 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 7974928C10D for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 15:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=0.309, 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 pg925V3D47-e for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 15:32:21 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id D800728C108 for <autoconf@ietf.org>; Thu, 29 Oct 2009 15:32:19 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 68E8CD4807B; Thu, 29 Oct 2009 23:32:30 +0100 (CET) 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 0FA0ED4808E; Thu, 29 Oct 2009 23:32:28 +0100 (CET) Message-ID: <4AEA17F8.9060300@gmail.com> Date: Thu, 29 Oct 2009 23:32:24 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" <charles.perkins@earthlink.net> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <7877C5C0B5CC894AB26113CF06CF886302C7FC76@ms-dt01thalia.tsn.tno.nl> <4AE9D473.4070001@earthlink.net> <4AE9F3DB.9030802@gmail.com> <4AEA0D10.2010403@earthlink.net> In-Reply-To: <4AEA0D10.2010403@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091029-0, 29/10/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 22:32:22 -0000 Charles E. Perkins a écrit : > > Hello Alex, > > Alexandru Petrescu wrote: >> I agree. This section starts now with the right thing. >> >>> Such subnet prefix assignment is outside the scope of this >>> document, since it depends on the specific characteristics of the >>> physical links and network interfaces. >> >> That sounds as if you are going to be concerned (inscope of this >> document) with prefix assignment which does not depend on the >> specific characteristics of the physical links and network >> interfaces. DO you think it is possible to even send a message on >> a physical link and network interface without knowing its MTU, for >> example? > > Yes, I do. There are minimal sizes involved as well as maximal > sizes. Charles, this is in an interesting point that I just stumbled across in ROLL too. I think the minimum sized packet isn't standardized. One may think 40bytes but that's no payload at all. One may think 41bytes but there's no Protocol number for a payload of only 1 bute. ETc. So what would be the minimum packet sized for IPv6? But that's not the most important point here. The important point is that the stack must know the MTU before sending a packet otherwise it may be tempted in sending huge packets, payload after payload. If the AUTOCONF link is such undefined such that even the MTU is unknown then the stack has much problems sending packets on it. > And, I think the document should focus on prefix assignment which > does not depend on the specific characteristics of the physical links > and network interfaces. And, since this is very general, it would > work for all links. :-) > Prefix assignment for specific link classes ought to be in a separate > document. Those techniques would not work for all links. :-) Charles, I gave a long list of links. That is not specific. That list is very heterogeneous. On one hand I read your text as ideal, which I share (IP runs over everything), on another hand the programmer has often real links at hand, not some undefined link. >>> If, on the other hand, the link to which an interface connects >>> enables no such assumptions of connectivity to other interfaces, >>> the only addresses which can be assumed "on link", are the >>> address(es) of that interface itself. Let's try this ^ text again. What does it mean? I can accept for a while MANET link being a link with no assumption of connectivity. But then, what does it mean "the only address assumed "on link" is the address of that interface"? Do you mean there is nobody else on that link? If there is nobody else on that link then it is an "off link", per rfc4861 def of "off link". Do you mean that all addresses in MANET link are off-link? Really, however I struggle to read that phrase I can't parse. >> You are mixing interface scope with link scope. This should be >> kept disambiguated, scopes 2 and 1. >> >> An address "on link" assumes there is a real link out there. >> >> An address "off link" is an address absent from the node and from >> all the nodes on that link. >> >> An address on-interface (not sure the terminology exists) can't go >> on the link on which that interface attaches, because its scope is >> solely that interface (scope 2 in rfc4291, which does exist). >> >> It sounds as a need to define undefinable links. > > Good luck with that! On balance, the abovementioned text is quite > clear. I didn't write it, by the way. Sorry for saying 'you'. I meant to say that that text says something I can't parse. Let's have the definitions of "link", "on link", "off link", "link scope", "interface scope". These are widely used and implemented and have their meanings understood as per rfc4861 and addr architecture and other docs. >> Let's copypaste here some relevant and recent definitions of link, >> if you wish. I could help. Any interest in that ^ ? >>> Subnet prefix configuration on such interfaces, SHOULD NOT make >>> any promises in terms of direct (one hop) IP connectivity to IP >>> addresses >>> >> I believe it's 0th hop. > > 0th hop doesn't leave the node. I think the statement above is > correct. Yes, I think I actually agree with you on that. I often stumble between 0 and 1... >>> other than that of the interface itself. This suggests the >>> following principle: >> >> Yes, the principle is that you want to define an on-interface >> scope. The problem with it is that it doesn't go out on a link. > > Your second statement is not correct. The transmission occurs on the > link to the neighbor. Well, clearly an "interface-local scope" means it stays on that interface, not go on link, as per arch doc. A "link scope" - it stays on that link, not global, etc. That "interface-local" scope is for multicast addresses. I have never seen an address in that interface-local scope. When reading the draft-baccelli draft it makes me think of such an address, because it says it is "on link", it is on interface, there's nobody else on that link, yet it's not "off link". Your use of neighbor... is it on purpose(?)... ND? NHDP? >>> o two distinct such interfaces in the network SHOULD NOT be >>> configured with the same subnet prefix. >>> >>> In all cases, when L2 communication is enabled between a pair of >>> interfaces, IP packet exchange is enabled regardless of the IP >>> subnet configuration on each of these interfaces. >> >> This sounds ok to me, it is very well said. Moreover, IP can run >> on links which have no MAC at all. >> >>> I'd also be willing to go through the rest of the document text >>> making similar revisions. >>> >>> Another alternative would be to strip link-locals out of the >>> document entirely, or put all such discussion in an Appendix. >> >> Entirely out of the document - I would agree with that. Don't >> mention the word link-local or link-local address anywhere >> throughout - I agree. > > I think it is not the best choice, but better than dawdling for even > one more month on these link-local details. I agree with you on this. >>> This would, however, make the document seem more mysterious and >>> arbitrary, since the fundamental reasoning and understanding >>> leading to the recommendations would be absent. >> >> I don't believe there is a coherent understanding of the link-local >> addresses. > > Maybe, but I personally feel that my understanding is crystal clear. Ok let's say there's no common crystal clear understanding of what the draft says about link-local addresses. >> You simply use them to say that because most of them rely on >> probably-not-unique MAC, and because they are not forwarded across >> links - then use /128... it's completely illogic. > > This statement is wrong in more than one way: - I didn't use them - > That is not why they are used in the document - The proportion of > them depending on probably-not-unique MAC is not evaluated - The > reason for /128 is not as you suggest - The reason for /128 is not > completely illogic - illogic is syntactically incorrect (I do not > fault you for this one). > > That's a pretty impressive score for a single sentence. Ha :-) let's agree that saying "/128" is not saying "/10" - we can agree on that, right? I.e. saying "/128" excludes saying "/10". >> BEtter don't mention them at all. I would agree with such a >> direction. > > In my opinion it should the the last resort, and a recognition that > the working group insists on making progress as slowly as possible. > But still better than zero progress, so I support it as a last > resort. I support it too not only as last resort - if Chairs want to decide that now - I am all for it - LLs out of the doc, completely, now. As for the /128 recommendation we can discuss separately, one thread is not enough. >>> I also used "SHOULD" and "SHOULD NOT" instead of "MUSTs", since >>> it seems to me that systems can clearly be built that do not >>> adhere to the recommendations. Nevertheless, in the absence of >>> system-specific assumptions, the general recommendations are >>> expected to be followed. This last sentence is merely a >>> regurgitation of the definition of "SHOULD". >> >> I agree with this direction in general, when things are to be >> explored. In the case of LLs things are widely used already, >> tested, demonstrated, in a different way that you suggest. Thus I >> would suggest "MAY" in many places where you say link-local >> address, and "MAY" where you say "/128 prefix". > > > I think you and others should form a design team to formulate an > addressing model for the subnets you want. Be sure to explain why > you need for the work you identify to be done within the [autoconf] > working group. Maybe you will be happy with DHCP and DAD and won't > need to do anything more. Well, not for the moment. For the moment let's do this document. Alex > > Regards, Charlie P. > > From alexandru.petrescu@gmail.com Thu Oct 29 15:46:16 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 0B22C3A6936 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 15:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.646 X-Spam-Level: X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_35=0.6] 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 ju-WAbGHfOLu for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 15:46:15 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id E91F93A689E for <autoconf@ietf.org>; Thu, 29 Oct 2009 15:46:13 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id AE457D480BB; Thu, 29 Oct 2009 23:46:25 +0100 (CET) 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 84FF4D48094; Thu, 29 Oct 2009 23:46:22 +0100 (CET) Message-ID: <4AEA1B3B.4020701@gmail.com> Date: Thu, 29 Oct 2009 23:46:19 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" <charles.perkins@earthlink.net> References: <C70F579F.1912%sratliff@cisco.com> <4AE9EBAE.2000909@gmail.com> <4AEA168E.9070502@earthlink.net> In-Reply-To: <4AEA168E.9070502@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091029-0, 29/10/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] issues with draft-baccelli address model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 22:46:16 -0000 Charles E. Perkins a écrit : > > Hello Alex, > > Since you CC:'d me, I feel that it should be O.K. for me to supply a > response. > > > Alexandru Petrescu wrote: >> >>> >>> Nonsense. "utility.. is limited" is not the same as "must not be >>> used". >> >> Would you agree to say "the utility of /128 prefixes is limited"? > > The utility of /128 prefixes is that using them enables solutions in > all circumstances. > > Is that limited? Yes, limited by its trade-offs (memory and search time you agree below). >>>> draft-baccelli says: >>>>> o A subnet prefix configured on this interface should be of >>>>> length /128. >>>> The link-local prefix of IPv6 LLs is fe80::/10, and not /128. >>> >>> The key word in that sentence is SHOULD. It does not say MUST. >> >> Well, LLs are a SHOULD on many interfaces. A SHOULD and and a >> SHOULD NOT could give a "MAY": "a /128 prefix on this interface >> MAY be /128". (and I invite implementers to do it and report back >> problems thank you). > > You seem to have already dismissed the experience of many > implementors on this list. Yes, we have an issue here. Many implementers on this list have often disregarded the fact that the LL address was there. Because of that, let us continue this complete disregard and not say MAY LL, neither SHOULD LL, nor MUST NOT LL. Just don't say LL - because they have always been completely disregarded - let us have this draft reflect that particular implementer situation. Disregarded in implementation, disregarded in the draft. But don't say wrong things about them. > Moreover, as has been noted before, MAY != ("SHOULD"+"SHOULD NOT"). > In fact it is not helpful at all to understand what is at issue. I tend to agree too. >>>> draft-baccelli says: >>>>> o Any [IPv4] subnet prefix configured on this interface >>>>> should be of length /32. >>>> Yet the prefix of the IPv4 LL is 169.254/16, and not a /32. >>>> >>> >>> Again, the sentence says SHOULD. Not MUST. >> >> Again, a MAY would be a better fit. > > MAY is completely worthless in this context. It adds almost no > information, and absolutely no practical information. Hmmm, I tend to agree... I often believe that seeing "MAY" is seeing lack of consensus. It is a big problem when trying to implement. [...] >> I believe that "dicouraged" fits better the use of host-based >> routes (the "/128" prefix recommendation) for a variety of reasons, >> making them limited use too: > >> (1) it doesn't scale to large domain, > > How large do you need? Hmmm, it can't become as big as the Internet is now. >> (2) can't connect to the Internet, > > Wrong. Can we talk about it without going solution space? I think we should talk about it in an addressing model draft which does not disturb the non adhoc aware nodes (i.e. Internet nodes). >> (3) consumes more ressources than /64-or-shorter prefixes (cycles: >> instead of average 64 bit comparisons you use a sure 128 bit >> comparisons, memory: instead of one entry covering several >> destinations you use an entry for each destination in each router). >> >> > > Here, I agree. Perhaps you might evaluate the cost of the memory. > Compare it to the cost of imposing more DAD or NUD cycles over the > air. Hmm... I do like the distributed manner of DAD+SLAAC, instead of req-resp messages between someone trying to obtain an address and someone delivering it one. This latter has its own problems. >> It sounds as we have it completely reverse, and "MAY" may solve it. >> >> > > I don't think so. Now that you say it, I think too so, a bit. I think better get rid of them (LLs) entirely rather than talk in an unconsensual way of them. Then we'll see the /128s recommendation separately. Alex > > Regards, Charlie P. > > > From charles.perkins@earthlink.net Thu Oct 29 16:00:38 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB1003A6844 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 16:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=0.092, 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 acIgBb+WZACD for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 16:00:37 -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 98DF53A6781 for <autoconf@ietf.org>; Thu, 29 Oct 2009 16:00:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=SV+fZrBj8sRmD2q4YeqxE804rqUdzrJgzgqsNfcrYd27aoFtbjg93DiS8GIRh0f2; 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.148]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N3dzA-0001bl-PN; Thu, 29 Oct 2009 19:00:52 -0400 Message-ID: <4AEA1EA3.1030800@earthlink.net> Date: Thu, 29 Oct 2009 16:00:51 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <7877C5C0B5CC894AB26113CF06CF886302C7FC76@ms-dt01thalia.tsn.tno.nl> <4AE9D473.4070001@earthlink.net> <4AE9F3DB.9030802@gmail.com> <4AEA0D10.2010403@earthlink.net> <4AEA17F8.9060300@gmail.com> In-Reply-To: <4AEA17F8.9060300@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52bee8aef5e3db2fa68da78f594fbe5997350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 23:00:38 -0000 Hello Alex, Alexandru Petrescu wrote: > So what would be the minimum packet sized for IPv6? You already know the answer to that, and you probably already know that some device drivers have to run adaptation software in order to manage transmission over media not supporting large packets. And you certainly already know that it is possible to transmit IPv6 packets with size far less than the minimum MTU. > > But that's not the most important point here. I thoroughly agree with that. > > The important point is that the stack must know the MTU before sending a > packet otherwise it may be tempted in sending huge packets, payload > after payload. I doubt this, for any sane operating system. Not everything runs over TCP. > > If the AUTOCONF link is such undefined such that even the MTU is unknown > then the stack has much problems sending packets on it. Not in my experience. > >> And, I think the document should focus on prefix assignment which >> does not depend on the specific characteristics of the physical links >> and network interfaces. And, since this is very general, it would >> work for all links. > > :-) > >> Prefix assignment for specific link classes ought to be in a separate >> document. Those techniques would not work for all links. > > :-) > > Charles, I gave a long list of links. That is not specific. That list > is very heterogeneous. This so thoroughly misses the point I am not sure just how to respond. > > On one hand I read your text as ideal, which I share (IP runs over > everything), on another hand the programmer has often real links at > hand, not some undefined link. Well at least I have finally received a very high compliment. I rarely suspect that my text might be ideal. For the rest of your comment, I invite you to consider the implications of having device drivers with well-defined interface routines. > >>>> If, on the other hand, the link to which an interface connects >>>> enables no such assumptions of connectivity to other interfaces, >>>> the only addresses which can be assumed "on link", are the >>>> address(es) of that interface itself. > > Let's try this ^ text again. > > What does it mean? I can accept for a while MANET link being a link > with no assumption of connectivity. > > But then, what does it mean "the only address assumed "on link" is the > address of that interface"? Do you mean there is nobody else on that > link? If there is nobody else on that link then it is an "off link", > per rfc4861 def of "off link". It means that you don't automatically know the layer-3 addresses of nodes reachable by that link. Really, Alex, couldn't you figure this out? > > Do you mean that all addresses in MANET link are off-link? No. > > Really, however I struggle to read that phrase I can't parse. Try harder. > >>> You are mixing interface scope with link scope. This should be >>> kept disambiguated, scopes 2 and 1. >>> >>> An address "on link" assumes there is a real link out there. >>> >>> An address "off link" is an address absent from the node and from >>> all the nodes on that link. >>> >>> An address on-interface (not sure the terminology exists) can't go >>> on the link on which that interface attaches, because its scope is >>> solely that interface (scope 2 in rfc4291, which does exist). >>> >>> It sounds as a need to define undefinable links. >> >> Good luck with that! On balance, the abovementioned text is quite >> clear. I didn't write it, by the way. > > Sorry for saying 'you'. > > I meant to say that that text says something I can't parse. Try! Don't try to imagine ways that it might be questionable and argued to infinity in an alternate universe. Try instead to understand what it might mean. That's what I do. > > Let's have the definitions of "link", "on link", "off link", "link > scope", "interface scope". These are widely used and implemented and > have their meanings understood as per rfc4861 and addr architecture and > other docs. Good luck with dancing on that mattress of nails. > >>> Let's copypaste here some relevant and recent definitions of link, >>> if you wish. I could help. > > Any interest in that ^ ? No. > > > > When reading the draft-baccelli draft it makes me think of such an > address, because it says it is "on link", it is on interface, there's > nobody else on that link, yet it's not "off link". > > Your use of neighbor... is it on purpose(?)... ND? NHDP? You ought to know. If not, then read the previously cited Baccelli/Perkins document. > > >> >> Maybe, but I personally feel that my understanding is crystal clear. > > Ok let's say there's no common crystal clear understanding of what the > draft says about link-local addresses. That is certainly true. > > > Ha :-) let's agree that saying "/128" is not saying "/10" - we can > agree on that, right? I.e. saying "/128" excludes saying "/10". I'm not concerned with this, and don't care to state a position. > >>> >>> I agree with this direction in general, when things are to be >>> explored. In the case of LLs things are widely used already, >>> tested, demonstrated, in a different way that you suggest. Thus I >>> would suggest "MAY" in many places where you say link-local >>> address, and "MAY" where you say "/128 prefix". >> >> >> I think you and others should form a design team to formulate an >> addressing model for the subnets you want. Be sure to explain why >> you need for the work you identify to be done within the [autoconf] >> working group. Maybe you will be happy with DHCP and DAD and won't >> need to do anything more. > > Well, not for the moment. For the moment let's do this document. I really think you ought to get with your colleagues into a task force. You are not helping with this document, in my opinion. Regards, Charlie P. From thomas@thomasclausen.org Thu Oct 29 16:07:03 2009 Return-Path: <thomas@thomasclausen.org> 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 C016A3A690D for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 16:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] 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 3iOXkkOG1VUq for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 16:07:02 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id D9AA23A6809 for <autoconf@ietf.org>; Thu, 29 Oct 2009 16:07:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id B496732317B1; Thu, 29 Oct 2009 16:07:19 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-57-17.w81-249.abo.wanadoo.fr [81.249.151.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 4DB4332317B0; Thu, 29 Oct 2009 16:07:18 -0700 (PDT) Message-Id: <4DA0467A-F8A1-4BD0-9CF6-0DDE8E17690B@thomasclausen.org> From: Thomas Heide Clausen <thomas@thomasclausen.org> To: Alexandru Petrescu <alexandru.petrescu@gmail.com> In-Reply-To: <4AEA1B3B.4020701@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: Fri, 30 Oct 2009 00:07:15 +0100 References: <C70F579F.1912%sratliff@cisco.com> <4AE9EBAE.2000909@gmail.com> <4AEA168E.9070502@earthlink.net> <4AEA1B3B.4020701@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] issues with draft-baccelli address model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 23:07:03 -0000 Alex, You must understand, that the things which you are trying hard to =20 deconstruct are things which this WG has spent ~5 years reaching an =20 understanding of as a viable approach -- an understanding based on =20 "running code" and real networks.....real AD HOC networks, even. Real ad hoc networks, connected to the Internet and with real and =20 regular applications running and in operation with real users (i.e. =20 outside a limited lab environment). I would appreciate if you would try to understand the reasons for why =20= the Townsley/Baccelli recommends as it does -- rather than blindly =20 picking out issues and declaring open war on those. You have been =20 given numerous references to documents which could help further your =20 understanding. We have existence proof that the recommendations in the Townsley/=20 Baccelli document work....in real ad hoc networks, connected to the =20 internet, and with hosts running regular applications and protocols. Thanks, Thomas On Oct 29, 2009, at 11:46 PM, Alexandru Petrescu wrote: > Charles E. Perkins a =E9crit : >> Hello Alex, >> Since you CC:'d me, I feel that it should be O.K. for me to supply =20= >> a response. >> Alexandru Petrescu wrote: >>>> Nonsense. "utility.. is limited" is not the same as "must not be >>>> used". >>> Would you agree to say "the utility of /128 prefixes is limited"? >> The utility of /128 prefixes is that using them enables solutions =20 >> in all circumstances. >> Is that limited? > > Yes, limited by its trade-offs (memory and search time you agree =20 > below). > >>>>> draft-baccelli says: >>>>>> o A subnet prefix configured on this interface should be of >>>>>> length /128. >>>>> The link-local prefix of IPv6 LLs is fe80::/10, and not /128. >>>> The key word in that sentence is SHOULD. It does not say MUST. >>> Well, LLs are a SHOULD on many interfaces. A SHOULD and and a =20 >>> SHOULD NOT could give a "MAY": "a /128 prefix on this interface =20 >>> MAY be /128". (and I invite implementers to do it and report back =20= >>> problems thank you). >> You seem to have already dismissed the experience of many =20 >> implementors on this list. > > Yes, we have an issue here. > > Many implementers on this list have often disregarded the fact that =20= > the > LL address was there. Because of that, let us continue this complete > disregard and not say MAY LL, neither SHOULD LL, nor MUST NOT LL. =20 > Just > don't say LL - because they have always been completely disregarded - > let us have this draft reflect that particular implementer situation. > Disregarded in implementation, disregarded in the draft. > > But don't say wrong things about them. > >> Moreover, as has been noted before, MAY !=3D ("SHOULD"+"SHOULD NOT"). >> In fact it is not helpful at all to understand what is at issue. > > I tend to agree too. > >>>>> draft-baccelli says: >>>>>> o Any [IPv4] subnet prefix configured on this interface should =20= >>>>>> be of length /32. >>>>> Yet the prefix of the IPv4 LL is 169.254/16, and not a /32. >>>> Again, the sentence says SHOULD. Not MUST. >>> Again, a MAY would be a better fit. >> MAY is completely worthless in this context. It adds almost no =20 >> information, and absolutely no practical information. > > Hmmm, I tend to agree... I often believe that seeing "MAY" is seeing > lack of consensus. It is a big problem when trying to implement. > > [...] >>> I believe that "dicouraged" fits better the use of host-based =20 >>> routes (the "/128" prefix recommendation) for a variety of reasons, >>> making them limited use too: >>> (1) it doesn't scale to large domain, >> How large do you need? > > Hmmm, it can't become as big as the Internet is now. > >>> (2) can't connect to the Internet, >> Wrong. > > Can we talk about it without going solution space? > > I think we should talk about it in an addressing model draft which =20 > does > not disturb the non adhoc aware nodes (i.e. Internet nodes). > >>> (3) consumes more ressources than /64-or-shorter prefixes (cycles: =20= >>> instead of average 64 bit comparisons you use a sure 128 bit =20 >>> comparisons, memory: instead of one entry covering several =20 >>> destinations you use an entry for each destination in each router). >> Here, I agree. Perhaps you might evaluate the cost of the memory. =20= >> Compare it to the cost of imposing more DAD or NUD cycles over the =20= >> air. > > Hmm... I do like the distributed manner of DAD+SLAAC, instead of > req-resp messages between someone trying to obtain an address and > someone delivering it one. This latter has its own problems. > >>> It sounds as we have it completely reverse, and "MAY" may solve it. >> I don't think so. > > Now that you say it, I think too so, a bit. > > I think better get rid of them (LLs) entirely rather than talk in an > unconsensual way of them. > > Then we'll see the /128s recommendation separately. > > Alex > >> Regards, Charlie P. > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From charles.perkins@earthlink.net Thu Oct 29 16:08:02 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B98E3A690D for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 16:08:02 -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.090, 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 2riwmmGQ7kWC for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 16:08:01 -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 67DFA3A6809 for <autoconf@ietf.org>; Thu, 29 Oct 2009 16:08:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=WAkLpCisfwQwVJEJQsnfeut23VqYHAko1Z6LSnOS+MPpx0LyjYfz1P5vgmsB44T1; 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.148]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N3e6K-0005RR-CM; Thu, 29 Oct 2009 19:08:17 -0400 Message-ID: <4AEA205B.9070506@earthlink.net> Date: Thu, 29 Oct 2009 16:08:11 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <C70F579F.1912%sratliff@cisco.com> <4AE9EBAE.2000909@gmail.com> <4AEA168E.9070502@earthlink.net> <4AEA1B3B.4020701@gmail.com> In-Reply-To: <4AEA1B3B.4020701@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52ce6693f8a4fe4d7aa89fad9fd04a83d5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] issues with draft-baccelli address model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 23:08:02 -0000 \Hello Alex, Alexandru Petrescu wrote: > > Yes, we have an issue here. > > Many implementers on this list have often disregarded the fact that the > LL address was there. Because of that, let us continue this complete > disregard and not say MAY LL, neither SHOULD LL, nor MUST NOT LL. Just > don't say LL - because they have always been completely disregarded - > let us have this draft reflect that particular implementer situation. > Disregarded in implementation, disregarded in the draft. This is not responsive to the need. > > But don't say wrong things about them. This is good advice, as always. > >>> (1) it doesn't scale to large domain, >> >> How large do you need? > > Hmmm, it can't become as big as the Internet is now. Is that your test for utility? > >>> (2) can't connect to the Internet, >> >> Wrong. > > Can we talk about it without going solution space? It's mathematically proven that your statement is wrong, by the mere existence of a counterexample. > > I think we should talk about it in an addressing model draft which does > not disturb the non adhoc aware nodes (i.e. Internet nodes). We already did. Regards, Charlie P. From alexandru.petrescu@gmail.com Thu Oct 29 16:20:47 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 0FC463A690D for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 16:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.646 X-Spam-Level: X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_35=0.6] 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 Fwqs+MqitdhR for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 16:20:46 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id CC0423A6809 for <autoconf@ietf.org>; Thu, 29 Oct 2009 16:20:44 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 8E215D48002; Fri, 30 Oct 2009 00:20:55 +0100 (CET) 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 2D670D48015; Fri, 30 Oct 2009 00:20:52 +0100 (CET) Message-ID: <4AEA2351.5050806@gmail.com> Date: Fri, 30 Oct 2009 00:20:49 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen <thomas@thomasclausen.org> References: <C70F579F.1912%sratliff@cisco.com> <4AE9EBAE.2000909@gmail.com> <4AEA168E.9070502@earthlink.net> <4AEA1B3B.4020701@gmail.com> <4DA0467A-F8A1-4BD0-9CF6-0DDE8E17690B@thomasclausen.org> In-Reply-To: <4DA0467A-F8A1-4BD0-9CF6-0DDE8E17690B@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091029-0, 29/10/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] issues with draft-baccelli address model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 23:20:47 -0000 Thomas Heide Clausen a écrit : > Alex, > > You must understand, that the things which you are trying hard to > deconstruct are things which this WG has spent ~5 years reaching an > understanding of as a viable approach -- an understanding based on > "running code" and real networks.....real AD HOC networks, even. > > Real ad hoc networks, connected to the Internet and with real and > regular applications running and in operation with real users (i.e. > outside a limited lab environment). > > I would appreciate if you would try to understand the reasons for why > the Townsley/Baccelli recommends as it does -- rather than blindly > picking out issues and declaring open war on those. You have been given > numerous references to documents which could help further your > understanding. > > We have existence proof that the recommendations in the > Townsley/Baccelli document work....in real ad hoc networks, connected to > the internet, and with hosts running regular applications and protocols. How do these networks use the link-local addresses? If somehow - please state how. If not at all - then please don't talk about them. About the /128 let's talk separately. Alex > > Thanks, > > Thomas > > > > On Oct 29, 2009, at 11:46 PM, Alexandru Petrescu wrote: > >> Charles E. Perkins a écrit : >>> Hello Alex, >>> Since you CC:'d me, I feel that it should be O.K. for me to supply a >>> response. >>> Alexandru Petrescu wrote: >>>>> Nonsense. "utility.. is limited" is not the same as "must not be >>>>> used". >>>> Would you agree to say "the utility of /128 prefixes is limited"? >>> The utility of /128 prefixes is that using them enables solutions in >>> all circumstances. >>> Is that limited? >> >> Yes, limited by its trade-offs (memory and search time you agree below). >> >>>>>> draft-baccelli says: >>>>>>> o A subnet prefix configured on this interface should be of >>>>>>> length /128. >>>>>> The link-local prefix of IPv6 LLs is fe80::/10, and not /128. >>>>> The key word in that sentence is SHOULD. It does not say MUST. >>>> Well, LLs are a SHOULD on many interfaces. A SHOULD and and a >>>> SHOULD NOT could give a "MAY": "a /128 prefix on this interface MAY >>>> be /128". (and I invite implementers to do it and report back >>>> problems thank you). >>> You seem to have already dismissed the experience of many >>> implementors on this list. >> >> Yes, we have an issue here. >> >> Many implementers on this list have often disregarded the fact that the >> LL address was there. Because of that, let us continue this complete >> disregard and not say MAY LL, neither SHOULD LL, nor MUST NOT LL. Just >> don't say LL - because they have always been completely disregarded - >> let us have this draft reflect that particular implementer situation. >> Disregarded in implementation, disregarded in the draft. >> >> But don't say wrong things about them. >> >>> Moreover, as has been noted before, MAY != ("SHOULD"+"SHOULD NOT"). >>> In fact it is not helpful at all to understand what is at issue. >> >> I tend to agree too. >> >>>>>> draft-baccelli says: >>>>>>> o Any [IPv4] subnet prefix configured on this interface should >>>>>>> be of length /32. >>>>>> Yet the prefix of the IPv4 LL is 169.254/16, and not a /32. >>>>> Again, the sentence says SHOULD. Not MUST. >>>> Again, a MAY would be a better fit. >>> MAY is completely worthless in this context. It adds almost no >>> information, and absolutely no practical information. >> >> Hmmm, I tend to agree... I often believe that seeing "MAY" is seeing >> lack of consensus. It is a big problem when trying to implement. >> >> [...] >>>> I believe that "dicouraged" fits better the use of host-based routes >>>> (the "/128" prefix recommendation) for a variety of reasons, >>>> making them limited use too: >>>> (1) it doesn't scale to large domain, >>> How large do you need? >> >> Hmmm, it can't become as big as the Internet is now. >> >>>> (2) can't connect to the Internet, >>> Wrong. >> >> Can we talk about it without going solution space? >> >> I think we should talk about it in an addressing model draft which does >> not disturb the non adhoc aware nodes (i.e. Internet nodes). >> >>>> (3) consumes more ressources than /64-or-shorter prefixes (cycles: >>>> instead of average 64 bit comparisons you use a sure 128 bit >>>> comparisons, memory: instead of one entry covering several >>>> destinations you use an entry for each destination in each router). >>> Here, I agree. Perhaps you might evaluate the cost of the memory. >>> Compare it to the cost of imposing more DAD or NUD cycles over the air. >> >> Hmm... I do like the distributed manner of DAD+SLAAC, instead of >> req-resp messages between someone trying to obtain an address and >> someone delivering it one. This latter has its own problems. >> >>>> It sounds as we have it completely reverse, and "MAY" may solve it. >>> I don't think so. >> >> Now that you say it, I think too so, a bit. >> >> I think better get rid of them (LLs) entirely rather than talk in an >> unconsensual way of them. >> >> Then we'll see the /128s recommendation separately. >> >> Alex >> >>> Regards, Charlie P. >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > From thomas@thomasclausen.org Thu Oct 29 16:22:40 2009 Return-Path: <thomas@thomasclausen.org> 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 07ACF3A6952 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 16:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] 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 7qM6eLAR2JEa for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 16:22:38 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id EB2BB3A6781 for <autoconf@ietf.org>; Thu, 29 Oct 2009 16:22:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id B754632317B0; Thu, 29 Oct 2009 16:22:55 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-57-17.w81-249.abo.wanadoo.fr [81.249.151.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 8FF2332317AB; Thu, 29 Oct 2009 16:22:54 -0700 (PDT) Message-Id: <87C759AD-5FC6-4DC5-9D4F-BF82CA72223B@thomasclausen.org> From: Thomas Heide Clausen <thomas@thomasclausen.org> To: Alexandru Petrescu <alexandru.petrescu@gmail.com> In-Reply-To: <4AEA2351.5050806@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: Fri, 30 Oct 2009 00:22:51 +0100 References: <C70F579F.1912%sratliff@cisco.com> <4AE9EBAE.2000909@gmail.com> <4AEA168E.9070502@earthlink.net> <4AEA1B3B.4020701@gmail.com> <4DA0467A-F8A1-4BD0-9CF6-0DDE8E17690B@thomasclausen.org> <4AEA2351.5050806@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] issues with draft-baccelli address model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 23:22:40 -0000 On Oct 30, 2009, at 12:20 AM, Alexandru Petrescu wrote: > Thomas Heide Clausen a =E9crit : >> Alex, >> You must understand, that the things which you are trying hard to =20 >> deconstruct are things which this WG has spent ~5 years reaching an =20= >> understanding of as a viable approach -- an understanding based on =20= >> "running code" and real networks.....real AD HOC networks, even. >> Real ad hoc networks, connected to the Internet and with real and =20 >> regular applications running and in operation with real users (i.e. =20= >> outside a limited lab environment). >> I would appreciate if you would try to understand the reasons for =20 >> why the Townsley/Baccelli recommends as it does -- rather than =20 >> blindly picking out issues and declaring open war on those. You =20 >> have been given numerous references to documents which could help =20 >> further your understanding. >> We have existence proof that the recommendations in the Townsley/=20 >> Baccelli document work....in real ad hoc networks, connected to the =20= >> internet, and with hosts running regular applications and protocols. > > How do these networks use the link-local addresses? If somehow - =20 > please state how. > > If not at all - then please don't talk about them. > As described in the Townsley/Baccelli document and in the many other =20 documents that have been handed to you. > About the /128 let's talk separately. No. They are an integral part of the addressing model that has an =20 existence proof. Thomas > > Alex > >> Thanks, >> Thomas >> On Oct 29, 2009, at 11:46 PM, Alexandru Petrescu wrote: >>> Charles E. Perkins a =E9crit : >>>> Hello Alex, >>>> Since you CC:'d me, I feel that it should be O.K. for me to =20 >>>> supply a response. >>>> Alexandru Petrescu wrote: >>>>>> Nonsense. "utility.. is limited" is not the same as "must not be >>>>>> used". >>>>> Would you agree to say "the utility of /128 prefixes is limited"? >>>> The utility of /128 prefixes is that using them enables solutions =20= >>>> in all circumstances. >>>> Is that limited? >>> >>> Yes, limited by its trade-offs (memory and search time you agree =20 >>> below). >>> >>>>>>> draft-baccelli says: >>>>>>>> o A subnet prefix configured on this interface should be of >>>>>>>> length /128. >>>>>>> The link-local prefix of IPv6 LLs is fe80::/10, and not /128. >>>>>> The key word in that sentence is SHOULD. It does not say MUST. >>>>> Well, LLs are a SHOULD on many interfaces. A SHOULD and and a =20 >>>>> SHOULD NOT could give a "MAY": "a /128 prefix on this interface =20= >>>>> MAY be /128". (and I invite implementers to do it and report =20 >>>>> back problems thank you). >>>> You seem to have already dismissed the experience of many =20 >>>> implementors on this list. >>> >>> Yes, we have an issue here. >>> >>> Many implementers on this list have often disregarded the fact =20 >>> that the >>> LL address was there. Because of that, let us continue this =20 >>> complete >>> disregard and not say MAY LL, neither SHOULD LL, nor MUST NOT LL. =20= >>> Just >>> don't say LL - because they have always been completely =20 >>> disregarded - >>> let us have this draft reflect that particular implementer =20 >>> situation. >>> Disregarded in implementation, disregarded in the draft. >>> >>> But don't say wrong things about them. >>> >>>> Moreover, as has been noted before, MAY !=3D ("SHOULD"+"SHOULD = NOT"). >>>> In fact it is not helpful at all to understand what is at issue. >>> >>> I tend to agree too. >>> >>>>>>> draft-baccelli says: >>>>>>>> o Any [IPv4] subnet prefix configured on this interface =20 >>>>>>>> should be of length /32. >>>>>>> Yet the prefix of the IPv4 LL is 169.254/16, and not a /32. >>>>>> Again, the sentence says SHOULD. Not MUST. >>>>> Again, a MAY would be a better fit. >>>> MAY is completely worthless in this context. It adds almost no =20 >>>> information, and absolutely no practical information. >>> >>> Hmmm, I tend to agree... I often believe that seeing "MAY" is seeing >>> lack of consensus. It is a big problem when trying to implement. >>> >>> [...] >>>>> I believe that "dicouraged" fits better the use of host-based =20 >>>>> routes (the "/128" prefix recommendation) for a variety of =20 >>>>> reasons, >>>>> making them limited use too: >>>>> (1) it doesn't scale to large domain, >>>> How large do you need? >>> >>> Hmmm, it can't become as big as the Internet is now. >>> >>>>> (2) can't connect to the Internet, >>>> Wrong. >>> >>> Can we talk about it without going solution space? >>> >>> I think we should talk about it in an addressing model draft which =20= >>> does >>> not disturb the non adhoc aware nodes (i.e. Internet nodes). >>> >>>>> (3) consumes more ressources than /64-or-shorter prefixes =20 >>>>> (cycles: instead of average 64 bit comparisons you use a sure =20 >>>>> 128 bit comparisons, memory: instead of one entry covering =20 >>>>> several destinations you use an entry for each destination in =20 >>>>> each router). >>>> Here, I agree. Perhaps you might evaluate the cost of the =20 >>>> memory. Compare it to the cost of imposing more DAD or NUD cycles =20= >>>> over the air. >>> >>> Hmm... I do like the distributed manner of DAD+SLAAC, instead of >>> req-resp messages between someone trying to obtain an address and >>> someone delivering it one. This latter has its own problems. >>> >>>>> It sounds as we have it completely reverse, and "MAY" may solve =20= >>>>> it. >>>> I don't think so. >>> >>> Now that you say it, I think too so, a bit. >>> >>> I think better get rid of them (LLs) entirely rather than talk in an >>> unconsensual way of them. >>> >>> Then we'll see the /128s recommendation separately. >>> >>> Alex >>> >>>> Regards, Charlie P. >>> >>> _______________________________________________ >>> 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 alexandru.petrescu@gmail.com Thu Oct 29 16:22:53 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 AF5983A699C for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 16:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[AWL=-0.441, BAYES_05=-1.11, 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 otzd1iiyfMT5 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 16:22:53 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id B95D73A6952 for <autoconf@ietf.org>; Thu, 29 Oct 2009 16:22:51 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 870ABD48015; Fri, 30 Oct 2009 00:23:02 +0100 (CET) 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 5CBB3D48037; Fri, 30 Oct 2009 00:23:00 +0100 (CET) Message-ID: <4AEA23D1.4070200@gmail.com> Date: Fri, 30 Oct 2009 00:22:57 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" <charles.perkins@earthlink.net> References: <C70F579F.1912%sratliff@cisco.com> <4AE9EBAE.2000909@gmail.com> <4AEA168E.9070502@earthlink.net> <4AEA1B3B.4020701@gmail.com> <4AEA205B.9070506@earthlink.net> In-Reply-To: <4AEA205B.9070506@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091029-0, 29/10/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] issues with draft-baccelli address model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 23:22:53 -0000 Charles E. Perkins a écrit : > > \Hello Alex, > > Alexandru Petrescu wrote: >> >> Yes, we have an issue here. >> >> Many implementers on this list have often disregarded the fact that the >> LL address was there. Because of that, let us continue this complete >> disregard and not say MAY LL, neither SHOULD LL, nor MUST NOT LL. Just >> don't say LL - because they have always been completely disregarded - >> let us have this draft reflect that particular implementer situation. >> Disregarded in implementation, disregarded in the draft. > This is not responsive to the need. > >> >> But don't say wrong things about them. > > This is good advice, as always. No, it is not good advice to talk about things one doesn't know, sorry. I agree, myself I don't know many things - but then I don't talk about them in my drafts. It's wrong to say that because Clausen adhoc network does not use LLs then I should not use them. Sorry about that and please get rid of them (LLs). Alex > >> >>>> (1) it doesn't scale to large domain, >>> >>> How large do you need? >> >> Hmmm, it can't become as big as the Internet is now. > > Is that your test for utility? > > >> >>>> (2) can't connect to the Internet, >>> >>> Wrong. >> >> Can we talk about it without going solution space? > > It's mathematically proven that your statement is wrong, > by the mere existence of a counterexample. > >> >> I think we should talk about it in an addressing model draft which does >> not disturb the non adhoc aware nodes (i.e. Internet nodes). > We already did. > > Regards, > Charlie P. > > > From alexandru.petrescu@gmail.com Thu Oct 29 16:36:51 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 77D2D3A6915 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 16:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=0.311, 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 eVtrQTsmVaWO for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 16:36:50 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 56C203A682F for <autoconf@ietf.org>; Thu, 29 Oct 2009 16:36:48 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 0B39ED4802D; Fri, 30 Oct 2009 00:37:00 +0100 (CET) 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 CA3E4D48074; Fri, 30 Oct 2009 00:36:57 +0100 (CET) Message-ID: <4AEA2716.6030207@gmail.com> Date: Fri, 30 Oct 2009 00:36:54 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" <charles.perkins@earthlink.net> References: <7FDC9EB7-F208-45A2-ACD7-283B980C23E3@thomasclausen.org> <7877C5C0B5CC894AB26113CF06CF886302C7FC76@ms-dt01thalia.tsn.tno.nl> <4AE9D473.4070001@earthlink.net> <4AE9F3DB.9030802@gmail.com> <4AEA0D10.2010403@earthlink.net> <4AEA17F8.9060300@gmail.com> <4AEA1EA3.1030800@earthlink.net> In-Reply-To: <4AEA1EA3.1030800@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091029-0, 29/10/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 23:36:51 -0000 Charles E. Perkins a écrit : > > Hello Alex, > > Alexandru Petrescu wrote: >> So what would be the minimum packet sized for IPv6? > You already know the answer to that, and you probably already > know that some device drivers have to run adaptation software > in order to manage transmission over media not supporting > large packets. And you certainly already know that it is possible > to transmit IPv6 packets with size far less than the minimum MTU. YEs yes, I'll give separately the context elsewhere when needed. [...] >> If the AUTOCONF link is such undefined such that even the MTU is unknown >> then the stack has much problems sending packets on it. > > Not in my experience. Did you experience receiving an RA with an MTU in it? Did you discourage that to, because it depends on the link characteristics? (you==one) [...] >> But then, what does it mean "the only address assumed "on link" is the >> address of that interface"? Do you mean there is nobody else on that >> link? If there is nobody else on that link then it is an "off link", >> per rfc4861 def of "off link". > > It means that you don't automatically know the layer-3 addresses > of nodes reachable by that link. Nobody said one would automatically know the L3 address of node on that link. If having their MAC addresses, Inverse Neighbor Discovery may help. What's the problem with that? > Really, Alex, couldn't you figure this out? No, really, I am completely lost. That paragraph is completely un-parsable to me. You refuse to have a common definition of a link, and this is not right. >> Do you mean that all addresses in MANET link are off-link? > > No. They're "on link", and they are the only ones assumed (by whom? by thesmelves? by the authors?) to be on link. What is this talking about? IT's really unclear. >> Really, however I struggle to read that phrase I can't parse. > > Try harder. No, I stop here. You try to explain that to whomever will ask you about it. I no longer care. [...] >> Your use of neighbor... is it on purpose(?)... ND? NHDP? > > You ought to know. If not, then read the previously cited > Baccelli/Perkins document. No, I am fed up, really. No negative intention but I am fed up. >> Ha :-) let's agree that saying "/128" is not saying "/10" - we can >> agree on that, right? I.e. saying "/128" excludes saying "/10". > > I'm not concerned with this, and don't care to > state a position. Well try to - saying that you use _only_ /128 means you don't use /10 (LL) that's as clear as it gets. >>>> I agree with this direction in general, when things are to be >>>> explored. In the case of LLs things are widely used already, >>>> tested, demonstrated, in a different way that you suggest. Thus I >>>> would suggest "MAY" in many places where you say link-local >>>> address, and "MAY" where you say "/128 prefix". >>> >>> >>> I think you and others should form a design team to formulate an >>> addressing model for the subnets you want. Be sure to explain why >>> you need for the work you identify to be done within the [autoconf] >>> working group. Maybe you will be happy with DHCP and DAD and won't >>> need to do anything more. >> >> Well, not for the moment. For the moment let's do this document. > > I really think you ought to get with your colleagues into a > task force. You are not helping with this document, in my > opinion. No, I will get from your way without needing to get into a Task Force. I am completely fed up. Yours, Alex From charles.perkins@earthlink.net Thu Oct 29 16:38:15 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D3023A682F for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 16:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[AWL=0.089, 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 4-OvzYTyGnrO for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 16:38:14 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id CCDB03A6781 for <autoconf@ietf.org>; Thu, 29 Oct 2009 16:38:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Q+w0JyiqrEGPsQlLK/y9Aw6rG0QoVZavufHA30MCjyM4WnjfcIB/2TUHQC0bU4b/; 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.148]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1N3eZa-0002d7-II; Thu, 29 Oct 2009 19:38:30 -0400 Message-ID: <4AEA2773.6010909@earthlink.net> Date: Thu, 29 Oct 2009 16:38:27 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu <alexandru.petrescu@gmail.com> References: <C70F579F.1912%sratliff@cisco.com> <4AE9EBAE.2000909@gmail.com> <4AEA168E.9070502@earthlink.net> <4AEA1B3B.4020701@gmail.com> <4AEA205B.9070506@earthlink.net> <4AEA23D1.4070200@gmail.com> In-Reply-To: <4AEA23D1.4070200@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f525b0598baba4feaf5df12195e2c5f981c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] issues with draft-baccelli address model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 23:38:15 -0000 Hello Alex, Alexandru Petrescu wrote: > > No, it is not good advice to talk about things one doesn't know, > sorry. I agree, myself I don't know many things - but then I don't > talk about them in my drafts. This doesn't seem to be responsive to the thread of discussion -- or at least I don't see the connection. > > It's wrong to say that because Clausen adhoc network does not use LLs > then I should not use them. Sorry about that and please get rid of > them (LLs). Nobody said that you should not use them. Regards, Charlie P. From alexandru.petrescu@gmail.com Thu Oct 29 16:41:04 2009 Return-Path: <alexandru.petrescu@gmail.com> 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 CCDAF3A6936 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 16:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.644 X-Spam-Level: X-Spam-Status: No, score=-1.644 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_35=0.6] 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 ERT6MPBqBcP6 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 16:41: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 336D23A67CC for <autoconf@ietf.org>; Thu, 29 Oct 2009 16:41:01 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 91251D48062; Fri, 30 Oct 2009 00:41:13 +0100 (CET) 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 68DA9D48056; Fri, 30 Oct 2009 00:41:11 +0100 (CET) Message-ID: <4AEA2814.1040607@gmail.com> Date: Fri, 30 Oct 2009 00:41:08 +0100 From: Alexandru Petrescu <alexandru.petrescu@gmail.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen <thomas@thomasclausen.org> References: <C70F579F.1912%sratliff@cisco.com> <4AE9EBAE.2000909@gmail.com> <4AEA168E.9070502@earthlink.net> <4AEA1B3B.4020701@gmail.com> <4DA0467A-F8A1-4BD0-9CF6-0DDE8E17690B@thomasclausen.org> <4AEA2351.5050806@gmail.com> <87C759AD-5FC6-4DC5-9D4F-BF82CA72223B@thomasclausen.org> In-Reply-To: <87C759AD-5FC6-4DC5-9D4F-BF82CA72223B@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091029-0, 29/10/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] issues with draft-baccelli address model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 23:41:04 -0000 Thomas Heide Clausen a écrit : > > On Oct 30, 2009, at 12:20 AM, Alexandru Petrescu wrote: > >> Thomas Heide Clausen a écrit : >>> Alex, >>> You must understand, that the things which you are trying hard to >>> deconstruct are things which this WG has spent ~5 years reaching an >>> understanding of as a viable approach -- an understanding based on >>> "running code" and real networks.....real AD HOC networks, even. >>> Real ad hoc networks, connected to the Internet and with real and >>> regular applications running and in operation with real users (i.e. >>> outside a limited lab environment). >>> I would appreciate if you would try to understand the reasons for why >>> the Townsley/Baccelli recommends as it does -- rather than blindly >>> picking out issues and declaring open war on those. You have been >>> given numerous references to documents which could help further your >>> understanding. >>> We have existence proof that the recommendations in the >>> Townsley/Baccelli document work....in real ad hoc networks, connected >>> to the internet, and with hosts running regular applications and >>> protocols. >> >> How do these networks use the link-local addresses? If somehow - >> please state how. >> >> If not at all - then please don't talk about them. >> > > As described in the Townsley/Baccelli document and in the many other > documents that have been handed to you. YEs - they discourage it. That was your way of using LLs? Discouraging them? How did you discourage their use other than not using them? Did you add some timers aging them slowly out? >> About the /128 let's talk separately. > > No. They are an integral part of the addressing model that has an > existence proof. Ok, no then. I am fed up anyways. Alex > > Thomas > >> >> Alex >> >>> Thanks, >>> Thomas >>> On Oct 29, 2009, at 11:46 PM, Alexandru Petrescu wrote: >>>> Charles E. Perkins a écrit : >>>>> Hello Alex, >>>>> Since you CC:'d me, I feel that it should be O.K. for me to supply >>>>> a response. >>>>> Alexandru Petrescu wrote: >>>>>>> Nonsense. "utility.. is limited" is not the same as "must not be >>>>>>> used". >>>>>> Would you agree to say "the utility of /128 prefixes is limited"? >>>>> The utility of /128 prefixes is that using them enables solutions >>>>> in all circumstances. >>>>> Is that limited? >>>> >>>> Yes, limited by its trade-offs (memory and search time you agree >>>> below). >>>> >>>>>>>> draft-baccelli says: >>>>>>>>> o A subnet prefix configured on this interface should be of >>>>>>>>> length /128. >>>>>>>> The link-local prefix of IPv6 LLs is fe80::/10, and not /128. >>>>>>> The key word in that sentence is SHOULD. It does not say MUST. >>>>>> Well, LLs are a SHOULD on many interfaces. A SHOULD and and a >>>>>> SHOULD NOT could give a "MAY": "a /128 prefix on this interface >>>>>> MAY be /128". (and I invite implementers to do it and report back >>>>>> problems thank you). >>>>> You seem to have already dismissed the experience of many >>>>> implementors on this list. >>>> >>>> Yes, we have an issue here. >>>> >>>> Many implementers on this list have often disregarded the fact that the >>>> LL address was there. Because of that, let us continue this complete >>>> disregard and not say MAY LL, neither SHOULD LL, nor MUST NOT LL. Just >>>> don't say LL - because they have always been completely disregarded - >>>> let us have this draft reflect that particular implementer situation. >>>> Disregarded in implementation, disregarded in the draft. >>>> >>>> But don't say wrong things about them. >>>> >>>>> Moreover, as has been noted before, MAY != ("SHOULD"+"SHOULD NOT"). >>>>> In fact it is not helpful at all to understand what is at issue. >>>> >>>> I tend to agree too. >>>> >>>>>>>> draft-baccelli says: >>>>>>>>> o Any [IPv4] subnet prefix configured on this interface should >>>>>>>>> be of length /32. >>>>>>>> Yet the prefix of the IPv4 LL is 169.254/16, and not a /32. >>>>>>> Again, the sentence says SHOULD. Not MUST. >>>>>> Again, a MAY would be a better fit. >>>>> MAY is completely worthless in this context. It adds almost no >>>>> information, and absolutely no practical information. >>>> >>>> Hmmm, I tend to agree... I often believe that seeing "MAY" is seeing >>>> lack of consensus. It is a big problem when trying to implement. >>>> >>>> [...] >>>>>> I believe that "dicouraged" fits better the use of host-based >>>>>> routes (the "/128" prefix recommendation) for a variety of reasons, >>>>>> making them limited use too: >>>>>> (1) it doesn't scale to large domain, >>>>> How large do you need? >>>> >>>> Hmmm, it can't become as big as the Internet is now. >>>> >>>>>> (2) can't connect to the Internet, >>>>> Wrong. >>>> >>>> Can we talk about it without going solution space? >>>> >>>> I think we should talk about it in an addressing model draft which does >>>> not disturb the non adhoc aware nodes (i.e. Internet nodes). >>>> >>>>>> (3) consumes more ressources than /64-or-shorter prefixes (cycles: >>>>>> instead of average 64 bit comparisons you use a sure 128 bit >>>>>> comparisons, memory: instead of one entry covering several >>>>>> destinations you use an entry for each destination in each router). >>>>> Here, I agree. Perhaps you might evaluate the cost of the memory. >>>>> Compare it to the cost of imposing more DAD or NUD cycles over the >>>>> air. >>>> >>>> Hmm... I do like the distributed manner of DAD+SLAAC, instead of >>>> req-resp messages between someone trying to obtain an address and >>>> someone delivering it one. This latter has its own problems. >>>> >>>>>> It sounds as we have it completely reverse, and "MAY" may solve it. >>>>> I don't think so. >>>> >>>> Now that you say it, I think too so, a bit. >>>> >>>> I think better get rid of them (LLs) entirely rather than talk in an >>>> unconsensual way of them. >>>> >>>> Then we'll see the /128s recommendation separately. >>>> >>>> Alex >>>> >>>>> Regards, Charlie P. >>>> >>>> _______________________________________________ >>>> 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 super.ismiti@gmail.com Thu Oct 29 19:49:25 2009 Return-Path: <super.ismiti@gmail.com> 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 52F473A6960 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 19:49:25 -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 nIL9cQ7LTaE5 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 19:49:24 -0700 (PDT) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id A13693A679C for <autoconf@ietf.org>; Thu, 29 Oct 2009 19:49:24 -0700 (PDT) Received: by pwi4 with SMTP id 4so435997pwi.29 for <autoconf@ietf.org>; Thu, 29 Oct 2009 19:49:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=LiLVV13KNbtq9oX28xKa8izI49bDuZOSl5d8rxfAMTY=; b=lfeCtXQDZqUoanoUWH4ADxaJqLOmbu9Dv0oEBBz4qo3TdBGVdIgL7yuecGUGqKLamR MNTn9iMrTKs0/Sy/Q5ClQstq5xu4Dz99+RhfIuPBTVlVZC7t9bVL+IwekcK9w0g8dVzM vV1vShARwKh1apCpczs+eYuNUwvOu0FWBjicA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=I7j0p60hc4Gc09jqlw7fOxs/gcqesCm+3QiqGFO/OWCo3wL4YJnX3ZJNemuPrZqrWS n3gp3G9jViEz0Fz0y8oLdTDx4mTuXZehp4pGQVihbusEDFmwsgOAYjdTrhx8b45BiROv FoA1BQ82cIINhfYItvW5Vg+2GWJvJ+Oezfdns= MIME-Version: 1.0 Received: by 10.142.75.14 with SMTP id x14mr89015wfa.151.1256870978051; Thu, 29 Oct 2009 19:49:38 -0700 (PDT) Date: Thu, 29 Oct 2009 23:49:38 -0300 Message-ID: <db92277f0910291949h732311cbn131f4b1ddc86b4ea@mail.gmail.com> From: Ricardo Schmidt <super.ismiti@gmail.com> To: autoconf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Autoconf] Regarding Baccelli/Townsley Internet-Draft X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 30 Oct 2009 02:49:25 -0000 Dear group members, I am in accordance with what is stated in the Internet-Draft adhoc-addr-model-00 by Baccelli/Townsley. Using the same email, I would like to ask: does the group only consider stateless address autoconfiguration? Or is stateful addressing also an alternative? Regards, Ricardo Schmidt. PS.: some may be surprise with my email, but yes I am following the group discussions. From charles.perkins@earthlink.net Thu Oct 29 20:07:11 2009 Return-Path: <charles.perkins@earthlink.net> X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ABB03A67C0 for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 20:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 9QpDlkO8-dwx for <autoconf@core3.amsl.com>; Thu, 29 Oct 2009 20:07:10 -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 723443A679C for <autoconf@ietf.org>; Thu, 29 Oct 2009 20:07:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=tqRc+xW/OkHNT9DXFUp5glcPn92AmCvlfiGpk2W1RGd0q17LBaceIMKGtCdmgXKT; 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 <charles.perkins@earthlink.net>) id 1N3hpm-0001DQ-Qt; Thu, 29 Oct 2009 23:07:27 -0400 Message-ID: <4AEA586C.9080104@earthlink.net> Date: Thu, 29 Oct 2009 20:07:24 -0700 From: "Charles E. Perkins" <charles.perkins@earthlink.net> Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ricardo Schmidt <super.ismiti@gmail.com> References: <db92277f0910291949h732311cbn131f4b1ddc86b4ea@mail.gmail.com> In-Reply-To: <db92277f0910291949h732311cbn131f4b1ddc86b4ea@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f524360f0ca8c899c2269cc8e737040f7a6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Regarding Baccelli/Townsley Internet-Draft X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 30 Oct 2009 03:07:11 -0000 Hello Ricardo, We haven't gotten to the point of deciding whether to use stateful or stateless address configuration yet. We're still trying to get started, although I guess things are finally resolving so that we will see some progress soon. My guess is that eventually solutions will be developed for both varieties, depending upon the network configuration and attachment. Regards, Charlie P. Ricardo Schmidt wrote: > Dear group members, > > I am in accordance with what is stated in the Internet-Draft > adhoc-addr-model-00 by Baccelli/Townsley. > > Using the same email, I would like to ask: does the group only > consider stateless address autoconfiguration? Or is stateful > addressing also an alternative? > > Regards, > Ricardo Schmidt. > > PS.: some may be surprise with my email, but yes I am following the > group discussions. > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > > > From super.ismiti@gmail.com Fri Oct 30 04:18:32 2009 Return-Path: <super.ismiti@gmail.com> 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 DA8003A6889 for <autoconf@core3.amsl.com>; Fri, 30 Oct 2009 04:18:32 -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 x7nKG2QeZ3s2 for <autoconf@core3.amsl.com>; Fri, 30 Oct 2009 04:18:32 -0700 (PDT) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id 1C8933A69FC for <autoconf@ietf.org>; Fri, 30 Oct 2009 04:18:32 -0700 (PDT) Received: by pzk42 with SMTP id 42so2127798pzk.31 for <autoconf@ietf.org>; Fri, 30 Oct 2009 04:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Pw5xnXkadhqFCXReO+DFhREManC97rPQIrhOSVJL9Eg=; b=HHGIrRtRgVPKMiqc7mYNZiCgPLJUl94HoG/7xWP8J7F/nx42DTVVnWkkdmLV9O56Sj EUU8HcemaDkdtGhroggJMcstY9z67pmF0cDL6q6Cixz9RhJcDTYkUessYqQ+y+gviBMj aV636a2l2UETB5u6Q0qfsByd4HT+GmebAs4Is= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vNzGJLVxX3fRcCzn+qjBswt3g9x1B0QtX8GSD2rJ5fg8ETfJfiGw4mwIClmr0eH1ll af4IPlGNfwjS/FAD/aismV+3C7A8gwxM7HpriJGmJgtb+wSVVfCHV6n6cOS73vCTdFQk tFWGqecYy9mUFEbs/c6t6bkmU/5+E1gi2UA3c= MIME-Version: 1.0 Received: by 10.142.59.10 with SMTP id h10mr131567wfa.91.1256901526612; Fri, 30 Oct 2009 04:18:46 -0700 (PDT) In-Reply-To: <4AEA586C.9080104@earthlink.net> References: <db92277f0910291949h732311cbn131f4b1ddc86b4ea@mail.gmail.com> <4AEA586C.9080104@earthlink.net> Date: Fri, 30 Oct 2009 08:18:46 -0300 Message-ID: <db92277f0910300418o26494cf9yce590cdb1806e599@mail.gmail.com> From: Ricardo Schmidt <super.ismiti@gmail.com> To: "Charles E. Perkins" <charles.perkins@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Regarding Baccelli/Townsley Internet-Draft X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 30 Oct 2009 11:18:32 -0000 Hi! That's OK! I will re-read the draft then, and see if there is any pertinent comment. Regards, Ricardo Schmidt. On Fri, Oct 30, 2009 at 12:07 AM, Charles E. Perkins <charles.perkins@earthlink.net> wrote: > > Hello Ricardo, > > We haven't gotten to the point of deciding whether to > use stateful or stateless address configuration yet. > We're still trying to get started, although I guess > things are finally resolving so that we will see some > progress soon. > > My guess is that eventually solutions will be > developed for both varieties, depending upon > the network configuration and attachment. > > Regards, > Charlie P. > > > > Ricardo Schmidt wrote: >> >> Dear group members, >> >> I am in accordance with what is stated in the Internet-Draft >> adhoc-addr-model-00 by Baccelli/Townsley. >> >> Using the same email, I would like to ask: does the group only >> consider stateless address autoconfiguration? Or is stateful >> addressing also an alternative? >> >> Regards, >> Ricardo Schmidt. >> >> PS.: some may be surprise with my email, but yes I am following the >> group discussions. >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >> >> >> > > -- Ricardo Schmidt MSc candidate in Computer Science / UFPE BSc in Computer Science / UPF From Fred.L.Templin@boeing.com Fri Oct 30 09:42:54 2009 Return-Path: <Fred.L.Templin@boeing.com> 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 B41543A684E for <autoconf@core3.amsl.com>; Fri, 30 Oct 2009 09:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 NkUgQV23M6mn for <autoconf@core3.amsl.com>; Fri, 30 Oct 2009 09:42:52 -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 9B2B83A682B for <autoconf@ietf.org>; Fri, 30 Oct 2009 09:42:52 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n9UGfIYK015515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 30 Oct 2009 09:41:19 -0700 (PDT) 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 n9UGfI3V012291; Fri, 30 Oct 2009 11:41:18 -0500 (CDT) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n9UGfH7g012252 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 30 Oct 2009 11:41:18 -0500 (CDT) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.102]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Fri, 30 Oct 2009 09:41:17 -0700 From: "Templin, Fred L" <Fred.L.Templin@boeing.com> To: Ricardo Schmidt <super.ismiti@gmail.com>, "Charles E. Perkins" <charles.perkins@earthlink.net> Date: Fri, 30 Oct 2009 09:41:15 -0700 Thread-Topic: [Autoconf] Regarding Baccelli/Townsley Internet-Draft Thread-Index: AcpZUscGKthy6+KURNG4bL3INNc3pgAKUdWg Message-ID: <12F4112206976147A34FEC0277597CCF27A49CCB78@XCH-NW-15V.nw.nos.boeing.com> References: <db92277f0910291949h732311cbn131f4b1ddc86b4ea@mail.gmail.com><4AEA586C.9080104@earthlink.net> <db92277f0910300418o26494cf9yce590cdb1806e599@mail.gmail.com> In-Reply-To: <db92277f0910300418o26494cf9yce590cdb1806e599@mail.gmail.com> 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" <autoconf@ietf.org> Subject: Re: [Autoconf] Regarding Baccelli/Townsley Internet-Draft X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 30 Oct 2009 16:42:54 -0000 I have been keeping out of this for a number of reasons, but I think there are two things I can say for now. First, my discomfort with both of these documents has been largely based on the use of MAY/SHOULD/MUST and their implications wrt to flexibility. On that subject, I would encourage folks to go back to Stan's three messages dated 10/29/09 which IMHO very clearly articulate the implications. Based on those considerations, I have to agree that the wg draft gives an appropriate balance of flexibility. Second, I want there to be flexibility to allow for "tethered" hosts that are always single-hop neighbors on a router's interface that otherwise has undetermined connectivity properties. That may mean that the router's interface may need to configure a prefix other than /32 or /128. I believe the flexibility is there because there is no MAY/SHOULD/MUST, but I believe there should be specific mention about support for tethered hosts within the model of a "semi-undetermined" connectivity property interface. Fred fred.l.templin@boeing.com From teco@inf-net.nl Sat Oct 31 01:05:10 2009 Return-Path: <teco@inf-net.nl> 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 049903A683A for <autoconf@core3.amsl.com>; Sat, 31 Oct 2009 01:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.364 X-Spam-Level: X-Spam-Status: No, score=-1.364 tagged_above=-999 required=5 tests=[AWL=-0.624, 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 7OpbQ7wVTnVl for <autoconf@core3.amsl.com>; Sat, 31 Oct 2009 01:05:09 -0700 (PDT) Received: from CPSMTPM-EML108.kpnxchange.com (Cpsmtpm-eml108.kpnxchange.com [195.121.3.12]) by core3.amsl.com (Postfix) with ESMTP id F1CE43A635F for <autoconf@ietf.org>; Sat, 31 Oct 2009 01:05:08 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML108.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Sat, 31 Oct 2009 09:05:24 +0100 From: "Teco Boot" <teco@inf-net.nl> To: "'Templin, Fred L'" <Fred.L.Templin@boeing.com> References: <db92277f0910291949h732311cbn131f4b1ddc86b4ea@mail.gmail.com><4AEA586C.9080104@earthlink.net> <db92277f0910300418o26494cf9yce590cdb1806e599@mail.gmail.com> <12F4112206976147A34FEC0277597CCF27A49CCB78@XCH-NW-15V.nw.nos.boeing.com> In-Reply-To: <12F4112206976147A34FEC0277597CCF27A49CCB78@XCH-NW-15V.nw.nos.boeing.com> Date: Sat, 31 Oct 2009 09:05:24 +0100 Message-ID: <006401ca5a00$e6b5e2a0$b421a7e0$@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: AcpZUscGKthy6+KURNG4bL3INNc3pgAKUdWgACDFp3A= Content-Language: nl X-OriginalArrivalTime: 31 Oct 2009 08:05:24.0826 (UTC) FILETIME=[E69143A0:01CA5A00] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Regarding Baccelli/Townsley Internet-Draft X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/autoconf> List-Post: <mailto:autoconf@ietf.org> List-Help: <mailto:autoconf-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 31 Oct 2009 08:05:10 -0000 >Templin, Fred L wrote: >Second, I want there to be flexibility to allow for >"tethered" hosts that are always single-hop neighbors >on a router's interface that otherwise has undetermined >connectivity properties. That may mean that the router's >interface may need to configure a prefix other than /32 or >/128. Yes, I deploy this stuff. But proponents on the baccelli draft would say this is supported, as there is some determined connectivity. I'm not sure this is valid argumentation, because I think the proponents know little of my MANETs. But also for this case (same as LLs), I think it makes sense we Autoconf work on for a maximum-length, global / ULA prefix. But the practical addressing model for MANETs shall dot say these are preferred. These are needed if nothing else is available and can be a stepping stone to acquire other prefixes. Regards, Teco