From autoconf-bounces@ietf.org Wed Apr 04 16:13:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZBr3-0007mJ-5X; Wed, 04 Apr 2007 16:13:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZBr1-0007m1-TY for autoconf@ietf.org; Wed, 04 Apr 2007 16:13:15 -0400 Received: from wr-out-0506.google.com ([64.233.184.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZBqo-0006Br-Tz for autoconf@ietf.org; Wed, 04 Apr 2007 16:13:15 -0400 Received: by wr-out-0506.google.com with SMTP id 71so240193wri for ; Wed, 04 Apr 2007 13:13:02 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=rbXCMYjP/b5GVTjQcdeuDSxCXEWmcb9Fvggjo+m7n0drfjOZ84HcESXRSBEKJqfUbZnJLpZ9i/tE+IIeFQMa9eBBXkL2JpQ5bCHcdIqpAlO69Q4KyNmVPTJqgBzCncK2oAQUgkXOjkwpGk8lXRBOXe/U6zKK8ItiD+roOv4N1HE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=W1JI0A78BCwaspORE5FRtOeXEFE3Y5CIzOSEIYdTyhTeVRK7Ya7FHs0kWgjLwaP2XHAAnQtbVZ5XTcjAQAJMltZMuZFVCjUZ5QdtBiujiUy43o7vJZHJ1VnDflc9LGGuOg8Nv/VyNdnf5jn2v3b2IPGUetcLoQtBLDAlVLehH3o= Received: by 10.114.159.1 with SMTP id h1mr398012wae.1175717581777; Wed, 04 Apr 2007 13:13:01 -0700 (PDT) Received: by 10.115.109.17 with HTTP; Wed, 4 Apr 2007 13:13:01 -0700 (PDT) Message-ID: Date: Wed, 4 Apr 2007 22:13:01 +0200 From: "Hasnaa Moustafa" To: autoconf@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: fca7d4b87f391aa4d413f865ce6efe79 Subject: [Autoconf] Problem Statement Draft: Comments on the Security Consideration Section X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2069650849==" Errors-To: autoconf-bounces@ietf.org --===============2069650849== Content-Type: multipart/alternative; boundary="----=_Part_37332_9244787.1175717581470" ------=_Part_37332_9244787.1175717581470 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, As settled during the last Autoconf session in Prague, here are my comments concerning the security consideration section in the autoconfiguration problem statement draft (draft-baccelli-autoconf-statement-02). ---------------------------------------------------------------------------= ------------------------------------------- Address Autoconfiguration for MANET: Terminology and Problem Statement (draft-baccelli-autoconf-statement-02) *Comments on Section (5. Security Consideration) * ** ** *I. Some unclear issues: * - In the statement: Analysis includes trust model and threats for a specifi= c ad hoc network scenario, where all the routers share a common link ( i.e. they are one hop away from each other, full-meshed connectivity is available). * Firstly: What do you mean by "routers share a common link"? One could understand that bus connectivity exists between routers, which is not the case as far as I understand and regarding the description given between brackets. I suggest revising this phrase or re-formulating it. * Secondly: Concerning the "mesh connectivity" that is mentioned between brackets, is this a requirement for security? I wonder if the mesh connectivity is related to RFC 3756 (IPv6 ND Trust Models and Threats) or i= t is a proposition that you are proposing. I checked RFC 3756 and I did not find something specific concerning mesh connectivity. Otherwise, if you are proposing this requirement, would not this lead to a mismatch with the deployment scenarios discussed in your draft (Section 3). - Last statement in the first paragraph: you are mentioning as attack example "DoS attacks on DAD procedures". Actually, DoS could take place during the whole autoconfiguration process and is not limited to the DAD process. *II. Trust models in RFC 3756 versus address autoconfiguration security: * ** ** - I noticed that you focus on the third trust model given in RFC 3756, whic= h reflects classical ad hoc networks scenarios. However, I think that the second trust model in RFC 3756 is also related to the autoconfiguration problem statement (the model representing a public network run by an operator, where the clients do not trust each other but they rather trust the operator " RFC 3756 Page 4 -> Section 3 -> point 2"). This trust model fits well in the case of connected MANET which you mention in section 3.2 i= n the problem statement draft. IMO, both trust models "classical ad hoc" and "public network" should be considered. I wonder if you have already considered both trust models or not in the security consideration section, as I find between the lines that you are mentioning the case when MANET is connected to the Internet! But no explici= t citation to the related trust model is given. ** ** ** *III. Suggestion of some re-phrasing and minor re-wording: * ** ** - In the statement (in particular, analysis includes trust model and threat= s for a specific ad hoc network scenario=85). IMHO, the word analysis does no= t match well with trust models. Also, mentioning "specific ad hoc network scenario" lets one thinks of a precise scenario of deployment, however the RFC 3756 gives a trust model for classical ad hoc networks scenarios howeve= r not explicitly mentioning threats related to multi-hop communication. Thus, I suggest modifying this statement as follows (trust models are derived and threats analysis are given considering ad hoc networks scenarios, where nodes do not directly trust. However, threats related to multi-hop communication are not clearly presented in [6]). - In the second part of the first statement (as in other type of IPv6 networks) -> I suggest putting "types" instead of "type" - In the statement "Although the document does not explicitly address MANETs, where routers can be multiple hop =85."-> I suggest putting "multip= le hops" instead of "multiple hop". ** *IV. Multi-hop Communication:* - The second paragraph gives some guidelines for securing the autoconfiguration process while taking into consideration multi-hop communication. It is mentioned that the security analysis has to be extende= d to include threats specific to multi-hop communication, and that routing security is out of the scope. I totally agree, but I would like to add a couple of points: * There is a need to develop a trust model taking care of multi-hop communication (may be this point should be mentioned before the point of security analysis and threats) * Attacks such as Man-in-the-middle and non cooperation in messages forwarding worth consideration. ---------------------------------------------------------------------------= -------------- Regards, Hassnaa Moustafa France Telecom R&D (Orange Labs) ------=_Part_37332_9244787.1175717581470 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi,
 
As settled during the last Autoconf session in Prague, here are my com= ments concerning the security consideration section in the autoconfiguratio= n problem statement draft (draft-baccelli-autoconf-statement-02).
 

Comments on Section (5. Security Consideration)

 

I. Some unclear issues:

* Firstly: What do you mean by "routers share a common link&quo= t;? One could understand that bus connectivity exists between routers, whic= h is not the case as far as I understand and regarding the description give= n between brackets. I suggest revising this phrase or re-formulating it.=20

* Secondly: Concerning the "mesh connectivity" that is men= tioned between brackets, is this a requirement for security? I wonder if th= e mesh connectivity is related to RFC 3756 (IPv6 ND Trust Models and Threat= s) or it is a proposition that you are proposing. I checked RFC 3756 and I = did not find something specific concerning mesh connectivity. Otherwise, if= you are proposing this requirement, would not this lead to a mismatch with= the deployment scenarios discussed in your draft (Section 3).=20

 

II. Trust models in RFC 3756 versus address autoconfiguration security= :=20

 

 

III. Suggestion of some re-phrasing and minor re-wording:  =

 

 

IV. Multi-hop Communication:

 

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZTO0-0004Nt-D2; Thu, 05 Apr 2007 10:56:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZTNy-0004Lz-0P for autoconf@ietf.org; Thu, 05 Apr 2007 10:56:26 -0400 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZTNu-00037b-Jo for autoconf@ietf.org; Thu, 05 Apr 2007 10:56:25 -0400 Received: from [128.93.17.56] (monteverdi.inria.fr [128.93.17.56]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l35EttIT001606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Apr 2007 16:55:55 +0200 Message-ID: <46150DFB.7090903@inria.fr> Date: Thu, 05 Apr 2007 16:55:55 +0200 From: Emmanuel Baccelli User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: autoconf@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 46150DFB.002 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Autoconf] Updated Problem Statement. Review requested. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hi all, The problem statement has been updated subsequent to the last WG meeting in Prague. Minor clarifications since -02, including: - Interpretation Issue: Section 4.3.2. (Address Uniqueness Requirements) was rephrased not to be wrongly interpreted, as pointed out by C. Perkins. - Terminology Issue: the term "Internet Gateway" leading to some confusions, as pointed out by R. Wakikawa. It is not used anymore, and now the document only mentions MANET Border Routers (MBR), a term already defined in the Architecture draft. Your review and your feedback is requested now. There was already some feedback today about the security section. Anything else? Check this link: http://tools.ietf.org/id/draft-baccelli-autoconf-statement-03.txt Emmanuel _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Apr 05 15:22:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZXXt-0002EJ-V7; Thu, 05 Apr 2007 15:22:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZXXs-0002EC-7k for autoconf@ietf.org; Thu, 05 Apr 2007 15:22:56 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HZXXq-0008UB-Di for autoconf@ietf.org; Thu, 05 Apr 2007 15:22:55 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-119.messagelabs.com!1175800973!19060547!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 9472 invoked from network); 5 Apr 2007 19:22:53 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-11.tower-119.messagelabs.com with SMTP; 5 Apr 2007 19:22:53 -0000 Received: from az33exr02.mot.com ([10.64.251.232]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l35JMrWF004928; Thu, 5 Apr 2007 14:22:53 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l35JMpd5023796; Thu, 5 Apr 2007 14:22:52 -0500 (CDT) Message-ID: <46154C86.7030804@gmail.com> Date: Thu, 05 Apr 2007 21:22:46 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Emmanuel Baccelli Subject: Re: [Autoconf] Updated Problem Statement. Review requested. References: <46150DFB.7090903@inria.fr> In-Reply-To: <46150DFB.7090903@inria.fr> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Emmanuel Baccelli wrote: > Hi all, > > The problem statement has been updated subsequent to the last WG meeting > in Prague. Minor clarifications since -02, including: > > > - Interpretation Issue: Section 4.3.2. (Address Uniqueness Requirements) > was rephrased not to be wrongly interpreted, as pointed out by C. Perkins. > > - Terminology Issue: the term "Internet Gateway" leading to some > confusions, as pointed out by R. Wakikawa. It is not used anymore, and > now the document only mentions MANET Border Routers (MBR), a term > already defined in the Architecture draft. Emmanuel, let me give again some feedback, some I already sent publicly but I don't see it reflected. -Do you consider CGA/HBA, privacy extensions for stateless autoconf and rfc2464 to be autoconfiguration mechanisms? How about teredo and 6to4. Should those be mentioned? -in addition to the problem of assigning addresses, should the problem statement describe the fine distinction between assigning a prefix (by eg dhcp-pd, or 6to4 derivation) and distributing a prefix (like OSPF LSA, or rfc4191). -should the document mention the problem of subscribing to some mandatory IPv6 multicast groups? -should the document state that DHCP (Relay) _can_ manage multi-hop networks? -should the document allow for wired networks as well (not only wireless). Consider that what some people may qualify as MANET nodes are accessed by human controllers via usb (IPv6 over USBnet is btw unspecified but has a nice way of working). -should the document point to existing means of existing 'MANET'-related link-layers for auto-configuring addresses. This is just things that strike me at a first view. Thanks, Alex > > > Your review and your feedback is requested now. There was already some > feedback today about the security section. Anything else? Check this link: > > http://tools.ietf.org/id/draft-baccelli-autoconf-statement-03.txt > > > > Emmanuel > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Apr 05 17:38:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZZeh-0003kN-SW; Thu, 05 Apr 2007 17:38:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZZeg-0003k5-7M for autoconf@ietf.org; Thu, 05 Apr 2007 17:38:06 -0400 Received: from smtp14.wxs.nl ([195.121.247.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZZee-0006UU-Rl for autoconf@ietf.org; Thu, 05 Apr 2007 17:38:06 -0400 Received: from Teco (ip56530916.direct-adsl.nl [86.83.9.22]) by smtp14.wxs.nl (iPlanet Messaging Server 5.2 HotFix 2.15 (built Nov 14 2006)) with ESMTP id <0JG100ENKO33QN@smtp14.wxs.nl> for autoconf@ietf.org; Thu, 05 Apr 2007 23:37:54 +0200 (CEST) Date: Thu, 05 Apr 2007 23:39:11 +0200 From: Teco Boot In-reply-to: <46154C86.7030804@gmail.com> To: 'Emmanuel Baccelli' Message-id: <002b01c777ca$da16b990$0202a8c0@Teco> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acd3t/ZmrBCKynbRRASRLOjWaddx5gACtI2g X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: autoconf@ietf.org Subject: [Autoconf] Updated Problem Statement. Review requested. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hi Emmanuel, Here some comments. RFC4291 defines the interface ID length: 64 bits. Reading 4.1, I could conclude other interface ID lengths are introduced. Is this proposed? On DAD, RFC4429 discusses probability of collisions. At time of writing, there was a discussion on wireless interfaces and DAD, the interface has no state change when moving and thus the DAD is not triggered. A reason accepting a risk on collisions is that interface IDs should be unique if burned in L2 addresses are used and collisions are extremely rare if truly random interface IDs are generated. What is the reason for a new mechanism? It could be DAD for manual configured addresses, but why use these on a MANET interface? Or support for IPv4 Link Local addresses? Teco _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Apr 17 10:59:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdp99-0004Hq-LR; Tue, 17 Apr 2007 10:59:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdp98-0004Hl-Qo for autoconf@ietf.org; Tue, 17 Apr 2007 10:59:06 -0400 Received: from discorde.inria.fr ([192.93.2.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdp96-0000LL-PA for autoconf@ietf.org; Tue, 17 Apr 2007 10:59:06 -0400 Received: from [192.168.0.2] (ras75-3-82-226-221-97.fbx.proxad.net [82.226.221.97]) (authenticated bits=0) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l3HEx1Tl007796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Apr 2007 16:59:02 +0200 Message-ID: <4624E0B5.2030302@inria.fr> Date: Tue, 17 Apr 2007 16:59:01 +0200 From: Emmanuel Baccelli User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: autoconf@ietf.org References: <002b01c777ca$da16b990$0202a8c0@Teco> In-Reply-To: <002b01c777ca$da16b990$0202a8c0@Teco> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 4624E0B5.002 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Autoconf] Re: Updated Problem Statement. Review requested. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hi Teco, see inline: Teco Boot wrote : > Hi Emmanuel, > > Here some comments. > > RFC4291 defines the interface ID length: 64 bits. Reading 4.1, I could > conclude other interface ID lengths are introduced. Is this proposed? No. Section 4.1 does not address interface ID length. It just states that an IPv6 address (128 bits long) must be configured. > > On DAD, RFC4429 discusses probability of collisions. At time of writing, > there was a discussion on wireless interfaces and DAD, the interface has no > state change when moving and thus the DAD is not triggered. A reason > accepting a risk on collisions is that interface IDs should be unique if > burned in L2 addresses are used and collisions are extremely rare if truly > random interface IDs are generated. What is the reason for a new mechanism? > It could be DAD for manual configured addresses, but why use these on a > MANET interface? Or support for IPv4 Link Local addresses? As far as I understand, aside from the address generation aspect, RFC 4429 does not address multihop detection, and does not deal with the standalone (no connection to the infrastructure) case. So in this regard, new DAD mechanisms are needed, if the scenario needs DAD. Emmanuel _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Apr 17 11:13:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdpNP-0002Ns-Jq; Tue, 17 Apr 2007 11:13:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdpNO-0002NR-4Q for autoconf@ietf.org; Tue, 17 Apr 2007 11:13:50 -0400 Received: from discorde.inria.fr ([192.93.2.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdpNN-0007ni-NY for autoconf@ietf.org; Tue, 17 Apr 2007 11:13:50 -0400 Received: from [192.168.0.2] (ras75-3-82-226-221-97.fbx.proxad.net [82.226.221.97]) (authenticated bits=0) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l3HFDmTj011274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Apr 2007 17:13:49 +0200 Message-ID: <4624E42C.3050906@inria.fr> Date: Tue, 17 Apr 2007 17:13:48 +0200 From: Emmanuel Baccelli User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: autoconf@ietf.org Subject: Re: [Autoconf] Updated Problem Statement. Review requested. References: <46150DFB.7090903@inria.fr> <46154C86.7030804@gmail.com> In-Reply-To: <46154C86.7030804@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 4624E42C.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hi Alex, see inline Alexandru Petrescu wrote : > Emmanuel, let me give again some feedback, some I already sent publicly > but I don't see it reflected. > > -Do you consider CGA/HBA, privacy extensions for stateless autoconf and > rfc2464 to be autoconfiguration mechanisms? How about teredo and 6to4. > Should those be mentioned? As far as I know, these can be considered as solutions for address generation schemes. However, they cannot provide any multihopDAD services, another aspect of the problem we are addressing. > -in addition to the problem of assigning addresses, should the problem > statement describe the fine distinction between assigning a prefix (by > eg dhcp-pd, or 6to4 derivation) and distributing a prefix (like OSPF > LSA, or rfc4191). The distinction between routing tasks and configuration tasks should indeed be clear. In my opinion it is already clear enough in the draft? > -should the document mention the problem of subscribing to some > mandatory IPv6 multicast groups? This is out of scope. We are initially focusing on issues concerning address configuration/assignment. No unicast routing, no multicast routing. > -should the document state that DHCP (Relay) _can_ manage multi-hop > networks? The draft already mentions DHCP and hierarchies as existing solutions. It also evokes their shortcommings regarding node mobility, paritioning, merging, multihopDAD etc. > -should the document allow for wired networks as well (not only > wireless). Consider that what some people may qualify as MANET nodes > are accessed by human controllers via usb (IPv6 over USBnet is btw > unspecified but has a nice way of working). For wired networks, I guess standard solutions are fine ;) so there is no additional problem to be mentionned here. > -should the document point to existing means of existing 'MANET'-related > link-layers for auto-configuring addresses. I don't understand your question. We are dealing with layers addressed by the IETF, i.e. not lower layers? > > This is just things that strike me at a first view. > > Thanks, > > Alex > > >> >> >> Your review and your feedback is requested now. There was already some >> feedback today about the security section. Anything else? Check this >> link: >> >> http://tools.ietf.org/id/draft-baccelli-autoconf-statement-03.txt >> >> >> >> Emmanuel >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www1.ietf.org/mailman/listinfo/autoconf >> > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Apr 17 11:36:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdpiq-0004p5-BA; Tue, 17 Apr 2007 11:36:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdpip-0004ou-4l for autoconf@ietf.org; Tue, 17 Apr 2007 11:35:59 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdpin-0006Uh-S6 for autoconf@ietf.org; Tue, 17 Apr 2007 11:35:59 -0400 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.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l3HFZvb1020164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Apr 2007 10:35:57 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l3HFZvUR007505; Tue, 17 Apr 2007 10:35:57 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l3HFZjV9006950; Tue, 17 Apr 2007 10:35:51 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 08:35:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Autoconf] Re: Updated Problem Statement. Review requested. Date: Tue, 17 Apr 2007 08:35:22 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED704@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <4624E0B5.2030302@inria.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Re: Updated Problem Statement. Review requested. Thread-Index: AceBAPYpYthkmxfDTF+K/uCSzKdASwAAoSXA References: <002b01c777ca$da16b990$0202a8c0@Teco> <4624E0B5.2030302@inria.fr> From: "Templin, Fred L" To: "Emmanuel Baccelli" , X-OriginalArrivalTime: 17 Apr 2007 15:35:43.0955 (UTC) FILETIME=[0FE12A30:01C78106] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org > > On DAD, RFC4429 discusses probability of collisions. At=20 > time of writing, > > there was a discussion on wireless interfaces and DAD, the=20 > interface has no > > state change when moving and thus the DAD is not triggered. A reason > > accepting a risk on collisions is that interface IDs should=20 > be unique if > > burned in L2 addresses are used and collisions are=20 > extremely rare if truly > > random interface IDs are generated. What is the reason for=20 > a new mechanism? > > It could be DAD for manual configured addresses, but why=20 > use these on a > > MANET interface? Or support for IPv4 Link Local addresses? >=20 >=20 > As far as I understand, aside from the address generation aspect, RFC=20 > 4429 does not address multihop detection, and does not deal with the=20 > standalone (no connection to the infrastructure) case. So in this=20 > regard, new DAD mechanisms are needed, if the scenario needs DAD. Because of partitions/merges/node movements, as far as I can tell the only way RFC4429 can absolutely assure address uniqueness in MANETs is if the optimistic nodes were to keep their addresses in the optimistic state indefinitely (e.g., by setting 'DupAddrDetectTransmits' to some value representing infinity). That would entail 1) having the optimistic node proactively sending NS every RetransTimer msec, and 2) sending initial packets through a default router and only taking direct paths to neighbors after receiving a Redirect. This might not be optimal for all node types and networks. RFC4429 does make the case that by the Birthday Paradox the odds of collision when using random self-generated addresses like CGAs is "vanishingly small", but unless a node remains "permanently optimistic" an unrecoverable collision is possible. (Of course, the odds of collision for manually-configured or administratively-assigned addresses is *much* higher.) Fred fred.l.templin@boeing.com _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Apr 17 12:41:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdqjp-0004TK-KZ; Tue, 17 Apr 2007 12:41:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdqjo-0004NI-4K for autoconf@ietf.org; Tue, 17 Apr 2007 12:41:04 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hdqjn-0004m0-LD for autoconf@ietf.org; Tue, 17 Apr 2007 12:41:04 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-153.messagelabs.com!1176828062!829507!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 19108 invoked from network); 17 Apr 2007 16:41:02 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-153.messagelabs.com with SMTP; 17 Apr 2007 16:41:02 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l3HGf2eX023329; Tue, 17 Apr 2007 09:41:02 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l3HGf1CL019700; Tue, 17 Apr 2007 11:41:01 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l3HGexIL019653; Tue, 17 Apr 2007 11:41:00 -0500 (CDT) Message-ID: <4624F89C.3000707@gmail.com> Date: Tue, 17 Apr 2007 18:41:00 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Emmanuel Baccelli Subject: Re: [Autoconf] Updated Problem Statement. Review requested. References: <46150DFB.7090903@inria.fr> <46154C86.7030804@gmail.com> <4624E42C.3050906@inria.fr> In-Reply-To: <4624E42C.3050906@inria.fr> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000734-0, 16/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Emmanuel Baccelli wrote: > Hi Alex, see inline Hi Emmanuel, > Alexandru Petrescu wrote : >> Emmanuel, let me give again some feedback, some I already sent >> publicly but I don't see it reflected. >> >> -Do you consider CGA/HBA, privacy extensions for stateless autoconf >> and rfc2464 to be autoconfiguration mechanisms? How about teredo >> and 6to4. Should those be mentioned? > > As far as I know, these can be considered as solutions for address > generation schemes. Ok, I can call these methods 'address generation' schemes instead of 'address auto-configuration'. It's still true that two nodes using any one of those schemes can communicate ok. The node generates an address locally and can use that address to communicate to other nodes. > However, they cannot provide any multihopDAD services, another aspect > of the problem we are addressing. I'm not sure I understand 'multihopDAD service'. It reads to me that the requirement is to have address auto-configuration that delivers unique addresses across a network, uniqueness that resists merging of subnets. This is too generic and corresponds to absolutely no real need. There is no real need of multi-hop sub-networks that merge together at the will of an unknown event, and across which addresses must be and stay unique. I am insisting very much on this. If some two subnetworks merge, we most certainly know why. And we should state that why. >> -in addition to the problem of assigning addresses, should the >> problem statement describe the fine distinction between assigning a >> prefix (by eg dhcp-pd, or 6to4 derivation) and distributing a >> prefix (like OSPF LSA, or rfc4191). > > The distinction between routing tasks and configuration tasks should > indeed be clear. In my opinion it is already clear enough in the > draft? It's not to my reading. The draft doesn't cite neither RFC4191 nor OSPF nor any other routing protocol. I suggest it does, it's very simple to cite RFCs. In your oppinion, in which part of the draft is there explicit that there's a difference between a mechanism for assigning a prefix (DHCP-Prefix Delegation) and a mechanism for distributing a prefix (OSPF LSA, RFC4191)? >> -should the document mention the problem of subscribing to some >> mandatory IPv6 multicast groups? > > This is out of scope. We are initially focusing on issues concerning > address configuration/assignment. No unicast routing, no multicast > routing. I see, I didn't mean multicast routing. For IPv6 Neighbour Discovery on a simple link to work ok it needs to be able to subscribe to link-local multicast groups; not multicast routing. For IPv6 Stateless Address autoconfiguration to work, for DAD, and for DHCPv6 to work, there is an absolute need for the host to be able to subscribe to multicast groups. This is true for any initial phase of any new address autoconfiguration mechanism (usually discovery of something). Hence any new method of address auto-configuration that involves communicating with somebody else in IPv6 will have this need of subscribing to IPv6 multicast groups. >> -should the document state that DHCP (Relay) _can_ manage multi-hop >> networks? > > The draft already mentions DHCP and hierarchies as existing > solutions. It also evokes their shortcommings regarding node > mobility, paritioning, merging, multihopDAD etc. Ok. >> -should the document allow for wired networks as well (not only >> wireless). Consider that what some people may qualify as MANET >> nodes are accessed by human controllers via usb (IPv6 over USBnet >> is btw unspecified but has a nice way of working). > > For wired networks, I guess standard solutions are fine ;) so there > is no additional problem to be mentionned here. Well, an example of MANET network has a number of mobile phones communicating with WiFi. However, for controlling each phone, one needs to connect a laptop to the phone. That connection is with wired USB. There's no IPv6-over-USB specification, so I'm not sure which standard solution you mean :-) I think the problem this draft has is that it assumes that MANET networks are exclusively wireless. I think wired segments can very well appear in a MANET network, at least USB. >> -should the document point to existing means of existing >> 'MANET'-related link-layers for auto-configuring addresses. > > I don't understand your question. We are dealing with layers > addressed by the IETF, i.e. not lower layers? I think all MANET networks are very much dependent to a large extent to the nature of below link-layer. That dictates lots of things about the nature of the MANET network. A number of link-layers addressed at IETF as 'foo', are wireless and can be good MANET constituents. For example IPv6-over-802.15.4 in 6LowPAN WG, very much MANET like. A document in that WG defines alternative means to generate an IPv6 address for such nodes, different than rfc2464. These 802.15.4 nodes are clearly candidates for being MANET nodes. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Apr 19 10:56:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeY3i-0001re-TP; Thu, 19 Apr 2007 10:56:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeY3h-0001bW-5B for autoconf@ietf.org; Thu, 19 Apr 2007 10:56:29 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeY3g-0000C6-Mt for autoconf@ietf.org; Thu, 19 Apr 2007 10:56:29 -0400 Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JGR0089U2U3K8@mailout3.samsung.com> for autoconf@ietf.org; Thu, 19 Apr 2007 23:56:27 +0900 (KST) Received: from Shubhranshu ([107.108.4.124]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0JGR00IHZ2U1MB@mmp2.samsung.com> for autoconf@ietf.org; Thu, 19 Apr 2007 23:56:27 +0900 (KST) Date: Thu, 19 Apr 2007 20:31:59 +0530 From: Shubhranshu Subject: Re: [Autoconf] Updated Problem Statement. Review requested. To: Alexandru Petrescu Message-id: <013201c78293$af985d30$7c046c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Outlook Express 6.00.2900.3028 Content-type: text/plain; reply-type=response; charset=Windows-1252; format=flowed Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <46150DFB.7090903@inria.fr> <46154C86.7030804@gmail.com> <4624E42C.3050906@inria.fr> <4624F89C.3000707@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hello Alex, Please see inline. ----- Original Message ----- From: "Alexandru Petrescu" > >>> -should the document mention the problem of subscribing to some >>> mandatory IPv6 multicast groups? >> I do not see any problem here of subscribing to the multicast groups e.g. for DAD purpose. It would help if you could elaborate on the particular problem you are referring to. >> This is out of scope. We are initially focusing on issues concerning >> address configuration/assignment. No unicast routing, no multicast >> routing. > > I see, I didn't mean multicast routing. > > For IPv6 Neighbour Discovery on a simple link to work ok it needs to be > able to subscribe to link-local multicast groups; not multicast routing. > > For IPv6 Stateless Address autoconfiguration to work, for DAD, and for > DHCPv6 to work, there is an absolute need for the host to be able to > subscribe to multicast groups. > > This is true for any initial phase of any new address autoconfiguration > mechanism (usually discovery of something). Hence any new method of > address auto-configuration that involves communicating with somebody > else in IPv6 will have this need of subscribing to IPv6 multicast groups. Any MANET node can simply join, say, solicited-node multicast address, and send NS message for DAD, just like in any IPv6 network. In the absence of MLD support, these can be statically assigned and would work fine. If there is MLD support, there still seems to be no issue. Do you mean there is need for a new way to achieve this in MANET environment? - Shubhranshu _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Apr 19 13:12:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeaBL-0004tb-OW; Thu, 19 Apr 2007 13:12:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeaBJ-0004tI-Op for autoconf@ietf.org; Thu, 19 Apr 2007 13:12:29 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HeaBI-0007jL-Cs for autoconf@ietf.org; Thu, 19 Apr 2007 13:12:29 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-153.messagelabs.com!1177002747!7998864!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.10] Received: (qmail 28173 invoked from network); 19 Apr 2007 17:12:27 -0000 Received: from motgate6.mot.com (HELO motgate.mot.com) (129.188.136.10) by server-11.tower-153.messagelabs.com with SMTP; 19 Apr 2007 17:12:27 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate.mot.com (8.12.11/Motorola) with ESMTP id l3JHCQ5i019215; Thu, 19 Apr 2007 10:12:26 -0700 (MST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l3JHCOkU021387; Thu, 19 Apr 2007 12:12:25 -0500 (CDT) Message-ID: <4627A2F2.7000208@gmail.com> Date: Thu, 19 Apr 2007 19:12:18 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Shubhranshu Subject: Re: [Autoconf] Updated Problem Statement. Review requested. References: <46150DFB.7090903@inria.fr> <46154C86.7030804@gmail.com> <4624E42C.3050906@inria.fr> <4624F89C.3000707@gmail.com> <013201c78293$af985d30$7c046c6b@sisodomain.com> In-Reply-To: <013201c78293$af985d30$7c046c6b@sisodomain.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000734-0, 16/04/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hi Shubranshu, Shubhranshu wrote: > Hello Alex, > > Please see inline. > > ----- Original Message ----- From: "Alexandru Petrescu" > >> >>>> -should the document mention the problem of subscribing to some >>>> mandatory IPv6 multicast groups? >>> > > I do not see any problem here of subscribing to the multicast groups > e.g. for DAD purpose. It would help if you could elaborate on the > particular problem you are referring to. I might have over-state it as a 'problem'. I think the problem statement draft should (1) list the multicast groups to which a MANET node should subscribe prior to AUTOCONFiguring a unicast IPv6 address. >>> This is out of scope. We are initially focusing on issues >>> concerning address configuration/assignment. No unicast routing, >>> no multicast routing. >> >> I see, I didn't mean multicast routing. >> >> For IPv6 Neighbour Discovery on a simple link to work ok it needs >> to be able to subscribe to link-local multicast groups; not >> multicast routing. >> >> For IPv6 Stateless Address autoconfiguration to work, for DAD, and >> for DHCPv6 to work, there is an absolute need for the host to be >> able to subscribe to multicast groups. >> >> This is true for any initial phase of any new address >> autoconfiguration mechanism (usually discovery of something). Hence >> any new method of address auto-configuration that involves >> communicating with somebody else in IPv6 will have this need of >> subscribing to IPv6 multicast groups. > > > Any MANET node can simply join, say, solicited-node multicast > address, and send NS message for DAD, just like in any IPv6 network. Right, this should be stated, IMHO. But formulated more in AUTOCONF terms, not just DAD terms. Also, any DHCPv6 server must join a all-servers group in order for DHCPv6 to work. I think the document should (2) state that AUTOCONF address autoconfiguration may involve an initial 'discovery' phase and that phase should happen with a multicast method, otherwise it will not scale. (the 'problem' could be that if multicast is not used for discovery then discovery is not scaleable). > In the absence of MLD support, these can be statically assigned and > would work fine. I'm not sure what you mean by 'statically assigning' an IPv6 multicast address. Can you elaborate. Do you mean setting up local filters in a driver? Or you mean 'ifconfig add _a_multicast_address'? I think the latter can't scale, while the former doesn't work on some link-layers. In absence of link-layer multicast support (and not of MLD) then discovery phase of any AUTOCONF mechanism doesn't scale, and that's a problem. > If there is MLD support, there still seems to be no issue. Do you > mean there is need for a new way to achieve this in MANET > environment? No, I didn't mean anything special for a MANET environment. For MANET environment: I've suggested to add _wired_ links to definition of MANET. If there's no MLD support, and no link-layer multicast support, then any address autoconfiguration mechanism can not scale well (the number of dropped discovery messages grows with the number of nodes - should only depend on number of discovered entities). And this is a problem that I meant. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Apr 20 08:38:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HesO3-0004gO-Us; Fri, 20 Apr 2007 08:38:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HesO2-0004gE-Kp for autoconf@ietf.org; Fri, 20 Apr 2007 08:38:50 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HesNz-00022M-Vv for autoconf@ietf.org; Fri, 20 Apr 2007 08:38:50 -0400 Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JGS00LANR4M79@mailout3.samsung.com> for autoconf@ietf.org; Fri, 20 Apr 2007 21:38:46 +0900 (KST) Received: from Shubhranshu ([107.108.4.124]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0JGS00LECR4KDY@mmp2.samsung.com> for autoconf@ietf.org; Fri, 20 Apr 2007 21:38:46 +0900 (KST) Date: Fri, 20 Apr 2007 18:14:21 +0530 From: Shubhranshu Subject: Re: [Autoconf] Updated Problem Statement. Review requested. To: Alexandru Petrescu Message-id: <00bd01c78349$9f703250$7c046c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Outlook Express 6.00.2900.3028 Content-type: text/plain; reply-type=response; charset=Windows-1252; format=flowed Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <46150DFB.7090903@inria.fr> <46154C86.7030804@gmail.com> <4624E42C.3050906@inria.fr> <4624F89C.3000707@gmail.com> <013201c78293$af985d30$7c046c6b@sisodomain.com> <4627A2F2.7000208@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hello Alex, Please see inline. ----- Original Message ----- From: "Alexandru Petrescu" To: "Shubhranshu" Cc: >>>>> -should the document mention the problem of subscribing to some >>>>> mandatory IPv6 multicast groups? >>>> >> >> I do not see any problem here of subscribing to the multicast groups >> e.g. for DAD purpose. It would help if you could elaborate on the >> particular problem you are referring to. > > I might have over-state it as a 'problem'. I think the problem > statement draft should (1) list the multicast groups to which a MANET > node should subscribe prior to AUTOCONFiguring a unicast IPv6 address. > Ok. Let me first see if there is any MANET-Autoconf specific issue here or not and then list or not this in the Autoconf problem statement draft. Please see below comments. >> Any MANET node can simply join, say, solicited-node multicast >> address, and send NS message for DAD, just like in any IPv6 network. > > Right, this should be stated, IMHO. But formulated more in AUTOCONF > terms, not just DAD terms. > > Also, any DHCPv6 server must join a all-servers group in order for > DHCPv6 to work. > > I think the document should (2) state that AUTOCONF address > autoconfiguration may involve an initial 'discovery' phase and that > phase should happen with a multicast method, otherwise it will not > scale. (the 'problem' could be that if multicast is not used for > discovery then discovery is not scaleable). Right, seems we are in agreement here. > >> In the absence of MLD support, these can be statically assigned and >> would work fine. > > I'm not sure what you mean by 'statically assigning' an IPv6 multicast > address. Can you elaborate. Do you mean setting up local filters in a > driver? Or you mean 'ifconfig add _a_multicast_address'? I think the > latter can't scale, while the former doesn't work on some link-layers. I meant setting up local filters in the driver. True, the later cannot scale and filter approach does not work well on all link-layers. Those link types would demand something different such as IPv6-over-foo, just like in any IPv6 network with such link characteristics. > > In absence of link-layer multicast support (and not of MLD) then > discovery phase of any AUTOCONF mechanism doesn't scale, and that's a > problem. Again, I see this as general problem and not specific to MANET environment or am I missing your point here ? > >> If there is MLD support, there still seems to be no issue. Do you >> mean there is need for a new way to achieve this in MANET >> environment? > > No, I didn't mean anything special for a MANET environment. > > For MANET environment: I've suggested to add _wired_ links to definition > of MANET. I think yes, we need to consider wired links as well in the MANET definition. > > If there's no MLD support, and no link-layer multicast support, then any > address autoconfiguration mechanism can not scale well (the number of > dropped discovery messages grows with the number of nodes - should only > depend on number of discovered entities). And this is a problem that I > meant. Agree, thanks for bringing this to the list. - Shubhranshu _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Apr 20 11:32:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hev5v-0003nd-3t; Fri, 20 Apr 2007 11:32:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hev5u-0003mR-6G for autoconf@ietf.org; Fri, 20 Apr 2007 11:32:18 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hev5t-0000R6-PJ for autoconf@ietf.org; Fri, 20 Apr 2007 11:32:18 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-153.messagelabs.com!1177083136!1082246!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 8419 invoked from network); 20 Apr 2007 15:32:16 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-153.messagelabs.com with SMTP; 20 Apr 2007 15:32:16 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l3KFWFPI027698; Fri, 20 Apr 2007 08:32:15 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l3KFWFjI003265; Fri, 20 Apr 2007 10:32:15 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l3KFWDWN003147; Fri, 20 Apr 2007 10:32:14 -0500 (CDT) Message-ID: <4628DCF3.5040505@gmail.com> Date: Fri, 20 Apr 2007 17:32:03 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Shubhranshu Subject: Re: [Autoconf] Updated Problem Statement. Review requested. References: <46150DFB.7090903@inria.fr> <46154C86.7030804@gmail.com> <4624E42C.3050906@inria.fr> <4624F89C.3000707@gmail.com> <013201c78293$af985d30$7c046c6b@sisodomain.com> <4627A2F2.7000208@gmail.com> <00bd01c78349$9f703250$7c046c6b@sisodomain.com> In-Reply-To: <00bd01c78349$9f703250$7c046c6b@sisodomain.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000734-0, 16/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Shubhranshu wrote: > Hello Alex, > > Please see inline. > > ----- Original Message ----- From: "Alexandru Petrescu" > To: "Shubhranshu" > Cc: > >>>>>> -should the document mention the problem of subscribing to >>>>>> some mandatory IPv6 multicast groups? >>>>> >>> >>> I do not see any problem here of subscribing to the multicast >>> groups e.g. for DAD purpose. It would help if you could elaborate >>> on the particular problem you are referring to. >> >> I might have over-state it as a 'problem'. I think the problem >> statement draft should (1) list the multicast groups to which a >> MANET node should subscribe prior to AUTOCONFiguring a unicast IPv6 >> address. >> > > Ok. Let me first see if there is any MANET-Autoconf specific issue > here or not and then list or not this in the Autoconf problem > statement draft. Please see below comments. Yes. >>> Any MANET node can simply join, say, solicited-node multicast >>> address, and send NS message for DAD, just like in any IPv6 >>> network. >> >> Right, this should be stated, IMHO. But formulated more in >> AUTOCONF terms, not just DAD terms. >> >> Also, any DHCPv6 server must join a all-servers group in order for >> DHCPv6 to work. >> >> I think the document should (2) state that AUTOCONF address >> autoconfiguration may involve an initial 'discovery' phase and that >> phase should happen with a multicast method, otherwise it will not >> scale. (the 'problem' could be that if multicast is not used for >> discovery then discovery is not scaleable). > > Right, seems we are in agreement here. Ok, so can we go as far to say that _if_ there's a discovery method using multicast addresses then a MANET multicast address should be used? Or should we say that an existing (non-MANET) multicast address should be used? >>> In the absence of MLD support, these can be statically assigned >>> and would work fine. >> >> I'm not sure what you mean by 'statically assigning' an IPv6 >> multicast address. Can you elaborate. Do you mean setting up >> local filters in a driver? Or you mean 'ifconfig add >> _a_multicast_address'? I think the latter can't scale, while the >> former doesn't work on some link-layers. > > I meant setting up local filters in the driver. Ok, I think this is not the same as doing an 'ifconfig add a IPv6_group_address' on a interface, ie statically assigning. > True, the later cannot scale and filter approach does not work well > on all link-layers. Those link types would demand something different > such as IPv6-over-foo, just like in any IPv6 network with such link > characteristics. So I think until we have references to those IPv6-over-foo behaviours with respect to multicast we can't eliminate the use of MLD, and we should solely rely on MLD in the textual description. >> In absence of link-layer multicast support (and not of MLD) then >> discovery phase of any AUTOCONF mechanism doesn't scale, and that's >> a problem. > > Again, I see this as general problem and not specific to MANET > environment or am I missing your point here ? What link-layers does the MANET environment use? If one knows that then one can say whether there's something specific for a MANET environment or not. >>> If there is MLD support, there still seems to be no issue. Do you >>> mean there is need for a new way to achieve this in MANET >>> environment? >> >> No, I didn't mean anything special for a MANET environment. >> >> For MANET environment: I've suggested to add _wired_ links to >> definition of MANET. > > I think yes, we need to consider wired links as well in the MANET > definition. But both this document and the MANET-arch document draft-ietf-autoconf-manetarch-01.txt only talk 'wireless' not 'wired'. So both should be updated? >> If there's no MLD support, and no link-layer multicast support, >> then any address autoconfiguration mechanism can not scale well >> (the number of dropped discovery messages grows with the number of >> nodes - should only depend on number of discovered entities). And >> this is a problem that I meant. > > Agree, thanks for bringing this to the list. Thanks for acknowledging it. Can we have the scalability issue, its multicast solution and the eventual necessity of multicast address for AUTOCONF purposes in the problem statement draft? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Apr 20 16:04:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HezKv-0000A0-UD; Fri, 20 Apr 2007 16:04:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HezKu-00009O-2M for autoconf@ietf.org; Fri, 20 Apr 2007 16:04:04 -0400 Received: from smtp13.wxs.nl ([195.121.247.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HezKr-0005pV-IE for autoconf@ietf.org; Fri, 20 Apr 2007 16:04:04 -0400 Received: from Teco (ip56530916.direct-adsl.nl [86.83.9.22]) by smtp13.wxs.nl (iPlanet Messaging Server 5.2 HotFix 2.15 (built Nov 14 2006)) with ESMTP id <0JGT00AS9BQJHV@smtp13.wxs.nl> for autoconf@ietf.org; Fri, 20 Apr 2007 22:04:00 +0200 (CEST) Date: Fri, 20 Apr 2007 22:05:00 +0200 From: Teco Boot Subject: RE: [Autoconf] Re: Updated Problem Statement. Review requested. In-reply-to: To: 'Emmanuel Baccelli' Message-id: <006b01c78387$2ec31930$0202a8c0@Teco> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AceBAPYpYthkmxfDTF+K/uCSzKdASwAAoSXAACApGSAAgL4j0A== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org I still think building strong DAD for EUI-64 or true random Interface ID generation is a waste of time and should have extremely low priority. Strong DAD for manual configured addresses or IPv4 link locals could be useful. I'll be thankful for adding this information to the PS document. Teco > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: dinsdag 17 april 2007 17:35 > To: Emmanuel Baccelli; autoconf@ietf.org > Subject: RE: [Autoconf] Re: Updated Problem Statement. Review requested. > > > > On DAD, RFC4429 discusses probability of collisions. At > > time of writing, > > > there was a discussion on wireless interfaces and DAD, the > > interface has no > > > state change when moving and thus the DAD is not triggered. A > > > reason accepting a risk on collisions is that interface IDs should > > be unique if > > > burned in L2 addresses are used and collisions are > > extremely rare if truly > > > random interface IDs are generated. What is the reason for > > a new mechanism? > > > It could be DAD for manual configured addresses, but why > > use these on a > > > MANET interface? Or support for IPv4 Link Local addresses? > > > > > > As far as I understand, aside from the address generation aspect, > > RFC > > 4429 does not address multihop detection, and does not deal with the > > standalone (no connection to the infrastructure) case. So in this > > regard, new DAD mechanisms are needed, if the scenario needs DAD. > > Because of partitions/merges/node movements, as far as I can tell the > only way RFC4429 can absolutely assure address uniqueness in MANETs is > if the optimistic nodes were to keep their addresses in the optimistic > state indefinitely (e.g., by setting 'DupAddrDetectTransmits' to some > value representing infinity). That would entail 1) having the > optimistic node proactively sending NS every RetransTimer msec, and 2) > sending initial packets through a default router and only taking > direct paths to neighbors after receiving a Redirect. > This might not be optimal for all node types and networks. > > RFC4429 does make the case that by the Birthday Paradox the odds of > collision when using random self-generated addresses like CGAs is > "vanishingly small", but unless a node remains "permanently > optimistic" an unrecoverable collision is possible. > (Of course, the odds of collision for manually-configured or > administratively-assigned addresses is *much* higher.) > > Fred > fred.l.templin@boeing.com > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Apr 20 16:17:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HezXv-0003Ok-D1; Fri, 20 Apr 2007 16:17:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HezXu-0003Of-H1 for autoconf@ietf.org; Fri, 20 Apr 2007 16:17:30 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HezXt-0008DO-8N for autoconf@ietf.org; Fri, 20 Apr 2007 16:17:30 -0400 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.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l3KKHJFO029557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 20 Apr 2007 13:17:28 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l3KKHJo0021567; Fri, 20 Apr 2007 13:17:19 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l3KKHDis021417; Fri, 20 Apr 2007 13:17:19 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 13:17:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Autoconf] Re: Updated Problem Statement. Review requested. Date: Fri, 20 Apr 2007 13:16:36 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED734@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <006b01c78387$2ec31930$0202a8c0@Teco> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Re: Updated Problem Statement. Review requested. Thread-Index: AceBAPYpYthkmxfDTF+K/uCSzKdASwAAoSXAACApGSAAgL4j0AAADX8Q References: <006b01c78387$2ec31930$0202a8c0@Teco> From: "Templin, Fred L" To: "Teco Boot" , "Emmanuel Baccelli" X-OriginalArrivalTime: 20 Apr 2007 20:17:13.0912 (UTC) FILETIME=[E2515380:01C78388] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org > I still think building strong DAD for EUI-64 or true random=20 > Interface ID > generation is a waste of time and should have extremely low priority. Other communities (e.g., NETLMM) have pushed back hard when I have raised this same point with them and have stipulated a hard requirement for address uniqueness assurance even for (pseudo)random interface IDs. Their argument is that there can be no dropped calls in an operator's network due to an address collision, no matter how unlikely the event of a collision. Fred fred.l.templin@boeing.com _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Apr 20 22:50:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf5gL-0005Tq-DV; Fri, 20 Apr 2007 22:50:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf5gJ-0005SK-T1 for autoconf@ietf.org; Fri, 20 Apr 2007 22:50:35 -0400 Received: from ccmail.cc.niigata-u.ac.jp ([133.35.23.1] helo=mxav02.cc.niigata-u.ac.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hf5gH-0005r3-LC for autoconf@ietf.org; Fri, 20 Apr 2007 22:50:35 -0400 Received: from mxav02.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5B9EA45458A for ; Sat, 21 Apr 2007 11:50:32 +0900 (JST) Received: from mxav02.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by mxav02.cc.niigata-u.ac.jp (Postfix) with SMTP id 49811454055 for ; Sat, 21 Apr 2007 11:50:32 +0900 (JST) Received: (qmail 19401 invoked from network); 21 Apr 2007 11:50:32 +0900 Received: from unknown (HELO chamame.ie.niigata-u.ac.jp) (133.35.169.34) by mxav02.cc.niigata-u.ac.jp with SMTP; 21 Apr 2007 11:50:32 +0900 Received: (qmail 2137 invoked from network); 21 Apr 2007 11:50:29 +0900 Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 21 Apr 2007 11:50:29 +0900 Message-Id: <7.0.0.16.2.20070421112344.03f81a98@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Sat, 21 Apr 2007 11:51:02 +0900 To: Teco Boot , 'Emmanuel Baccelli' From: mase Subject: RE: [Autoconf] Re: Updated Problem Statement. Review requested. In-Reply-To: <006b01c78387$2ec31930$0202a8c0@Teco> References: <006b01c78387$2ec31930$0202a8c0@Teco> Mime-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1552001087==" Errors-To: autoconf-bounces@ietf.org --===============1552001087== Content-Type: multipart/alternative; boundary="=====================_61883671==.ALT" --=====================_61883671==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Dear Teco, Thank you for your comments. I am thinking to add the following remarks in the end of 4.3.2. Address Uniqueness Requirements of the draft. Does this account for your concern? Thanks, Kenichi "The need for checking uniqueness of addresses that are to be assigned or already assigned and used may depend on the possibilty of address conflicts and the amount of the overhead for checking uniquenes of addresses. For example, if the former is extremely low and the latter is significant, checking uniqueness of addresses may not be used. If the former is not extremely low, checking uniquenss of addresses should be used. " At 05:05 07/04/21, Teco Boot wrote: >I still think building strong DAD for EUI-64 or true random Interface ID >generation is a waste of time and should have extremely low priority. >Strong DAD for manual configured addresses or IPv4 link locals could be >useful. I'll be thankful for adding this information to the PS document. >Teco > > > -----Original Message----- > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > Sent: dinsdag 17 april 2007 17:35 > > To: Emmanuel Baccelli; autoconf@ietf.org > > Subject: RE: [Autoconf] Re: Updated Problem Statement. Review requested. > > > > > > On DAD, RFC4429 discusses probability of collisions. At > > > time of writing, > > > > there was a discussion on wireless interfaces and DAD, the > > > interface has no > > > > state change when moving and thus the DAD is not triggered. A > > > > reason accepting a risk on collisions is that interface IDs should > > > be unique if > > > > burned in L2 addresses are used and collisions are > > > extremely rare if truly > > > > random interface IDs are generated. What is the reason for > > > a new mechanism? > > > > It could be DAD for manual configured addresses, but why > > > use these on a > > > > MANET interface? Or support for IPv4 Link Local addresses? > > > > > > > > > As far as I understand, aside from the address generation aspect, > > > RFC > > > 4429 does not address multihop detection, and does not deal with the > > > standalone (no connection to the infrastructure) case. So in this > > > regard, new DAD mechanisms are needed, if the scenario needs DAD. > > > > Because of partitions/merges/node movements, as far as I can tell the > > only way RFC4429 can absolutely assure address uniqueness in MANETs is > > if the optimistic nodes were to keep their addresses in the optimistic > > state indefinitely (e.g., by setting 'DupAddrDetectTransmits' to some > > value representing infinity). That would entail 1) having the > > optimistic node proactively sending NS every RetransTimer msec, and 2) > > sending initial packets through a default router and only taking > > direct paths to neighbors after receiving a Redirect. > > This might not be optimal for all node types and networks. > > > > RFC4429 does make the case that by the Birthday Paradox the odds of > > collision when using random self-generated addresses like CGAs is > > "vanishingly small", but unless a node remains "permanently > > optimistic" an unrecoverable collision is possible. > > (Of course, the odds of collision for manually-configured or > > administratively-assigned addresses is *much* higher.) > > > > Fred > > fred.l.templin@boeing.com > > > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www1.ietf.org/mailman/listinfo/autoconf > > >_______________________________________________ >Autoconf mailing list >Autoconf@ietf.org >https://www1.ietf.org/mailman/listinfo/autoconf --=====================_61883671==.ALT Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Teco,

Thank you for your comments. I am thinking to add the following remarks in the end of 

4.3.2.  Address Uniqueness Requirements of the draft. Does this
account for your concern?

Thanks,
Kenichi
"The need for checking uniqueness of addresses that are to be assigned or already assigned and used may depend on the possibilty of address conflicts and the amount of the overhead for checking uniquenes of addresses. For example, if the former is extremely low and the latter is significant, checking uniqueness of addresses may not be used. If the former is not extremely low, checking uniquenss of addresses should be used.  "

At 05:05 07/04/21, Teco Boot wrote:
I still think building strong DAD for EUI-64 or true random Interface ID
generation is a waste of time and should have extremely low priority.
Strong DAD for manual configured addresses or IPv4 link locals could be
useful. I'll be thankful for adding this information to the PS document.
Teco

> -----Original Message-----
> From: Templin, Fred L [ mailto:Fred.L.Templin@boeing.com]
> Sent: dinsdag 17 april 2007 17:35
> To: Emmanuel Baccelli; autoconf@ietf.org
> Subject: RE: [Autoconf] Re: Updated Problem Statement. Review requested.
>
> > > On DAD, RFC4429 discusses probability of collisions. At
> > time of writing,
> > > there was a discussion on wireless interfaces and DAD, the
> > interface has no
> > > state change when moving and thus the DAD is not triggered. A
> > > reason accepting a risk on collisions is that interface IDs should
> > be unique if
> > > burned in L2 addresses are used and collisions are
> > extremely rare if truly
> > > random interface IDs are generated. What is the reason for
> > a new mechanism?
> > > It could be DAD for manual configured addresses, but why
> > use these on a
> > > MANET interface? Or support for IPv4 Link Local addresses?
> >
> >
> > As far as I understand, aside from the address generation aspect,
> > RFC
> > 4429 does not address multihop detection, and does not deal with the
> > standalone (no connection to the infrastructure) case. So in this
> > regard, new DAD mechanisms are needed, if the scenario needs DAD.
>
> Because of partitions/merges/node movements, as far as I can tell the
> only way RFC4429 can absolutely assure address uniqueness in MANETs is
> if the optimistic nodes were to keep their addresses in the optimistic
> state indefinitely (e.g., by setting 'DupAddrDetectTransmits' to some
> value representing infinity). That would entail 1) having the
> optimistic node proactively sending NS every RetransTimer msec, and 2)
> sending initial packets through a default router and only taking
> direct paths to neighbors after receiving a Redirect.
> This might not be optimal for all node types and networks.
>
> RFC4429 does make the case that by the Birthday Paradox the odds of
> collision when using random self-generated addresses like CGAs is
> "vanishingly small", but unless a node remains "permanently
> optimistic" an unrecoverable collision is possible.
> (Of course, the odds of collision for manually-configured or
> administratively-assigned addresses is *much* higher.)
>
> Fred
> fred.l.templin@boeing.com
>
> _______________________________________________
> Autoconf mailing list
> Autoconf@ietf.org
> https://www1.ietf.org/mailman/listinfo/autoconf


_______________________________________________
Autoconf mailing list
Autoconf@ietf.org
https://www1.ietf.org/mailman/listinfo/autoconf
--=====================_61883671==.ALT-- --===============1552001087== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf --===============1552001087==-- From autoconf-bounces@ietf.org Sat Apr 21 03:23:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf9wO-0008Tu-AV; Sat, 21 Apr 2007 03:23:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf9wM-0008Tp-ME for autoconf@ietf.org; Sat, 21 Apr 2007 03:23:26 -0400 Received: from server9.hosting2go.nl ([83.137.192.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hf9wL-0005bl-6c for autoconf@ietf.org; Sat, 21 Apr 2007 03:23:26 -0400 Received: (qmail 26334 invoked from network); 21 Apr 2007 09:23:22 +0200 Received: from localhost (127.0.0.1) by localhost with SMTP; 21 Apr 2007 09:23:22 +0200 Received: from ip56530916.direct-adsl.nl (ip56530916.direct-adsl.nl [86.83.9.22]) by webmail.inf-net.nl (Horde MIME library) with HTTP; Sat, 21 Apr 2007 09:23:22 +0200 Message-ID: <20070421092322.sw92t88r7kwc0oso@webmail.inf-net.nl> Date: Sat, 21 Apr 2007 09:23:22 +0200 From: teco@inf-net.nl To: mase Subject: RE: [Autoconf] Re: Updated Problem Statement. Review requested. References: <006b01c78387$2ec31930$0202a8c0@Teco> <7.0.0.16.2.20070421112344.03f81a98@ie.niigata-u.ac.jp> In-Reply-To: <7.0.0.16.2.20070421112344.03f81a98@ie.niigata-u.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1) X-Spam-Score: 0.2 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: autoconf@ietf.org, 'Emmanuel Baccelli' X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Text is fine, thanks. Teco Quoting mase : > Dear Teco, > > Thank you for your comments. I am thinking to add the following remarks > in the end of > 4.3.2. Address Uniqueness Requirements of the draft. Does this account > for your concern? > > Thanks, > Kenichi > > "The need for checking uniqueness of addresses that are to be assigned > or already assigned and used may depend on the possibilty of address > conflicts and the amount of the overhead for checking uniquenes of > addresses. For example, if the former is extremely low and the latter > is significant, checking uniqueness of addresses may not be used. If > the former is not extremely low, checking uniquenss of addresses should > be used. " > > At 05:05 07/04/21, Teco Boot wrote: >> I still think building strong DAD for EUI-64 or true random Interface ID >> generation is a waste of time and should have extremely low priority. >> Strong DAD for manual configured addresses or IPv4 link locals could be >> useful. I'll be thankful for adding this information to the PS document. >> Teco >> >>> -----Original Message----- >>> From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] >>> Sent: dinsdag 17 april 2007 17:35 >>> To: Emmanuel Baccelli; autoconf@ietf.org >>> Subject: RE: [Autoconf] Re: Updated Problem Statement. Review requested. >>> >>> > > On DAD, RFC4429 discusses probability of collisions. At >>> > time of writing, >>> > > there was a discussion on wireless interfaces and DAD, the >>> > interface has no >>> > > state change when moving and thus the DAD is not triggered. A >>> > > reason accepting a risk on collisions is that interface IDs should >>> > be unique if >>> > > burned in L2 addresses are used and collisions are >>> > extremely rare if truly >>> > > random interface IDs are generated. What is the reason for >>> > a new mechanism? >>> > > It could be DAD for manual configured addresses, but why >>> > use these on a >>> > > MANET interface? Or support for IPv4 Link Local addresses? >>> > >>> > >>> > As far as I understand, aside from the address generation aspect, >>> > RFC >>> > 4429 does not address multihop detection, and does not deal with the >>> > standalone (no connection to the infrastructure) case. So in this >>> > regard, new DAD mechanisms are needed, if the scenario needs DAD. >>> >>> Because of partitions/merges/node movements, as far as I can tell the >>> only way RFC4429 can absolutely assure address uniqueness in MANETs is >>> if the optimistic nodes were to keep their addresses in the optimistic >>> state indefinitely (e.g., by setting 'DupAddrDetectTransmits' to some >>> value representing infinity). That would entail 1) having the >>> optimistic node proactively sending NS every RetransTimer msec, and 2) >>> sending initial packets through a default router and only taking >>> direct paths to neighbors after receiving a Redirect. >>> This might not be optimal for all node types and networks. >>> >>> RFC4429 does make the case that by the Birthday Paradox the odds of >>> collision when using random self-generated addresses like CGAs is >>> "vanishingly small", but unless a node remains "permanently >>> optimistic" an unrecoverable collision is possible. >>> (Of course, the odds of collision for manually-configured or >>> administratively-assigned addresses is *much* higher.) >>> >>> Fred >>> fred.l.templin@boeing.com >>> >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> https://www1.ietf.org/mailman/listinfo/autoconf >> >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www1.ietf.org/mailman/listinfo/autoconf _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sat Apr 21 09:30:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfFfZ-0005pl-TV; Sat, 21 Apr 2007 09:30:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfFfY-0005pO-Nq for autoconf@ietf.org; Sat, 21 Apr 2007 09:30:28 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfFfX-00018G-Fz for autoconf@ietf.org; Sat, 21 Apr 2007 09:30:28 -0400 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.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l3LDU88f003240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 21 Apr 2007 08:30:23 -0500 (CDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l3LDU8hC019266; Sat, 21 Apr 2007 06:30:08 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l3LDU7bP019257; Sat, 21 Apr 2007 06:30:07 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Apr 2007 06:30:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Autoconf] Re: Updated Problem Statement. Review requested. Date: Sat, 21 Apr 2007 06:30:07 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED738@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <7.0.0.16.2.20070421112344.03f81a98@ie.niigata-u.ac.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Re: Updated Problem Statement. Review requested. Thread-Index: AceDv9pktWrDaFUoQ/20CMbtYvrb9gAWEnbQ References: <006b01c78387$2ec31930$0202a8c0@Teco> <7.0.0.16.2.20070421112344.03f81a98@ie.niigata-u.ac.jp> From: "Templin, Fred L" To: "mase" , "Teco Boot" , "Emmanuel Baccelli" X-OriginalArrivalTime: 21 Apr 2007 13:30:07.0727 (UTC) FILETIME=[2D9707F0:01C78419] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org > "The need for checking uniqueness of addresses that are to be > assigned or already assigned and used may depend on the possibilty > of address conflicts and the amount of the overhead for checking > uniquenes of addresses. For example, if the former is extremely > low and the latter is significant, checking uniqueness of addresses > may not be used. That would be inconsistent with the position taken by the NETLMM wg, where the only technical reason given for not allowing shared media (such as MANETs) as access links was the possibility of collisions even for (pseudo)random addresses that are highly likely to be unique. Fred fred.l.templin@boeing.com _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sat Apr 21 23:09:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfSSE-0007Ye-IB; Sat, 21 Apr 2007 23:09:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfSSC-0007YU-Mv for autoconf@ietf.org; Sat, 21 Apr 2007 23:09:32 -0400 Received: from ccmail.cc.niigata-u.ac.jp ([133.35.23.1] helo=mxav02.cc.niigata-u.ac.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfSSA-00055b-Bt for autoconf@ietf.org; Sat, 21 Apr 2007 23:09:32 -0400 Received: from mxav02.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id ED2F7454DFE for ; Sun, 22 Apr 2007 12:09:27 +0900 (JST) Received: from mxav02.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by mxav02.cc.niigata-u.ac.jp (Postfix) with SMTP id DB587454DF1 for ; Sun, 22 Apr 2007 12:09:27 +0900 (JST) Received: (qmail 25197 invoked from network); 22 Apr 2007 12:09:27 +0900 Received: from unknown (HELO chamame.ie.niigata-u.ac.jp) (133.35.169.34) by mxav02.cc.niigata-u.ac.jp with SMTP; 22 Apr 2007 12:09:27 +0900 Received: (qmail 17213 invoked from network); 22 Apr 2007 12:09:25 +0900 Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 22 Apr 2007 12:09:25 +0900 Message-Id: <7.0.0.16.2.20070422115119.03f952c8@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Sun, 22 Apr 2007 12:10:02 +0900 To: "Templin, Fred L" , "Teco Boot" , "Emmanuel Baccelli" From: mase Subject: RE: [Autoconf] Re: Updated Problem Statement. Review requested. In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED738@XCH-NW-7V2.nw.nos .boeing.com> References: <006b01c78387$2ec31930$0202a8c0@Teco> <7.0.0.16.2.20070421112344.03f81a98@ie.niigata-u.ac.jp> <39C363776A4E8C4A94691D2BD9D1C9A1029ED738@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hi, Fred, Thank you for your comments. My comments are in line. At 22:30 07/04/21, Templin, Fred L wrote: > > "The need for checking uniqueness of addresses that are to be > > assigned or already assigned and used may depend on the possibilty > > of address conflicts and the amount of the overhead for checking > > uniquenes of addresses. For example, if the former is extremely > > low and the latter is significant, checking uniqueness of addresses > > may not be used. > >That would be inconsistent with the position taken by the >NETLMM wg, where the only technical reason given for not >allowing shared media (such as MANETs) as access links was >the possibility of collisions even for (pseudo)random >addresses that are highly likely to be unique. Besed on your comments, I would propose to modify the text as follows: "The need for checking uniqueness of addresses that are to be assigned or already assigned and used may depend on the possibilty of address conflicts, the amount of the overhead for checking uniquenes of addresses, and address uniqueness requirement from applications. For example, if the former is extremely low and the latter is significant, checking uniqueness of addresses may not be used. If the former is not extremely low, checking uniquenss of addresses should be used. If the application has a hard requirement for address uniqueness assurance, checking uniqueness of addresses should be always used no matter how unlikely the event of addres conflict." I woudl appreciate your comments. Thanks, Kenichi _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Apr 23 01:06:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfqlB-00022M-Sv; Mon, 23 Apr 2007 01:06:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfqlA-00020z-Kf for autoconf@ietf.org; Mon, 23 Apr 2007 01:06:44 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfqlA-00044A-43 for autoconf@ietf.org; Mon, 23 Apr 2007 01:06:44 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3N56I1x017128; Mon, 23 Apr 2007 08:06:33 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 08:06:17 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 00:06:15 -0500 Received: from [10.162.89.30] ([10.162.89.30]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 00:06:14 -0500 Message-ID: <462C3EBE.6000000@nokia.com> Date: Sun, 22 Apr 2007 22:06:06 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ext mase Subject: Re: [Autoconf] Re: Updated Problem Statement. Review requested. References: <006b01c78387$2ec31930$0202a8c0@Teco> <7.0.0.16.2.20070421112344.03f81a98@ie.niigata-u.ac.jp> <39C363776A4E8C4A94691D2BD9D1C9A1029ED738@XCH-NW-7V2.nw.nos.boeing.com> <7.0.0.16.2.20070422115119.03f952c8@ie.niigata-u.ac.jp> In-Reply-To: <7.0.0.16.2.20070422115119.03f952c8@ie.niigata-u.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Apr 2007 05:06:14.0877 (UTC) FILETIME=[1E3BB8D0:01C78565] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hello Mase, Your text is O.K. with me. However, I want to take issue with the suggestion that we have to be restricted by the way things are done in [netlmm]. It seems to me that working group has, at best, very rough consensus, and maybe the people who don't agree have just bailed out in despair. I think that the underlying model of operation in [netlmm] is so radically different than what is envisioned for at hoc networks, that almost no comparison is possible. So, it would be a mistake to accept the same restrictions on the design space that they have accepted. Regards, Charlie P. ext mase wrote: > Hi, Fred, > > Thank you for your comments. My comments are in line. > > At 22:30 07/04/21, Templin, Fred L wrote: >> > "The need for checking uniqueness of addresses that are to be >> > assigned or already assigned and used may depend on the possibilty >> > of address conflicts and the amount of the overhead for checking >> > uniquenes of addresses. For example, if the former is extremely >> > low and the latter is significant, checking uniqueness of addresses >> > may not be used. >> >> That would be inconsistent with the position taken by the >> NETLMM wg, where the only technical reason given for not >> allowing shared media (such as MANETs) as access links was >> the possibility of collisions even for (pseudo)random >> addresses that are highly likely to be unique. > > Besed on your comments, I would propose to modify the text as follows: > > "The need for checking uniqueness of addresses that are to be assigned > or already assigned and used may depend on the possibilty of address > conflicts, the amount of the overhead for checking uniquenes of > addresses, and address uniqueness requirement from applications. For > example, if the former is extremely low and the latter is significant, > checking uniqueness of addresses may not be used. If the former is not > extremely low, checking uniquenss of addresses should be used. If the > application has a hard requirement for address uniqueness assurance, > checking uniqueness of addresses should be always used no matter how > unlikely the event of addres conflict." > > I woudl appreciate your comments. > Thanks, > Kenichi > > > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Apr 23 01:35:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfrD4-0003Qs-78; Mon, 23 Apr 2007 01:35:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfrD2-0003LY-Q9 for autoconf@ietf.org; Mon, 23 Apr 2007 01:35:32 -0400 Received: from ccmail.cc.niigata-u.ac.jp ([133.35.23.1] helo=mxav01.cc.niigata-u.ac.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfrD1-0007eZ-1P for autoconf@ietf.org; Mon, 23 Apr 2007 01:35:32 -0400 Received: from mxav01.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 857734F4BFD for ; Mon, 23 Apr 2007 14:35:27 +0900 (JST) Received: from mxav01.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by mxav01.cc.niigata-u.ac.jp (Postfix) with SMTP id 7299E4F4BE1 for ; Mon, 23 Apr 2007 14:35:27 +0900 (JST) Received: (qmail 29543 invoked from network); 23 Apr 2007 14:35:27 +0900 Received: from unknown (HELO chamame.ie.niigata-u.ac.jp) (133.35.169.34) by mxav01.cc.niigata-u.ac.jp with SMTP; 23 Apr 2007 14:35:27 +0900 Received: (qmail 7895 invoked from network); 23 Apr 2007 14:35:26 +0900 Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 23 Apr 2007 14:35:26 +0900 Message-Id: <7.0.0.16.2.20070423142256.041a00c0@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Mon, 23 Apr 2007 14:36:04 +0900 To: "Charles E. Perkins" From: mase Subject: Re: [Autoconf] Re: Updated Problem Statement. Review requested. In-Reply-To: <462C3EBE.6000000@nokia.com> References: <006b01c78387$2ec31930$0202a8c0@Teco> <7.0.0.16.2.20070421112344.03f81a98@ie.niigata-u.ac.jp> <39C363776A4E8C4A94691D2BD9D1C9A1029ED738@XCH-NW-7V2.nw.nos.boeing.com> <7.0.0.16.2.20070422115119.03f952c8@ie.niigata-u.ac.jp> <462C3EBE.6000000@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hello Charlie, Thank you for your comments and suggestions. I agree with you. I tried to make the text so that it did not introduce any restrictions for MANET problem statement. I would refine the text together with the co-authors. Thanks, Kenichi At 14:06 07/04/23, Charles E. Perkins wrote: >Hello Mase, > >Your text is O.K. with me. However, I want to take issue >with the suggestion that we have to be restricted by the way >things are done in [netlmm]. It seems to me that working >group has, at best, very rough consensus, and maybe the >people who don't agree have just bailed out in despair. >I think that the underlying model of operation in [netlmm] >is so radically different than what is envisioned for at hoc >networks, that almost no comparison is possible. So, >it would be a mistake to accept the same restrictions on >the design space that they have accepted. > >Regards, >Charlie P. > > >ext mase wrote: >>Hi, Fred, >> >>Thank you for your comments. My comments are in line. >> >>At 22:30 07/04/21, Templin, Fred L wrote: >>> > "The need for checking uniqueness of addresses that are to be >>> > assigned or already assigned and used may depend on the possibilty >>> > of address conflicts and the amount of the overhead for checking >>> > uniquenes of addresses. For example, if the former is extremely >>> > low and the latter is significant, checking uniqueness of addresses >>> > may not be used. >>> >>>That would be inconsistent with the position taken by the >>>NETLMM wg, where the only technical reason given for not >>>allowing shared media (such as MANETs) as access links was >>>the possibility of collisions even for (pseudo)random >>>addresses that are highly likely to be unique. >> >>Besed on your comments, I would propose to modify the text as follows: >> >>"The need for checking uniqueness of addresses that are to be >>assigned or already assigned and used may depend on the possibilty >>of address conflicts, the amount of the overhead for checking >>uniquenes of addresses, and address uniqueness requirement from >>applications. For example, if the former is extremely low and the >>latter is significant, checking uniqueness of addresses may not be >>used. If the former is not extremely low, checking uniquenss of >>addresses should be used. If the application has a hard requirement >>for address uniqueness assurance, checking uniqueness of addresses >>should be always used no matter how unlikely the event of addres conflict." >> >>I woudl appreciate your comments. >>Thanks, >>Kenichi >> >> >> >> >>_______________________________________________ >>Autoconf mailing list >>Autoconf@ietf.org >>https://www1.ietf.org/mailman/listinfo/autoconf > > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Apr 23 08:18:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfxVQ-0001of-QE; Mon, 23 Apr 2007 08:18:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfxVP-0001ik-BE for autoconf@ietf.org; Mon, 23 Apr 2007 08:18:55 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfxVO-00032D-Kv for autoconf@ietf.org; Mon, 23 Apr 2007 08:18:55 -0400 Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JGY00M8UA7GJV@mailout1.samsung.com> for autoconf@ietf.org; Mon, 23 Apr 2007 21:18:53 +0900 (KST) Received: from Shubhranshu ([107.108.4.124]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0JGY008MRA7FFX@mmp2.samsung.com> for autoconf@ietf.org; Mon, 23 Apr 2007 21:18:52 +0900 (KST) Date: Mon, 23 Apr 2007 17:54:30 +0530 From: Shubhranshu Subject: Re: [Autoconf] Updated Problem Statement. Review requested. To: Alexandru Petrescu Message-id: <01d101c785a2$5884e8d0$7c046c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Outlook Express 6.00.2900.3028 Content-type: text/plain; reply-type=response; charset=Windows-1252; format=flowed Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <46150DFB.7090903@inria.fr> <46154C86.7030804@gmail.com> <4624E42C.3050906@inria.fr> <4624F89C.3000707@gmail.com> <013201c78293$af985d30$7c046c6b@sisodomain.com> <4627A2F2.7000208@gmail.com> <00bd01c78349$9f703250$7c046c6b@sisodomain.com> <4628DCF3.5040505@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Please see inline ----- Original Message ----- From: "Alexandru Petrescu" To: "Shubhranshu" >>> >>> I think the document should (2) state that AUTOCONF address >>> autoconfiguration may involve an initial 'discovery' phase and that >>> phase should happen with a multicast method, otherwise it will not >>> scale. (the 'problem' could be that if multicast is not used for >>> discovery then discovery is not scaleable). >> >> Right, seems we are in agreement here. > > Ok, so can we go as far to say that _if_ there's a discovery method > using multicast addresses then a MANET multicast address should be used? > Or should we say that an existing (non-MANET) multicast address should > be used? > I see related points that needs to be considered here. Discovery of which nodes are you referring to? If you mean only those nodes that are on the same link then existing addresses could be used. If you are referring to discovery of all nodes in a particular MANET then you might need to use a MANET multicast address. If we are assigning an unique prefix to each Ad-hoc node then we need not discover every other node for address-autoconf purposes. >>>> In the absence of MLD support, these can be statically assigned >>>> and would work fine. >>> >>> I'm not sure what you mean by 'statically assigning' an IPv6 >>> multicast address. Can you elaborate. Do you mean setting up >>> local filters in a driver? Or you mean 'ifconfig add >>> _a_multicast_address'? I think the latter can't scale, while the >>> former doesn't work on some link-layers. >> >> I meant setting up local filters in the driver. > > Ok, I think this is not the same as doing an 'ifconfig add a > IPv6_group_address' on a interface, ie statically assigning. > Right. had used the term to convey approach if nodes are not subscribing to the multicast group. >> True, the later cannot scale and filter approach does not work well >> on all link-layers. Those link types would demand something different >> such as IPv6-over-foo, just like in any IPv6 network with such link >> characteristics. > > So I think until we have references to those IPv6-over-foo behaviours > with respect to multicast we can't eliminate the use of MLD, and we > should solely rely on MLD in the textual description. > Yes. >>> In absence of link-layer multicast support (and not of MLD) then >>> discovery phase of any AUTOCONF mechanism doesn't scale, and that's >>> a problem. >> >> Again, I see this as general problem and not specific to MANET >> environment or am I missing your point here ? > > What link-layers does the MANET environment use? If one knows that then > one can say whether there's something specific for a MANET environment > or not. OK, could have started with this question then. As you would expect, MANET specifications are applicable to all link types. However, AFAIK, MANET implementations & related documents mostly assume WiFi like link characteristics. > >>>> If there is MLD support, there still seems to be no issue. Do you >>>> mean there is need for a new way to achieve this in MANET >>>> environment? >>> >>> No, I didn't mean anything special for a MANET environment. >>> >>> For MANET environment: I've suggested to add _wired_ links to >>> definition of MANET. >> >> I think yes, we need to consider wired links as well in the MANET >> definition. > > But both this document and the MANET-arch document > draft-ietf-autoconf-manetarch-01.txt only talk 'wireless' not 'wired'. > So both should be updated? Yes. > >>> If there's no MLD support, and no link-layer multicast support, >>> then any address autoconfiguration mechanism can not scale well >>> (the number of dropped discovery messages grows with the number of >>> nodes - should only depend on number of discovered entities). And >>> this is a problem that I meant. >> >> Agree, thanks for bringing this to the list. > > Thanks for acknowledging it. Can we have the scalability issue, its > multicast solution and the eventual necessity of multicast address for > AUTOCONF purposes in the problem statement draft? > Agree that if there is no MLD and link-layer multicast support then there could be scalability issues. But here we can consider the case where MLD is supported. - Shubhranshu _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Apr 23 10:23:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfzS9-0003Yh-RU; Mon, 23 Apr 2007 10:23:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfzS8-0003YS-W6 for autoconf@ietf.org; Mon, 23 Apr 2007 10:23:41 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HfzS8-0006M5-KM for autoconf@ietf.org; Mon, 23 Apr 2007 10:23:40 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-119.messagelabs.com!1177338220!15412777!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 14966 invoked from network); 23 Apr 2007 14:23:40 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-119.messagelabs.com with SMTP; 23 Apr 2007 14:23:40 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l3NENdx1005829; Mon, 23 Apr 2007 07:23:39 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l3NENdq4005358; Mon, 23 Apr 2007 09:23:39 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l3NENbfj005243; Mon, 23 Apr 2007 09:23:38 -0500 (CDT) Message-ID: <462CC164.3040108@gmail.com> Date: Mon, 23 Apr 2007 16:23:32 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Shubhranshu Subject: Re: [Autoconf] Updated Problem Statement. Review requested. References: <46150DFB.7090903@inria.fr> <46154C86.7030804@gmail.com> <4624E42C.3050906@inria.fr> <4624F89C.3000707@gmail.com> <013201c78293$af985d30$7c046c6b@sisodomain.com> <4627A2F2.7000208@gmail.com> <00bd01c78349$9f703250$7c046c6b@sisodomain.com> <4628DCF3.5040505@gmail.com> <01d101c785a2$5884e8d0$7c046c6b@sisodomain.com> In-Reply-To: <01d101c785a2$5884e8d0$7c046c6b@sisodomain.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000735-1, 21/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Shubhranshu wrote: > Please see inline > > ----- Original Message ----- From: "Alexandru Petrescu" > To: "Shubhranshu" > >>>> >>>> I think the document should (2) state that AUTOCONF address >>>> autoconfiguration may involve an initial 'discovery' phase and >>>> that phase should happen with a multicast method, otherwise it >>>> will not scale. (the 'problem' could be that if multicast is >>>> not used for discovery then discovery is not scaleable). >>> >>> Right, seems we are in agreement here. >> >> Ok, so can we go as far to say that _if_ there's a discovery >> method using multicast addresses then a MANET multicast address >> should be used? Or should we say that an existing (non-MANET) >> multicast address should be used? >> > > I see related points that needs to be considered here. Discovery of > which nodes are you referring to? If you mean only those nodes that > are on the same link then existing addresses could be used. If you > are referring to discovery of all nodes in a particular MANET then > you might need to use a MANET multicast address. I mean multicast addresses that may be specific to AUTOCONF address auto-configuration. It may indeed be that MANET multicast addresses (those proposed in draft-ietf-manet-iana) are all that's needed. > If we are assigning an unique prefix to each Ad-hoc node then we need > not discover every other node for address-autoconf purposes. This is something I consider open to question in the MANET Architecture document (draft-ietf-autoconf-manetarch-01). I don't think it's neither useful nor necessary to assign _a_ unique prefix (shorter than /128) per node in a MANET network. We can discuss that separately. I think the prefixes are assigned to subnets, not necessarily to routers. I mean both should be possible (assign a prefix per node, and per subnets). >>> True, the later cannot scale and filter approach does not work >>> well on all link-layers. Those link types would demand something >>> different such as IPv6-over-foo, just like in any IPv6 network >>> with such link characteristics. >> >> So I think until we have references to those IPv6-over-foo >> behaviours with respect to multicast we can't eliminate the use of >> MLD, and we should solely rely on MLD in the textual description. >> > > Yes. > >>>> In absence of link-layer multicast support (and not of MLD) >>>> then discovery phase of any AUTOCONF mechanism doesn't scale, >>>> and that's a problem. >>> >>> Again, I see this as general problem and not specific to MANET >>> environment or am I missing your point here ? >> >> What link-layers does the MANET environment use? If one knows that >> then one can say whether there's something specific for a MANET >> environment or not. > > OK, could have started with this question then. As you would expect, > MANET specifications are applicable to all link types. However, > AFAIK, MANET implementations & related documents mostly assume WiFi > like link characteristics. Three things here: (1) necessity to clarify which link-layers have been experimented with MANET protocols, (2) necessity to clarify which link-layer triggers have been used and (3) necessity to that a MANET protocol is actually run at link-layer (no IP addressing). WiFi-like interfaces may cover a wide range of interfaces. 802.11a, b, g, n have different bandwidths and latencies, ranging from simple to almost two orders of magnitude in difference (2Mb up to 250Mb); and uplink/downlink assymmetry characteristics. This should give large differences in terms of IP protocol behaviour, at least in corner extreme cases. Wireless-PAN may also be a very good candidate link-layer. 802.11s is another way of looking at MANET protocols. In this context, would you consider that MANET networks are only for 802.11b 11Mb/s? (where it was experimented presumably the most). The second thing (link-layer triggers) seems to be mentioned in the MANETarch document, section 7 cross-layering; but not enough precise IMHO, simply because it doesn't say which trigger. The third thing is that it _appears_ to me that some forms of MANET protocols specified at IETF may have been used as link-layer protocols, for _some_ link layers. By abuse of language IMHO then people say that a certain IETF MANET protocol is actually in widespread use. But such a IETF MANET protocol run at link layer is completely differently implemented from what's specified at IETF, at least because there are no IP addresses, no port numbers. This relationship between MANET protocols and link-layers (link-layer message encapsulating eg a DYMO-like message) should clarified IMHO. Or I should be directed to a place where that's clarified. >> >>>>> If there is MLD support, there still seems to be no issue. Do >>>>> you mean there is need for a new way to achieve this in MANET >>>>> environment? >>>> >>>> No, I didn't mean anything special for a MANET environment. >>>> >>>> For MANET environment: I've suggested to add _wired_ links to >>>> definition of MANET. >>> >>> I think yes, we need to consider wired links as well in the MANET >>> definition. >> >> But both this document and the MANET-arch document >> draft-ietf-autoconf-manetarch-01.txt only talk 'wireless' not >> 'wired'. So both should be updated? > > Yes. Ok. >>>> If there's no MLD support, and no link-layer multicast support, >>>> then any address autoconfiguration mechanism can not scale well >>>> (the number of dropped discovery messages grows with the number >>>> of nodes - should only depend on number of discovered >>>> entities). And this is a problem that I meant. >>> >>> Agree, thanks for bringing this to the list. >> >> Thanks for acknowledging it. Can we have the scalability issue, >> its multicast solution and the eventual necessity of multicast >> address for AUTOCONF purposes in the problem statement draft? >> > > Agree that if there is no MLD and link-layer multicast support then > there could be scalability issues. But here we can consider the case > where MLD is supported. Ok, I agree to consider only AUTOCONF cases where MLD is supported. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Apr 23 10:26:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfzUk-0006m9-FR; Mon, 23 Apr 2007 10:26:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfzUj-0006ln-4t for autoconf@ietf.org; Mon, 23 Apr 2007 10:26:21 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfzUh-00075p-Rn for autoconf@ietf.org; Mon, 23 Apr 2007 10:26:21 -0400 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.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l3NEQGr5010650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 23 Apr 2007 07:26:17 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l3NEQGJc006354; Mon, 23 Apr 2007 07:26:16 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l3NEQ9fl006070; Mon, 23 Apr 2007 07:26:15 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 07:26:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Autoconf] Re: Updated Problem Statement. Review requested. Date: Mon, 23 Apr 2007 07:26:12 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED73E@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <462C3EBE.6000000@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Re: Updated Problem Statement. Review requested. Thread-Index: AceFZS2yzMSkU8j4TImVGjtqYnMGRwATHojA References: <006b01c78387$2ec31930$0202a8c0@Teco> <7.0.0.16.2.20070421112344.03f81a98@ie.niigata-u.ac.jp> <39C363776A4E8C4A94691D2BD9D1C9A1029ED738@XCH-NW-7V2.nw.nos.boeing.com> <7.0.0.16.2.20070422115119.03f952c8@ie.niigata-u.ac.jp> <462C3EBE.6000000@nokia.com> From: "Templin, Fred L" To: "Charles E. Perkins" , "ext mase" X-OriginalArrivalTime: 23 Apr 2007 14:26:13.0226 (UTC) FILETIME=[5868ECA0:01C785B3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Charlie, > Your text is O.K. with me. However, I want to take issue > with the suggestion that we have to be restricted by the way > things are done in [netlmm]. It is not the point at all that MANET/Autoconf should be compared with NETLMM; rather, NETLMM is a network- based service and MANET/Autoconf is an access technology that could be used in a NETLMM domain. The point is that it was said in the NETLMM wg that MANET/Autoconf would not be supported as an access technology because of the DAD uncertainties - even when self-generated addresses like CGA are used. That is what I mean by an inconsistency should this wg now go ahead and say "let's just forget about DAD". There is another angle to this discussion too which is sure to cause a rathole but was brought up by Jinmei in a different wg. What if not all nodes in the network use the same (pseudo)random address generation scheme, i.e., what if some nodes use the scheme and others use other mechanisms like DHCP or manual config? All birthday paradox considerations go out the window when not all nodes implement the same address generation scheme. Fred fred.l.templin@boeing.com=20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Apr 23 10:30:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfzYr-0001Yw-M1; Mon, 23 Apr 2007 10:30:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfzYq-0001Yo-LD for autoconf@ietf.org; Mon, 23 Apr 2007 10:30:36 -0400 Received: from smtp1.bae.co.uk ([20.133.0.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfzYp-0008LC-0M for autoconf@ietf.org; Mon, 23 Apr 2007 10:30:36 -0400 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l3NEUSAB002493 for ; Mon, 23 Apr 2007 15:30:28 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l3NEUSot028441 for ; Mon, 23 Apr 2007 15:30:28 +0100 Received: from glkms0001.GREENLNK.NET ([10.15.184.1]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 23 Apr 2007 15:30:25 +0100 Received: from glkms2122.GREENLNK.NET ([10.15.184.26]) by glkms0001.GREENLNK.NET with Microsoft SMTPSVC(5.0.2195.6713); Mon, 23 Apr 2007 15:30:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Autoconf] Updated Problem Statement. Review requested. Date: Mon, 23 Apr 2007 15:29:56 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Updated Problem Statement. Review requested. Thread-Index: AceFsxKS+IbDtMnwRmCMMHveg79KmgAAFWzw From: "Dearlove, Christopher \(UK\)" To: "Alexandru Petrescu" , "Shubhranshu" X-OriginalArrivalTime: 23 Apr 2007 14:30:02.0884 (UTC) FILETIME=[E14BF440:01C785B3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org > In this context, would you consider that MANET networks are only for > 802.11b 11Mb/s? (where it was experimented presumably the most). Absolutely definitely not. Not even if you widen to 802.11 (not just b). > This relationship between MANET protocols and link-layers (link-layer > message encapsulating eg a DYMO-like message) should clarified IMHO. The protocols being defined in the MANET WG are being specified in the network layer. > Or I should be directed to a place where that's clarified. RFC 2501. ******************************************************************** 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. ******************************************************************** _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Apr 24 02:25:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgET7-0004VF-QC; Tue, 24 Apr 2007 02:25:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgET6-0004Tn-5t for autoconf@ietf.org; Tue, 24 Apr 2007 02:25:40 -0400 Received: from server9.hosting2go.nl ([83.137.192.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgET5-000585-DL for autoconf@ietf.org; Tue, 24 Apr 2007 02:25:40 -0400 Received: (qmail 10188 invoked from network); 24 Apr 2007 08:25:37 +0200 Received: from unknown (HELO Teco) (217.169.232.211) by server9.hosting2go.nl with SMTP; 24 Apr 2007 08:25:34 +0200 From: "Teco Boot / C2SC" To: "'Templin, Fred L'" , "'Charles E. Perkins'" , "'ext mase'" Date: Tue, 24 Apr 2007 08:25:53 +0200 Message-ID: <000001c78639$7ee82770$a100800a@Teco> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceFZS2yzMSkU8j4TImVGjtqYnMGRwATHojAAAKTh+AAHyZ6IA== In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: autoconf@ietf.org Subject: [Autoconf] Updated Problem Statement. Review requested. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org For random addresses, it is not important if others use manual, dhcp or whatever. For EUI64, some malware / misuse / bugs could be in place. If so, DAD could be disabled also. So DAD doesn't realy help for these. Manual addresses configured explicitly for spoofing cannot be protected by DAD also. SeND would be an option here. Teco > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: maandag 23 april 2007 16:26 > To: Charles E. Perkins; ext mase > Cc: autoconf@ietf.org > Subject: RE: [Autoconf] Re: Updated Problem Statement. Review requested. > > Charlie, > > > Your text is O.K. with me. However, I want to take issue with the > > suggestion that we have to be restricted by the way things are done > > in [netlmm]. > > It is not the point at all that MANET/Autoconf should be compared with > NETLMM; rather, NETLMM is a network- based service and MANET/Autoconf > is an access technology that could be used in a NETLMM domain. The > point is that it was said in the NETLMM wg that MANET/Autoconf would > not be supported as an access technology because of the DAD > uncertainties - even when self-generated addresses like CGA are used. > That is what I mean by an inconsistency should this wg now go ahead > and say "let's just forget about DAD". > > There is another angle to this discussion too which is sure to cause a > rathole but was brought up by Jinmei in a different wg. What if not > all nodes in the network use the same (pseudo)random address > generation scheme, i.e., what if some nodes use the scheme and others > use other mechanisms like DHCP or manual config? All birthday paradox > considerations go out the window when not all nodes implement the same > address generation scheme. > > Fred > fred.l.templin@boeing.com > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Apr 24 06:46:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgIXq-0006v4-PG; Tue, 24 Apr 2007 06:46:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgIXo-0006qB-VM for autoconf@ietf.org; Tue, 24 Apr 2007 06:46:48 -0400 Received: from discorde.inria.fr ([192.93.2.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgIXo-0001Rz-HR for autoconf@ietf.org; Tue, 24 Apr 2007 06:46:48 -0400 Received: from [192.168.0.2] (ras75-3-82-226-221-97.fbx.proxad.net [82.226.221.97]) (authenticated bits=0) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l3OAkg27031078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Apr 2007 12:46:47 +0200 Message-ID: <462DE012.7070905@inria.fr> Date: Tue, 24 Apr 2007 12:46:42 +0200 From: Emmanuel Baccelli User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: autoconf@ietf.org Subject: Re: [Autoconf] Updated Problem Statement. Review requested. References: <000001c78639$7ee82770$a100800a@Teco> In-Reply-To: <000001c78639$7ee82770$a100800a@Teco> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-j-chkmail-Score: MSGID : 462DE012.000 on discorde : j-chkmail score : XX : 5/20 0 0.000 -> 2 X-Miltered: at discorde with ID 462DE012.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by discorde.inria.fr id l3OAkg27031078 X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Folks, I think we are getting carried away. The problem statement must only=20 give the gist of issues concerning acquireing IPv6 addresses for=20 configuration of interfaces on MANET nodes. In that respect, I would like to see the debate not go too much in the=20 solution space. That is: depending on the scenario, and the address=20 generation scheme that is used, DAD is more or less needed, granted. But=20 this is not in contradiction with what is in the problem statement for no= w. The only things we should be looking at in the Problem statement are=20 issues that have to do with: - providing automatic configuration of MANET-local prefixes (or=20 addresses) to each MANET router, whether a MANET Border Router is=20 reachable or not. - if checking uniqueness within a given multi-hop scope is needed,=20 providing automatic detection and resolution of duplicated prefixes (or=20 addresses) within this scope. - if one or more MANET Border Router is reachable, providing automatic=20 configuration of global prefixes (or addresses) to each MANET router. Emmanuel Teco Boot / C2SC a =E9crit : > For random addresses, it is not important if others use manual, dhcp or > whatever.=20 > For EUI64, some malware / misuse / bugs could be in place. If so, DAD c= ould > be disabled also. So DAD doesn't realy help for these. > Manual addresses configured explicitly for spoofing cannot be protected= by > DAD also. SeND would be an option here. > Teco >=20 >=20 >> -----Original Message----- >> From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] >> Sent: maandag 23 april 2007 16:26 >> To: Charles E. Perkins; ext mase >> Cc: autoconf@ietf.org >> Subject: RE: [Autoconf] Re: Updated Problem Statement. Review requeste= d. >> >> Charlie, >> >>> Your text is O.K. with me. However, I want to take issue with the=20 >>> suggestion that we have to be restricted by the way things are done=20 >>> in [netlmm]. >> It is not the point at all that MANET/Autoconf should be compared with= =20 >> NETLMM; rather, NETLMM is a network- based service and MANET/Autoconf=20 >> is an access technology that could be used in a NETLMM domain. The=20 >> point is that it was said in the NETLMM wg that MANET/Autoconf would=20 >> not be supported as an access technology because of the DAD=20 >> uncertainties - even when self-generated addresses like CGA are used.=20 >> That is what I mean by an inconsistency should this wg now go ahead=20 >> and say "let's just forget about DAD". >> >> There is another angle to this discussion too which is sure to cause a= =20 >> rathole but was brought up by Jinmei in a different wg. What if not=20 >> all nodes in the network use the same (pseudo)random address=20 >> generation scheme, i.e., what if some nodes use the scheme and others=20 >> use other mechanisms like DHCP or manual config? All birthday paradox=20 >> considerations go out the window when not all nodes implement the same= =20 >> address generation scheme. >> >> Fred >> fred.l.templin@boeing.com >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www1.ietf.org/mailman/listinfo/autoconf >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf >=20 >=20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Apr 24 09:29:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgL5h-00039S-Ik; Tue, 24 Apr 2007 09:29:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgL5g-00039K-5Q for autoconf@ietf.org; Tue, 24 Apr 2007 09:29:56 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HgL5d-0008Bk-FC for autoconf@ietf.org; Tue, 24 Apr 2007 09:29:55 -0400 Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JH0008IU85RPE@mailout3.samsung.com> for autoconf@ietf.org; Tue, 24 Apr 2007 22:29:51 +0900 (KST) Received: from Shubhranshu ([107.108.4.124]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0JH0001GR85PQ0@mmp1.samsung.com> for autoconf@ietf.org; Tue, 24 Apr 2007 22:29:50 +0900 (KST) Date: Tue, 24 Apr 2007 19:05:28 +0530 From: Shubhranshu To: Alexandru Petrescu Message-id: <020e01c78675$6cc6ec20$7c046c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: autoconf@ietf.org Subject: [Autoconf] MANET-Arch (was: Updated Problem Statement. Review requested) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0837460144==" Errors-To: autoconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0837460144== Content-type: multipart/alternative; boundary="Boundary_(ID_f2WSFRIu32HhHjCWmLKmyA)" This is a multi-part message in MIME format. --Boundary_(ID_f2WSFRIu32HhHjCWmLKmyA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT ----- Original Message ----- From: "Alexandru Petrescu" To: "Shubhranshu" > This is something I consider open to question in the MANET Architecture > document (draft-ietf-autoconf-manetarch-01). I don't think it's neither > useful nor necessary to assign _a_ unique prefix (shorter than /128) per > node in a MANET network. We can discuss that separately. I think the > prefixes are assigned to subnets, not necessarily to routers. I mean > both should be possible (assign a prefix per node, and per subnets). > The architecture allows for a prefix length shorter than /128. It allows a prefix to be allocated to a router and hosts attached to it that form a subnet. There had been a very long discussion on architecture aspect. I recall we had a very good consensus on the MANET-Architecture during IETF-67 Autoconf WG meeting and I believe the draft-ietf-autoconf-manetarch-01 captures them reasonably well. > In this context, would you consider that MANET networks are only for > 802.11b 11Mb/s? (where it was experimented presumably the most). > No. > The second thing (link-layer triggers) seems to be mentioned in the > MANETarch document, section 7 cross-layering; but not enough precise > IMHO, simply because it doesn't say which trigger. > OK. In the current ID version, the Cross-layering section seems much more general. Not sure if authors/others think it is somehow related to the manet-architecture and could be kept in the next version as well ? IMO, providing trigger details seems to be out of scope of this document. - Shubhranshu --Boundary_(ID_f2WSFRIu32HhHjCWmLKmyA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
----- Original Message -----
From: "Alexandru Petrescu" <alexandru.petrescu@gmail.com>
To: "Shubhranshu" <shubhranshu@samsung.com>
 
> This is something I consider open to question in the MANET Architecture
> document (draft-ietf-autoconf-manetarch-01).  I don't think it's neither
> useful nor necessary to assign _a_ unique prefix (shorter than /128) per
> node in a MANET network.  We can discuss that separately.  I think the
> prefixes are assigned to subnets, not necessarily to routers.  I mean
> both should be possible (assign a prefix per node, and per subnets).
>
 
The architecture allows for a prefix length shorter than /128.
It allows a prefix to be allocated to a router and hosts attached
to it that form a subnet.
 
There had been a very long discussion on architecture aspect. I 
recall we had a very good consensus on the MANET-Architecture during
IETF-67 Autoconf WG meeting and I believe the draft-ietf-autoconf-manetarch-01 
captures them reasonably well.
 
 
<snip>
> In this context, would you consider that MANET networks are only for
> 802.11b 11Mb/s? (where it was experimented presumably the most).
>
No.

> The second thing (link-layer triggers) seems to be mentioned in the
> MANETarch document, section 7 cross-layering; but not enough precise
> IMHO, simply because it doesn't say which trigger.
>

 OK.
In the current ID version, the Cross-layering section seems much more
general. Not sure if authors/others think it is somehow related to the
manet-architecture and could be kept in the next version as well ? IMO, providing
trigger details seems to be out of scope of this document.
 
- Shubhranshu
 --Boundary_(ID_f2WSFRIu32HhHjCWmLKmyA)-- --===============0837460144== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf --===============0837460144==-- From autoconf-bounces@ietf.org Tue Apr 24 10:33:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgM4e-00008V-AJ; Tue, 24 Apr 2007 10:32:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgM4c-0008M9-OX for autoconf@ietf.org; Tue, 24 Apr 2007 10:32:54 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HgM4a-0000Kx-ED for autoconf@ietf.org; Tue, 24 Apr 2007 10:32:54 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-153.messagelabs.com!1177425170!911105!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 16343 invoked from network); 24 Apr 2007 14:32:51 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-7.tower-153.messagelabs.com with SMTP; 24 Apr 2007 14:32:51 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id l3OEWopx015508; Tue, 24 Apr 2007 07:32:50 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l3OEWoZJ000781; Tue, 24 Apr 2007 09:32:50 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l3OEWlVv000679; Tue, 24 Apr 2007 09:32:48 -0500 (CDT) Message-ID: <462E1509.1040503@gmail.com> Date: Tue, 24 Apr 2007 16:32:41 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Shubhranshu References: <020e01c78675$6cc6ec20$7c046c6b@sisodomain.com> In-Reply-To: <020e01c78675$6cc6ec20$7c046c6b@sisodomain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000735-2, 23/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: autoconf@ietf.org Subject: [Autoconf] Re: MANET-Arch (was: Updated Problem Statement. Review requested) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Shubhranshu wrote: > ----- Original Message ----- From: "Alexandru Petrescu" > > > To: "Shubhranshu" > > >> This is something I consider open to question in the MANET >> Architecture document (draft-ietf-autoconf-manetarch-01). I don't >> think it's neither useful nor necessary to assign _a_ unique prefix >> (shorter than /128) per node in a MANET network. We can discuss >> that separately. I think the prefixes are assigned to subnets, not >> necessarily to routers. I mean both should be possible (assign a >> prefix per node, and per subnets). >> > > The architecture allows for a prefix length shorter than /128. It > allows a prefix to be allocated to a router and hosts attached to it > that form a subnet. On a router there can be two different prefixes. Something like P1 is 2002:c3d4:6df5:1000::/64 and P2 is 2002:c3d4:6df5:2000::/64. That router has two interfaces and each prefix is valid on one of these interface. There is no _one_ common prefix assigned to the router. The common prefix of P1 and P2 is 2002:c3d4:6df5::/48 and is assigned to another router. Figure 6 of MANETarch document suggests that in order for P:1:: and P:2:: to be assigned to an interface then P:: must be delegated to that router: > If the MANET router is delegated a prefix p::, this prefix can be > assigned to the classic IP link(s), and hosts can be assigned > addresses from within this prefix, and configured with this prefix as > illustrated in Figure 6. Or, I believe it is very possible that P:1::/64 and P:2::/64 be assigned to one router; then P:3::/64 and P:4::/64 to another router and the common _one_ P::/48 assigned to a yet another router. Additionally, I don't see anything MANET-specific that requires that when P:1::/64 and P:2::/64 are assigned to a MANET router's interfaces then the entire P::/48 (the _one_ prefix) must be assigned to that router's interface. That's why I believe saying that _one_ prefix is assigned to a MANET router is generally little valid. One can easily say that _one_ prefix is assigned to a subnet, generally. But one can't say so easily and generally that one prefix is assigned to a router - there are at least two prefixes between which the router routes. Moreover, MANETarch goes on: > However it is worth noting that prefix lengths shorter than /128 > (IPv6) or /32 (IPv4) are possible on the MANET interfaces All interfaces of all routers (MANET or others) usually have prefix lenghts shorter than /128. This is true for IPv4 as well. I don't understand why this paragraph sounds like this were an exception ('it is worth noting that prefixes... are possible') - it's the standard way, not an exception. > Link-local Multicast/Broadcast Scope On a MANET interface, a > link-local multicast or broadcast reaches MANET interfaces of > neighboring nodes, A link-local multicast _what_? A packet that is sent to multicast address with link scope? > regardless of their configured addresses. A link-local multicast or > broadcast on a MANET interfaces is a "neighborcast" and is not > forwarded, nor is it assumed to be received by all nodes within a > MANET. "Neighborcast" is a new term, ack. Ok, it is not received by all nodes within a MANET (what's a MANET? - a link or a set of links connected by routers? because the terminology section of this document calls a MANET a set of MANET routers that is reachable via one or more hops.) But is received by all nodes that have subscribed to that multicast address' group. > The MANET addressing model presented in this section makes a clear > separation between the role of router and host in a MANET, > recognizing that: > > o MANET interfaces are seen only by the router, assumed to be MANET > aware, and running appropriate protocols; Can a real interface be a MANET interface? In that case the host in that box also sees the MANET interface, not only the router in that box. But the entire concept of MANET interface in this draft is a bit weird to me, because it sounds like the MANET interface can not be a real interface. > There had been a very long discussion on architecture aspect. I > recall we had a very good consensus on the MANET-Architecture during > IETF-67 Autoconf WG meeting and I believe the > draft-ietf-autoconf-manetarch-01 captures them reasonably well. That's fine if there's consensus on this document. [...] Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Apr 24 11:08:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgMd7-0000Hf-P7; Tue, 24 Apr 2007 11:08:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgMd6-0000H5-Cx for autoconf@ietf.org; Tue, 24 Apr 2007 11:08:32 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgMd5-0000i1-3G for autoconf@ietf.org; Tue, 24 Apr 2007 11:08:32 -0400 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.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l3OF84Dc005689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 Apr 2007 08:08:19 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l3OF80Rq022573; Tue, 24 Apr 2007 10:08:00 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l3OF7jlm021894; Tue, 24 Apr 2007 10:07:56 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 08:07:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Apr 2007 08:07:51 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED74A@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <000001c78639$7ee82770$a100800a@Teco> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated Problem Statement. Review requested. Thread-Index: AceFZS2yzMSkU8j4TImVGjtqYnMGRwATHojAAAKTh+AAHyZ6IAASNIXg References: <000001c78639$7ee82770$a100800a@Teco> From: "Templin, Fred L" To: "Teco Boot / C2SC" , "Charles E. Perkins" , "ext mase" X-OriginalArrivalTime: 24 Apr 2007 15:07:52.0361 (UTC) FILETIME=[546C6990:01C78682] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: autoconf@ietf.org Subject: [Autoconf] RE: Updated Problem Statement. Review requested. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Teco, =20 > For random addresses, it is not important if others use=20 > manual, dhcp or whatever. Based, on my read, the birthday paradox calculations presume a random assignment scheme being used by all nodes. Therefore, if some nodes use the scheme and others do not the calculations cannot accurately estimate the probability of collision. Again, this issue has been brought up in other working groups. Fred fred.l.templin@boeing.com _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Apr 24 11:33:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgN14-00086d-N6; Tue, 24 Apr 2007 11:33:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgN13-00086B-Gq for autoconf@ietf.org; Tue, 24 Apr 2007 11:33:17 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HgN12-0007Ee-3u for autoconf@ietf.org; Tue, 24 Apr 2007 11:33:17 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-2.tower-153.messagelabs.com!1177428794!4106279!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 9032 invoked from network); 24 Apr 2007 15:33:14 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-153.messagelabs.com with SMTP; 24 Apr 2007 15:33:14 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l3OFXE0Y005365 for ; Tue, 24 Apr 2007 08:33:14 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l3OFXELE012257 for ; Tue, 24 Apr 2007 10:33:14 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l3OFXCsT012187 for ; Tue, 24 Apr 2007 10:33:13 -0500 (CDT) Message-ID: <462E2333.5090905@gmail.com> Date: Tue, 24 Apr 2007 17:33:07 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) 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 000735-2, 23/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Subject: [Autoconf] MANET interfaces X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org MANET-arch document draft-ietf-autoconf-manetarch-01.txt defines MANET interfaces. I take several issues with it. draft says: > MANET Router (MR) an entity that has one or more MANET interfaces and > that engages in a MANET routing protocol. A MANET router may also > have zero or more classic IP interfaces to which hosts may connect. Is it sure that authors meant a MANET router can have zero classic IP interfaces? Or 1? Because if it has 0 classical interfaces then it can not connect, not in a classical way. > 4. MANET Interface Characteristics Can a MANET Interface be a normal regular classical real interface? Or must it always be a virtual interface? I think this should be clarified. I think the main definition of a MANET Interface should say it can be either a real Ethernet interface or a virtual interface. It should be exemplified with interface types that people have run in MANETs. I think the main characteristic, and probably the only fully agreeable, is that a MANET interface is the one on which a MANET protocol is run. > 4.2.1. Semi-Broadcast Interface This pictures how wireless routers rt1, 2 and 3 may have limited visibility at link layer, although rt2 sees both rt1 and rt3. This is a typical problem in wireless (I've personally first saw it in wifi). An IP router trying to achieve the role of rt2 will in no case 'forward' packets, nor will it IP route packets between rt1 and rt3. It will bridge or repeat. > The possibly unique set of adjacent nodes in each node often requires > nodes to forward packets out the same wireless interface as the one > over which they were received. Because of above I think the node shouldn't 'forward' but 'bridge' or 'repeat' packets. I don't think it should be solved at IP layer. ... Figure 4 showing a MANET and how it splits uses the the abbreviation MN for MANET Node. But "MN" term is in wide use as Mobile Node (Mobile IPv6), and defined in an RFC. I suggest to call that a MANET router instead. Still on the characteristics of MANET interfaces. I believe it should be discussed whether or not the address and prefix of a MANET interface are allowed (or are expected) to change during the lifetime of a MANET network. I personally think that most if not all the MANETs that have been built until now have prefixes assigned statically (or manually) and the prefixes and the addresses don't change on these MANET interfaces. I think this should be stated as such, that MANET interfaces don't change their prefixes nor their addresses. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Apr 25 02:28:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgazS-0002eX-Tm; Wed, 25 Apr 2007 02:28:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgazS-0002eM-1Z; Wed, 25 Apr 2007 02:28:34 -0400 Received: from psmtp08.wxs.nl ([195.121.247.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgazQ-0001ZY-P5; Wed, 25 Apr 2007 02:28:34 -0400 Received: from Teco (ip56530916.direct-adsl.nl [86.83.9.22]) by psmtp08.wxs.nl (iPlanet Messaging Server 5.2 HotFix 2.15 (built Nov 14 2006)) with ESMTP id <0JH100HHEJBG1V@psmtp08.wxs.nl>; Wed, 25 Apr 2007 08:28:31 +0200 (MEST) Date: Wed, 25 Apr 2007 08:29:32 +0200 From: Teco Boot In-reply-to: <024701c786f1$7598b190$d3f6200a@amer.cisco.com> To: 'IETF NEMO WG' , autoconf@ietf.org Message-id: <000401c78703$169c4460$0202a8c0@Teco> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AceG79J8Hx3iT/NBSKGK2VVfS88FIAAAP7AAAAPdrSA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Subject: [Autoconf] MR terminology X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hi all, I think the abbreviation MR is confusing. In a NEMO context it stands for Mobile Router, where in MANET context is stands for MANET Router. Those two are very different. RFC 3753 Mobility Related Terminology & draft-ietf-nemo-terminology-06: Mobile Router (MR) A router capable of changing its point of attachment to the network, moving from one link to another link. The MR is capable of forwarding packets between two or more interfaces, and possibly running a dynamic routing protocol modifying the state by which it does packet forwarding. A MR acting as a gateway between an entire mobile network and the rest of the Internet has one or more egress interface(s) and one or more ingress interface(s). Packets forwarded upstream to the rest of the Internet are transmitted through one of the MR's egress interface; packets forwarded downstream to the mobile network are transmitted through one of the MR's ingress interface. draft-ietf-autoconf-manetarch-01: MANET Router (MR) an entity that has one or more MANET interfaces and that engages in a MANET routing protocol. A MANET router may also have zero or more classic IP interfaces to which hosts may connect. So a router could be no MR, a MR, a MR or a MR and MR. Also publish on MANET ML? Regards, Teco _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Apr 25 05:03:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgdPD-0008Ac-Oo; Wed, 25 Apr 2007 05:03:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgdPC-0008AU-HZ for autoconf@ietf.org; Wed, 25 Apr 2007 05:03:18 -0400 Received: from cluster-d.mailcontrol.com ([217.69.20.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgdPA-00061d-M5 for autoconf@ietf.org; Wed, 25 Apr 2007 05:03:18 -0400 Received: from rly07d.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly07d.srv.mailcontrol.com (MailControl) with ESMTP id l3P93AlQ010008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Apr 2007 10:03:14 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly07d.srv.mailcontrol.com (MailControl) id l3P92XPr008760 for autoconf@ietf.org; Wed, 25 Apr 2007 10:02:33 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly07d-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l3P92N3l008513; Wed, 25 Apr 2007 10:02:33 +0100 (BST) Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via smtp id 6800_5e9b2660_f309_11db_8c42_0030482aac25; Wed, 25 Apr 2007 10:45:49 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007042510595529-1181471 ; Wed, 25 Apr 2007 10:59:55 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.126,BAYES_00: -1.665,TOTAL_SCORE: -1.539 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Wed, 25 Apr 2007 10:59:44 +0200 MIME-Version: 1.0 Subject: RE: [Autoconf] Updated Problem Statement. Review requested. X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <000001c78639$7ee82770$a100800a@Teco> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Updated Problem Statement. Review requested. Thread-Index: AceFZS2yzMSkU8j4TImVGjtqYnMGRwATHojAAAKTh+AAHyZ6IAADIYBw References: <000001c78639$7ee82770$a100800a@Teco> To: "Teco Boot / C2SC" , "Templin, Fred L" , "Charles E. Perkins" , "ext mase" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB0E9566@lan-ex-02.panasonic.de> Date: Wed, 25 Apr 2007 10:59:45 +0200 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MailControl A-06-00-00 (www.mailcontrol.com) on 10.68.1.117 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org sorry for jumping in, but I couldn't resist to comment: > For random addresses, it is not important if others use=20 > manual, dhcp or > whatever.=20 > For EUI64, some malware / misuse / bugs could be in place. If=20 > so, DAD could > be disabled also. So DAD doesn't realy help for these. If some nodes in the network don't use random IPv6 addresses, but manually assign addresses, or if EUI64-based IPv6 addresses are not unique due to bugs/misuse, the probability of address conflicts in the network should be higher than with only random addresses. So this is an argument to mandate DAD IMO. Regarding the case that some nodes may disable DAD:=20 - If DAD is mandated in the standard, nodes cannot disable it without violating the standard. Or do you propose to defend against implementations that don't follow the standard?=20 - Furthermore, some in-service DAD solutions allow the other conflict partner or some intermediate nodes to detect the address conflict, even if one conflict partner has disabled DAD.=20 > Manual addresses configured explicitly for spoofing cannot be=20 > protected by > DAD also. SeND would be an option here. Although DAD is not able prevent spoofing attacks, in-service DAD solutions may be able to detect address spoofing attacks in MANETs. Another benefit of DAD: it can even reduce the routing protocol overhead in case of random address assignment. This is due to the following trade-off: with increasing length of the random part of a node's address, the probability of conflits decreases. This is good, but the address compression efficiency and hence the routing protocol overhead may increase at the same time, if some kind of address compression is applied to addresses in routing protocol packets (such as the address blocks in packetbb). The reason is that the common part of the address (which is the redundant information utilized for the compression) gets smaller with increasing length of the random part of the address. Since the reduction of routing protocol overhead due to address compression can be significant especially in case of IPv6 (up to 90%, see, e.g., Kilian Weniger, "PACMAN: Passive autoconfiguration for mobile ad hoc networks", IEEE Journal on Selected Areas in Communications, vol. 23, no. 3, Mar 2005 pp. 507-519) and the gain in terms of overhead reduction can be much higher than the overhead introduced by some DAD solutions, the use of DAD can even reduce the overall signaling overhead.=20 My two cents, Kilian >=20 > > -----Original Message----- > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > Sent: maandag 23 april 2007 16:26 > > To: Charles E. Perkins; ext mase > > Cc: autoconf@ietf.org > > Subject: RE: [Autoconf] Re: Updated Problem Statement.=20 > Review requested. > >=20 > > Charlie, > >=20 > > > Your text is O.K. with me. However, I want to take issue=20 > with the=20 > > > suggestion that we have to be restricted by the way=20 > things are done=20 > > > in [netlmm]. > >=20 > > It is not the point at all that MANET/Autoconf should be=20 > compared with=20 > > NETLMM; rather, NETLMM is a network- based service and=20 > MANET/Autoconf=20 > > is an access technology that could be used in a NETLMM domain. The=20 > > point is that it was said in the NETLMM wg that=20 > MANET/Autoconf would=20 > > not be supported as an access technology because of the DAD=20 > > uncertainties - even when self-generated addresses like CGA=20 > are used.=20 > > That is what I mean by an inconsistency should this wg now go ahead=20 > > and say "let's just forget about DAD". > >=20 > > There is another angle to this discussion too which is sure=20 > to cause a=20 > > rathole but was brought up by Jinmei in a different wg. What if not=20 > > all nodes in the network use the same (pseudo)random address=20 > > generation scheme, i.e., what if some nodes use the scheme=20 > and others=20 > > use other mechanisms like DHCP or manual config? All=20 > birthday paradox=20 > > considerations go out the window when not all nodes=20 > implement the same=20 > > address generation scheme. > >=20 > > Fred > > fred.l.templin@boeing.com > >=20 > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www1.ietf.org/mailman/listinfo/autoconf >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf >=20 >=20 Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Apr 25 05:21:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgdhB-00039v-Mq; Wed, 25 Apr 2007 05:21:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgdhA-00039i-AX for autoconf@ietf.org; Wed, 25 Apr 2007 05:21:52 -0400 Received: from psmtp09.wxs.nl ([195.121.247.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgdh7-0005ZG-BE for autoconf@ietf.org; Wed, 25 Apr 2007 05:21:51 -0400 Received: from Teco (ip56530916.direct-adsl.nl [86.83.9.22]) by psmtp09.wxs.nl (iPlanet Messaging Server 5.2 HotFix 2.15 (built Nov 14 2006)) with ESMTP id <0JH1009IHRC85A@psmtp09.wxs.nl> for autoconf@ietf.org; Wed, 25 Apr 2007 11:21:48 +0200 (MEST) Date: Wed, 25 Apr 2007 11:22:46 +0200 From: Teco Boot Subject: RE: [Autoconf] Updated Problem Statement. Review requested. In-reply-to: <1FEB9B9F2EC38343955D02B2AE86AACB0E9566@lan-ex-02.panasonic.de> To: 'Kilian Weniger' Message-id: <002301c7871b$4b2a5240$0202a8c0@Teco> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AceFZS2yzMSkU8j4TImVGjtqYnMGRwATHojAAAKTh+AAHyZ6IAADIYBwADVFx/A= X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org No misunderstanding, I never suggested disabling DAD and I never will. The problem with MANET DAD is single-hop probing, so two nodes could meet with duplicate addresses, where both did perform DAD but did not see each other at that time. Performing multi-hop DAD and repeating DAD for detecting duplicates when MANETs merge may introduce high overhead. DAD is useful and needed where duplicates are likely and have less usage where duplicates are extremely rare. Proposed text in PS was OK for me. Teco > -----Original Message----- > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > Sent: woensdag 25 april 2007 11:00 > To: Teco Boot / C2SC; Templin, Fred L; Charles E. Perkins; ext mase > Cc: autoconf@ietf.org > Subject: RE: [Autoconf] Updated Problem Statement. Review requested. > > sorry for jumping in, but I couldn't resist to comment: > > > For random addresses, it is not important if others use > > manual, dhcp or > > whatever. > > For EUI64, some malware / misuse / bugs could be in place. If > > so, DAD could > > be disabled also. So DAD doesn't realy help for these. > > If some nodes in the network don't use random IPv6 addresses, but > manually assign addresses, or if EUI64-based IPv6 addresses are not > unique due to bugs/misuse, the probability of address conflicts in the > network should be higher than with only random addresses. So this is an > argument to mandate DAD IMO. > > Regarding the case that some nodes may disable DAD: > - If DAD is mandated in the standard, nodes cannot disable it without > violating the standard. Or do you propose to defend against > implementations that don't follow the standard? > - Furthermore, some in-service DAD solutions allow the other conflict > partner or some intermediate nodes to detect the address conflict, even > if one conflict partner has disabled DAD. > > > Manual addresses configured explicitly for spoofing cannot be > > protected by > > DAD also. SeND would be an option here. > > Although DAD is not able prevent spoofing attacks, in-service DAD > solutions may be able to detect address spoofing attacks in MANETs. > > Another benefit of DAD: it can even reduce the routing protocol overhead > in case of random address assignment. This is due to the following > trade-off: with increasing length of the random part of a node's > address, the probability of conflits decreases. This is good, but the > address compression efficiency and hence the routing protocol overhead > may increase at the same time, if some kind of address compression is > applied to addresses in routing protocol packets (such as the address > blocks in packetbb). The reason is that the common part of the address > (which is the redundant information utilized for the compression) gets > smaller with increasing length of the random part of the address. Since > the reduction of routing protocol overhead due to address compression > can be significant especially in case of IPv6 (up to 90%, see, e.g., > Kilian Weniger, "PACMAN: Passive autoconfiguration for mobile ad hoc > networks", IEEE Journal on Selected Areas in Communications, vol. 23, > no. 3, Mar 2005 pp. 507-519) and the gain in terms of overhead > reduction can be much higher than the overhead introduced by some DAD > solutions, the use of DAD can even reduce the overall signaling > overhead. > > My two cents, > > Kilian > > > > > > -----Original Message----- > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > Sent: maandag 23 april 2007 16:26 > > > To: Charles E. Perkins; ext mase > > > Cc: autoconf@ietf.org > > > Subject: RE: [Autoconf] Re: Updated Problem Statement. > > Review requested. > > > > > > Charlie, > > > > > > > Your text is O.K. with me. However, I want to take issue > > with the > > > > suggestion that we have to be restricted by the way > > things are done > > > > in [netlmm]. > > > > > > It is not the point at all that MANET/Autoconf should be > > compared with > > > NETLMM; rather, NETLMM is a network- based service and > > MANET/Autoconf > > > is an access technology that could be used in a NETLMM domain. The > > > point is that it was said in the NETLMM wg that > > MANET/Autoconf would > > > not be supported as an access technology because of the DAD > > > uncertainties - even when self-generated addresses like CGA > > are used. > > > That is what I mean by an inconsistency should this wg now go ahead > > > and say "let's just forget about DAD". > > > > > > There is another angle to this discussion too which is sure > > to cause a > > > rathole but was brought up by Jinmei in a different wg. What if not > > > all nodes in the network use the same (pseudo)random address > > > generation scheme, i.e., what if some nodes use the scheme > > and others > > > use other mechanisms like DHCP or manual config? All > > birthday paradox > > > considerations go out the window when not all nodes > > implement the same > > > address generation scheme. > > > > > > Fred > > > fred.l.templin@boeing.com > > > > > > _______________________________________________ > > > Autoconf mailing list > > > Autoconf@ietf.org > > > https://www1.ietf.org/mailman/listinfo/autoconf > > > > > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www1.ietf.org/mailman/listinfo/autoconf > > > > > > > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Apr 25 10:28:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgiUJ-0000sY-Dq; Wed, 25 Apr 2007 10:28:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgiUH-0000sS-Fj for autoconf@ietf.org; Wed, 25 Apr 2007 10:28:53 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgiUG-0004nY-2a for autoconf@ietf.org; Wed, 25 Apr 2007 10:28:53 -0400 Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JH200IDW5K23Y@mailout3.samsung.com> for autoconf@ietf.org; Wed, 25 Apr 2007 23:28:50 +0900 (KST) Received: from Shubhranshu ([107.108.4.124]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0JH2000Q45K0RW@mmp1.samsung.com> for autoconf@ietf.org; Wed, 25 Apr 2007 23:28:50 +0900 (KST) Date: Wed, 25 Apr 2007 20:04:28 +0530 From: Shubhranshu Subject: Re: [Autoconf] Updated Problem Statement. Review requested. To: Kilian Weniger Message-id: <020e01c78746$d53354c0$7c046c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Outlook Express 6.00.2900.3028 Content-type: text/plain; reply-type=original; charset=iso-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <000001c78639$7ee82770$a100800a@Teco> <1FEB9B9F2EC38343955D02B2AE86AACB0E9566@lan-ex-02.panasonic.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org ----- Original Message ----- From: "Kilian Weniger" > sorry for jumping in, but I couldn't resist to comment: Your comments are appreciated. One important purpose of this mailing list is to discuss technical details of Ad-hoc network autoconfiguration, within the scope of the WG charter. - Shubhranshu _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Apr 25 11:13:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgjBv-00079l-4g; Wed, 25 Apr 2007 11:13:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgjBu-00079g-CW for autoconf@ietf.org; Wed, 25 Apr 2007 11:13:58 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgjBr-0000JZ-QT for autoconf@ietf.org; Wed, 25 Apr 2007 11:13:58 -0400 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.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l3PFDAqJ026945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Apr 2007 08:13:25 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l3PFDA91002225; Wed, 25 Apr 2007 08:13:10 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l3PFD8NX002148; Wed, 25 Apr 2007 08:13:10 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 08:13:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Autoconf] Updated Problem Statement. Review requested. Date: Wed, 25 Apr 2007 08:13:02 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED752@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB0E9566@lan-ex-02.panasonic.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Updated Problem Statement. Review requested. Thread-Index: AceFZS2yzMSkU8j4TImVGjtqYnMGRwATHojAAAKTh+AAHyZ6IAADIYBwAEFF0LA= References: <000001c78639$7ee82770$a100800a@Teco> <1FEB9B9F2EC38343955D02B2AE86AACB0E9566@lan-ex-02.panasonic.de> From: "Templin, Fred L" To: "Kilian Weniger" , "Teco Boot / C2SC" , "Charles E. Perkins" , "ext mase" X-OriginalArrivalTime: 25 Apr 2007 15:13:03.0267 (UTC) FILETIME=[3826A730:01C7874C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Kilian, Thanks for this; the in-service DAD proposals I think bear close consideration but do they apply only to the proactive routing protocols or also for reactive routing protocols? I won't tout this as a preferred in-service DAD solution, but a "greedy" method would be to have MANET nodes treat addresses they assign to MANET interfaces as "permanently optimistic" (in the RFC4429 sense). That way, the optimistic nodes would perpetually rerun DAD every RetransTimer msec and detect and react appropriately to duplicates that may have occurred during network partitions/merges. But again, would this cover only the proactive routing protocols or also the reactive ones? Thanks - Fred fred.l.templin@boeing.com=20 =20 > -----Original Message----- > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com]=20 > Sent: Wednesday, April 25, 2007 2:00 AM > To: Teco Boot / C2SC; Templin, Fred L; Charles E. Perkins; ext mase > Cc: autoconf@ietf.org > Subject: RE: [Autoconf] Updated Problem Statement. Review requested. >=20 > sorry for jumping in, but I couldn't resist to comment: >=20 > > For random addresses, it is not important if others use=20 > > manual, dhcp or > > whatever.=20 > > For EUI64, some malware / misuse / bugs could be in place. If=20 > > so, DAD could > > be disabled also. So DAD doesn't realy help for these. >=20 > If some nodes in the network don't use random IPv6 addresses, but > manually assign addresses, or if EUI64-based IPv6 addresses are not > unique due to bugs/misuse, the probability of address conflicts in the > network should be higher than with only random addresses. So=20 > this is an > argument to mandate DAD IMO. >=20 > Regarding the case that some nodes may disable DAD:=20 > - If DAD is mandated in the standard, nodes cannot disable it without > violating the standard. Or do you propose to defend against > implementations that don't follow the standard?=20 > - Furthermore, some in-service DAD solutions allow the other conflict > partner or some intermediate nodes to detect the address=20 > conflict, even > if one conflict partner has disabled DAD.=20 >=20 > > Manual addresses configured explicitly for spoofing cannot be=20 > > protected by > > DAD also. SeND would be an option here. >=20 > Although DAD is not able prevent spoofing attacks, in-service DAD > solutions may be able to detect address spoofing attacks in MANETs. >=20 > Another benefit of DAD: it can even reduce the routing=20 > protocol overhead > in case of random address assignment. This is due to the following > trade-off: with increasing length of the random part of a node's > address, the probability of conflits decreases. This is good, but the > address compression efficiency and hence the routing protocol overhead > may increase at the same time, if some kind of address compression is > applied to addresses in routing protocol packets (such as the address > blocks in packetbb). The reason is that the common part of the address > (which is the redundant information utilized for the compression) gets > smaller with increasing length of the random part of the=20 > address. Since > the reduction of routing protocol overhead due to address compression > can be significant especially in case of IPv6 (up to 90%, see, e.g., > Kilian Weniger, "PACMAN: Passive autoconfiguration for mobile ad hoc > networks", IEEE Journal on Selected Areas in Communications, vol. 23, > no. 3, Mar 2005 pp. 507-519) and the gain in terms of overhead > reduction can be much higher than the overhead introduced by some DAD > solutions, the use of DAD can even reduce the overall signaling > overhead.=20 >=20 > My two cents, >=20 > Kilian >=20 > >=20 > > > -----Original Message----- > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > Sent: maandag 23 april 2007 16:26 > > > To: Charles E. Perkins; ext mase > > > Cc: autoconf@ietf.org > > > Subject: RE: [Autoconf] Re: Updated Problem Statement.=20 > > Review requested. > > >=20 > > > Charlie, > > >=20 > > > > Your text is O.K. with me. However, I want to take issue=20 > > with the=20 > > > > suggestion that we have to be restricted by the way=20 > > things are done=20 > > > > in [netlmm]. > > >=20 > > > It is not the point at all that MANET/Autoconf should be=20 > > compared with=20 > > > NETLMM; rather, NETLMM is a network- based service and=20 > > MANET/Autoconf=20 > > > is an access technology that could be used in a NETLMM=20 > domain. The=20 > > > point is that it was said in the NETLMM wg that=20 > > MANET/Autoconf would=20 > > > not be supported as an access technology because of the DAD=20 > > > uncertainties - even when self-generated addresses like CGA=20 > > are used.=20 > > > That is what I mean by an inconsistency should this wg=20 > now go ahead=20 > > > and say "let's just forget about DAD". > > >=20 > > > There is another angle to this discussion too which is sure=20 > > to cause a=20 > > > rathole but was brought up by Jinmei in a different wg.=20 > What if not=20 > > > all nodes in the network use the same (pseudo)random address=20 > > > generation scheme, i.e., what if some nodes use the scheme=20 > > and others=20 > > > use other mechanisms like DHCP or manual config? All=20 > > birthday paradox=20 > > > considerations go out the window when not all nodes=20 > > implement the same=20 > > > address generation scheme. > > >=20 > > > Fred > > > fred.l.templin@boeing.com > > >=20 > > > _______________________________________________ > > > Autoconf mailing list > > > Autoconf@ietf.org > > > https://www1.ietf.org/mailman/listinfo/autoconf > >=20 > >=20 > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www1.ietf.org/mailman/listinfo/autoconf > >=20 > >=20 >=20 >=20 > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke >=20 >=20 >=20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Apr 25 12:46:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgkdO-0004jl-Kk; Wed, 25 Apr 2007 12:46:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgkdN-0004jO-IH for autoconf@ietf.org; Wed, 25 Apr 2007 12:46:25 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgkdL-0006dt-2a for autoconf@ietf.org; Wed, 25 Apr 2007 12:46:25 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3PGjx8M021182; Wed, 25 Apr 2007 19:46:21 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 19:46:10 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 11:45:40 -0500 Received: from [10.162.83.238] ([10.162.83.238]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 11:45:39 -0500 Message-ID: <462F85AA.5090007@nokia.com> Date: Wed, 25 Apr 2007 09:45:30 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ext Teco Boot Subject: Re: [Autoconf] Updated Problem Statement. Review requested. References: <002301c7871b$4b2a5240$0202a8c0@Teco> In-Reply-To: <002301c7871b$4b2a5240$0202a8c0@Teco> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Apr 2007 16:45:39.0631 (UTC) FILETIME=[280083F0:01C78759] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hello Teco, I think we need to distinguish between "Pre-service" requirements and "In-service" requirements (to use the language of the draft). I reckon multi-hop DAD is typically required for pre-service assignment, but not so for in-service DAD. In order to have in-service DAD, someone has to figure out how to avoid a flood of address checking every time any node in the manet briefly goes out of service. Regards, Charlie P. ext Teco Boot wrote: > No misunderstanding, I never suggested disabling DAD and I never will. The > problem with MANET DAD is single-hop probing, so two nodes could meet with > duplicate addresses, where both did perform DAD but did not see each other > at that time. > Performing multi-hop DAD and repeating DAD for detecting duplicates when > MANETs merge may introduce high overhead. DAD is useful and needed where > duplicates are likely and have less usage where duplicates are extremely > rare. Proposed text in PS was OK for me. > Teco > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Apr 25 20:21:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgrk0-0000oX-Hy; Wed, 25 Apr 2007 20:21:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgrk0-0000nv-96 for autoconf@ietf.org; Wed, 25 Apr 2007 20:21:44 -0400 Received: from ccmail.cc.niigata-u.ac.jp ([133.35.23.1] helo=mxav02.cc.niigata-u.ac.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgrjx-0004z6-Th for autoconf@ietf.org; Wed, 25 Apr 2007 20:21:44 -0400 Received: from mxav02.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id F023445439A for ; Thu, 26 Apr 2007 09:21:39 +0900 (JST) Received: from mxav02.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by mxav02.cc.niigata-u.ac.jp (Postfix) with SMTP id DCEE4454261 for ; Thu, 26 Apr 2007 09:21:39 +0900 (JST) Received: (qmail 2597 invoked from network); 26 Apr 2007 09:21:39 +0900 Received: from unknown (HELO chamame.ie.niigata-u.ac.jp) (133.35.169.34) by mxav02.cc.niigata-u.ac.jp with SMTP; 26 Apr 2007 09:21:39 +0900 Received: (qmail 9228 invoked from network); 26 Apr 2007 09:21:39 +0900 Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 26 Apr 2007 09:21:39 +0900 Message-Id: <7.0.0.16.2.20070426085849.040b6fa8@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Thu, 26 Apr 2007 09:22:22 +0900 To: "Charles E. Perkins" , ext Teco Boot From: mase Subject: Re: [Autoconf] Updated Problem Statement. Review requested. In-Reply-To: <462F85AA.5090007@nokia.com> References: <002301c7871b$4b2a5240$0202a8c0@Teco> <462F85AA.5090007@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hello Charlie, My comments are in line. At 01:45 07/04/26, Charles E. Perkins wrote: >Hello Teco, > >I think we need to distinguish between "Pre-service" >requirements and "In-service" requirements (to use the language >of the draft). I reckon multi-hop DAD is typically required >for pre-service assignment, but not so for in-service DAD. Right, if multi-hop DAD means a kind of strong DAD. In-service DAD should of course work as multi-hop DAD (should discover address conflict between nodes beyond one hop. Passive DAD is one of the solutions for in-service DAD. >In order to have in-service DAD, someone has to figure >out how to avoid a flood of address checking every time >any node in the manet briefly goes out of service. When a node comes back after out of service, it may acquire a new tentative address and perform pre-service DAD or it may decide to use the same address it used before out of service and directly enter the state with in-service DAD. We may use passive DAD to avoid a flood of address uniqueness checking. Of course this discussion is for the solution space and not in the scope of PS draft. Regards, Kenichi >Regards, >Charlie P. > > > >ext Teco Boot wrote: >No misunderstanding, I never suggested disabling DAD and I never will. The >problem with MANET DAD is single-hop probing, so two nodes could meet with >duplicate addresses, where both did perform DAD but did not see each other >at that time. >Performing multi-hop DAD and repeating DAD for detecting duplicates when >MANETs merge may introduce high overhead. DAD is useful and needed where >duplicates are likely and have less usage where duplicates are extremely >rare. Proposed text in PS was OK for me. Teco _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Apr 26 03:22:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgyJc-0004Ll-8Z; Thu, 26 Apr 2007 03:22:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgyJa-0004Lg-Ud for autoconf@ietf.org; Thu, 26 Apr 2007 03:22:54 -0400 Received: from cluster-e.mailcontrol.com ([217.79.216.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgyJa-0005rj-6m for autoconf@ietf.org; Thu, 26 Apr 2007 03:22:54 -0400 Received: from rly22e.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly22e.srv.mailcontrol.com (MailControl) with ESMTP id l3Q7MlVM032036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Apr 2007 08:22:50 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly22e.srv.mailcontrol.com (MailControl) id l3Q7M4RY030055 for autoconf@ietf.org; Thu, 26 Apr 2007 08:22:04 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly22e-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l3Q7LxHO029823; Thu, 26 Apr 2007 08:22:04 +0100 (BST) Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via smtp id 4341_84ee3814_f3c4_11db_9671_0030482aac25; Thu, 26 Apr 2007 09:05:30 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007042609202773-1251388 ; Thu, 26 Apr 2007 09:20:27 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.101,BAYES_00: -1.665,TOTAL_SCORE: -1.564 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Thu, 26 Apr 2007 09:20:19 +0200 MIME-Version: 1.0 Subject: RE: [Autoconf] Updated Problem Statement. Review requested. X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED752@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Updated Problem Statement. Review requested. Thread-Index: AceFZS2yzMSkU8j4TImVGjtqYnMGRwATHojAAAKTh+AAHyZ6IAADIYBwAEFF0LAAIXlY4A== References: <000001c78639$7ee82770$a100800a@Teco> <1FEB9B9F2EC38343955D02B2AE86AACB0E9566@lan-ex-02.panasonic.de> <39C363776A4E8C4A94691D2BD9D1C9A1029ED752@XCH-NW-7V2.nw.nos.boeing.com> To: "Templin, Fred L" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB0E9603@lan-ex-02.panasonic.de> Date: Thu, 26 Apr 2007 09:20:15 +0200 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MailControl A-06-00-00 (www.mailcontrol.com) on 10.69.1.132 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hi Fred, I think just as routes can be discovered proactively or on-demand, DAD could also be done proactively or on-demand. Whether this is desirable is another question.=20 On-demand DAD would mean that DAD for an address is triggered, when a node with this address gets involved in a unicast-based application session with another node in the MANET. Of course, on-demand DAD may introduce delay for the first data packets, similar to an on-demand route discovery. Furthermore, nodes that are not involved in unicast application sessions may have duplicate addresses, but that may be ok as long as the nodes do not use the duplicate address. We have done some analysis and simulations with Passive DAD for AODV, where nodes detect conflicts passively by analyzing the routing protocol msgs that are sent by AODV (see the paper I references below). It works if expanding-ring-search is not used (at least not for the initial route discovery). Regards, Kilian > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 > Sent: Mittwoch, 25. April 2007 17:13 > To: Kilian Weniger; Teco Boot / C2SC; Charles E. Perkins; ext mase > Cc: autoconf@ietf.org > Subject: RE: [Autoconf] Updated Problem Statement. Review requested. >=20 > Kilian, >=20 > Thanks for this; the in-service DAD proposals I think > bear close consideration but do they apply only to the > proactive routing protocols or also for reactive routing > protocols? >=20 > I won't tout this as a preferred in-service DAD solution, > but a "greedy" method would be to have MANET nodes treat > addresses they assign to MANET interfaces as "permanently > optimistic" (in the RFC4429 sense). That way, the optimistic > nodes would perpetually rerun DAD every RetransTimer msec > and detect and react appropriately to duplicates that may > have occurred during network partitions/merges. But again, > would this cover only the proactive routing protocols or > also the reactive ones? >=20 > Thanks - Fred > fred.l.templin@boeing.com=20 > =20 >=20 > > -----Original Message----- > > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com]=20 > > Sent: Wednesday, April 25, 2007 2:00 AM > > To: Teco Boot / C2SC; Templin, Fred L; Charles E. Perkins; ext mase > > Cc: autoconf@ietf.org > > Subject: RE: [Autoconf] Updated Problem Statement. Review requested. > >=20 > > sorry for jumping in, but I couldn't resist to comment: > >=20 > > > For random addresses, it is not important if others use=20 > > > manual, dhcp or > > > whatever.=20 > > > For EUI64, some malware / misuse / bugs could be in place. If=20 > > > so, DAD could > > > be disabled also. So DAD doesn't realy help for these. > >=20 > > If some nodes in the network don't use random IPv6 addresses, but > > manually assign addresses, or if EUI64-based IPv6 addresses are not > > unique due to bugs/misuse, the probability of address=20 > conflicts in the > > network should be higher than with only random addresses. So=20 > > this is an > > argument to mandate DAD IMO. > >=20 > > Regarding the case that some nodes may disable DAD:=20 > > - If DAD is mandated in the standard, nodes cannot disable=20 > it without > > violating the standard. Or do you propose to defend against > > implementations that don't follow the standard?=20 > > - Furthermore, some in-service DAD solutions allow the=20 > other conflict > > partner or some intermediate nodes to detect the address=20 > > conflict, even > > if one conflict partner has disabled DAD.=20 > >=20 > > > Manual addresses configured explicitly for spoofing cannot be=20 > > > protected by > > > DAD also. SeND would be an option here. > >=20 > > Although DAD is not able prevent spoofing attacks, in-service DAD > > solutions may be able to detect address spoofing attacks in MANETs. > >=20 > > Another benefit of DAD: it can even reduce the routing=20 > > protocol overhead > > in case of random address assignment. This is due to the following > > trade-off: with increasing length of the random part of a node's > > address, the probability of conflits decreases. This is=20 > good, but the > > address compression efficiency and hence the routing=20 > protocol overhead > > may increase at the same time, if some kind of address=20 > compression is > > applied to addresses in routing protocol packets (such as=20 > the address > > blocks in packetbb). The reason is that the common part of=20 > the address > > (which is the redundant information utilized for the=20 > compression) gets > > smaller with increasing length of the random part of the=20 > > address. Since > > the reduction of routing protocol overhead due to address=20 > compression > > can be significant especially in case of IPv6 (up to 90%, see, e.g., > > Kilian Weniger, "PACMAN: Passive autoconfiguration for mobile ad hoc > > networks", IEEE Journal on Selected Areas in=20 > Communications, vol. 23, > > no. 3, Mar 2005 pp. 507-519) and the gain in terms of overhead > > reduction can be much higher than the overhead introduced=20 > by some DAD > > solutions, the use of DAD can even reduce the overall signaling > > overhead.=20 > >=20 > > My two cents, > >=20 > > Kilian > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > > Sent: maandag 23 april 2007 16:26 > > > > To: Charles E. Perkins; ext mase > > > > Cc: autoconf@ietf.org > > > > Subject: RE: [Autoconf] Re: Updated Problem Statement.=20 > > > Review requested. > > > >=20 > > > > Charlie, > > > >=20 > > > > > Your text is O.K. with me. However, I want to take issue=20 > > > with the=20 > > > > > suggestion that we have to be restricted by the way=20 > > > things are done=20 > > > > > in [netlmm]. > > > >=20 > > > > It is not the point at all that MANET/Autoconf should be=20 > > > compared with=20 > > > > NETLMM; rather, NETLMM is a network- based service and=20 > > > MANET/Autoconf=20 > > > > is an access technology that could be used in a NETLMM=20 > > domain. The=20 > > > > point is that it was said in the NETLMM wg that=20 > > > MANET/Autoconf would=20 > > > > not be supported as an access technology because of the DAD=20 > > > > uncertainties - even when self-generated addresses like CGA=20 > > > are used.=20 > > > > That is what I mean by an inconsistency should this wg=20 > > now go ahead=20 > > > > and say "let's just forget about DAD". > > > >=20 > > > > There is another angle to this discussion too which is sure=20 > > > to cause a=20 > > > > rathole but was brought up by Jinmei in a different wg.=20 > > What if not=20 > > > > all nodes in the network use the same (pseudo)random address=20 > > > > generation scheme, i.e., what if some nodes use the scheme=20 > > > and others=20 > > > > use other mechanisms like DHCP or manual config? All=20 > > > birthday paradox=20 > > > > considerations go out the window when not all nodes=20 > > > implement the same=20 > > > > address generation scheme. > > > >=20 > > > > Fred > > > > fred.l.templin@boeing.com > > > >=20 > > > > _______________________________________________ > > > > Autoconf mailing list > > > > Autoconf@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/autoconf > > >=20 > > >=20 > > > _______________________________________________ > > > Autoconf mailing list > > > Autoconf@ietf.org > > > https://www1.ietf.org/mailman/listinfo/autoconf > > >=20 > > >=20 > >=20 > >=20 > > Panasonic R&D Center Germany GmbH > > 63225 Langen, Hessen, Germany > > Reg: AG Offenbach (Hessen) HRB 33974 > > Managing Director: Thomas Micke > >=20 > >=20 > >=20 >=20 >=20 Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Apr 27 08:07:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhPEj-0008Lt-Hb; Fri, 27 Apr 2007 08:07:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhPEh-00085H-MO for autoconf@ietf.org; Fri, 27 Apr 2007 08:07:39 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhPEg-0008Lo-8R for autoconf@ietf.org; Fri, 27 Apr 2007 08:07:39 -0400 Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JH50094EOCO9R@mailout2.samsung.com> for autoconf@ietf.org; Fri, 27 Apr 2007 21:07:36 +0900 (KST) Received: from Shubhranshu ([107.108.4.124]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0JH500IM7OCHKE@mmp1.samsung.com> for autoconf@ietf.org; Fri, 27 Apr 2007 21:07:36 +0900 (KST) Date: Fri, 27 Apr 2007 17:42:45 +0530 From: Shubhranshu To: autoconf@ietf.org Message-id: <032401c788c5$61799000$7c046c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [Autoconf] Draft-baccelli-autoconf-statement as WG doc X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2041636796==" Errors-To: autoconf-bounces@ietf.org This is a multi-part message in MIME format. --===============2041636796== Content-type: multipart/alternative; boundary="Boundary_(ID_TdAYFd057nKZgDMOXGqakg)" This is a multi-part message in MIME format. --Boundary_(ID_TdAYFd057nKZgDMOXGqakg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT All, The problem statement I-D draft-baccelli-autoconf-statement has been undergoing a few iterations lately, and -absent objections - we'd like to suggest that we move it to a wg document at its next incarnation, reflecting recent discussions at the mailing list. This does not imply that there will not be any more changes to this I-D, but rather that the WG will focus its efforts on developing and finalizing this I-D. Sincerely, Thomas & Shubhranshu --Boundary_(ID_TdAYFd057nKZgDMOXGqakg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
All,

The problem statement I-D draft-baccelli-autoconf-statement has
been undergoing a few iterations lately, and -absent objections - we'd 
like to suggest that we move it to a wg document at its next
incarnation, reflecting recent discussions at the mailing list. This
does not imply that there will not be any more changes to this I-D,
but rather that the WG will focus its efforts on developing and finalizing
this I-D.

Sincerely,
Thomas & Shubhranshu
--Boundary_(ID_TdAYFd057nKZgDMOXGqakg)-- --===============2041636796== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf --===============2041636796==--