From autoconf-bounces@ietf.org Fri Nov 02 16:56: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 1Io3ZG-00074I-T8; Fri, 02 Nov 2007 16:56:38 -0400 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Io3ZF-00073p-9j for autoconf-confirm+ok@megatron.ietf.org; Fri, 02 Nov 2007 16:56:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io3ZF-0006zx-07 for autoconf@ietf.org; Fri, 02 Nov 2007 16:56:37 -0400 Received: from hpsmtp-eml11.kpnxchange.com ([213.75.38.111]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Io3Z7-0006lO-7U for autoconf@ietf.org; Fri, 02 Nov 2007 16:56:31 -0400 Received: from hpsmtp-eml05.kpnxchange.com ([213.75.38.105]) by hpsmtp-eml11.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Nov 2007 21:56:23 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml05.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Nov 2007 21:56:23 +0100 From: "Teco Boot" To: Date: Fri, 2 Nov 2007 21:56:12 +0100 Message-ID: <002301c81d92$cd32fa40$6798eec0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acgdksz8XRtA/qjbRI695LpczP3/Iw== Content-Language: nl X-OriginalArrivalTime: 02 Nov 2007 20:56:23.0441 (UTC) FILETIME=[D3B60010:01C81D92] X-Spam-Score: -1.0 (-) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Autoconf] New peronal ID: draft-boot-autoconf-nemo4manet-00.txt 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 submitted an I-D which describes a complete solution for Autoconf. http://www.ietf.org/internet-drafts/draft-boot-autoconf-nemo4manet-00.txt Please read / review, comments are welcome. I could process some comments before Vancouver (cut-off -01 version: November 19th). Teco. Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007 Abstract Mobile Ad-hoc Networks could be attached to a fixed infrastructure network, like the Internet. This document specifies a mechanism for Border Router discovery and utilization. It provides facilities for choosing the best Border Router, configuring IP addresses needed for using the selected Border Router and providing a path to the selected Border Router. Seamless transition to alternate Border Routers is provided. When mobile nodes in the MANET make use of Mobile IP or NEMO (NEtwork MObility), session continuity is provided. NEMO for MANET is based on NEMO, which utilizes IPv6 mobility support. The NEMO basic support protocol can easily be enhanced to support IPv4, which provides IPv4 support by NEMO for MANET. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 05 05:11:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoyvH-0002be-M6; Mon, 05 Nov 2007 05:11:11 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IoyvF-0002aC-UM for autoconf-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 05:11:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoyvA-0002XG-AN for autoconf@ietf.org; Mon, 05 Nov 2007 05:11:04 -0500 Received: from smtprelay08.ispgateway.de ([80.67.29.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ioyv9-0001dn-KD for autoconf@ietf.org; Mon, 05 Nov 2007 05:11:04 -0500 Received: (qmail 5599 invoked from network); 5 Nov 2007 10:11:01 -0000 Received: from unknown (HELO 0-052.vpn.RWTH-Aachen.DE) (159037@[134.130.240.52]) (envelope-sender ) by smtprelay08.ispgateway.de (qmail-ldap-1.03) with SMTP; 5 Nov 2007 10:11:01 -0000 From: Volker =?iso-8859-1?q?B=F6hme?= To: Alexandru Petrescu Subject: Re: [Autoconf] Effect of IP assignment on routing Date: Mon, 5 Nov 2007 11:10:55 +0100 User-Agent: KMail/1.9.7 References: <200710251729.06666.mailinglisten@volker-boehme.de> <200710301153.09747.mailinglisten@volker-boehme.de> <47289828.7070103@gmail.com> In-Reply-To: <47289828.7070103@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711051110.56233.mailinglisten@volker-boehme.de> 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 On Wednesday 31 October 2007 15:58:48 Alexandru Petrescu wrote: > > (Sorry, I don't know about publications, but why do you ask?) > I am currently writing my diploma thesis and therefore working on an autoconfiguration algorithm for ip address assignment in wireless mesh networks. I was wondering if it is really possible to create an autoconfiguration algorithm which has no requirements regarding the used routing protocol. Currently i would say that every autoconfiguration for ip address assignment at least determines if flat routing or hierarchical routing has to be used within the wireless mesh network. Volker _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 05 05:43: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 1IozQQ-0003So-MC; Mon, 05 Nov 2007 05:43:22 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IozQP-0003Ri-0M for autoconf-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 05:43:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IozQO-0003Ra-Mz for autoconf@ietf.org; Mon, 05 Nov 2007 05:43:20 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IozQN-0003R9-EH for autoconf@ietf.org; Mon, 05 Nov 2007 05:43:20 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-128.messagelabs.com!1194259397!24981055!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 31780 invoked from network); 5 Nov 2007 10:43:18 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-6.tower-128.messagelabs.com with SMTP; 5 Nov 2007 10:43:18 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id lA5AhHdP025064; Mon, 5 Nov 2007 03:43:17 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id lA5AhGFG011868; Mon, 5 Nov 2007 04:43:16 -0600 (CST) 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 lA5AhEEU011847; Mon, 5 Nov 2007 04:43:15 -0600 (CST) Message-ID: <472EF3C1.9040003@gmail.com> Date: Mon, 05 Nov 2007 11:43:13 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Volker_B=F6hme?= Subject: Re: [Autoconf] Effect of IP assignment on routing References: <200710251729.06666.mailinglisten@volker-boehme.de> <200710301153.09747.mailinglisten@volker-boehme.de> <47289828.7070103@gmail.com> <200711051110.56233.mailinglisten@volker-boehme.de> In-Reply-To: <200711051110.56233.mailinglisten@volker-boehme.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 071104-0, 04/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.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 Volker Böhme wrote: > On Wednesday 31 October 2007 15:58:48 Alexandru Petrescu wrote: >> (Sorry, I don't know about publications, but why do you ask?) >> > > I am currently writing my diploma thesis and therefore working on an > autoconfiguration algorithm for ip address assignment in wireless > mesh networks. What are the detail requirements? Should the same address be assigned to a node upon its movement? Or should a different address be assigned to it? Should tunnelling be used or not. Is the 'mesh' made of a single IP subnet or several. Are the IP addresses needing to be unique Internet-wide? subnet-wide? locals only? Which link-layer technology for the 'mesh'. What's different about 'mesh' and 'wireless' compared to traditional networks, from an IP standpoint? > I was wondering if it is really possible to create an > autoconfiguration algorithm which has no requirements regarding the > used routing protocol. Well, yes. DHCP works completely independently of OSPF. But I think a good question is whether an autoconfiguration algorithm is possible (1) without having pre-configured addressing architecture on the network and (2) with dynamically forming subnets (not meshes made of a single IP subnet) and (3) reach - be reachable from - the Internet. > Currently i would say that every autoconfiguration for ip address > assignment at least determines if flat routing or hierarchical > routing has to be used within the wireless mesh network. Probably yes, I don't know. I think DHCP assumes the subnets are already assigned prefixes, don't you think. Dynamic formation of link-local addresses assumes these addresses are not unique Internet-wide. NAT isn't reachable. There may be other ways of assigning addresses that I don't know. 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 Nov 07 06:47:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpjNc-0000Gv-BW; Wed, 07 Nov 2007 06:47:32 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IpjNb-0000Gk-Mk for autoconf-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 06:47:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpjNb-0000Gc-A3 for autoconf@ietf.org; Wed, 07 Nov 2007 06:47:31 -0500 Received: from mho-02-bos.mailhop.org ([63.208.196.179]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpjNZ-0002Zd-PQ for autoconf@ietf.org; Wed, 07 Nov 2007 06:47:31 -0500 Received: from aste-genev-bois-153-1-16-110.w83-112.abo.wanadoo.fr ([83.112.196.110] helo=[192.168.147.106]) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1IpjNY-000P1n-JB; Wed, 07 Nov 2007 11:47:29 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 83.112.196.110 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/jaFtXwyN/9BSoWWKBaNXU Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7DB97653-DC8F-42C4-8577-50CFAFCCE821@thomasclausen.org> Content-Transfer-Encoding: 7bit From: Thomas Clausen Date: Wed, 7 Nov 2007 12:47:20 +0100 To: Emmanuel Baccelli , Ruffino Simone , Shubhranshu Singh , Kenichi Mase X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00134749b78ab2213964fc53d03de937 Cc: autoconf@ietf.org Subject: [Autoconf] Review of draft-ietf-autoconf-statement-01 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 Dear Authors, AUTOCONF wg, I've been reading over the I-D mentioned in subj, and want to share a few comments with you. I hope that the authors can address/discuss these issues on the mailing list and, if appropriate, issue updated I- Ds, that we may be able to make rapid progress. Let me, however, first thank the authors for the effort they've gone through in trying to collect and write this I-D, and keep things consistent with http://www.ietf.org/internet-drafts/draft-ietf- autoconf-manetarch-06.txt -- I know that it is not an easy task to "chase a moving target" such as another I-D while at the same time try to stabilise draft- ietf-autoconf-statement, and I am impressed by the progress made. So THANKS, and keep up the good work ;) I'll also apologise in advance here, since I'm trying to ask a bunch of nasty questions here, but I am not trying to be nasty -- rather, to ask them such that we can get them discussed and addressed quickly. I hope that you will forgive my direct style in the below. I hope that this may also inspire others to carefully review this I- D and provide feedback -- specifically those who are contemplating or already have proposed solutions. Hereby general comments, followed by specific comments to different sections of the I-D. General comments =============== o After a brief read-through the I-D, it is unclear what the focus is. Are we talking about assigning IP addresses? Delegating prefixes? Both? Neither? How does this I-D position itself wrt. prefix delegation and NDP? DHCP? Do either/both of these support both address assignment and prefix delegation? (I *know* the answer to this question, but the discussion related would be useful in the I-D since, I think that it transpires that in this I-D we are really looking at "prefix delegation" -- in which case there may be reasons other than "ad hoc networks' unique characteristics" (to borrow a phrase from the introduction) which may motivate additional/new work. This, to me, is a rather big issue that I would like to be very clear on -- addresses? prefixes? both? neither? o Also after the first read-through, it is not clear that the goal is a mechanism for within MANETs, but that this implies that "outside MANETs" things remain as they are. In other words, this I-D should not indicate that "protocol XXX has shortcomings, so it should be abandoned and replaced by something- yet-to- be-designed". It'd be good to, up-front, state the scope of the problem statement very clearly, and thereby the scope of the protocols-yet-to-be- designed. 1. Introduction =========== o last paragraph states that: "Standard automatic IPv6 address/prefix assignment solutions [5], [3] [4] do not work "as-is" on MANETs due to ad hoc networks' unique characteristics [2], therefore new or modified mechanisms are needed. This document thus details and categorizes the issues that need to be addressed." While that no doubt is true, reading through [2], there are a number of the "unique characteristics" which MANETs have, and which do not immediately spring forward as making existing solutions "not work". As an example, that nodes in a MANET may join/leave freely is more common in a MANET, but is still ocurring in other forms of network (I regularly connect/ disconnect my laptop, and NDP happily gives me addresses). It might be well to be more explicit as to what it is precisely that "does not work" and what "might work, but not efficiently enough". I note that this document has a large educational mission, and as such it is important to be clear on such matters o last paragraph, and also elsewhere in the I-D: "...MANETs due to ad hoc networks' ...." There's through the document a somewhat inconsistent use of "MANET" and of "ad hoc network". Are these interchangeable (in which case a single term should be chosen and used) or are they so subtly different that the subtlety escaped me (in which case it might be helpful to be up-front and define the difference)? This comment applies also to the remainder of the I-D, where the MANET / ad hoc network terminology is neither used consistently nor defined such that any difference is clear. 2. Terminology ============ o Is it a conscious choice not to import RFC2119 terminology? o first paragraph, there's an extraneous space before the colon ":" o plenty of "MANET" vs. "ad hoc network" confusion. o to "Global Address": - what does it mean when saying "An IP address configured on a MANET router"? as far as I am concerned, we usually talk about *delegating* (if appropriate) prefixes to routers, and *assigning* IP addresses to interfaces o to "Standalone MANET": - this is defined by "An independent ad hoc network...." It'd be helpful to understand what "independent" means. - I note that a "Non-standalone MANET" is not defined anywhere. Should we go with the logic of negation, then this would become "A dependent ad hoc network....." - Later in the I-D (3.1 and 3.2) you talk about "Standalone" as opposed to "Connected". Is the difference between these two to be found in the presence of a "MANET border router", as is indicated in 3.2? If so, then stating this clearly in the terminology section might help. Also see comments to 3.3 below. o to "Address Generation".....I do not think (but Chris will confirm/ correct this, I gather ;) ) that it is correct English to say ".....in view to configure...". Could it not become "with the purpose of" - or something similar - instead? o to "Address Generation" and "Address Assignment": - first, there's a logical issue that I think is unclear: * "address generation" yields a "tentative address" * "address assignment" assigns a generated address (I assume the address resulting from "address generation") to an interface This leads me to read that "address assignment means configuring an interface with a tentative address" -- is that intentional? At what point does an interface get a non-tentative address assigned? - Second, here, we talk about addresses. Are we concerned with addresses or prefixes? How do prefixes appear and are delegated to routers? o to "Pre/In-service address uniqueness": - again, here the I-D talks about addresses. How about prefixes? - something is "unique within a certain scope". What is the definition of "scope"? What "is" a scope? (Playing the devils advocate here) do you by "scope" really mean "subnet"? 3.1 Standalone MANET and 3.2 Connected MANET ======================================== o as discussed above, the definition of a standalone and connected MANET is fuzzy to me. It reads as if it can apply to: - a network where there is no MANET border router present; - a network where there is a MANET border router present, yet this MANET border router does not have a prefix from which it can assign/delegate addresses/ prefixes; - a network where there is a MANET border router present, which has authority of a prefix. Of course, this comes down to the fact that "MANET border router" from a router-guys point-of-view may simply be an entity forwarding traffic not destined to itself -- which is exactly what the I-D states, saying that "MANET routers may generate traffic destined to remote hosts" (may MANET routers also receive traffic from such remote hosts, btw.? If so, does it happen directly, or through an ill-viewed technique which rhymes with "CAT"?) For AUTOCONF, it seems that there might be some underlying assumptions as to if it also runs "something else on its interfaces which can autoconfigure MANET routers", but this is not clearly spelled out. Would it be possible to be much more explicit on this item? o This is only to 3.1.......in second paragraph, you write "pre- configured local or global IP addresses (or prefixes)" - what's a "local address"? - what's a "local prefix"? - can it have either? both? Again, the fact that we do not know (at least, the I-D does not make it clear) at this point if the aim is "something with addresses" or "something with prefixes", then this seems unclear, Also, is "local address" == "Link Local Address", or is it a "MANET Local Address" as defined in this I-D in the terminology section? 4. Problem Statement ================= o the crux of this section is, that it talks about addresses and prefixes as if these are interchangeable, yet nowhere is this motivated. Taking a purely academic viewpoint, one may argue that an address just is a prefix of length==ADDRESSLENGTH, and yes, one can argue this way. However, in case of any mechanism for continued address uniqueness verification, it may be important to make the distinction. Assuming that MR1 has the prefix p:1:: delegated, and MR2 has the prefix p:2:: delegated, then MR1 and MR2 are each responsible for the uniqueness within p:1:: and p:2:: respectively, whereas "the MANET" is responsible for simply assuring that MR1 and MR2 have unique prefixes delegated. In case we are talking about address assignment, not prefix delegation, then if MR1 has 3 hosts attached, these might get addresses p: 1::3 p:2::4 and p:2::5, all assigned "from outside MR1" -- and thus, any continued address uniqueness (or duplicate address detection) would not be among the MANET routers, but also involve attached hosts which would otherwise not be MANET aware. It might be evident to the authors and to the autoconf WG how to think about this, but I think that it is something that should be made clear in this I-D -- and I find that it is not. o in 4.1, does a MANET router *need* to configure a link-local address on its MANET interface? A /128? a MLA? I have run numerous MANETs where I did not have a link-local address on the MANET interface, and I wonder why that is broken since, in practice, it runs just fine? o in 4.1, I have a little difficulty with the second paragraph. In this, it is clearly said (for the first time) that the goal is prefix delegation (and in IPv6......also for the first time). It tries to make a distinction between "routing" and "autoconfiguration", but I find that this is a slight bit backwards. Is it more complicated than that: - autoconf: getting an unique prefix assigned to each router - routing: propagating information about which prefixes are physically where in the network (and subsequently finding paths etc...) I may be missing something subtle, and the way this section appeared made me think that this might indeed be the case ;) o for 4.2 "Existing Protocols' Shortcomings": - see general comment, specifically: - do other protocols do prefix delegation? how? (rhetoric question again, my point is that there are no references to or discussion of such). Perhaps a new subsection to 4.2?; - some MANET characteristics may not "break" existing protocols, but just make these protocols "less efficient". Could it be possible to be a bit more explicit on this? - I am unclear on what "traditional solutions" means exactly. Can we not just start by saying something like "PD/AC is done using RFCXXX, YYY, XXX. These do not support the following events, which are common in MANETs" somewhere early in 4.2 ("traditional" is one step away from "legacy" -- a word I've promised Thomas N to not use ;) ) Anyway, the introduction to 4.2.3 and 4.2.4 starting "XXX is a potential event that was not considered in the design of traditional solutions" may even be wrong -- likely it was considered and then classified as "not relevant" for the network topologies these "traditional solutions" were designed for. - in 4.2.4, I have a difficulty with "The MANET must thus function without traditional address allocation server availability". Assuming that one uses, say, DHCP, to delegate prefixes to each MANET router, can a MANET not survive even if the top-level DHCP server is unavailable for "a while"? o for 4.3 "MANET Autoconfiguration issues", I think that: - it should be added that the "shortcomings of traditional solutions" are only within the scope of a MANET, and not in general. I.e. that it should not be insinuated that the existing solutions do not work in general (they work rather fine within the context where they were designed). o for 4.3.1 "Address and Prefix Generation" - what is "traditional"? - I do not think that it is fair to say that "hierarchies" are "bad", which is sort of what is being said in this paragraph. Rather, if I read the I-D correctly, no explicit hierarchy is assumed within the MANET, but with respect to other networks, hierarchies are respected -- e.g. wrt. any form of global addresses or prefixes acquired/delegated - can we find an alternative phrase to replace the last sentence, in particular I do not like the word "totally", and I do not understand what "....a priori over all the MANET" means. o for 4.3.2 - another "totally" - last paragraph first sentence, add "then" before "checking". Also second sentence. - last paragraph second sentence, is it reasonable to state that "checking should be used", universally? - to the whole section, paragraph 2+3 discusses pre/in-service issues, whereas 3+4 discuss "checking". One wonders if this refers to pre-service checking or in-service checking -- or both or neither. I suspect (since the talk is about merging/ partitioning) that these paragraphs reference in-service, but it is not clearly spelled out. o for 4.3.3 "MANET Border Routers Related Issues" - the MANEMO initiative has brought some good stuff forward on this subject, notably about the importance that if an address is acquired from one MANET border router, then the traffic to/from that node should go through that MANET border router. I would suggest looking at some of the discussions relative to MANEMO, and perhaps consult some of the MANEMO proponents to ensure that this section reflects their considerations correctly. Off the top of my head, Teco (having just published an individual I-D relative to this) and Wakikawa (if you can find his now expired global6 I-D) might make good starting points for this? In any event, I feel that this section should elaborate a bit on this issue, since it is not at all addressed in the current incarnation of this section. o for 5 "Solutions considerations" - A thing that can be brought forward would be "compatibility with existing solutions" -- example: NDP is used for IPv6 stateless, but also for MobileIP/NEMO. Assuming that a solution "multi-hop NDP with prefix-delegation" was produced, would this interwork with other uses of NDP, say NEMO, which may make other assumptions of how far a NA/NS/RA/RS travels in the network? I am not having precise suggestions to this section, but I would encourage that it be thought about and discussed since this may be one of the areas where there would be gains for other protocols if the AUTOCONF wg developed protocols are done in one way or another. That's all for now! Cheers, Thomas -- Thomas Clausen Thomas@thomasclausen.org http://www.thomasclausen.org/ http://hipercom.thomasclausen.org/ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 07 23:44: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 1IpzFb-0006rQ-5b; Wed, 07 Nov 2007 23:44:19 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IpzFa-0006qW-HS for autoconf-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 23:44:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpzFa-0006pi-75 for autoconf@ietf.org; Wed, 07 Nov 2007 23:44:18 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpzFX-0007tr-1g for autoconf@ietf.org; Wed, 07 Nov 2007 23:44:18 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns0.neustar.com (Postfix) with ESMTP id E928632880; Thu, 8 Nov 2007 04:44:14 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IpzFW-0003Bv-Pl; Wed, 07 Nov 2007 23:44:14 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ian.chakeres@gmail.com From: IETF I-D Submission Tool Message-Id: Date: Wed, 07 Nov 2007 23:44:14 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: autoconf@ietf.org, macker@itd.nrl.navy.mil, T.Clausen@computer.org Subject: [Autoconf] New Version Notification for draft-ietf-autoconf-manetarch-07 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 A new version of I-D, draft-ietf-autoconf-manetarch-07.txt has been successfuly submitted by Ian Chakeres and posted to the IETF repository. Filename: draft-ietf-autoconf-manetarch Revision: 07 Title: Mobile Ad hoc Network Architecture Creation_date: 2007-11-08 WG ID: autoconf Number_of_pages: 20 Abstract: This document discusses Mobile Ad hoc NETworks (MANETs). It presents the initial motivation for MANET and describes unaccustomed characteristics and challenges. It also defines a MANET, other MANET entities, and MANET architectural concepts. The IETF Secretariat. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 07 23:50:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpzLA-0004v1-ME; Wed, 07 Nov 2007 23:50:04 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IpzL8-0004tE-N9 for autoconf-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 23:50:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpzL8-0004t6-DC; Wed, 07 Nov 2007 23:50:02 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpzL8-000818-0K; Wed, 07 Nov 2007 23:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id D1BE4327BC; Thu, 8 Nov 2007 04:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IpzL7-00086A-M0; Wed, 07 Nov 2007 23:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Nov 2007 23:50:01 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: autoconf@ietf.org Subject: [Autoconf] I-D Action:draft-ietf-autoconf-manetarch-07.txt 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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Ad-Hoc Network Autoconfiguration Working Group of the IETF. Title : Mobile Ad hoc Network Architecture Author(s) : I. Chakeres, et al. Filename : draft-ietf-autoconf-manetarch-07.txt Pages : 20 Date : 2007-11-07 This document discusses Mobile Ad hoc NETworks (MANETs). It presents the initial motivation for MANET and describes unaccustomed characteristics and challenges. It also defines a MANET, other MANET entities, and MANET architectural concepts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-autoconf-manetarch-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-autoconf-manetarch-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-autoconf-manetarch-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-07234412.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-autoconf-manetarch-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-autoconf-manetarch-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-07234412.I-D\@ietf.org> --OtherAccess-- --NextPart 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 --NextPart-- From autoconf-bounces@ietf.org Wed Nov 14 00:12:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsAXj-00013i-Rk; Wed, 14 Nov 2007 00:12:03 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IsAXi-00010U-CK for autoconf-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 00:12:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsAXi-0000yl-08 for autoconf@ietf.org; Wed, 14 Nov 2007 00:12:02 -0500 Received: from an-out-0708.google.com ([209.85.132.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsAXf-0005Cw-PH for autoconf@ietf.org; Wed, 14 Nov 2007 00:12:01 -0500 Received: by an-out-0708.google.com with SMTP id c5so19547anc for ; Tue, 13 Nov 2007 21:11:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=TsDAmyfg6ki6pWFevSz+JyR4Xzuin+OkCJGavgvpXas=; b=ueDE9+1U/b5mhuNTq0+RhvVvnRty//MKQGTDJNcXk8fm7j0707zSfXqKRZS2l5+LLOtHd/gAEIB2fkLKcq82jZ1FGRxGpdwSxiL55BCao6gEkpdyySI0v2WyRxz32d7yj+PBaK/A6RedyjnZa4BQwb0kZct+oBIIv1ABvKP4R84= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=TD0VB6obG5qKVx5x1qS860t+83EwJr4SsrtCM2Bn8sAh3I5ww+3HB2StHyqMZJFHNjYeDqnOcyX/7cNPBpBeaG63XIVpezcgPl2aWYL+u26l8qmRHKdaGc0Vsv/Rruq9Y7gGznYbLnBZ+c530SxWyilwFh9JUMdMSVlyyMc3oMs= Received: by 10.100.253.12 with SMTP id a12mr10992978ani.1195017119501; Tue, 13 Nov 2007 21:11:59 -0800 (PST) Received: by 10.100.229.8 with HTTP; Tue, 13 Nov 2007 21:11:59 -0800 (PST) Message-ID: Date: Wed, 14 Nov 2007 10:41:59 +0530 From: Shubhranshu To: autoconf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Autoconf] IETF-70 Autoconf WG Meeting Agenda 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 If you have any agenda item(s) for the upcoming Autoconf WG meeting then please send them to the chairs or to the list. Autoconf WG session is tentatively scheduled for Monday, https://datatracker.ietf.org/meeting/70/agenda.html: AUTOCONF Session 1 (2 hours) Monday, Afternoon Session III 1740-1950 Room Name: Salon 2 - Shubhranshu _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 14 05:12:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsFEN-0007hk-5l; Wed, 14 Nov 2007 05:12:23 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IsFEL-0007hN-St for autoconf-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 05:12:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsFEL-0007hA-CA for autoconf@ietf.org; Wed, 14 Nov 2007 05:12:21 -0500 Received: from hpsmtp-eml16.kpnxchange.com ([213.75.38.116]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsFEK-00038y-9c for autoconf@ietf.org; Wed, 14 Nov 2007 05:12:20 -0500 Received: from hpsmtp-eml02.kpnxchange.com ([213.75.38.102]) by hpsmtp-eml16.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 11:12:18 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml02.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 11:12:18 +0100 From: "Teco Boot" To: Date: Wed, 14 Nov 2007 11:12:06 +0100 Message-ID: <006e01c826a6$d0c7c9c0$72575d40$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acgmps9JazNMyiOwQRuvsSKC2lljrQ== Content-Language: nl X-OriginalArrivalTime: 14 Nov 2007 10:12:18.0523 (UTC) FILETIME=[D6807AB0:01C826A6] X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Subject: [Autoconf] Lining up Autoconf documents 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="===============0171022121==" Errors-To: autoconf-bounces@ietf.org Dit is een meerdelig bericht met een MIME-indeling. --===============0171022121== Content-Type: multipart/alternative; boundary="----=_NextPart_000_006F_01C826AF.328C31C0" Content-Language: nl Dit is een meerdelig bericht met een MIME-indeling. ------=_NextPart_000_006F_01C826AF.328C31C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, In some private / public discussions, we struggled with terms related to Autoconf. I think all Autoconf terms shall be defined in autoconf-statement. Some terms specific to MANET only may be defined in autoconf-manetarch. I prefer a clear definition on Border Router. Some suggest there is a difference in Border Router and Internet Gateway. I understand the difference very well, but lacking a defined term for Internet Gateway I use Border Router (BR). I suggest lining up both Autoconf WG drafts, as they are using the same term for both. And verify with the charter, this text use Internet Gateway and not Border Router. On addresses, the Autoconf charter defines very well what is needed: - unique local addresses - globally routable unique addresses The first is called MANET Local Address (MLA) in autoconf-statement, I will use this term in a next version of my personal I-D. For the second one, I introduced MGA, MANET Generated Address. I could update this into MANET Global Address, keeping the MGA abbreviation and using wording in line with MLA. Any other term is OK for me, as long as it is consistently used and well defined. I think Carlos Bernardos (et alia) has published good documents on Autoconf. Lining up terms with these documents doesn't harm. And we should discuss accepting these documents as WG docs in Vancouver, for being published as informational RFC. I suggest chairs prepare a proposal for both draft-bernardos-autoconf-evaluation-considerations and draft-bernardos-autoconf-solution-space. AD approval could be required, I suggest a break-of-silence procedure here. Cheers, Teco ------=_NextPart_000_006F_01C826AF.328C31C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

In some private / public discussions, we = struggled with terms related to Autoconf.

I think all Autoconf terms shall be defined in autoconf-statement. Some terms specific to MANET only may be defined in autoconf-manetarch.

 

I prefer a clear definition on Border Router. = Some suggest there is a difference in Border Router and Internet Gateway. I understand the difference very well, but lacking a defined term for = Internet Gateway I use Border Router (BR). I suggest lining up both Autoconf WG = drafts, as they are using the same term for both. And verify with the charter, = this text use Internet Gateway and not Border Router.

 

On addresses, the Autoconf charter defines very = well what is needed:

- unique local addresses

- globally routable unique = addresses

The first is called MANET Local Address (MLA) in = autoconf-statement, I will use this term in a next version of my personal = I-D.

For the second one, I introduced MGA, MANET = Generated Address. I could update this into MANET Global Address, keeping the MGA abbreviation and using wording in line with MLA. Any other term is OK = for me, as long as it is consistently used and well defined.

 

I think Carlos Bernardos (et alia) has published = good documents on Autoconf. Lining up terms with these documents doesn't = harm. And we should discuss accepting these documents as WG docs in Vancouver, for = being published as informational RFC. I suggest chairs prepare a proposal for both = draft-bernardos-autoconf-evaluation-considerations and draft-bernardos-autoconf-solution-space. AD approval could be = required, I suggest a break-of-silence procedure here.

 

Cheers, Teco

 

------=_NextPart_000_006F_01C826AF.328C31C0-- --===============0171022121== 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 --===============0171022121==-- From autoconf-bounces@ietf.org Wed Nov 14 08:55: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 1IsIi6-00042L-DN; Wed, 14 Nov 2007 08:55:18 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IsIi4-0003za-Bu for autoconf-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 08:55:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsIi3-0003zJ-UW for autoconf@ietf.org; Wed, 14 Nov 2007 08:55:15 -0500 Received: from mho-01-bos.mailhop.org ([63.208.196.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsIi0-00040S-VX for autoconf@ietf.org; Wed, 14 Nov 2007 08:55:15 -0500 Received: from [193.253.141.91] (helo=[10.1.8.247]) by mho-01-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1IsIhz-000Gan-Tl; Wed, 14 Nov 2007 13:55:12 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 193.253.141.91 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19xKpLFGXau02rV/4zOX+4k In-Reply-To: <006e01c826a6$d0c7c9c0$72575d40$@nl> References: <006e01c826a6$d0c7c9c0$72575d40$@nl> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <596F7C00-60C4-4ADD-9F2A-9F95939CD8E4@thomasclausen.org> Content-Transfer-Encoding: 7bit From: Thomas Clausen Subject: Re: [Autoconf] Lining up Autoconf documents Date: Wed, 14 Nov 2007 14:55:23 +0100 To: Teco Boot X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 3.3 (+++) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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 Teco, All, Thanks for your email and your comments. I agree with Teco that it is important to try to ensure coherence between the different documents, in particular those which are wg documents. I appreciate *everybody's* review -- on this and on other matters in these I-Ds -- and feedback on the M-L. Regarding the suggestion of Teco to accept new I-Ds as wg documents -- and without passing any judgement on the merits of these documents in this email -- I want to emphasize two procedural matters: o a good start would be to discuss these I-Ds on the 'list, to understand how the wg feels about those. An I-D becoming a wg document implicitly means that the wg accepts responsibility for progressing these documents; o the AUTOCONF wg has an existing set of work-items to complete, and has let the milestones slip multiple times. I believe that if the wg was to accept new work-items, then I as chair would want to be convinced that we were "on track" with our existing milestones and that the working group as a whole would be able to assume the responsibility for carrying those "new" items to completion -- respecting these milestones. As I said, I am not pronouncing myself on the merits of the documents in question, but rather am encouraging that we all follow Teco's example and discuss those on the M-L -- AND that we make an effort on the already existing milestones to carry those forward. Cheers, Thomas On Nov 14, 2007, at 11:12 AM, Teco Boot wrote: > Hi, > > > > In some private / public discussions, we struggled with terms > related to Autoconf. > > I think all Autoconf terms shall be defined in autoconf-statement. > Some terms specific to MANET only may be defined in autoconf- > manetarch. > > > > I prefer a clear definition on Border Router. Some suggest there is > a difference in Border Router and Internet Gateway. I understand > the difference very well, but lacking a defined term for Internet > Gateway I use Border Router (BR). I suggest lining up both Autoconf > WG drafts, as they are using the same term for both. And verify > with the charter, this text use Internet Gateway and not Border > Router. > > > > On addresses, the Autoconf charter defines very well what is needed: > > - unique local addresses > > - globally routable unique addresses > > The first is called MANET Local Address (MLA) in autoconf- > statement, I will use this term in a next version of my personal I-D. > > For the second one, I introduced MGA, MANET Generated Address. I > could update this into MANET Global Address, keeping the MGA > abbreviation and using wording in line with MLA. Any other term is > OK for me, as long as it is consistently used and well defined. > > > > I think Carlos Bernardos (et alia) has published good documents on > Autoconf. Lining up terms with these documents doesn't harm. And we > should discuss accepting these documents as WG docs in Vancouver, > for being published as informational RFC. I suggest chairs prepare > a proposal for both draft-bernardos-autoconf-evaluation- > considerations and draft-bernardos-autoconf-solution-space. AD > approval could be required, I suggest a break-of-silence procedure > here. > > > > Cheers, Teco > > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf -- Thomas Clausen Thomas@ThomasClausen.org htp://www.thomasclausen.org/ htp://www.thomasclausen.org/hipercom/ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 16 05:06: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 1Isy5p-0007il-AB; Fri, 16 Nov 2007 05:06:33 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Isy5o-0007hS-MY for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 05:06:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isy5m-0007d4-Nx for autoconf@ietf.org; Fri, 16 Nov 2007 05:06:31 -0500 Received: from hpsmtp-eml19.kpnxchange.com ([213.75.38.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Isy5h-0007pl-V6 for autoconf@ietf.org; Fri, 16 Nov 2007 05:06:30 -0500 Received: from hpsmtp-eml09.kpnxchange.com ([213.75.38.109]) by hpsmtp-eml19.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 11:06:24 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml09.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 11:06:24 +0100 From: "Teco Boot" To: References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> In-Reply-To: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> Subject: RE: [Autoconf] Review of draft-ietf-autoconf-statement-01 Date: Fri, 16 Nov 2007 11:06:12 +0100 Message-ID: <008001c82838$50f37030$f2da5090$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgoCvs+kogp1oNsT2azrjQL7ebEeAAIqkRw Content-Language: nl X-OriginalArrivalTime: 16 Nov 2007 10:06:24.0699 (UTC) FILETIME=[586EB8B0:01C82838] X-Spam-Score: -1.0 (-) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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 All, More comments on the Problem Statement. First of all, I would like that the document is lined up with the charter. I think the primary goal is "Develop an IPv6 address autoconfiguration mechanism" and NOT work on prefix delegation. I think those are very different. And I think existing prefix delegation mechanisms can be used. So why invent something that can be reused? The charter is very clear on this. Then I want descriptions of problems with MLA and MGA (L=local, G=global). I think problems for the two types are very different, as MGAs must be globally routable and topologically correct and generation has to do with Border Routers. Note that an MGA can be used as MLA, MLA cannot be used as MGA. I think MLA are to be used as failback when no MGA can be generated, e.g. just after startup MN and in a Standalone MANET. Then I want the focus on IPv6 unique address generation. I want a list of all current methods, and the probability / risks on duplicates. My personal opinion is that some methods can provide almost absolutely uniqueness, other methods cannot. Here is also a link to a security issue, e.g. address spoofing. My personal opinion is that duplicates caused by spoofing is a far more important problem than collisions. And a remedy for the spoofing security issue would solve collisions also. Or it shall be described why not. Recently, the relation with routing is discussed. I think there are problems. Number one is the routing protocol convergence. It takes time for the MANET protocol to adopt a newly generated address, and during convergence connectivity from other nodes and border routers in the MANET to the node with the newly generated address is bad. The second relation is for MGA and the relation between Border Routers used for MGA generation. This problem is described in the current text. Maybe text should specify more precisely what the problem really is. Current text: >>> When a device changes its MANET border router attachment ... How can a device changes its MANET border router attachment? OK, it can generate a new MGA for using that border router. But it cannot attach to that border router, this is up to the routing protocol and is dependent on other nodes. This is a large problem, with as a result traffic blocking by ingress filters on border routers not accepting MGAs as source with prefixes not belonging to that border outer. Following text on asymmetry may be removed, it has to do with routing and not with addressing. >>> asymmetry in the routers' choice of ingress/egress MANET border >>> router can lead to non-optimal paths followed by inbound/outbound >>> data traffic Text on Deployment Scenarios should be taken out and inserted in the MANET Architecture document. On references: There are new RFCs for IPv6 ND and Autoconf (RF4861, RFC4862). Following references should be added: RFC4291: IP Version 6 Addressing Architecture RFC3041: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 RFC3971: SEcure Neighbor Discovery (SEND) RFC3972: Cryptographically Generated Addresses (CGA) RFC4429: Optimistic Duplicate Address Detection (DAD) for IPv6 RFC4193: Unique Local IPv6 Unicast Addresses Also consider: draft-ietf-nemo-prefix-delegation: Mobile Network Prefix Delegation Consider removing references to: RFC2328: OSPF version 2 RFC2740: OSPF for IPv6 draft-ietf-manet-iana: Allocations for the Mobile Ad hoc Networks (MANET) Working Group Changing references implies changing text. Maybe adding lots of text. Thanks, Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 16 05:53: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 1Isyp5-0005Hx-Ah; Fri, 16 Nov 2007 05:53:19 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Isyp3-0005D4-Oo for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 05:53:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isyp3-0005C3-8G for autoconf@ietf.org; Fri, 16 Nov 2007 05:53:17 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Isyp2-0006og-G3 for autoconf@ietf.org; Fri, 16 Nov 2007 05:53:17 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-119.messagelabs.com!1195210395!21145170!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 21862 invoked from network); 16 Nov 2007 10:53:15 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-119.messagelabs.com with SMTP; 16 Nov 2007 10:53:15 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lAGArFhn018409; Fri, 16 Nov 2007 03:53:15 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id lAGArEBm004510; Fri, 16 Nov 2007 04:53:14 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id lAGArDl5004498; Fri, 16 Nov 2007 04:53:13 -0600 (CST) Message-ID: <473D7695.1060808@gmail.com> Date: Fri, 16 Nov 2007 11:53:09 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Teco Boot Subject: Re: [Autoconf] Review of draft-ietf-autoconf-statement-01 References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> In-Reply-To: <008001c82838$50f37030$f2da5090$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071115-0, 15/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected 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 Teco Boot wrote: > All, > > More comments on the Problem Statement. > > First of all, I would like that the document is lined up with the > charter. I think the primary goal is "Develop an IPv6 address > autoconfiguration mechanism" and NOT work on prefix delegation. I > think those are very different. And I think existing prefix > delegation mechanisms can be used. So why invent something that can > be reused? The charter is very clear on this. Err... I'm agreeing with you to have a PS aligned with the Charter. But I don't understand: do you disagree reusing DHCP PD? ("NOT work on prefix delegation"). I may misunderstand you. > Then I want descriptions of problems with MLA and MGA (L=local, > G=global). I think problems for the two types are very different, as > MGAs must be globally routable and topologically correct and > generation has to do with Border Routers. Sorry what's MG/LA other than global/local? M? A? It's strange to talk about topologically correct addresses when the strong assumption in MANETs is that the topology changes. In a sense any address is correct in a topology changing to follow it. Or maybe one AUTOCONF requirement is to support dynamic L2 topology changes with a overlay stable L3 topologies? Or vice-versa? Or none? I think the problem (and solution) is very different if we consider the L3 topology be stable over a fixed L2 topology vs L3-variable/L2-variable. For example, if we consider a MANET to be a set of PDAs physically moving around wifi range, but keeping their L2 and L3 topologies stable, then the obvious solution is DHCPv6-PD there's no need of anything else. And if this is a typical deploying scenario then we're all happy. If on the other hand we consider a MANET to be a pda+laptop+phone personal set dynamically changing the way it intra-connects and Internet-connects then we can have a whole different set of solutions. But is this a relevant scenario, pertinent from market perspective - question mark. Unfortunately to me, the current scenarios in the PS draft aren't detailed enough, and too theoretical. For example they only briefly mention "emergency network", "UMTS", "WiMAX" at the end of sections. And there are so many ways and types deployed of emergency networks and umts and wimax where there's no problem of address auto-configuration - because they use ppp/dhcp/L2IPaddressassignment. I think I have a big problem understanding AUTOCONF overall. I don't understand the requirements. > Note that an MGA can be used as MLA, MLA cannot be used as MGA. I > think MLA are to be used as failback when no MGA can be generated, > e.g. just after startup MN and in a Standalone MANET. > > Then I want the focus on IPv6 unique address generation. I want a > list of all current methods, and the probability / risks on > duplicates. My personal opinion is that some methods can provide > almost absolutely uniqueness, other methods cannot. Here is also a > link to a security issue, e.g. address spoofing. My personal opinion > is that duplicates caused by spoofing is a far more important problem > than collisions. And a remedy for the spoofing security issue would > solve collisions also. Or it shall be described why not. > > Recently, the relation with routing is discussed. I think there are > problems. I agree. > Number one is the routing protocol convergence. Then number zero is to make simply routing (strike protocol), make the default route meaningful and work overall in the presence of topology changes (L2? L3?). > It takes time for the MANET protocol to adopt a newly generated > address, and during convergence connectivity from other nodes and > border routers in the MANET to the node with the newly generated > address is bad. The second relation is for MGA and the relation > between Border Routers used for MGA generation. This problem is > described in the current text. Maybe text should specify more > precisely what the problem really is. Current text: >>>> When a device changes its MANET border router attachment ... > How can a device changes its MANET border router attachment? OK, it > can generate a new MGA for using that border router. But it cannot > attach to that border router, this is up to the routing protocol and > is dependent on other nodes. This is a large problem, with as a > result traffic blocking by ingress filters on border routers not > accepting MGAs as source with prefixes not belonging to that border > outer. Following text on asymmetry may be removed, it has to do with > routing and not with addressing. >>>> asymmetry in the routers' choice of ingress/egress MANET border >>>> router can lead to non-optimal paths followed by >>>> inbound/outbound data traffic > > Text on Deployment Scenarios should be taken out and inserted in the > MANET Architecture document. Somehow yes... in my reading (IMHO) the current text on Deployment Scenarios could largely benefit from augmenting with, err, deployment scenarios. More talk of vehicles, handsetphones, walkietalkies, pdas, gameconsoles, temperaturesensors, antennapoles, videocameras, gpsunits, audiorecorders - all IP yes. ALso, a list of requirements in the form of: Req 0 - should do this. Req 1 - should do that. could help a lot understanding, methinks. > On references: There are new RFCs for IPv6 ND and Autoconf (RF4861, > RFC4862). Following references should be added: RFC4291: IP Version 6 > Addressing Architecture RFC3041: Privacy Extensions for Stateless > Address Autoconfiguration in IPv6 RFC3971: SEcure Neighbor Discovery > (SEND) RFC3972: Cryptographically Generated Addresses (CGA) RFC4429: > Optimistic Duplicate Address Detection (DAD) for IPv6 RFC4193: Unique > Local IPv6 Unicast Addresses Also consider: > draft-ietf-nemo-prefix-delegation: Mobile Network Prefix Delegation > Consider removing references to: RFC2328: OSPF version 2 RFC2740: > OSPF for IPv6 draft-ietf-manet-iana: Allocations for the Mobile Ad > hoc Networks (MANET) Working Group I agree. 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 Nov 16 06:10:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isz5O-0006CP-CN; Fri, 16 Nov 2007 06:10:10 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Isz5M-0006Ay-Kj for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 06:10:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isz5M-0006Ao-AR for autoconf@ietf.org; Fri, 16 Nov 2007 06:10:08 -0500 Received: from smtp02.uc3m.es ([163.117.176.132] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Isz5J-0003HB-FN for autoconf@ietf.org; Fri, 16 Nov 2007 06:10:08 -0500 Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.uc3m.es (Postfix) with ESMTP id 151A8233FA9 for ; Fri, 16 Nov 2007 12:01:14 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: autoconf@ietf.org Organization: Universidad Carlos III de Madrid Date: Fri, 16 Nov 2007 12:01:19 +0100 Message-Id: <1195210879.16335.81.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 X-Spam-Score: -4.0 (----) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Subject: [Autoconf] [Fwd: I-D Action:draft-bernardos-autoconf-solution-space-00.txt] X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2147129924==" Errors-To: autoconf-bounces@ietf.org --===============2147129924== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-KeVAulbWmOZVuVAPGQVE" --=-KeVAulbWmOZVuVAPGQVE Content-Type: multipart/mixed; boundary="=-MUOnMnGk5QV8+hwTfmzo" --=-MUOnMnGk5QV8+hwTfmzo Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi all, We have recently submitted a draft, analysing the solution space for the ad hoc IP autoconfiguration problem, based on the problem statement draft and the MANET architecture draft. We think this document may be of interest for the WG. Comments would be highly appreciated. Thanks a lot, Mar=EDa, Hassnaa and Carlos --=20 =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-MUOnMnGk5QV8+hwTfmzo Content-Disposition: inline Content-Description: Mensaje reenviado: I-D Action:draft-bernardos-autoconf-solution-space-00.txt Content-Type: message/rfc822 Return-Path: Received: from smtp.uc3m.es (smtp03.uc3m.es [163.117.176.133]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by shem.uc3m.es (Postfix) with ESMTP id 7F4229A0C; Mon, 12 Nov 2007 12:52:34 +0100 (CET) Received: from megatron.ietf.org (lists.ietf.ORG [156.154.16.145])(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))(No client certificate requested)by smtp.uc3m.es (Postfix) with ESMTP id C3B7A1CD28D; Mon, 12 Nov 2007 12:52:33 +0100 (CET) Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)by megatron.ietf.org with esmtp (Exim 4.43) id 1IrXnn-0003Bl-3gfor i-d-announce@ietf.org; Mon, 12 Nov 2007 06:50:03 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a])by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrXnm-0007NW-Kwfor i-d-announce@ietf.org; Mon, 12 Nov 2007 06:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com[10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 4BDBA26E7Afor ; Mon, 12 Nov 2007 11:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)id 1IrXnm-0007Uk-4Kfor i-d-announce@ietf.org; Mon, 12 Nov 2007 06:50:02 -0500 Content-Type: Multipart/Mixed; Boundary=NextPart Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 12 Nov 2007 06:50:02 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Subject: I-D Action:draft-bernardos-autoconf-solution-space-00.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: i-d-announce-bounces@ietf.org X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:N SM:2 X-imss-tmaseResult: TT:1 TS:-4.0375 TC:1F TRN:62 TV:5.0.1023(15540.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) --NextPart Content-Transfer-Encoding: quoted-printable A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Ad-Hoc IP Autoconfiguration Solution Space Analysis Author(s) : C. Bernardos, et al. Filename : draft-bernardos-autoconf-solution-space-00.txt Pages : 21 Date : 2007-11-12 This draft aims at analysing the solution space for the ad hoc IP autoconfiguration problem, based on the problem statement draft and the MANET architecture draft. Some evaluation considerations, are also taken into account. This draft classifies, at a generic level, the solution space of the possible approaches that could be followed to solve the IPv6 autoconfiguration for MANETs problem. The various approaches of IPv6 autoconfiguration for MANETs are illustrated, and the benefits and tradeoffs in different aspects of IPv6 autoconfiguration are explored. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bernardos-autoconf-solution-space= -00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then "get draft-bernardos-autoconf-solution-space-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-bernardos-autoconf-solution-space-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Content-ID: <2007-11-12064546.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bernardos-autoconf-solution-space-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-bernardos-autoconf-solution-space-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Content-ID: <2007-11-12064546.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- --=-MUOnMnGk5QV8+hwTfmzo-- --=-KeVAulbWmOZVuVAPGQVE Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHPXh/Ndy6TdFwT2cRAkCrAJ9bZ5Lz9TDG+Kc40oRXYIyH5a0qwgCfUYtR 8KPedVKvnbEmtX30DYaTBFo= =sKfs -----END PGP SIGNATURE----- --=-KeVAulbWmOZVuVAPGQVE-- --===============2147129924== 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 --===============2147129924==-- From autoconf-bounces@ietf.org Fri Nov 16 06:10:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isz5T-0006Fe-QA; Fri, 16 Nov 2007 06:10:15 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Isz5S-0006FN-6X for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 06:10:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isz5R-0006FB-Ph for autoconf@ietf.org; Fri, 16 Nov 2007 06:10:13 -0500 Received: from smtp01.uc3m.es ([163.117.176.131] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Isz5O-0003HV-32 for autoconf@ietf.org; Fri, 16 Nov 2007 06:10:13 -0500 Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.uc3m.es (Postfix) with ESMTP id 2FE2E229F29; Fri, 16 Nov 2007 12:04:39 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: autoconf@ietf.org Organization: Universidad Carlos III de Madrid Date: Fri, 16 Nov 2007 12:04:44 +0100 Message-Id: <1195211084.16335.86.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 X-Spam-Score: -3.8 (---) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Cc: Patrick Stupar , Ignacio Soto Campos Subject: [Autoconf] [Fwd: I-D Action:draft-bernardos-autoconf-backbone-mesh-reqs-00.txt] X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0635734538==" Errors-To: autoconf-bounces@ietf.org --===============0635734538== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-D154Fwb9HWcxp/HYmcHU" --=-D154Fwb9HWcxp/HYmcHU Content-Type: multipart/mixed; boundary="=-CiUmwd150+kJh5Kbtawj" --=-CiUmwd150+kJh5Kbtawj Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi all, Given the increasing interest of users and companies in mesh networking, we have generated a document trying to identify the particular requirements posed by this scenario on IP autoconf solutions.=20 Comments are highly welcome. Kind Regards, Mar=EDa, Ignacio, Patrick and Carlos --=20 =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-CiUmwd150+kJh5Kbtawj Content-Disposition: inline Content-Description: Mensaje reenviado: I-D Action:draft-bernardos-autoconf-backbone-mesh-reqs-00.txt Content-Type: message/rfc822 Return-Path: Received: from smtp.uc3m.es (smtp02.uc3m.es [163.117.176.132]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by shem.uc3m.es (Postfix) with ESMTP id 18384EBFB; Mon, 12 Nov 2007 13:11:48 +0100 (CET) Received: from megatron.ietf.org (lists.ietf.ORG [156.154.16.145])(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))(No client certificate requested)by smtp.uc3m.es (Postfix) with ESMTP id 606C720920F; Mon, 12 Nov 2007 13:11:47 +0100 (CET) Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)by megatron.ietf.org with esmtp (Exim 4.43) id 1IrY7c-0004mK-DAfor i-d-announce@ietf.org; Mon, 12 Nov 2007 07:10:32 -0500 Received: from ns4.neustar.com ([156.154.24.139])by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrY7b-0003Oq-VYfor i-d-announce@ietf.org; Mon, 12 Nov 2007 07:10:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com[10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id C5B0C2AC69for ; Mon, 12 Nov 2007 12:10:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)id 1IrY77-0001ON-ISfor i-d-announce@ietf.org; Mon, 12 Nov 2007 07:10:01 -0500 Content-Type: Multipart/Mixed; Boundary=NextPart Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 12 Nov 2007 07:10:01 -0500 X-Spam-Score: 0.2 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Subject: I-D Action:draft-bernardos-autoconf-backbone-mesh-reqs-00.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: i-d-announce-bounces@ietf.org X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:N SM:2 X-imss-tmaseResult: TT:1 TS:-1.8615 TC:1F TRN:71 TV:5.0.1023(15540.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) --NextPart Content-Transfer-Encoding: quoted-printable A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Requirements for IP Autoconfiguration Mechanisms in Back= bone Wireless Mesh Network scenarios Author(s) : C. Bernardos, et al. Filename : draft-bernardos-autoconf-backbone-mesh-reqs-00.txt Pages : 15 Date : 2007-11-12 This Internet Draft presents the multi-hop Backbone Wireless Mesh Network scenario, summarising its basic characteristics and describing the requirements and desired properties of an IP Autoconfiguration mechanism aimed at being used in this kind of networks. Once that the AUTOCONF WG has almost finalised the documents that describe the general architecture of MANETs and the IP autoconfiguration problem statement in MANETs, the WG is expected to start working on solutions. This document describes an ad-hoc scenario that is getting a lot of attention from both telecommunication operators and end-users: Backbone/infrastructure Wireless Mesh Networking. This document identifies and explains the requirements posed by this particular scenario to an IP autoconfiguration mechanism. The goal is to help the AUTOCONF WG identify the requirements that need to be taken into account when designing IP autoconfiguration solution(s) suitable for this Wireless Mesh environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bernardos-autoconf-backbone-mesh-= reqs-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then "get draft-bernardos-autoconf-backbone-mesh-reqs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-bernardos-autoconf-backbone-mesh-reqs-00.txt"= . NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Content-ID: <2007-11-12070603.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bernardos-autoconf-backbone-mesh-reqs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-bernardos-autoconf-backbone-mesh-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Content-ID: <2007-11-12070603.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- --=-CiUmwd150+kJh5Kbtawj-- --=-D154Fwb9HWcxp/HYmcHU Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHPXlMNdy6TdFwT2cRAgdIAJ0XP7WJ0zptKA4apafjC3wGnBS4QgCcCXuh cx3FYAOKm0ceclaMAzSgOhs= =1FvG -----END PGP SIGNATURE----- --=-D154Fwb9HWcxp/HYmcHU-- --===============0635734538== 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 --===============0635734538==-- From autoconf-bounces@ietf.org Fri Nov 16 06:19: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 1IszEI-0002IL-KX; Fri, 16 Nov 2007 06:19:22 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IszEF-0002FC-Hu for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 06:19:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IszEF-0002Bj-4v for autoconf@ietf.org; Fri, 16 Nov 2007 06:19:19 -0500 Received: from mail2-relais-roc.national.inria.fr ([192.134.164.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IszE8-0003kN-62 for autoconf@ietf.org; Fri, 16 Nov 2007 06:19:19 -0500 X-IronPort-AV: E=Sophos;i="4.21,426,1188770400"; d="txt'?zip'48?scan'48,48,208";a="4323830" Received: from ras75-3-82-226-221-97.fbx.proxad.net (HELO BoolfightMaN-Laptop.local) ([82.226.221.97]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Nov 2007 12:19:09 +0100 Message-ID: <473D7CAC.9040806@inria.fr> Date: Fri, 16 Nov 2007 12:19:08 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> In-Reply-To: <008001c82838$50f37030$f2da5090$@nl> Content-Type: multipart/mixed; boundary="------------080406080302060800010200" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0076290b21c69318492534f4e4dfda6a Subject: [Autoconf] new version draft-ietf-autoconf-statement-02 (pre-release) 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 This is a multi-part message in MIME format. --------------080406080302060800010200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi all, authors, Thomas, Teco, Thanks for the feedback. Here's an updated version of the PS taking into account recent comments by Thomas and Teco. Aside from fixing various editorial details that they pointed out, the main upgrades concern: * the introduction in the terminology section of the term ICP, standing for Internet Configuration Provider, lifting an ambiguity about border routers' potential funtionalities in MANETs. * the tightening of the definition/use of "prefix" and "address" related terms. * more precision in relating to existing protocols' scope as well as the one of the protocols-yet-to-be-designed. * updated references I encourage everyone to continue the public reviewing and discussions on this updated basis, until it is published (the plan is to submit soon ;) Cheers, Emmanuel Teco Boot a écrit : > All, > > More comments on the Problem Statement. > > First of all, I would like that the document is lined up with the charter. I > think the primary goal is "Develop an IPv6 address autoconfiguration > mechanism" and NOT work on prefix delegation. I think those are very > different. And I think existing prefix delegation mechanisms can be used. So > why invent something that can be reused? The charter is very clear on this. > > Then I want descriptions of problems with MLA and MGA (L=local, G=global). I > think problems for the two types are very different, as MGAs must be > globally routable and topologically correct and generation has to do with > Border Routers. Note that an MGA can be used as MLA, MLA cannot be used as > MGA. I think MLA are to be used as failback when no MGA can be generated, > e.g. just after startup MN and in a Standalone MANET. > > Then I want the focus on IPv6 unique address generation. I want a list of > all current methods, and the probability / risks on duplicates. My personal > opinion is that some methods can provide almost absolutely uniqueness, other > methods cannot. Here is also a link to a security issue, e.g. address > spoofing. My personal opinion is that duplicates caused by spoofing is a far > more important problem than collisions. And a remedy for the spoofing > security issue would solve collisions also. Or it shall be described why > not. > > Recently, the relation with routing is discussed. I think there are > problems. Number one is the routing protocol convergence. It takes time for > the MANET protocol to adopt a newly generated address, and during > convergence connectivity from other nodes and border routers in the MANET to > the node with the newly generated address is bad. > The second relation is for MGA and the relation between Border Routers used > for MGA generation. This problem is described in the current text. Maybe > text should specify more precisely what the problem really is. > Current text: >>>> When a device changes its MANET border router attachment ... > How can a device changes its MANET border router attachment? OK, it can > generate a new MGA for using that border router. But it cannot attach to > that border router, this is up to the routing protocol and is dependent on > other nodes. This is a large problem, with as a result traffic blocking by > ingress filters on border routers not accepting MGAs as source with prefixes > not belonging to that border outer. > Following text on asymmetry may be removed, it has to do with routing and > not with addressing. >>>> asymmetry in the routers' choice of ingress/egress MANET border >>>> router can lead to non-optimal paths followed by inbound/outbound >>>> data traffic > > Text on Deployment Scenarios should be taken out and inserted in the MANET > Architecture document. > > On references: > There are new RFCs for IPv6 ND and Autoconf (RF4861, RFC4862). > Following references should be added: > RFC4291: IP Version 6 Addressing Architecture > RFC3041: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 > RFC3971: SEcure Neighbor Discovery (SEND) > RFC3972: Cryptographically Generated Addresses (CGA) > RFC4429: Optimistic Duplicate Address Detection (DAD) for IPv6 > RFC4193: Unique Local IPv6 Unicast Addresses > Also consider: > draft-ietf-nemo-prefix-delegation: Mobile Network Prefix Delegation > Consider removing references to: > RFC2328: OSPF version 2 > RFC2740: OSPF for IPv6 > draft-ietf-manet-iana: Allocations for the Mobile Ad hoc Networks (MANET) > Working Group > > Changing references implies changing text. Maybe adding lots of text. > > Thanks, > Teco. > > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf > > --------------080406080302060800010200 Content-Type: text/plain; name="draft-ietf-autoconf-problem-statement-02.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-autoconf-problem-statement-02.txt" MANET Autoconfiguration (Autoconf) E. Baccelli (Ed.) Internet-Draft INRIA Expires: May 19, 2008 K. Mase Niigata University S. Ruffino Telecom Italia S. Singh Samsung November 16, 2007 Address Autoconfiguration for MANET: Terminology and Problem Statement draft-ietf-autoconf-statement-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 19, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Baccelli (Ed.), et al. Expires May 19, 2008 [Page 1] Internet-Draft MANET Autoconf Problem Statement November 2007 Abstract Traditional dynamic IPv6 address assignment solutions are not adapted to mobile ad hoc networks. This document elaborates on this problem, states the need for new solutions, and requirements to these solutions. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 6 3.1. Connected MANET . . . . . . . . . . . . . . . . . . . . . 6 3.2. Standalone MANET . . . . . . . . . . . . . . . . . . . . . 6 3.3. Deployment Scenarios Selection . . . . . . . . . . . . . . 6 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 4.1. MANET Autoconfiguration Goals . . . . . . . . . . . . . . 7 4.1.1. Multi-hop Support . . . . . . . . . . . . . . . . . . 7 4.1.2. Dynamic Topology Support . . . . . . . . . . . . . . . 8 4.1.3. Network Merging Support . . . . . . . . . . . . . . . 8 4.1.4. Network Partitioning Support . . . . . . . . . . . . . 9 4.2. MANET Autoconfiguration Issues . . . . . . . . . . . . . . 9 4.2.1. Address and Prefix Generation . . . . . . . . . . . . 9 4.2.2. Prefix and Address Uniqueness Requirements . . . . . . 10 4.2.3. Internet Configuration Provider Related Issues . . . . 10 5. Solutions Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. Informative References . . . . . . . . . . . . . . . . . . . . 15 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Baccelli (Ed.), et al. Expires May 19, 2008 [Page 2] Internet-Draft MANET Autoconf Problem Statement November 2007 1. Introduction A Mobile Ad hoc NETwork (also known as a MANET [1]) consists of a loosely connected set of MANET routers. Each MANET router embodies IP routing/forwarding functionality and may also incorporate host functionality [2]. These routers dynamically self-organize and maintain a routing structure among themselves, regardless of the availability of a connection to any infrastructure. MANET routers may be mobile and may communicate over symmetric or assymetric wireless links. They may thus join and leave the MANET at any time, at a rate that can be substantially higher than in usual networks. However, prior to participation in IP communication, each MANET router that does not benefit from appropriate static configuration needs to automatically acquire at least one IP address, and may also need to be delegated an IP prefix. This address or this prefix may be required to be unique within a given scope, or to be topologically appropriate. Standard automatic IPv6 address assignment and prefix delegation solutions [5], [3] [4] do not work "as-is" on MANETs due to ad hoc networks' unique characteristics [2]. Therefore new or modified mechanisms are needed for operation within MANET scope, and this document thus details and categorizes the issues that need to be addressed. Baccelli (Ed.), et al. Expires May 19, 2008 [Page 3] Internet-Draft MANET Autoconf Problem Statement November 2007 2. Terminology This document uses the terminology defined in [2], as well as the following terms : MANET Local Prefix (MLP) - An IP prefix delegated to a MANET router, consisting in chunks of IP addresses valid for communications inside the MANET. MANET Local Address (MLA) - An IP address configured on a MANET interface, and valid for communications inside the MANET. Global prefix - An IP prefix delegated to a MANET router, consisting in chunks of IP addresses valid for communications reaching outside the MANET (as well as communications within the MANET). Global address - An IP address configured on an interface and valid for communications reaching outside the MANET (as well as communications within the MANET). Internet Configuration Provider (ICP) - A router that can provide other routers requesting configuration with addresses or prefixes derived from a global prefix. Connected MANET - A mobile ad hoc network, which contains at least one ICP. Standalone MANET - A mobile ad hoc network, which does not contain any ICP. Network merger - The process by which two or more previously disjoint ad hoc networks get connected. Network partitioning - The process by which an ad hoc network splits into two or more disconnected ad hoc networks. Address generation - The process of selecting a tentative address with the purpose of configuring an interface. Address assignment - The process of configuring an interface with a given address. Pre-service address uniqueness - The property of an address which is assigned at most once within a given scope, and which is unique, before it is being used. Baccelli (Ed.), et al. Expires May 19, 2008 [Page 4] Internet-Draft MANET Autoconf Problem Statement November 2007 In-service address uniqueness - The property of an address which was assigned at most once within a given scope, and which remains unique over time, after the address has started being used. Baccelli (Ed.), et al. Expires May 19, 2008 [Page 5] Internet-Draft MANET Autoconf Problem Statement November 2007 3. Deployment Scenarios Automatic configuration of IP addresses on MANET interfaces and prefix delegation to MANET routers are necessary in a number of deployment scenarios. This section outlines the different categories of scenarios that are considered. 3.1. Connected MANET Connected MANETs are mobile ad hoc networks which contain at least one ICP, i.e. a router that can provide other routers requesting configuration with addresses or prefixes derived from a global prefix. Routers joining a connected MANET may either (i) have no previous configuration, or (ii) already own pre-configured local or global IP addresses (or prefixes). Typical instances of this scenario include public wireless networks of scattered fixed WLAN Access Points participating in a MANET of mobile users, and acting as MANET border routers. Another example of such a scenario is coverage extension of a fixed wide-area wireless network, where one or more mobile routers in the MANET are connected to the Internet through technologies such as UMTS or WiMAX. 3.2. Standalone MANET Standalone MANETs are mobile ad hoc networks which do not contain any ICP, i.e. which do not contain any router able to provide other routers requesting configuration with addresses or prefixes derived from a global prefix. Again, routers joining a standalone MANET may either have (i) no previous configuration, or (ii) pre-configured local or global IP addresses (or prefixes). Due to potential network partitions and mergers, standalone MANETs may be composed of routers of either types. Typical instances of this scenario include private or temporary networks, set-up in areas where neither wireless coverage nor network infrastructure exist (e.g. emergency networks for disaster recovery, or conference-room networks). 3.3. Deployment Scenarios Selection Both "Standalone MANET" and "Connected MANET" scenarios are to be addressed by solutions for MANET autoconfiguration. Note that solutions should also aim at addressing cases where a MANET transits from one scenario to an other. Baccelli (Ed.), et al. Expires May 19, 2008 [Page 6] Internet-Draft MANET Autoconf Problem Statement November 2007 4. Problem Statement This section details the goals of MANET autoconfiguration. A taxonomy of autoconfiguration issues specific to MANETs is then elaborated. 4.1. MANET Autoconfiguration Goals A MANET router needs to configure IP addresses and prefixes as usual, on its non-MANET interfaces as well as its attached hosts and routers, if any. In addition, a MANET router needs to configure a link local address, or an MLA on its MANET interface and it may also require a delegated MLP, provided prefix uniqueness is guaranteed [2]. The primary goal of MANET autoconfiguration is thus to provide mechanisms for IPv6 prefix delegation and address assignment for operation on mobile ad hoc networks. Note that this task is distinct from that of propagating knowledge about address or prefix location, as a routing protocol does (see for example [8], [9]), or as described in [7]. The mechanisms employed by solutions to be designed must address the distributed, multi-hop nature of MANETs [2], and be able to follow topology and connectivity changes by (re)configuring addresses and/or prefixes accordingly. Traditional dynamic IP address assignment protocols, such as [5], [3] or [4], do not work efficiently (if at all) on MANETs, due to these networks' unique properties. The following thus overviews what must be specifically supported for efficient operation on mobile ad hoc networks. 4.1.1. Multi-hop Support Traditional solutions assume that a broadcast directly reaches every router or host on the subnetwork, whereas this generally is not the case in MANETs (see [2]). Some routers in the MANET will typically assume multihop broadcast, and expect to receive through several intermediate relayings by peer MANET routers. For example, in Fig. 1, the MANET router MR3 cannot communicate directly with a DHCP server [4] that would be available through a MANET border router, since the server and the MANET router are not located on the same logical link. While some DHCP extensions (such as the relay-agent [11]) overcome this issue in a static network, it is not the case in a dynamic topology, as explained below. Baccelli (Ed.), et al. Expires May 19, 2008 [Page 7] Internet-Draft MANET Autoconf Problem Statement November 2007 ----- MR1...MR3 / . +-------------+ +------------+ / . | | p2p | MANET |/ . | ISP Edge | Link | Border | . | Router +---------+ Router |\ . | | | | \ . +-------------+ +------------+ \----- MR2 Fig. 1. Connected MANET router topology. 4.1.2. Dynamic Topology Support A significant proportion of the routers in the MANET may be mobile with wireless interface(s), leading to ever changing neighbor sets for most MANET routers (see [1]). Therefore, network topology may change rather dynamically compared to traditional networks, which invalidates traditional delegation solutions that were developed for infrastructure-based networks, such as [11], which do not assume intermittent reachability of configuration server(s), and a potentially ever changing hierarchy among devices. For instance, in Fig. 1, even if MR1 would be able to delegate prefixes to MR3 with DHCP [4], it cannot be assumed that MR1 and MR3 will not move and become unable to communicate directly. Moreover, possible frequent reconfiguration due to intermittent reachability cause [5] to be less efficient than expected, due to large amounts of control signalling. 4.1.3. Network Merging Support Network merging is a potential event that was not considered in the design of traditional solutions, and that may greatly disrupt the autoconfiguration mechanisms in use (see [2]). Examples of network merging related issues include cases where a MANET A may feature routers and hosts that use IP addresses that are locally unique within MANET A, but this uniqueness is not guaranteed anymore if MANET A merges with another MANET B. If address uniqueness is required within the MANET (see Section 4.2.2), issues arise that were not accounted for in traditional networks and solutions. For instance, [5] and [3] test address uniqueness via messages that are sent to neighbors only, and as such cannot detect the presence of duplicate addresses configured within the network but located several hops away. However, since MANETs are generally multi-hop, detection of duplicate addresses over several hops is a feature that may be required for MANET interface address assignment (see Section 4.2.2). Baccelli (Ed.), et al. Expires May 19, 2008 [Page 8] Internet-Draft MANET Autoconf Problem Statement November 2007 4.1.4. Network Partitioning Support Network partitioning is a potential event that was not considered in the design of traditional solutions, and that may invalidate usual autoconfiguration mechanisms (see [2]). Examples of related issues include cases such as a standalone MANET, whereby connection to the infrastructure is not available, possibly due to network partitioning and loss of connectivity to a MANET border router. The MANET must thus function without traditional address allocation server availability. While stateless protocols such as [5] and [3] could provide IP address configuration (for MANET interfaces, loopback interfaces), these solutions do not provide any mechanism for allocating "unique prefix(es)" to routers in order to enable the configuration of host interfaces. ----- MR1...MR3...MR5 / . / . / . MR4 . \ . \ . \----- MR2 Fig. 2. Standalone MANET router topology. 4.2. MANET Autoconfiguration Issues Taking into account the shortcomings of traditional solutions in the mobile ad hoc context, this section categorizes general issues with regards to MANET autoconfiguration. 4.2.1. Address and Prefix Generation The distributed nature of MANETs brings the need for address generation algorithms that can complement existing solutions by supporting operation outside "client-server" schemes and without fixed hierarchies to provide routers with appropriate addresses and prefixes. In addition, the multi-hop aspect of MANETs brings specific needs as far as address and prefix uniqueness is concerned, as detailed below. Baccelli (Ed.), et al. Expires May 19, 2008 [Page 9] Internet-Draft MANET Autoconf Problem Statement November 2007 4.2.2. Prefix and Address Uniqueness Requirements If prefix or address uniqueness is required within a specific scope, and if the address/prefix generation mechanism in use does not ensure address/prefix uniqueness, then additional issues arise. This section overviews these problems. Pre-service Issues -- Address or prefix uniqueness problems in this category are called pre-service issues. Conceptually, they relate to the fact that before a generated address or prefix is assigned and used, it should be verified that it will not create an address conflict within the specified scope. This is essential in the context of routing, where it is desireable to reduce the risks of loops due to routing table pollution with duplicate addresses. In-Service Issues -- Address or prefix uniqueness problems in this category are called in-service issues. They come from the fact that even if an assigned address or prefix is currently unique within the specified scope, it cannot be ensured that it will indeed remain unique over time. Phenomena such as MANET merging and MANET partitioning may bring the need for checking the uniqueness (within the specified scope) of addresses or prefixes that are already assigned and used. This need may depend on (i) the probability of address conflicts, (ii) the amount of the overhead for checking uniqueness of addresses, and (iii) address/prefix uniqueness requirements from applications. For instance, if (i) is extremely low and (ii) significant, then checking pre-service uniqueness of addresses and prefixes may not be used. If on the other hand (i) is not extremely low, then checking pre-service and in-service uniqueness of addresses or prefixes may be required. In any case, if the application has a hard requirement for address uniqueness assurance, in-service uniqueness checks of addresses and prefixes should always be used, no matter how unlikely is the event of address conflict. 4.2.3. Internet Configuration Provider Related Issues Another category of problems concern the management of Internet configuration providers (ICPs). In the case where multiple ICPs are available in the MANET, providing access to multiple address configuration servers, specific problems arise. One problem is the way in which global prefixes are managed within the MANET. If one prefix is used for the whole MANET, partitioning of the MANET may result in invalid routes towards MANET routers, over the Internet. On the other hand, the use of multiple Baccelli (Ed.), et al. Expires May 19, 2008 [Page 10] Internet-Draft MANET Autoconf Problem Statement November 2007 network prefixes guarantees traffic is unambiguously routed from the hosts/routers in the Internet towards the border router responsible for one particular prefix. However, asymmetry in the routers' choice of ingress/egress border router can lead to non-optimal paths followed by inbound/outbound data traffic, or to broken connectivity, if egress filtering is being done. When a device changes its ICP attachment, some routes may be broken, affecting MANET packet forwarding performance and applications. In a multiple border router / multiple-prefixes MANET, frequent reconfiguration could cause a large amount of control signalling (for instance if [5] is used). Baccelli (Ed.), et al. Expires May 19, 2008 [Page 11] Internet-Draft MANET Autoconf Problem Statement November 2007 5. Solutions Considerations Solutions must achieve their task with (i) low overhead, due to scarse bandwidth, and (ii) low delay/convergence time, due to the dynamicity of the topology. The evaluation of such criteria may depend on the targeted network properties, which include (but are not limited to) node cardinality, node mobility characteristics, etc. Solutions are to be designed to work at the network layer and thus to apply to all link types. However, in situations where link-layer multicast is needed it is possible that on some link types (e.g. NBMA links), alternative mechanisms or protocols specifying operation over a particular link type would be required. Solutions must interact with existing protocols in a way that leverages as much as possible appropriate mechanisms that are deployed. For instance, besides the possible use of the well-known IPv6 multicast addresses defined for neighbor discovery in [3] (e.g. for Duplicate Address Detection), solutions may as well use some addresses defined in [10] for auto-configuration purposes. However, it must be ensured that no modification of existing protocols is to be required outside of MANET scope. Solutions must also take into account the security and trust issues that are specific to ad hoc networking (see Section 6). Baccelli (Ed.), et al. Expires May 19, 2008 [Page 12] Internet-Draft MANET Autoconf Problem Statement November 2007 6. Security Considerations Address configuration in MANET could be prone to security attacks, as in other types of IPv6 networks. Security threats to IPv6 neighbor discovery were discussed in SEND WG and described in [6]: three different trust models are specified, with varying levels of trust among network nodes and routers. Among them, the model by which no trust exists among nodes may be suitable a priori for most ad hoc networks. However, the other two models may be applicable in some cases, for example when a trust relationship exists between an operator and some MANET routers, or between military devices that are in the same unit. Although [6] does not explicitly address MANETs, the trust models it provides for ad hoc networks can be valid also in the context of MANET autoconfiguration. It is worth noting that analysis of [6] is strictly related to Neighbor Discovery, Neighbor Unreachability Detection and Duplicate Address Detection procedures, as defined in [3] and [5]. As explained in the present document, current standard procedures cannot be used as-is in MANET context to achieve autoconfiguration of MANET routers and, therefore, design of new mechanisms can be foreseen. In this case, although security threats and attacks defined in [6] could also apply in presence of new solutions, additional threats and attacks could be possible (e.g., non-cooperation in message forwarding in multi-hop communications). Therefore, the security analysis has to be further extended to include threats, specific to multi-hop networks and related to the particular address configuration solution. General security issues of ad hoc routing protocols' operations are not in the scope of MANET autoconfiguration. Baccelli (Ed.), et al. Expires May 19, 2008 [Page 13] Internet-Draft MANET Autoconf Problem Statement November 2007 7. IANA Considerations This document does currently not specify IANA considerations. Baccelli (Ed.), et al. Expires May 19, 2008 [Page 14] Internet-Draft MANET Autoconf Problem Statement November 2007 8. Informative References [1] Macker, J. and S. Corson, "MANET Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, January 1999. [2] Macker, J., Chakeres, I., and T. Clausen, "Mobile Ad hoc Network Architecture", ID draft-ietf-autoconf-manetarch, February 2007. [3] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IPv6", RFC 4861, September 2007. [4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6", RFC 3315, July 2003. [5] Narten, T., Thomson, S., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [6] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. [7] Draves, R. and D. Thaler, "Default Router Preferences and More- Specific Routes", RFC 4191, 2005. [8] Moy, J., "OSPF version 2", RFC 2328, 1998. [9] Moy, J., Coltun, R., and D. Ferguson, "OSPF for IPv6", RFC 2740, 1999. [10] Chakeres, I., "Internet Assigned Numbers Authority (IANA) Allocations for the Mobile Ad hoc Networks (MANET) Working Group", ID draft-ietf-manet-iana, May 2007. [11] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, 2001. Baccelli (Ed.), et al. Expires May 19, 2008 [Page 15] Internet-Draft MANET Autoconf Problem Statement November 2007 Contributors This document is the result of joint efforts, including those of the following contributers, listed in alphabetical order: C. Adjih, C. Bernardos, T. Boot, T. Clausen, C. Dearlove, H. Moustafa, C. Perkins, A. Petrescu, P. Ruiz, P. Stupar, F. Templin, D. Thaler, K. Weniger. Baccelli (Ed.), et al. Expires May 19, 2008 [Page 16] Internet-Draft MANET Autoconf Problem Statement November 2007 Authors' Addresses Emmanuel Baccelli INRIA Phone: +33 1 69 33 55 11 Email: Emmanuel.Baccelli@inria.fr Kenichi Mase Niigata University Phone: +81 25 262 7446 Email: Mase@ie.niigata-u.ac.jp Simone Ruffino Telecom Italia Phone: +39 011 228 7566 Email: Simone.Ruffino@telecomitalia.it Shubhranshu Singh Samsung Phone: +82 31 280 9569 Email: Shubranshu@gmail.com Baccelli (Ed.), et al. Expires May 19, 2008 [Page 17] Internet-Draft MANET Autoconf Problem Statement November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Baccelli (Ed.), et al. Expires May 19, 2008 [Page 18] --------------080406080302060800010200 Content-Type: application/zip; name="draft-ietf-autoconf-problem-statement-02.txt.zip" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="draft-ietf-autoconf-problem-statement-02.txt.zip" UEsDBBQACAAIAGZecDcAAAAAAAAAAAAAAAAsABAAZHJhZnQtaWV0Zi1hdXRvY29uZi1wcm9i bGVtLXN0YXRlbWVudC0wMi50eHRVWAwAYXw9RyB2PUf1AfUBvV1Zcxs5kn5X7I9A6GWkaIq2 DsvHvjQtyTanLVlByuvp9foBrAJJjItVnDoks2N+/OaFo8iiLLvVo92YtqiqRCKRyPzyALiz s3M5uLq4UYOmLpIin9pZU+raFrnacx/tq66fi756rZPEZJlVexdpf39nmNemzE19cF7qad35 0vd+hlej4WDn4tvSlqZ6pS71Sh2+7Kmjp09f/AiZ3/rwamV2fooHdWXtTNdafcztrSkrW69+ kpD7GffVqJlObV78CUI3JjNJsVDDWmdW/0mOiKexzWfzP01IjfWiavLZzxK6Km7NYmJKdXhK C/18Z2dHDdIUFKDq0MppUSrS2FcgkXIBMs2K2UrpPFXXZTHJzEKNa12bhcnrTpZSVM4Da+rp gRbqB5V74+Dp0c4Ovt9Uqpiqem4rdWkWxQ6Ser1SVTNZ2LoGwfHf2irfU0YncwVk58BlaZYw ByBawbO6BhZJj/RymdlEA6dqCaPmtYJni3oOEhhej1SSabugwe/mFojNDf69gv/AcPpOl6TV c31r1MSYHP94Z7MMflGprZKsqEzaI3HAeF1kJqhFpiJWkFzX6zZXsLWLMtV5gg/UczU2Ccn/ FGm+PrtWz1/2SSptEQCPSLIov6KM0iJpFiQBEqbxD6uLfGZzY0rLinOjq6/qTVHCaHvDi5s3 +8AD09IVzwZ/dWRnZdEsqz7qTm1IuEiDZch/UwuwHDqrCpxVXdpJU3dxpaMVRBI8he3zIt2J 3r+FrZiSSmoY8ZtdNAucaWW/qUWR13OWMnCP7ICIm2UKSw4CBt3IdIL/wsWfVEVm4HM1Wcks Iha94tR2YWDOwxo1weagR2WxLK1GERSqqcwmyxUMNDWlgVVECgt4Fl7IcFB4JbEkPdgxPCgI Msd3dlFQqAMwwAy3YX+XJHIDC5iBOHGKSVOWqLvrQyZAAiaKjqECVVK8NPO6Xr568uTu7q6P G69flLMn+I8nhzY90BNYIZ2A3OtvdX9jpDWvMp7rtLhT5+AgkroorfmRMSt6uT+vF5kbaGMT 834w5IIUKHzsg+Cls2K5Ku1sXqPyWZArkgkf7p3tE/eoxOqmbGAOe2jU9uFV99N2m2A0YImz PtomcXzf8Xufr/XMqMMvO//V6XLb/nzTKq7bXbG5A1kGlkupU4v7HZQlXeV6YROwTrenSoth 1lVlZzmRA+Vt8FHeInkBs0n1EtSZlLaAnTCxYOx0quZFooBZVC/cvSR8p+nKZHpSgJGH6YPU yboumfUeEiITXZERAbvBmy43d2F0NhOl+VcDIuS9A4PD84wD/HO4EDdkfkG5zmCX4qM06cM+ 7fqySBu2df0f/j91jISOcHKRc/oZQidI6Bj+cQ6moliRiMaJyXVpi+pHCJ2yFzzu4/Rgvjns G5Afa8lPEcLpgTblqc6K3AilnyG0dXpjxDrfXQImdAL/6NDxHxL2c+bohGS0DQ+/LcCh3E/Y EWJSRKzJanswL5Zq3CyXRflAztqEUODnsgtviiUrlaP3HUIvYkIo8CvegABryhl6wwfy1SZ0 EhG61mVNtiKmdg+hl07YR/cIe1hVjblfzx0hJoXCdqiRwaCZght+a3IjJB9I6Ij0iV5GOo4m BAP/aoAY/HMU25iY0OHTmNBxP4AI3HjR7EBfb20KtncEVg9349p0mdAz3GfeuAKFCt/R/OvD NPvwCAmdIiEDLhtCmXU6DyVEhu05TmlwNfhJIkSIDNsLkg3YcIAkEGSBHASmPNy0HT5jz5sz vCvKH7GKLUJkRgYE2qu/uQX/AU48oecON2ZovhrwnbDQS1PWHJ8ElODtVPcghy92Nn8eBzUc PTJqWPeZ5EgH6pJ9/oB9PlAmS7FHiPxrXtwRztQy6OfDL/sqQY2qOFKg6DYrIBbJVvgHcVmV IUDILwHMh0kgjLjAmCv+UAGHRWo5xhle06dgm56AukHAk6KZmjZ5wvDGyuL4gMHmEPgsCYkA 8xVhyfbjn4++EHoBZOHYcCBJZ8AxsD09ALipc/uHQeKMvW1eawysHD8AaUoQWgOgSUO0MCMo Du/emgoDhBmwmqG54dCJIolbbQElWeIC5eSEgzYFwA5GfDafltpTZpTbkpiLRRwsk7lDULho cpgBTBvWGGLF1WJhYG8lEC3Q4BV8wh/cgboRa5nNBcmZFVGp5xA4/7PAaQLdzGCYipCNOWBg jlxiLNOj2EaRoClAFhwPMTaAvby2JMw5bBgXmwDZpoJthVQ8jqQZvivuDDDdA8hoObhZoldK 7JINLrwJihDmCJ9JsE6cIQnRHeIkLWA7IZKdgMWf2lpNy2Kh4ogL4ShIouW0mC2TEvDE3AIa N1YJnZDLwBmDUDCwAeAEHAmc7rVU0NFBMhiXg6xn5CU0zWJJzsnhZwfIcdaMmcl1AS0kA68L InbUGvJjFNOTMs7A/OaqSsBO9SQunGBASSiDuZeshZs7S5wBYJmGiW4NEHBuwpbMRYQVIofP z7701OfjL+rzyReQPsmeTMaurg5stUuBGK4U7LSG4l0OJ2JN+JubWzLXGMhAqFsBW1XYr8BD gSEKhA0w0wXYiKnlMGVh4KXcVgsJYkD6EmOg/WYdEpGxKovAcGoodqThIxnaBKmB3Z4xFsFN NYNY9Q8JYCx7e1K1sNAkZnE+ab/DAzymHzh+ZD+wFvKE4NpLpalk9nUUGaWgFTkIAOQKq9RD r3AHk8P/is2bFllW3FHCDd6r1KvIor0vEvKxpFp7l++v95U6UINol0SbB3WmZQl7AtbE8+AQ wEYyb8CmUeLBb08TZ3paRqQSGpbgUDB1/Q0uHY4ENgcRm267OEMCjBa5Y9QTB26nOhF928bK FibeZsUExhd5/Ih8Isl4Tn5UPmB+wMoGCkC5zSSAgrDma+/KjvPP7rdm5ET3PVnmQYBBfsLO PQzfz6rXnYcw/L0oYG94Jqrb8kLoD5f8jJMe5emcI0fLblhx28ETJWzD2sAcebWNYxsGBbOf iltTs1hF+pLRWksUIHOdmZyeZJiBBcQ3lfdxjmf0dGfXsdeI0gbfp+t9sQwgZBFFeLIuFF1A TAsCAqKYgwPZYUYQs6pMCh5iw1/iH82tLZoqc8Wd1FYIXOr1RJWamTqA0PZ4yzj03TYqJlVb JFW1BAQXTAemqSLOMA/vpb+eNWN8LYo+i4Lb9uCYhOYcCjCmFea4ONASrZCxSVFQW5cNQN6K UmJOlejNaO+0h47c++bQ20iIYsrgjDyEIaYOpvygMuWtTTyn4tRz2ekyEgdVCIE9BZG2dXNj DikdDHIlyJVswz1oFtzrMqDzDhPGDJay7hODU2oi//w43vjkkb0x2Zw/K8k7/edEWRqMeRwN wWYUWgj6n7KlCwzOwb4CsC6pFLIh6of/PM6iPHvkRdmW7dyR9IOg6LYpX/ezDgeHTVW5CHMD YqNLb4d+jG1xm+pyRVU+lTfEYzElCBvYqxx7LtCoJM4EUhD2CZYDBE2Jm9pjXPYxaH98Nper nzB0IlkjWtPOhHSX72G2u6sIbd/Tcj3id3rK9k1fou4Oz7rVp+6Qe3+YW+12qGFRYKIjGQB9 DBvlZM3FYvhnLHGzZ/e5xMsdA85XtfmhcG3PwqM6A9CSwi6+w2mZgwgAZQQ+OYIXN9/Sp71o FoJWblZLjPsQTtaaUnKuEu6WFHMkWZOi25hkcT7ALYtXAV3XuNwK6afq0/vBlRpQmU5do6+t 4jCd8bfDoKyQsupgBkoJkrX4tEqemxRlGtYPk8A5r6j5phdLqvJQqNmgJ45mgMIEW4Qb3XwD /1jJbtPC6x3oxgHWn/3solgTsYmh8qDxbltYdYoUw0Cn/LzcUhZrlcPrObw3A18McSiFRljX ZJ4r9fHyZozDfLKXg3/QzumqwHTiqwfsHYm2/RbiYnPYOduechuKSmmYcIn3U0io/BRMdfuJ AsAujArLPAM+en6QsK2qdYgpqRDZWrStcH/lxXf3VXsvcVKSt9MD9hIYe85ULAuEX1h2F8nT lnbIkTMEDFxBxde59+k6iDQQoaWoozJp2WUysXq1NNWP72CQM6X8gIBZYNqzXMVJlR5mXQ+a JW1N7MYQzc9lVL/1/W7KqTDrJ9rOR8Jew7L+nunP+srQrPNkFVQS4zHAv/AC7mlDRFcExShQ y6VKcFAWoBTurX3aE98vJnITD+in2l3fJ7u0Crtrnmc3cmK4jzbTNIjyQxbL9yYpvV7QWm9W CS9V86LJUs49a7ugpCiTpx2jUbNY5s401qUGc8UBBO0OnIZfWcoD8y58XJB6+sh4qLNwGxJH Dm+4RBrayxmVYH0NoEvKAzKv+luRFwvGtRu1RUm/VUuT2Cm4LweTKvQKMAyFmL4dAbHKAwrD rvAR1yF8MtgbkbbBCIlRQ806lNxmbc+p4Skv8oNNuBfyJdQjVdc6mZuUihUeDIqJABuOyH5F VRoc2bKF099llGswNv8qNs9nqrHZCUDo+4Fjco1B6dZqZbMlBw3DhnzT5fvrnnMaPj8chSiw FrNGg6rXhm0vpnF9dxDYrQViWNSIexSCV7SpIge1lu7FPUuJ6034THBjM96dMpoKiWH4/609 Ln7Ts/2tsc8Ns6KUVktqv4XpEZgHRmR6xmgIC2WZSWHrgSo23iwER0lLQwvKBZqotgR0UBQZ p0/2KmNopg4UfX6B+faXX/Z5PTl/baqktBPJxj6PhB2JC3wEWNh1w+cKFRImLrDtyXEredzQ h5f24AHXFZFrcgtuBStJA+cpdXQJtOAcMOOmZej3dMWvWyyHIYczQ2mXvdLst1IQ8YZ7wqsX th31OcJj2ap/T+tTlyI4GaOTFKjm6hjisT6fwK9xOcNMweBYeDkDNnFroiXO9kN5o+fqG75x aaO8IUE7IESuasQpclR19Jm31tyh28CAveF4CCtrYvG4SsmdGlLm8Izdo9drZbetLS4bYow6 xMD0LmRDaDUpC50mWA5LqZ0PuKLsKywLVvNWUVkOWJxz5oEcQdVM2lCcCgbWpcRwfpazhqJ+ 6EeV9UUk2hCgavvUYrHYAtupE7BmMCVlMOaf9Bdn7GfAOmu+gYRrXD6YjrFU/GRgX+GEOCQk S7kwKdURAT3pFSwdKe7SmLIdsQN7b8K2pcbcN3bWRzKHvYhTkdLl6BhjW0bqoZ7rpcuIW52/ O7smEAKKYkhLeUXuCIngxuNCcxb4113hFjfmWUwG0aIwOa6JrXHmWgPJYnFinl7RC8O4mmqN 5HBgzp/mqHUVLgzyGiI0XDnZavg6Se8AwAn3en8+xE4C1H9scWaFIGfPgaXUbL3icE5PlMRp CK2y3/jO3lBlClY301SumhjYcP3HBFfPHz8D+DM/B/gDanTY7/dBmX6SzBP+T3/t9V8O4p9f uj//xb298fq/N35bHi35X1JLwF/c212vD8fX6gL9Kb/+HtEN/us1K3VrjK7ROYfTZvmX+ON/ /999r3f99u/2x+79nxSd+j+3gEdbVQDtB7a6rld4XH5MNJ60+3vNhwJ60SOSX2GniH+RbApt 0i7T2mpCQSpkmnw06dHkXgVbKjOaunbArqIZZV+PH0AUOptP8GCDkXCIsjHgJ9p5Tzb3h2Tu fR9Az9djPKqQVAFjCexMoV78qLUHo3AtzRR15OFCuEzpEjbzVGjkruUYUwSAGQEoMr8Y5KUw wwx8cOpwZjuAPphoDDuj8NwhD7B9vXayhp1VcDm2puMm5GKjLqI2YGYjTmIn/EtgyWUwQALt BZhb8GplMl9JCxNwbxPj3JbLP/TErrLq9ZBGjoEJ2JnI5wjYcxFCgGgYn4FjQw1BKuQRCFnZ 2nk7fJ9mm7IokTKyz++BF8eHFsWtb8fiUzAAqdywXf4SwQ0oSsGdRQUgP3x4Sgkt9jiYooil J+Btu7wTjQc1ACYKZnaJxYC/qNOJgQRCZaGY6XJGfWKNnKbBTFwJ+B73HiwMLIZAsnt6fDdq pZRzxbAh5KhwbWrRR+0Lr5K2lz0s0QKMTHu8C+m51hjNgeAMhIAABKKAsll6VLYZr0WhBnV7 mRZUu2AcRAKIckxuKqV000qA73JcXTmUAbE1NRR+xNlKZJsjaWKejtXEMbsvZlBYDFNiVO5M mG8QGvQUBDuMQdpRLYo0RLYYnVP+2E5Dy8iAE4KVADbJaPPfXvfVcNpV0+PKp2/3Wu9FYEG6 Y1zU6YynrFhUurSVCVaIkD5aEAiOQOEkRkBqHTaPRBaOV9DWZ6Pjdj+qOz6EDV5gDusu7m+t hklXlZ5FQmaQmhOidrYea2DZSqyTJMnFCqSmJvhN+QE8epe49H/a0KG72kQrGVVJIlk5n4CL 58BqBN4B9NMxPLQNvumQIXCUcA9RiI90e8KdtL6BAnfxxJ2XPByPRdtT9DTsJ05D+rUOicco DbMZsHZowKOC2BePniH8/kmD7f0YP2jYKL0wNz9o2IKXD62p91q1beasbbt4/8Tmy/n5zQKH RMAT3yotpV+xsWsJeDFAPsLzjm3lXE3eIUyaFnb0Fr7DI6Reos6xVngo6QkBfJKGoBSF66em jYeprVjUXnEzl94SUEJMRC3QIVBEPSLc6FMycUbG254EsQZnf7hW1dE0JmffO3YULH1WFMuJ Tr56TEWf7/c4WxPhOUFgbhwsl3kdcMDOzQ9UddendhDy7AHJXUoiBOTMckUALIhF0hrrzQKU JAms0fbeEgiojXCP/vfZ9ue3xHUbD2x/Ymt0xj+XoxN1/xPwszXG2nxk+xMPjpQg/NloWusK lXYecp6JM2P6K9e6cd+wg+VcyBzMGcBQygZtMz8RAmvnnBEPmm91T+p8YgbizmNxSs7lOzjN Jw2q0CyyWVXhyX33hJXPF0e53s0E76SkCbYOckZdaVFPm86Q9Xq+qELXBgZgGfsMKiXSOQov nMmKa/3kGaiHMyQzpZtzN8kQZh+wScEK3xzI8YzEGlEgSU0ALryxJq4g+H3J6Cw6FdDKNMdp 5vX6C84+JMF1RWnDdRnRXFyRiks0YNCmuiQ/EK1EZ/EkwSYtcMSpKw5wIe0vyV69fHTH/6Pn 8LjnbepEEXRqTSrr8FgHCXMDm/N0dhq3pj0RupF2BnsugYpvVDV5JUHF2tuBFdKAoBBhVxIQ l5YrRr/SdeWT+uxq5Gh0R9+kHCUE2zbYqBdFsnAE2KDwYGItVtyvAv6JC3OeNPPIXVuJWeIJ N0TiNZ7+YfwCu8ThKPA/ArekhVI76Zm0o5Rlq6jNkDdPw3dR1K5EDuEySIHObDBhW4fgPsEI 00RdjM49AsauY4Av642wHhfctbfB/+POZawYjKyYVdd1AdvS9f5w9hjRIowsSQRQrEaS4bCO 1CbP2W1E8gKvXIWu5itAioyNFxuTjpjAtZAfjP+aBbb55vrSeS5KkEhxMlpOylZIAofui3CL 1rWkck2ED5OjhYism1uLtYwO76O1tbZ5il6Dm0tJS9YaS2VHwPYC/nPtgaDAUEkVUHKIPmnF DBRblVxKk+qbuChwE8lX+UMs5r3tqrUvy9/d4uQTCa57L1Z/bnwV1cylAI7MpWZpciqfYA8T R7rFJD4TGOFZVH0wNdTL5DIulEFyqVkU2hwGb88wml0gaDjyQRpAD5sOt9m29h0M7uRc5g5J 8PqspQenNB3cg99qfBMUBnwUSYK4jzLMPd+i4RmObdQW5tu9FihJVjJnZ/rkPaQqVUinGI2+ 70KmFmtiwB0L4utDy3Xe2ljbmIr1YTOsF9CQrygE7HmXFIRJHdMa/rds3XzhI4xNF4hZ0tLl ZLv4oxlVG5rbEp9vWbrTq4oOFZKlzgu8YQaR8RzWrskz+9Vw2ZT7aiQE71BSQZg/fmKeCxCS H/PWjfso2PoJDGLEpXNAKwthwo20GUcJzsPCwfDsuvKneEKdkF0AIThsp8CneC/7wmmcenN9 Li6Q5g5YvBrFEeiOQhmjYpLfYRQ3LSIjUOFD7uGAE/QdZSakGtDqnDTSEUqSSKOsZTg1JjvB RGYc15dsBBGfF5mbGOl9bEDFsIQiD0wLJoncSKqE0TNO/47ijrUDuNhhdCvnAtwK0STXdiZj 6IbPrDg5PgKilct1nj5+PdbnVdxC+CQwFYiwAMDHT/RiAjpAZ5NYKKl3w5yCrOrqyVpVLXQS i1jxw1Y2BldiiQmvSWZcqYxWmTqwm0w7WxRnNrWcAl+5cWTYv4GdKCzfKgXyh5UnX2DoP2vj YtiGFTzKLRX5QbEEN40KqeWCLO5f4Z4im0/AQaVP4FX6h0rxJj4Rjz+gXBZf0fhGSSjSRDCQ wsHUZjVdLhZO7aQwWd7Inwh6S63KNw5hKxvsY+mnw6XscQeC6KtULHlsDhOmUzlh5ZBE8tWQ 8XXXDED0SXdc5OISWn6QrTs5dmcG2oJ74v9w4HVG7Ml9NSjKckmhSbcKR911I0p2xQl7lCOm zWTj7z/4AM7jbL3HvtjqvmtUuGne/5Eb1zDe53sLbMkde4TNEQogKHGgydXmCMgmugRxT2CR 72xaz3sBuuArKfapPAGub7nj2cgRqNDrRUUKLjQLkKOj0i7DxHkVAwa08ak+rnyUlu50c6Xr gA/pfVz8OtSLo94xVyt2WeY9LHhIlw7FLHZh+VgwtspTGhp1mm7A6PEnlICS3rv4wD0ufNJf E63vnw5tgvArMaXrVuUFROW7iKhzk/Ya7BzONGfcJST97pGtAgtV2bpxR3HJQ+OTB0TQ7zPq NxNUbVIJ43xxl/swc975YRzuWKdSw+vLAd97gRVytDI5n6yMcvwE63wimnz3qpWNIrNJvVKx +fXDhaK4h4JdikppXi3RbUiHhaEpv3FH13Jw3JYZbtKnRNJCAiM/9ziTFc0mLsbxATGCpm0E PzG4q9jteILinQk0gF04oJtfCEphw21YjQAz3X0AfLubNHfQgVjsB6TG1OMvYTHwsXMfMrtw +NwV2vZ7UW6Q+pGldbqpuLusjXHjywgAAHBmEqzNwRo65LOyse6R9eRWy43AFVEx3TSR+J3b tVRO0eMbO1zO0vc3c8ai02jh8YFafzUdeWV38xNtKbqSMBSZfBQad8O325jJRcSVw9N7PcLj OIHHvqfoniuwWuea17rHXTU/cRsSViwnQxakingBO3G0VO3cbZpkN+j8Jih71BLu2ajnmLOi QECeYYWnjeZ1nruC4NeGDpwA/fHF1bn69JbWs920ffrlFVGVjmt3NpMXHbTQZFW82Bi0ke24 1SUZKLQPmRQfpF7HfT3ONqPd52AwOnDnLy+SvDaOE46/8xFGZoEUv3I0iZbAqqqxnBDTfIWP Da1cHc3HkdUPUQGeoZc5CtHoql2b+w1P9dReqx3+jhEhM0mZTFSMuV06jicwMt62q9l0kx0v Sul8WLTrQnxGwr2xQBeJJxWkNaplTm3ogsUYHAOdQYY1iNkcFzNKKX/DmVhMpLlQUfrFXbq1 tcbWlx4rqa+0T/7JTUscj8mtV45QlPHcXg9S7h5aoFfjGsuVyHRbrc5WlSUtwjlgNQpvjeLu 7kzuGuGqvRj4c6fsvfDZx7zVN+VtOsnc2/x464ZH6CqCFEww7cqWXT+WavAzvBJowK1Xvq1X lkOubfZX1/T8bbeVu/QojCD5SjHdFCjTlUWx7WCBkllmaLnZIeCkvdaKRPrt2hVDZwLeYBR5 aFlOfArsdB6lKzAFS7kj7dSqWrc+FJewDWtJ6vQLJ0bC4TSCYHQtsO+t2biCNRQ0IvpkR2SI YEkdSiBv3qPQMClCwc7mrh9IPL0LqvAPvnTWvoBlrb8z9n5c1xHVxLQZg9FpU8pp4RpwM4NS B4llBr3YN3oYyadX4haooNysRQHYrVUkogSPSE7utZECrV8iqQlRwow28PrpHojDvcAqZ1TQ XjjDgnjh/p38Vznwx75gasvVkx0XTZHRDIUHFIdgcCaQtAj8x2+XEPk89pUf22/UJBF9PvyC tDFDAU7z733S2DF2gZcVFqR3ediRKNi1Oz52HTIYoU1CKlBI4iKEpO2F2e2p0ZszdfTs6SGM p/MGfeDhy5dya/znozY/PXU2B/RKJnvY5/D5BtjLMI1B/MU3SgZWXOfXAKv0aP/BJsPQw/PO e/5hHqbGgn4vUHhjJiUxh4IU5o6RuSu8iASGvgF2rooyXWg8NHIBv43tYklS+yScvusjHrdA PiK8u+nf/GlDkc7Ji1OQztgs67CWwsIJsnBeFgsQyAiGeY3ZMJbU/xTZH/AB/Ou9WRTCISwU IHV4+Ex4uoyaX840aBl4113XyP8OgdVGhp2XPPAYCCCzx8eHz4CBJiNRHQufz9ZFdTMHnpGr cVjGv9t8YSyMTzh37Nu1Bq3biJTabJwJgjraIqhTYsB+haFQla5h1N/MYjllWZGO9qP1Yxau IqjNP2GN9q7O9+Xq9kuBzDgLdgbCz/HzZ6c92ufAyYlw8pyXTNMFniPeYud9eFNnyNnuuZlq zIXLeZHrMlx6SwsGPusgMDR2TocedwOfHL48JMPyTAZ9QfuoWPF0dz+Mr98o+tYSWNIjtwmP j170cPO9kJdetl46K7K6yVnNhOc3ppw1bBiI4jadOHp+8rQXb2uMm9e28q7PTQ9chfOKLp2p 5NJddHV7aJr3I0XwzX+VLzys3yrrnO8e37WmPnGwGoi8xe+C2LAGZAQOLIABv4JOlw7RSl5r hKugKpfIPJ02wKLTSg1m/I0HYmRBwB+WkY4ePz05jcQDZA83nMvj+I7HvpkovkS5w6Fad9iO KjmAJvieNDMFQSA8YrzEAUDhUz4hsy83f0hLGMZH+N0ODDN1tgSMb+ieVG5yfAUWDJb4n3aO tgypvMYcW5kWFRoYMIRF3Wv5Bnj+3Ogyg1n10BRfFrB39VTTX5xdpEgBf61hHkmDhkKNGvsH /WNcNwDXeuoN7FY84Yw3i0Q797e++mRyOws3KvxHocJjX7ywedU1LfrFAnZGA6G745qiCPpC Ju6oKHLzSv1yfKwO1elLcAfq2TN1eMivapu98hT6jsKvNi+t7k/LHSLxGwgR3LT/bqaOL1qK R3pxCPBBHZ0eqecnJ6fROPj+r9b0c37/oOnrpP/PJQ8CzhlTNNEXLq19c1JrMi/V00MY5uiF Aosej8Fk+kLm15ppWCLRt7WMNW8mc7yNY96Eb1Ny34fUmsqROoZhXjxVL5+dvoyHAQpM4NcZ ftKHQf5abXrsk6Zvmizrutr8B74YpcviVM3kn3KWmtupgAhZjsTkriEBpkyZBXcRq9xOxJaF vqPohTuXje1qdFyEC3R87WFprPRi8lc2yQEavuEIj35TBYiH7mLTnXS2kUsIPDB9yrf5ay4K l0LaHYzVcLyrJhrjUQIY7y7U2Yerm9Hw9cebD6MeffBh9HZwNfzfwc3ww5V6d/FkDJ+NLq5H F+OLq5sxEvowAjpqfP3havxhdHGuXv8OvvSNGlz9vs8khlc3FyNc2fGHMxD+7/IpLcPo4xhW /OqcphY/e3H1dnh1cTEaXr1VN4Pxb+rNh9HZhTofjs/eD4aXavD+vfo0GI0GVzfDizGg4n8g T56hy+v3w4tzcLxXZ+8/niMRmJO6+nCj3g8vhzfA5s0HZNHR+B1GH9wQCx/HMOs3gSEY+NJN f3QxvFKfhjA2koK/IX8XRGg0fPvuZoyD42/CABV7PZdAVl1ejM7ewa+D18P3QxgWnn8zvLkC 1nGGaqCuB6Ob4dnH94ORuv44uv4wvkCT33mnv293Jlli7r2iS6WKilIg0ljtWsYo10alvTKE 5e6yrc6vDBiR3oVvB2M9lKMntKfwWij8ujCfUcMXUXll01jXKy05pjKuyPirxlatJDKnAWMt F/RFGRLaj+5a05XbjapB7M0FSeaS0iTEI2Zx6R/umKbrkPlvuimKgnVbhy9L891+c86nL7Sc n8DGP6xtGg89KFeDv2Noj49EDMTRsNTbXHLPZ+4o9Y1dEe7OBhYwyA/hXPgKLk6vMZ5p8si4 0L6NvwsNzJ11Sf+R+0I1Goum4W59Q30ZmwQtDVbb3Le1UYrK9WcRFW/tOFnFsggnd2RlAjBj 24I9WItl7ccsJvLFA+4EgFs2rFPiOdWKogUHs1lHqKqN8uSaoKEctkgI+zScaiGMZ8Uq/TVj 9K67a0TOIVCGkjmJ+llYFkV+gFdKktBAEXADUZPq9u8OW5b99vaz+a2tyS2suC5qCGFiEm7F LSNygFyuTEKtKfxtd4lzU+Bh+Ev5uIjL388Xd230wn6MBEN+I96e9IUK1MYUdll0eK91Kb8X pd96Ls2MHfB4n2XoD1v3NrFGsbgoxAH5/OqEhfZrkLi7hLxnfgOaTN+EIauOKn+RouDD6Sz+ Ci72XJOVH4mT7gub4zEPzja5r/0ZuDNhEM+NB490ulCAC50u/H9QSwcI8TsCZBQkAACwdAAA UEsBAhUDFAAIAAgAZl5wN/E7AmQUJAAAsHQAACwADAAAAAAAAAAAQKSBAAAAAGRyYWZ0LWll dGYtYXV0b2NvbmYtcHJvYmxlbS1zdGF0ZW1lbnQtMDIudHh0VVgIAGF8PUcgdj1HUEsFBgAA AAABAAEAZgAAAH4kAAAAAA== --------------080406080302060800010200 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 --------------080406080302060800010200-- From autoconf-bounces@ietf.org Fri Nov 16 06:41:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isza1-0003is-FS; Fri, 16 Nov 2007 06:41:49 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Isza0-0003gy-Qo for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 06:41:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isza0-0003gE-GU for autoconf@ietf.org; Fri, 16 Nov 2007 06:41:48 -0500 Received: from mail3-relais-sop.national.inria.fr ([192.134.164.104]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IszZv-00050b-VR for autoconf@ietf.org; Fri, 16 Nov 2007 06:41:48 -0500 X-IronPort-AV: E=Sophos;i="4.21,426,1188770400"; d="scan'208";a="5887944" Received: from ras75-3-82-226-221-97.fbx.proxad.net (HELO BoolfightMaN-Laptop.local) ([82.226.221.97]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Nov 2007 12:41:44 +0100 Message-ID: <473D81F5.1050502@inria.fr> Date: Fri, 16 Nov 2007 12:41:41 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org Subject: Re: [Autoconf] Review of draft-ietf-autoconf-statement-01 References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> In-Reply-To: <008001c82838$50f37030$f2da5090$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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 > First of all, I would like that the document is lined up with the charter. I > think the primary goal is "Develop an IPv6 address autoconfiguration > mechanism" and NOT work on prefix delegation. I think those are very > different. And I think existing prefix delegation mechanisms can be used. So > why invent something that can be reused? The charter is very clear on this. > The PS already insists on the importance of leveraging existing protocols. As far as prefix delegation is concerned, the fact that the topology is dynamic brings issues regarding using existing prefic delegation mechanisms. So the PS states that these issues should be looked at. > Then I want descriptions of problems with MLA and MGA (L=local, G=global). I > think problems for the two types are very different, as MGAs must be > globally routable and topologically correct and generation has to do with > Border Routers. Note that an MGA can be used as MLA, MLA cannot be used as > MGA. I think MLA are to be used as failback when no MGA can be generated, > e.g. just after startup MN and in a Standalone MANET. > I agree. Thus the definitions are tighter in -02. > Then I want the focus on IPv6 unique address generation. I want a list of > all current methods, and the probability / risks on duplicates. My personal > opinion is that some methods can provide almost absolutely uniqueness, other > methods cannot. Here is also a link to a security issue, e.g. address > spoofing. My personal opinion is that duplicates caused by spoofing is a far > more important problem than collisions. And a remedy for the spoofing > security issue would solve collisions also. Or it shall be described why > not. > We must be careful not to go in the solution space. What we are trying to do here is describing the taxonomy of problems and scenarios that are of interest. > Recently, the relation with routing is discussed. I think there are > problems. Number one is the routing protocol convergence. It takes time for > the MANET protocol to adopt a newly generated address, and during > convergence connectivity from other nodes and border routers in the MANET to > the node with the newly generated address is bad. > The second relation is for MGA and the relation between Border Routers used > for MGA generation. This problem is described in the current text. Maybe > text should specify more precisely what the problem really is. > Current text: >>>> When a device changes its MANET border router attachment ... > How can a device changes its MANET border router attachment? OK, it can > generate a new MGA for using that border router. But it cannot attach to > that border router, this is up to the routing protocol and is dependent on > other nodes. This is a large problem, with as a result traffic blocking by > ingress filters on border routers not accepting MGAs as source with prefixes > not belonging to that border outer. > Following text on asymmetry may be removed, it has to do with routing and > not with addressing. >>>> asymmetry in the routers' choice of ingress/egress MANET border >>>> router can lead to non-optimal paths followed by inbound/outbound >>>> data traffic > I think talking about addresses and prefixes without talking about how it impacts on routing is nonsense. The whole Internet architecture is based on a precise relationship between prefix<=>location<=>routing. So I think we have to mention the potential impact of ill address/prefix configuration in this document. > Text on Deployment Scenarios should be taken out and inserted in the MANET > Architecture document. > I do not agree. Again, this document is supposed to describe the taxonomy of problems and scenarios that are of interest, and to define the terminology in order to do so. > On references: > There are new RFCs for IPv6 ND and Autoconf (RF4861, RFC4862). > Following references should be added: > RFC4291: IP Version 6 Addressing Architecture > RFC3041: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 > RFC3971: SEcure Neighbor Discovery (SEND) > RFC3972: Cryptographically Generated Addresses (CGA) > RFC4429: Optimistic Duplicate Address Detection (DAD) for IPv6 > RFC4193: Unique Local IPv6 Unicast Addresses > Also consider: > draft-ietf-nemo-prefix-delegation: Mobile Network Prefix Delegation > Consider removing references to: > RFC2328: OSPF version 2 > RFC2740: OSPF for IPv6 > draft-ietf-manet-iana: Allocations for the Mobile Ad hoc Networks (MANET) > Working Group > > Changing references implies changing text. Maybe adding lots of text. > > Thanks, > Teco. > > > > _______________________________________________ > 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 Nov 16 07:04:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IszvX-0003Vp-FD; Fri, 16 Nov 2007 07:04:03 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IszvV-0003UD-Ht for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 07:04:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IszvV-0003Te-6S for autoconf@ietf.org; Fri, 16 Nov 2007 07:04:01 -0500 Received: from hpsmtp-eml11.kpnxchange.com ([213.75.38.111]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IszvU-000303-Ca for autoconf@ietf.org; Fri, 16 Nov 2007 07:04:01 -0500 Received: from hpsmtp-eml08.kpnxchange.com ([213.75.38.108]) by hpsmtp-eml11.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 13:03:59 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml08.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 13:03:58 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7695.1060808@gmail.com> In-Reply-To: <473D7695.1060808@gmail.com> Subject: RE: [Autoconf] Review of draft-ietf-autoconf-statement-01 Date: Fri, 16 Nov 2007 13:03:46 +0100 Message-ID: <00b101c82848$bd7580d0$38608270$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgoPuSxoM2/1WlnTvOVCgFROnp/2AABVPPA Content-Language: nl X-OriginalArrivalTime: 16 Nov 2007 12:03:58.0968 (UTC) FILETIME=[C51ABF80:01C82848] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 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 > > First of all, I would like that the document is lined up with the > > charter. I think the primary goal is "Develop an IPv6 address > > autoconfiguration mechanism" and NOT work on prefix delegation. I > > think those are very different. And I think existing prefix > > delegation mechanisms can be used. So why invent something that can > > be reused? The charter is very clear on this. > > Err... I'm agreeing with you to have a PS aligned with the Charter. > But > I don't understand: do you disagree reusing DHCP PD? ("NOT work on > prefix delegation"). I may misunderstand you. Why not reusing IPv6? Or UDP? ;-) Of course, we shall reuse what we already have. When there are problems, and only then, we will write it down. As a next step, we work on a solution. > > Then I want descriptions of problems with MLA and MGA (L=local, > > G=global). I think problems for the two types are very different, as > > MGAs must be globally routable and topologically correct and > > generation has to do with Border Routers. > > Sorry what's MG/LA other than global/local? M? A? ;-) That is why it is important to commonly use terminology. MLA: MANET Local address (is listed in I-D) MGA: you can find out yourself... > It's strange to talk about topologically correct addresses when the > strong assumption in MANETs is that the topology changes. In a sense > any address is correct in a topology changing to follow it. No, it is not. That is the problem. MGA are unique in MANET and may be used for intra-MANET traffic. But for traffic with CNs, a topologically correct addresses must be used. You are right on topology changing in MANET, this introduces the problem! > Or maybe one AUTOCONF requirement is to support dynamic L2 topology > changes with a overlay stable L3 topologies? Or vice-versa? Or none? We are in IETF here and discus Internet and IP related issues. When L2 mechanisms hide mobility, that's fine. When not, we (IETF) have a problem. > I think the problem (and solution) is very different if we consider the > L3 topology be stable over a fixed L2 topology vs L3-variable/L2- > variable. O no!!! Obstacles may move also. I have lots of experience with this, my test environment is spread over multiple buildings and we do not have to move MN for frequently topology changes;-) Some strange guys sit in iron object to go from A to B. Sometimes they are delivering something to us and block some links for a long time. Tests may be not reproducible but very similar to real world. > For example, if we consider a MANET to be a set of PDAs physically > moving around wifi range, but keeping their L2 and L3 topologies > stable, > then the obvious solution is DHCPv6-PD there's no need of anything > else. > And if this is a typical deploying scenario then we're all happy. If one has also WiMAX or 3G, and there is some delivery using these iron objects, traffic flows could swap to the other BR. Nice if we could use this technology, isn't it? > If on the other hand we consider a MANET to be a pda+laptop+phone > personal set dynamically changing the way it intra-connects and > Internet-connects then we can have a whole different set of solutions. > But is this a relevant scenario, pertinent from market perspective - > question mark. Typed in this scenario above. I do not see any reason not supporting this. Or be aware of the problem. If it is not needed in some cases, OK. But writing this down in a problem statement is the first thing we shall do. > > Unfortunately to me, the current scenarios in the PS draft aren't > detailed enough, and too theoretical. For example they only briefly > mention "emergency network", "UMTS", "WiMAX" at the end of sections. > And there are so many ways and types deployed of emergency networks and > umts and wimax where there's no problem of address auto-configuration - > because they use ppp/dhcp/L2IPaddressassignment. Please stick to MANET related topics. And please don't focus on technology. We are in IETF and produce protocols that are adaptive for all these lower layer technologies. > I think I have a big problem understanding AUTOCONF overall. I don't > understand the requirements. Alex: Please read MANET Architecture. And RFC4861 Appendix B: (RFC2461 is OK) o Adding additional procedures for links where asymmetric and non- transitive reachability is part of normal operations. Such procedures might allow hosts and routers to find usable paths on, e.g., radio links. And RFC4862 3. Design Goals (RFC2462 is OK). And RFC4429 Appendix A. Probability of Collision > Then number zero is to make simply routing (strike protocol), make the > default route meaningful and work overall in the presence of topology > changes (L2? L3?). Not in scope for Autoconf. I thought we agreed on having a PS aligned with the Charter? (your text;-) Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 16 07:22: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 1It0Di-0003Dx-QP; Fri, 16 Nov 2007 07:22:50 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1It0Dh-0003DK-MP for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 07:22:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It0Dh-0003DB-Bc for autoconf@ietf.org; Fri, 16 Nov 2007 07:22:49 -0500 Received: from hpsmtp-eml12.kpnxchange.com ([213.75.38.112]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It0Dg-00046G-EP for autoconf@ietf.org; Fri, 16 Nov 2007 07:22:48 -0500 Received: from hpsmtp-eml08.kpnxchange.com ([213.75.38.108]) by hpsmtp-eml12.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 13:22:47 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml08.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 13:22:47 +0100 From: "Teco Boot" To: "'Emmanuel Baccelli'" , References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D81F5.1050502@inria.fr> In-Reply-To: <473D81F5.1050502@inria.fr> Subject: RE: [Autoconf] Review of draft-ietf-autoconf-statement-01 Date: Fri, 16 Nov 2007 13:22:34 +0100 Message-ID: <00b201c8284b$5dd4bb20$197e3160$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgoRcE+WASco0uISMGCx4mIu6qrlgAA3ojg Content-Language: nl X-OriginalArrivalTime: 16 Nov 2007 12:22:47.0085 (UTC) FILETIME=[6583BDD0:01C8284B] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 Hi Emmanual. Comments inline. Teco. > > First of all, I would like that the document is lined up with the > charter. I > > think the primary goal is "Develop an IPv6 address autoconfiguration > > mechanism" and NOT work on prefix delegation. I think those are very > > different. And I think existing prefix delegation mechanisms can be > used. So > > why invent something that can be reused? The charter is very clear on > this. > > > > The PS already insists on the importance of leveraging existing > protocols. As far as prefix delegation is concerned, the fact that the > topology is dynamic brings issues regarding using existing prefic > delegation mechanisms. So the PS states that these issues should be > looked at. First, declare the two issues. PS draft: Address assignment - The process of configuring a generated address on an interface Prefix delegation - ??????? I think I have a different idea what prefix delegation is. I'll comment on this in -02. > > Then I want the focus on IPv6 unique address generation. I want a > list of > > all current methods, and the probability / risks on duplicates. My > personal > > opinion is that some methods can provide almost absolutely > uniqueness, other > > methods cannot. Here is also a link to a security issue, e.g. address > > spoofing. My personal opinion is that duplicates caused by spoofing > is a far > > more important problem than collisions. And a remedy for the spoofing > > security issue would solve collisions also. Or it shall be described > why > > not. > > > > We must be careful not to go in the solution space. What we are trying > to do here is describing the taxonomy of problems and scenarios that > are > of interest. Partly agree. But please do not reinvent the wheel. The Autoconf is solving problems with RFCs2462/RFC2461 for MANET, nothing more. And all additions on these could be used, is applicable. If we forget verifying there is a problem to solve, we are forgetting something. I do not agree this is solution space. Not at all. > I think talking about addresses and prefixes without talking about how > it impacts on routing is nonsense. That is what I am saying also. > The whole Internet architecture is > based on a precise relationship between prefix<=>location<=>routing. So > I think we have to mention the potential impact of ill address/prefix > configuration in this document. Yes. But asymmetry in inbound/outbound is a generic issue and not related to Autoconf. Or am I missing something? > > > > Text on Deployment Scenarios should be taken out and inserted in the > MANET Architecture document. > I do not agree. Again, this document is supposed to describe the > taxonomy of problems and scenarios that are of interest, and to define > the terminology in order to do so. Describing something twice is of no use. I think both Autoconf documents shall be checked on completeness and redundancy. General MANET architecture and related issues should be described in the MANET Architecture document. I think Deployment Scenarios is MANET Architecture and not Problem Statement, although this is a minor issue. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 16 08:38: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 1It1PM-0001jz-Nj; Fri, 16 Nov 2007 08:38:56 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1It1PL-0001hG-9V for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 08:38:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It1PK-0001fC-T6 for autoconf@ietf.org; Fri, 16 Nov 2007 08:38:54 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1It1PG-000309-2v for autoconf@ietf.org; Fri, 16 Nov 2007 08:38:54 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-153.messagelabs.com!1195220329!4058485!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 25004 invoked from network); 16 Nov 2007 13:38:49 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-153.messagelabs.com with SMTP; 16 Nov 2007 13:38:49 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lAGDchqV022265; Fri, 16 Nov 2007 06:38:48 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id lAGDcgQo028868; Fri, 16 Nov 2007 07:38:42 -0600 (CST) 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 lAGDcfbR028843; Fri, 16 Nov 2007 07:38:41 -0600 (CST) Message-ID: <473D9D60.6090009@gmail.com> Date: Fri, 16 Nov 2007 14:38:40 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Teco Boot Subject: Re: Scenarios and Requirements (was: [Autoconf] Review of draft-ietf-autoconf-statement-01) References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7695.1060808@gmail.com> <00b101c82848$bd7580d0$38608270$@nl> In-Reply-To: <00b101c82848$bd7580d0$38608270$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071115-0, 15/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c 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 Teco, Teco Boot wrote: >>> First of all, I would like that the document is lined up with the >>> charter. I think the primary goal is "Develop an IPv6 address >>> autoconfiguration mechanism" and NOT work on prefix delegation. I >>> think those are very different. And I think existing prefix >>> delegation mechanisms can be used. So why invent something that >>> can be reused? The charter is very clear on this. >> Err... I'm agreeing with you to have a PS aligned with the Charter. >> But I don't understand: do you disagree reusing DHCP PD? ("NOT >> work on prefix delegation"). I may misunderstand you. > Why not reusing IPv6? Or UDP? ;-) Of course, we shall reuse what we > already have. When there are problems, and only then, we will write > it down. As a next step, we work on a solution. Reuse DHCP when doing address autoconf. Reuse UDP when transporting data. Reuse both. In what is DHCP/UDP lacking features necessary to AUTOCONF? (please don't direct me to MANET WG) >>> Then I want descriptions of problems with MLA and MGA (L=local, >>> G=global). I think problems for the two types are very different, >>> as MGAs must be globally routable and topologically correct and >>> generation has to do with Border Routers. >> Sorry what's MG/LA other than global/local? M? A? > ;-) That is why it is important to commonly use terminology. MLA: > MANET Local address (is listed in I-D) MGA: you can find out > yourself... Sorry. I've tried to figure out myself before questioning you. And I started searching MGA and there wasn't. I should have started searching MLA (which sounds surprisingly tongue twisting LMA of netlmm btw). Thus, I think maybe the PS terminology could define MGA in addition to MLA - it would have been clearer to one reader. >> It's strange to talk about topologically correct addresses when the >> strong assumption in MANETs is that the topology changes. In a >> sense any address is correct in a topology changing to follow it. > No, it is not. That is the problem. MGA are unique in MANET and may > be used for intra-MANET traffic. But for traffic with CNs, a > topologically correct addresses must be used. You are right on > topology changing in MANET, this introduces the problem! > > >> Or maybe one AUTOCONF requirement is to support dynamic L2 topology >> changes with a overlay stable L3 topologies? Or vice-versa? Or >> none? > We are in IETF here and discus Internet and IP related issues. When > L2 mechanisms hide mobility, that's fine. When not, we (IETF) have a > problem. Can we detail the when not case? I know of some MANET testbeds where the L2 hides mobility from L3, and that's with WiFi laptops and pdas. Can we describe a case MANET where L2 doesn't hide the mobility to L3? >> I think the problem (and solution) is very different if we consider >> the L3 topology be stable over a fixed L2 topology vs >> L3-variable/L2- variable. > O no!!! Obstacles may move also. I have lots of experience with this, > my test environment is spread over multiple buildings and we do not > have to move MN for frequently topology changes;-) Some strange guys > sit in iron object to go from A to B. Sometimes they are delivering > something to us and block some links for a long time. Can we describe this scenario in the Scenarios section? It sounds intriguing to me, and if we try to describe it in draft then people may chime in and share your views. > Tests may be not reproducible but very similar to real world. > > >> For example, if we consider a MANET to be a set of PDAs physically >> moving around wifi range, but keeping their L2 and L3 topologies >> stable, then the obvious solution is DHCPv6-PD there's no need of >> anything else. And if this is a typical deploying scenario then >> we're all happy. > If one has also WiMAX or 3G, and there is some delivery using these > iron objects, traffic flows could swap to the other BR. Nice if we > could use this technology, isn't it? > > >> If on the other hand we consider a MANET to be a pda+laptop+phone >> personal set dynamically changing the way it intra-connects and >> Internet-connects then we can have a whole different set of >> solutions. But is this a relevant scenario, pertinent from market >> perspective - question mark. > Typed in this scenario above. I do not see any reason not supporting > this. If needed, I can describe this scenario in the Scenarios section of the PS document. > Or be aware of the problem. If it is not needed in some cases, OK. > But writing this down in a problem statement is the first thing we > shall do. > > >> Unfortunately to me, the current scenarios in the PS draft aren't >> detailed enough, and too theoretical. For example they only >> briefly mention "emergency network", "UMTS", "WiMAX" at the end of >> sections. And there are so many ways and types deployed of >> emergency networks and umts and wimax where there's no problem of >> address auto-configuration - because they use >> ppp/dhcp/L2IPaddressassignment. > Please stick to MANET related topics. And please don't focus on > technology. We are in IETF and produce protocols that are adaptive > for all these lower layer technologies. ??? What's MANET? This is not a rhetorical question. This simply says I don't personally understand the word MANET in a sense that could lead to a special IP mechanism. 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 Nov 16 08:44:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It1UX-000271-0r; Fri, 16 Nov 2007 08:44:17 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1It1UW-00026W-1G for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 08:44:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It1UV-00026O-Nm for autoconf@ietf.org; Fri, 16 Nov 2007 08:44:15 -0500 Received: from hpsmtp-eml19.kpnxchange.com ([213.75.38.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It1UQ-0003I2-MX for autoconf@ietf.org; Fri, 16 Nov 2007 08:44:15 -0500 Received: from hpsmtp-eml06.kpnxchange.com ([213.75.38.106]) by hpsmtp-eml19.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 14:44:09 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml06.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 14:44:09 +0100 From: "Teco Boot" To: "'Emmanuel Baccelli'" , References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7CAC.9040806@inria.fr> In-Reply-To: <473D7CAC.9040806@inria.fr> Subject: RE: [Autoconf] new version draft-ietf-autoconf-statement-02 (pre-release) Date: Fri, 16 Nov 2007 14:43:55 +0100 Message-ID: <00c001c82856$bba57360$32f05a20$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgoQqKK5qmajTp+TLGuAcff4uRvygAEKVaA Content-Language: nl X-OriginalArrivalTime: 16 Nov 2007 13:44:09.0075 (UTC) FILETIME=[C3684C30:01C82856] X-Spam-Score: -1.0 (-) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c 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 Hi Emmanuel, On not mentioning Solution Space, I do not like the introduction of = Internet Configuration Provider right now. For Border Router, I roughly what this is, although the discussion is on = a specific border router connecting a MANET to the Internet and a border router connecting two MANETs, without Internet Connectivity. I think Autoconf has only to deal with MANETs connected to Internet. Standalone MANETs are of less interest of IETF, and especially the = Internet Area. So for me, a Border Router is a router connecting a MANET to the Internet. Minor issue with term Internet. When a MANET is connected to Internet, = it is immediately part of the Internet.=20 Then, a router at the bottom can be used as Border Router for a lower = level MANET. So be careful when defining terminology for Internet and Border Router. Teco. > -----Oorspronkelijk bericht----- > Van: Emmanuel Baccelli [mailto:Emmanuel.Baccelli@inria.fr] > Verzonden: vrijdag 16 november 2007 12:19 > Aan: autoconf@ietf.org > Onderwerp: [Autoconf] new version draft-ietf-autoconf-statement-02 > (pre-release) >=20 > Hi all, authors, Thomas, Teco, >=20 > Thanks for the feedback. Here's an updated version of the PS taking > into account recent comments by Thomas and Teco. Aside from fixing > various editorial details that they pointed out, the main upgrades > concern: >=20 >=20 > * the introduction in the terminology section of the term ICP, = standing > for Internet Configuration Provider, lifting an ambiguity about border > routers' potential funtionalities in MANETs. >=20 > * the tightening of the definition/use of "prefix" and "address" > related terms. >=20 > * more precision in relating to existing protocols' scope as well as > the one of the protocols-yet-to-be-designed. >=20 > * updated references >=20 >=20 >=20 > I encourage everyone to continue the public reviewing and discussions > on this updated basis, until it is published (the plan is to submit > soon ;) >=20 >=20 > Cheers, >=20 > Emmanuel >=20 >=20 >=20 >=20 > Teco Boot a =E9crit : > > All, > > > > More comments on the Problem Statement. > > > > First of all, I would like that the document is lined up with the > charter. I > > think the primary goal is "Develop an IPv6 address autoconfiguration > > mechanism" and NOT work on prefix delegation. I think those are very > > different. And I think existing prefix delegation mechanisms can be > used. So > > why invent something that can be reused? The charter is very clear = on > this. > > > > Then I want descriptions of problems with MLA and MGA (L=3Dlocal, > G=3Dglobal). I > > think problems for the two types are very different, as MGAs must be > > globally routable and topologically correct and generation has to do > with > > Border Routers. Note that an MGA can be used as MLA, MLA cannot be > used as > > MGA. I think MLA are to be used as failback when no MGA can be > generated, > > e.g. just after startup MN and in a Standalone MANET. > > > > Then I want the focus on IPv6 unique address generation. I want a > list of > > all current methods, and the probability / risks on duplicates. My > personal > > opinion is that some methods can provide almost absolutely > uniqueness, other > > methods cannot. Here is also a link to a security issue, e.g. = address > > spoofing. My personal opinion is that duplicates caused by spoofing > is a far > > more important problem than collisions. And a remedy for the = spoofing > > security issue would solve collisions also. Or it shall be described > why > > not. > > > > Recently, the relation with routing is discussed. I think there are > > problems. Number one is the routing protocol convergence. It takes > time for > > the MANET protocol to adopt a newly generated address, and during > > convergence connectivity from other nodes and border routers in the > MANET to > > the node with the newly generated address is bad. > > The second relation is for MGA and the relation between Border > Routers used > > for MGA generation. This problem is described in the current text. > Maybe > > text should specify more precisely what the problem really is. > > Current text: > >>>> When a device changes its MANET border router attachment ... > > How can a device changes its MANET border router attachment? OK, it > can > > generate a new MGA for using that border router. But it cannot = attach > to > > that border router, this is up to the routing protocol and is > dependent on > > other nodes. This is a large problem, with as a result traffic > blocking by > > ingress filters on border routers not accepting MGAs as source with > prefixes > > not belonging to that border outer. > > Following text on asymmetry may be removed, it has to do with = routing > and > > not with addressing. > >>>> asymmetry in the routers' choice of ingress/egress MANET border > >>>> router can lead to non-optimal paths followed by inbound/outbound > >>>> data traffic > > > > Text on Deployment Scenarios should be taken out and inserted in the > MANET > > Architecture document. > > > > On references: > > There are new RFCs for IPv6 ND and Autoconf (RF4861, RFC4862). > > Following references should be added: > > RFC4291: IP Version 6 Addressing Architecture > > RFC3041: Privacy Extensions for Stateless Address Autoconfiguration > in IPv6 > > RFC3971: SEcure Neighbor Discovery (SEND) > > RFC3972: Cryptographically Generated Addresses (CGA) > > RFC4429: Optimistic Duplicate Address Detection (DAD) for IPv6 > > RFC4193: Unique Local IPv6 Unicast Addresses > > Also consider: > > draft-ietf-nemo-prefix-delegation: Mobile Network Prefix Delegation > > Consider removing references to: > > RFC2328: OSPF version 2 > > RFC2740: OSPF for IPv6 > > draft-ietf-manet-iana: Allocations for the Mobile Ad hoc Networks > (MANET) > > Working Group > > > > Changing references implies changing text. Maybe adding lots of = text. > > > > Thanks, > > Teco. > > > > > > > > _______________________________________________ > > 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 Nov 16 08:56: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 1It1gD-0002pQ-Un; Fri, 16 Nov 2007 08:56:21 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1It1gA-0002jO-1w for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 08:56:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It1g9-0002in-LU for autoconf@ietf.org; Fri, 16 Nov 2007 08:56:17 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1It1g6-0003y0-9i for autoconf@ietf.org; Fri, 16 Nov 2007 08:56:17 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-128.messagelabs.com!1195221412!10029071!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 31842 invoked from network); 16 Nov 2007 13:56:52 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-13.tower-128.messagelabs.com with SMTP; 16 Nov 2007 13:56:52 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id lAGDu86N011730; Fri, 16 Nov 2007 06:56:12 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id lAGDu7WM018655; Fri, 16 Nov 2007 07:56:07 -0600 (CST) 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 lAGDu5YS018625; Fri, 16 Nov 2007 07:56:05 -0600 (CST) Message-ID: <473DA174.6050600@gmail.com> Date: Fri, 16 Nov 2007 14:56:04 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Teco Boot Subject: Re: Border Router term (was: [Autoconf] new version draft-ietf-autoconf-statement-02 (pre-release)) References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7CAC.9040806@inria.fr> <00c001c82856$bba57360$32f05a20$@nl> In-Reply-To: <00c001c82856$bba57360$32f05a20$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071115-0, 15/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 Teco Boot wrote: [...] > Minor issue with term Internet. When a MANET is connected to > Internet, it is immediately part of the Internet. Then, a router at > the bottom can be used as Border Router for a lower level MANET. So > be careful when defining terminology for Internet and Border Router. Do we have an RFC definition of the Border Router term? I know of Area BR (ABR in ospf) and ASBR (Autonomous System Border Router). But is there a short English "Border Router" term defined in an RFC? (don't direct me to manufacturer manuals or Wikipedia in German :-) If yes then let's reuse. If not then let's define. 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 Nov 16 09:05:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It1ob-0002JJ-O6; Fri, 16 Nov 2007 09:05:01 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1It1oa-0002Ht-Ij for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 09:05:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It1oa-0002Hk-94 for autoconf@ietf.org; Fri, 16 Nov 2007 09:05:00 -0500 Received: from hpsmtp-eml11.kpnxchange.com ([213.75.38.111]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It1oX-0004bn-Nn for autoconf@ietf.org; Fri, 16 Nov 2007 09:05:00 -0500 Received: from hpsmtp-eml09.kpnxchange.com ([213.75.38.109]) by hpsmtp-eml11.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 15:04:56 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml09.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 15:04:55 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7695.1060808@gmail.com> <00b101c82848$bd7580d0$38608270$@nl> <473D9D60.6090009@gmail.com> In-Reply-To: <473D9D60.6090009@gmail.com> Subject: RE: Scenarios and Requirements (was: [Autoconf] Review of draft-ietf-autoconf-statement-01) Date: Fri, 16 Nov 2007 15:04:42 +0100 Message-ID: <00c701c82859$a2cea070$e86be150$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgoVgZqBGfl6wKmQkiJljlFI5JP5QAAgs9A Content-Language: nl X-OriginalArrivalTime: 16 Nov 2007 14:04:56.0012 (UTC) FILETIME=[AAA3C8C0:01C82859] X-Spam-Score: -1.0 (-) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 Alex, comments inline. Teco. > In what is DHCP/UDP lacking features necessary to AUTOCONF? (please > don't direct me to MANET WG) No, I won't direct you to MANET WG. This info shall be included in the Autoconf PS. If you can't find it, post this as comment on ML. > >> Or maybe one AUTOCONF requirement is to support dynamic L2 topology > >> changes with a overlay stable L3 topologies? Or vice-versa? Or > >> none? > > We are in IETF here and discus Internet and IP related issues. When > > L2 mechanisms hide mobility, that's fine. When not, we (IETF) have a > > problem. > > Can we detail the when not case? Yes, this is described in MANET Architecture. > >> I think the problem (and solution) is very different if we consider > >> the L3 topology be stable over a fixed L2 topology vs > >> L3-variable/L2- variable. > > O no!!! Obstacles may move also. I have lots of experience with this, > > my test environment is spread over multiple buildings and we do not > > have to move MN for frequently topology changes;-) Some strange guys > > sit in iron object to go from A to B. Sometimes they are delivering > > something to us and block some links for a long time. > > Can we describe this scenario in the Scenarios section? It sounds > intriguing to me, and if we try to describe it in draft then people may > chime in and share your views. Flapping links is common in wireless technologies. I think the MANET Architecture document describes wireless likes quite good, although it has some abstraction level. I prefer this abstraction level and not zoom into details. > What's MANET? > > This is not a rhetorical question. This simply says I don't personally > understand the word MANET in a sense that could lead to a special IP > mechanism. Maybe there are multiple definitions. In Autoconf context, it is well defined in MANET Architecture. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 16 09:08:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It1rW-0004fz-3h; Fri, 16 Nov 2007 09:08:02 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1It1rU-0004c7-H8 for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 09:08:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It1rU-0004bK-6M for autoconf@ietf.org; Fri, 16 Nov 2007 09:08:00 -0500 Received: from maile.telecomitalia.it ([156.54.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It1rO-0004lp-LB for autoconf@ietf.org; Fri, 16 Nov 2007 09:08:00 -0500 thread-index: AcgoWhP/t9OAahK3SBmE9aOL2Xwp/w== Received: from ptpxch009ba020.idc.cww.telecomitalia.it ([156.54.240.52]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 15:07:52 +0100 Received: from ptpxch006ba020.idc.cww.telecomitalia.it ([156.54.240.45]) by ptpxch009ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 15:07:52 +0100 Received: from [10.229.4.26] ([10.229.4.26]) by ptpxch006ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 15:07:51 +0100 Message-ID: <473DA3CB.8050404@telecomitalia.it> Date: Fri, 16 Nov 2007 15:06:03 +0100 Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2929 From: "Simone Ruffino" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Subject: Re: [Autoconf] Review of draft-ietf-autoconf-statement-01 References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D81F5.1050502@inria.fr> In-Reply-To: <473D81F5.1050502@inria.fr> Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 16 Nov 2007 14:07:51.0607 (UTC) FILETIME=[134D7470:01C8285A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 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, some quick comment below. Generally, I agree with Emmanuel. mytwocents. Regs, Simone Emmanuel Baccelli wrote: > Hi Teco, see inline > >> First of all, I would like that the document is lined up with the=20 >> charter. I >> think the primary goal is "Develop an IPv6 address autoconfiguration >> mechanism" and NOT work on prefix delegation. I think those are very >> different. And I think existing prefix delegation mechanisms can be=20 >> used. So >> why invent something that can be reused? The charter is very clear on = >> this. >> > > The PS already insists on the importance of leveraging existing=20 > protocols. As far as prefix delegation is concerned, the fact that the = > topology is dynamic brings issues regarding using existing prefic=20 > delegation mechanisms. So the PS states that these issues should be=20 > looked at. I might add that PS clearly specifies (many times) that the goal of an=20 autoconfiguration mechanism (not of a prefix delegation mechanism) IS=20 address assigment AND prefix delegation. > >> Then I want descriptions of problems with MLA and MGA (L=3Dlocal,=20 >> G=3Dglobal). I >> think problems for the two types are very different, as MGAs must be >> globally routable and topologically correct and generation has to do=20 >> with >> Border Routers. Note that an MGA can be used as MLA, MLA cannot be=20 >> used as >> MGA. I think MLA are to be used as failback when no MGA can be=20 >> generated, >> e.g. just after startup MN and in a Standalone MANET. >> > > I agree. Thus the definitions are tighter in -02. Manet Local Address has a precise meaning within a MANET and, hence we=20 need its definition. Instead, a IPv6 Global Address still remains a IPv6 = Global Address within a MANET, so I don't think a new definition is=20 really needed. I'm afraid it generates more confusion... > >> Then I want the focus on IPv6 unique address generation. I want a=20 >> list of >> all current methods, and the probability / risks on duplicates. My=20 >> personal >> opinion is that some methods can provide almost absolutely=20 >> uniqueness, other >> methods cannot. Here is also a link to a security issue, e.g. address >> spoofing. My personal opinion is that duplicates caused by spoofing=20 >> is a far >> more important problem than collisions. And a remedy for the spoofing >> security issue would solve collisions also. Or it shall be described = why >> not. >> > > We must be careful not to go in the solution space. What we are trying = > to do here is describing the taxonomy of problems and scenarios that=20 > are of interest. Absolutely agree! Many times in the past we (authors) tried to include=20 more details of the problems any single solution (e.g. prefix delegation = with DHCP) might have. It was agreed, IIRC, that was out-of-scope and we = were required to focus only on the problem. Moreover, don't other contributions to this WG (I'm talking about Carlos = work) provide some sort of gap analysis of current methods ? I=20 definitely think that gap analysis should be carried out separately,=20 also to speed up WG work. > >> Recently, the relation with routing is discussed. I think there are >> problems. Number one is the routing protocol convergence. It takes=20 >> time for >> the MANET protocol to adopt a newly generated address, and during >> convergence connectivity from other nodes and border routers in the=20 >> MANET to >> the node with the newly generated address is bad. >> The second relation is for MGA and the relation between Border=20 >> Routers used >> for MGA generation. This problem is described in the current text. = Maybe >> text should specify more precisely what the problem really is.=20 >> Current text: >>>>> When a device changes its MANET border router attachment ... >> How can a device changes its MANET border router attachment?=20 Teco, I agree that the word 'attachment' is not fully appropriate here,=20 because it reminds of one-hop radio attachment (this word is frequently=20 used in cellular networks). I also suspect that 'device' here is wrong:=20 it should be 'MANET router'. In our minds, a MANET router X is 'attached' to a border router Y, if=20 prefixes used by X have been delegated by Y. Hence, packets flowing from = the Internet to the MANET router X are injected in the MANET by border=20 router Y. To answer your question : a MANET border router can abruptly disappear=20 from the MANET, as any other MANET router. In a MANET where multiple=20 MANET border routers are available and active (I mean, they're=20 delegating valid prefixes), MANET routers can immediately use a new=20 prefix coming from a new border router. >> OK, it can >> generate a new MGA for using that border router. But it cannot attach = to >> that border router, this is up to the routing protocol and is=20 >> dependent on >> other nodes. This is a large problem, with as a result traffic=20 >> blocking by >> ingress filters on border routers not accepting MGAs as source with=20 >> prefixes >> not belonging to that border outer. That is a good point, which I personally support and which covers both=20 routing AND addressing, in my opinion. Currently, we make no assumptions on Ingress Filtering on MANET border=20 routers, as well as on any other characteristics Border Router might=20 have. Now, in a MANET with multiple border routers, ingress and egress=20 routers can be different and problems like the one you mentioned could=20 arise. In fact, when MR chooses a prefix, among those received, it consequently = decides which border router will receive its traffic from the outside:=20 hence, it decides its ingress border router. But, AFAIK, ingress border=20 router (for a particular MR) could differ from the egress border router=20 (for that particular MR), which is usually indicated by the routing=20 protocol. In my opinion, this is a sort of "cross-issue" that can impact routing,=20 addressing mechanism, source address selection. I think it should not be = excluded from the scope of AUTOCONF WG and in particular from this I-D. >> Following text on asymmetry may be removed, it has to do with routing = >> and >> not with addressing. >>>>> asymmetry in the routers' choice of ingress/egress MANET border >>>>> router can lead to non-optimal paths followed by inbound/outbound >>>>> data traffic My previous comment applies here too. In my opinion it has do with=20 addressing too, since, in MANET case, an unwise addressing mechanism can = have severe impacts on performance of applications running on MANET=20 routers, or on hosts attached to them. > I think talking about addresses and prefixes without talking about how = > it impacts on routing is nonsense. The whole Internet architecture is=20 > based on a precise relationship between = prefix<=3D>location<=3D>routing.=20 > So I think we have to mention the potential impact of ill=20 > address/prefix configuration in this document. > > >> Text on Deployment Scenarios should be taken out and inserted in the=20 >> MANET >> Architecture document. >> > > I do not agree. Again, this document is supposed to describe the=20 > taxonomy of problems and scenarios that are of interest, and to define = > the terminology in order to do so. > > Agree with Emmanuel. We discussed this long ago. Deployment scenarios=20 are useful to describe characteristics of scenarios in which autoconf=20 mechanism have to work and hence they are functional to the PS=20 definition. For example, dynamic scenarios where mobile phones connect=20 to the Internet through a cellular network. -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please contact us by replying to = webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- =20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 16 09:08: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 1It1rW-0004gM-B8; Fri, 16 Nov 2007 09:08:02 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1It1rU-0004cF-Nr for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 09:08:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It1rU-0004c1-E7 for autoconf@ietf.org; Fri, 16 Nov 2007 09:08:00 -0500 Received: from mail1-relais-roc.national.inria.fr ([192.134.164.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It1rP-0004ls-AL for autoconf@ietf.org; Fri, 16 Nov 2007 09:08:00 -0500 X-IronPort-AV: E=Sophos;i="4.21,426,1188770400"; d="scan'208";a="4572972" Received: from ras75-3-82-226-221-97.fbx.proxad.net (HELO BoolfightMaN-Laptop.local) ([82.226.221.97]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Nov 2007 15:07:53 +0100 Message-ID: <473DA439.9070303@inria.fr> Date: Fri, 16 Nov 2007 15:07:53 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7695.1060808@gmail.com> <00b101c82848$bd7580d0$38608270$@nl> <473D9D60.6090009@gmail.com> In-Reply-To: <473D9D60.6090009@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Subject: [Autoconf] Re: Scenarios and Requirements 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, >>>> Then I want descriptions of problems with MLA and MGA (L=local, >>>> G=global). I think problems for the two types are very different, >>>> as MGAs must be globally routable and topologically correct and >>>> generation has to do with Border Routers. >>> Sorry what's MG/LA other than global/local? M? A? >> ;-) That is why it is important to commonly use terminology. MLA: >> MANET Local address (is listed in I-D) MGA: you can find out >> yourself... > > Sorry. I've tried to figure out myself before questioning you. And I > started searching MGA and there wasn't. I should have started searching > MLA (which sounds surprisingly tongue twisting LMA of netlmm btw). > > Thus, I think maybe the PS terminology could define MGA in addition to > MLA - it would have been clearer to one reader. > There is no sense in the term MGA. What does it mean: MANET+Global? I don't understand. Instead in PS-02, we just talk about and define global addresses and prefixes. It makes sense and it is enough to be precise. >>> It's strange to talk about topologically correct addresses when the >>> strong assumption in MANETs is that the topology changes. In a >>> sense any address is correct in a topology changing to follow it. >> No, it is not. That is the problem. MGA are unique in MANET and may >> be used for intra-MANET traffic. But for traffic with CNs, a >> topologically correct addresses must be used. You are right on >> topology changing in MANET, this introduces the problem! >> >> >>> Or maybe one AUTOCONF requirement is to support dynamic L2 topology >>> changes with a overlay stable L3 topologies? Or vice-versa? Or >>> none? >> We are in IETF here and discus Internet and IP related issues. When >> L2 mechanisms hide mobility, that's fine. When not, we (IETF) have a >> problem. > > Can we detail the when not case? > > I know of some MANET testbeds where the L2 hides mobility from L3, and > that's with WiFi laptops and pdas. > > Can we describe a case MANET where L2 doesn't hide the mobility to L3? > >>> I think the problem (and solution) is very different if we consider >>> the L3 topology be stable over a fixed L2 topology vs >>> L3-variable/L2- variable. >> O no!!! Obstacles may move also. I have lots of experience with this, >> my test environment is spread over multiple buildings and we do not >> have to move MN for frequently topology changes;-) Some strange guys >> sit in iron object to go from A to B. Sometimes they are delivering >> something to us and block some links for a long time. > > Can we describe this scenario in the Scenarios section? It sounds > intriguing to me, and if we try to describe it in draft then people may > chime in and share your views. This scenario is already included. We are talking about dynamic topology, coming from mobility but of course also from the versatility of the wireless medium! > >> Tests may be not reproducible but very similar to real world. >> >> >>> For example, if we consider a MANET to be a set of PDAs physically >>> moving around wifi range, but keeping their L2 and L3 topologies >>> stable, then the obvious solution is DHCPv6-PD there's no need of >>> anything else. And if this is a typical deploying scenario then >>> we're all happy. >> If one has also WiMAX or 3G, and there is some delivery using these >> iron objects, traffic flows could swap to the other BR. Nice if we >> could use this technology, isn't it? >> >> >>> If on the other hand we consider a MANET to be a pda+laptop+phone >>> personal set dynamically changing the way it intra-connects and >>> Internet-connects then we can have a whole different set of >>> solutions. But is this a relevant scenario, pertinent from market >>> perspective - question mark. >> Typed in this scenario above. I do not see any reason not supporting >> this. > > If needed, I can describe this scenario in the Scenarios section of the > PS document. Can you tell me how exactly this scenario is not considered by the PS now? We are considering this as a special case of the Connected MANET or the Standalone MANET depending on what is the external connectivity of the case you describe. Please try to check if the scenarios you are envisionning are relevant in the sense that they create a case that is cannot be mapped in the taxonomy described in the PS. Emmanuel > > > ______________________________________________________________________ > 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 > > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 16 09:16: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 1It1zl-00062I-5s; Fri, 16 Nov 2007 09:16:33 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1It1zk-00060G-L3 for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 09:16:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It1zk-0005yN-9x for autoconf@ietf.org; Fri, 16 Nov 2007 09:16:32 -0500 Received: from mail1-relais-roc.national.inria.fr ([192.134.164.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It1zj-0002bU-VD for autoconf@ietf.org; Fri, 16 Nov 2007 09:16:32 -0500 X-IronPort-AV: E=Sophos;i="4.21,426,1188770400"; d="scan'208";a="4573519" Received: from ras75-3-82-226-221-97.fbx.proxad.net (HELO BoolfightMaN-Laptop.local) ([82.226.221.97]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Nov 2007 15:16:30 +0100 Message-ID: <473DA63E.40403@inria.fr> Date: Fri, 16 Nov 2007 15:16:30 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7CAC.9040806@inria.fr> <00c001c82856$bba57360$32f05a20$@nl> <473DA174.6050600@gmail.com> In-Reply-To: <473DA174.6050600@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Autoconf] Re: Border Router term 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 Alexandru Petrescu a écrit : > Teco Boot wrote: > [...] >> Minor issue with term Internet. When a MANET is connected to Internet, >> it is immediately part of the Internet. Then, a router at the bottom >> can be used as Border Router for a lower level MANET. So be careful >> when defining terminology for Internet and Border Router. > > Do we have an RFC definition of the Border Router term? I know of Area > BR (ABR in ospf) and ASBR (Autonomous System Border Router). But is > there a short English "Border Router" term defined in an RFC? (don't > direct me to manufacturer manuals or Wikipedia in German :-) > > If yes then let's reuse. If not then let's define. > I agree. There is no definition as far as I know. So this is why the term ICP (internet configuration provider) came up in -02. Because all we care about in the context of MANET autoconf is where to get configuration from. Nothing else. Emmanuel _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 16 09:26:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It28w-0006BW-2u; Fri, 16 Nov 2007 09:26:02 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1It28u-00069p-VZ for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 09:26:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It28u-000682-LN for autoconf@ietf.org; Fri, 16 Nov 2007 09:26:00 -0500 Received: from hpsmtp-eml14.kpnxchange.com ([213.75.38.114]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It28t-0003UY-TM for autoconf@ietf.org; Fri, 16 Nov 2007 09:26:00 -0500 Received: from hpsmtp-eml09.kpnxchange.com ([213.75.38.109]) by hpsmtp-eml14.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 15:25:58 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml09.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 15:25:58 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7CAC.9040806@inria.fr> <00c001c82856$bba57360$32f05a20$@nl> <473DA174.6050600@gmail.com> In-Reply-To: <473DA174.6050600@gmail.com> Subject: RE: Border Router term (was: [Autoconf] new version draft-ietf-autoconf-statement-02 (pre-release)) Date: Fri, 16 Nov 2007 15:25:45 +0100 Message-ID: <00cd01c8285c$9353bce0$b9fb36a0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgoWHZ6abSvV7BTSAesk5QTZZ4eeQAAzT9A Content-Language: nl X-OriginalArrivalTime: 16 Nov 2007 14:25:58.0574 (UTC) FILETIME=[9B2F74E0:01C8285C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 > Do we have an RFC definition of the Border Router term? I know of Area > BR (ABR in ospf) and ASBR (Autonomous System Border Router). But is > there a short English "Border Router" term defined in an RFC? (don't > direct me to manufacturer manuals or Wikipedia in German :-) > > If yes then let's reuse. If not then let's define. I don't speak German very well, I'm Dutch;-) Border Router (BR) A border router participates in multiple routing domains, and often multiple routing protocols. A BR defines the border between its multiple routing domains. A BR is responsible for presenting a consistent picture of the nodes reachable through itself to each routing domain. A BR determines the routing information to propagate between different routing domains. http://www.ietf.org/internet-drafts/draft-ietf-autoconf-manetarch-07.txt Print this and put it under your pillow;-) Tomorrow (or next week) I expect no questions anymore, where answers can be found in this document. Cheers, Teco _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 16 09:51: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 1It2Xo-0008Er-5D; Fri, 16 Nov 2007 09:51:44 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1It2Xm-0008CT-Qf for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 09:51:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It2Xm-0008BJ-GK for autoconf@ietf.org; Fri, 16 Nov 2007 09:51:42 -0500 Received: from hpsmtp-eml15.kpnxchange.com ([213.75.38.115]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It2Xl-0005dA-Oo for autoconf@ietf.org; Fri, 16 Nov 2007 09:51:42 -0500 Received: from hpsmtp-eml08.kpnxchange.com ([213.75.38.108]) by hpsmtp-eml15.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 15:51:40 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml08.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 15:51:40 +0100 From: "Teco Boot" To: "'Emmanuel Baccelli'" , References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7695.1060808@gmail.com> <00b101c82848$bd7580d0$38608270$@nl> <473D9D60.6090009@gmail.com> <473DA439.9070303@inria.fr> In-Reply-To: <473DA439.9070303@inria.fr> Subject: RE: [Autoconf] Re: Scenarios and Requirements Date: Fri, 16 Nov 2007 15:51:26 +0100 Message-ID: <00d101c82860$2a3cd3a0$7eb67ae0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgoWi0qHtGVKYwSQoymP0+0nnPFZgAAor9Q Content-Language: nl X-OriginalArrivalTime: 16 Nov 2007 14:51:40.0372 (UTC) FILETIME=[322B2940:01C82860] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 > > There is no sense in the term MGA. What does it mean: MANET+Global? I > don't understand. Instead in PS-02, we just talk about and define > global > addresses and prefixes. It makes sense and it is enough to be precise. > Let me try to explain. On fixed networks (or where mobility is hidden already), current mechanisms apply and there is no need for improvement. In a MANET, there are problems. If there were no problems, we can stop Autoconf. MGA are special, because they are generated in a way that is applicable for MANET. Not all Global Unique Address generation mechanisms are applicable for MANET, but ALL MGA address generation mechanism are applicable:-). We just have to work out which are applicable. A Border Router (or BR related function, as suggested) could very well make differences in Global Addresses and MGA, for example MGA could require roaming, e.g. using MIP functionality. For Global Addresses not being MGA, there is no need for this. Think of Home Address (HoA). This is also a special Global Address. Global Address is not HoA. Same for CoA. See RFC3753 for details, please read this before reacting. I think it is needed for understanding Autoconf problems to use clear definitions. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 16 10:07: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 1It2mi-00064t-1M; Fri, 16 Nov 2007 10:07:08 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1It2mg-00060K-NM for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 10:07:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It2mg-0005zk-DU for autoconf@ietf.org; Fri, 16 Nov 2007 10:07:06 -0500 Received: from hpsmtp-eml17.kpnxchange.com ([213.75.38.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It2md-0001MQ-0G for autoconf@ietf.org; Fri, 16 Nov 2007 10:07:06 -0500 Received: from hpsmtp-eml05.kpnxchange.com ([213.75.38.105]) by hpsmtp-eml17.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 16:07:01 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml05.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Nov 2007 16:07:01 +0100 From: "Teco Boot" To: "'Simone Ruffino'" , References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D81F5.1050502@inria.fr> <473DA3CB.8050404@telecomitalia.it> In-Reply-To: <473DA3CB.8050404@telecomitalia.it> Subject: RE: [Autoconf] Review of draft-ietf-autoconf-statement-01 Date: Fri, 16 Nov 2007 16:06:48 +0100 Message-ID: <00d201c82862$4f40c510$edc24f30$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgoWhP/t9OAahK3SBmE9aOL2Xwp/wABp6Lg Content-Language: nl X-OriginalArrivalTime: 16 Nov 2007 15:07:01.0342 (UTC) FILETIME=[571C07E0:01C82862] X-Spam-Score: -1.0 (-) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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 > I might add that PS clearly specifies (many times) that the goal of an > autoconfiguration mechanism (not of a prefix delegation mechanism) IS > address assigment AND prefix delegation. Can you refer to Autoconf charter? Teco _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 16 10:12: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 1It2rz-0008T9-Pc; Fri, 16 Nov 2007 10:12:35 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1It2rw-0008OW-L3 for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 10:12:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It2rw-0008O5-Ad for autoconf@ietf.org; Fri, 16 Nov 2007 10:12:32 -0500 Received: from mail3-relais-sop.national.inria.fr ([192.134.164.104]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It2rv-0007if-V1 for autoconf@ietf.org; Fri, 16 Nov 2007 10:12:32 -0500 X-IronPort-AV: E=Sophos;i="4.21,426,1188770400"; d="scan'208";a="5898170" Received: from ras75-3-82-226-221-97.fbx.proxad.net (HELO BoolfightMaN-Laptop.local) ([82.226.221.97]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Nov 2007 16:12:30 +0100 Message-ID: <473DB35E.4030406@inria.fr> Date: Fri, 16 Nov 2007 16:12:30 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org Subject: Re: [Autoconf] Re: Scenarios and Requirements References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7695.1060808@gmail.com> <00b101c82848$bd7580d0$38608270$@nl> <473D9D60.6090009@gmail.com> <473DA439.9070303@inria.fr> <00d101c82860$2a3cd3a0$7eb67ae0$@nl> In-Reply-To: <00d101c82860$2a3cd3a0$7eb67ae0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Boot a écrit : > > MGA are special, because they are generated in a way that is applicable for > MANET. Not all Global Unique Address generation mechanisms are applicable > for MANET, but ALL MGA address generation mechanism are applicable:-). We > just have to work out which are applicable. > > A Border Router (or BR related function, as suggested) could very well make > differences in Global Addresses and MGA, for example MGA could require > roaming, e.g. using MIP functionality. For Global Addresses not being MGA, > there is no need for this. > You are right into the solution space. For a specific solution, why not? But as far as the problem statement is concerned, this orientation is not appropriate. Emmanuel _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 16 10:14: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 1It2th-0003B8-Uj; Fri, 16 Nov 2007 10:14:21 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1It2tg-00039p-PA for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 10:14:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It2tg-00039O-FH for autoconf@ietf.org; Fri, 16 Nov 2007 10:14:20 -0500 Received: from maile.telecomitalia.it ([156.54.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It2tc-0001yr-Lz for autoconf@ietf.org; Fri, 16 Nov 2007 10:14:20 -0500 thread-index: AcgoY1mgC0BgwrqiS8eLWANlFLtbQA== Received: from ptpxch008ba020.idc.cww.telecomitalia.it ([156.54.240.51]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 16:14:15 +0100 Received: from ptpxch005ba020.idc.cww.telecomitalia.it ([156.54.240.44]) by ptpxch008ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 16:14:14 +0100 Received: from [10.229.4.26] ([10.229.4.26]) by ptpxch005ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 16:14:13 +0100 Message-ID: <473DB35B.3020800@telecomitalia.it> Date: Fri, 16 Nov 2007 16:12:27 +0100 Content-Class: urn:content-classes:message From: "Simone Ruffino" Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2929 User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Teco Boot" Subject: Re: [Autoconf] Review of draft-ietf-autoconf-statement-01 References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D81F5.1050502@inria.fr> <473DA3CB.8050404@telecomitalia.it> <00d201c82862$4f40c510$edc24f30$@nl> In-Reply-To: <00d201c82862$4f40c510$edc24f30$@nl> Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 16 Nov 2007 15:14:13.0767 (UTC) FILETIME=[58DAD970:01C82863] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 Teco, ok, I did not get your point initially. Yes, PS talks about prefix=20 delegation and charter not. I think this is because charter does not=20 reflect yet improvements (and terminology) introduced with the work on=20 MANET architecture. However, as per address assignment, I see no misalignment. Simone Teco Boot wrote: >> I might add that PS clearly specifies (many times) that the goal of = an >> autoconfiguration mechanism (not of a prefix delegation mechanism) IS >> address assigment AND prefix delegation. >> =20 > > Can you refer to Autoconf charter? > > Teco > > > =20 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please contact us by replying to = webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- =20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 16 10:17: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 1It2wH-0006FI-1t; Fri, 16 Nov 2007 10:17:01 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1It2wF-0006C4-Lk for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 10:16:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It2wF-0006BF-Bf for autoconf@ietf.org; Fri, 16 Nov 2007 10:16:59 -0500 Received: from maile.telecomitalia.it ([156.54.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It2wC-0002FN-NM for autoconf@ietf.org; Fri, 16 Nov 2007 10:16:59 -0500 thread-index: AcgoY7dfzvrwwxTBRFybEaN0qDmPhQ== Received: from ptpxch008ba020.idc.cww.telecomitalia.it ([156.54.240.51]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 16:16:51 +0100 Received: from ptpxch005ba020.idc.cww.telecomitalia.it ([156.54.240.44]) by ptpxch008ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 16:15:57 +0100 Received: from [10.229.4.26] ([10.229.4.26]) by ptpxch005ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 16:15:56 +0100 Message-ID: <473DB3C2.6090405@telecomitalia.it> Date: Fri, 16 Nov 2007 16:14:10 +0100 Content-Class: urn:content-classes:message From: "Simone Ruffino" Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2929 User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Emmanuel Baccelli" Subject: Re: [Autoconf] Re: Scenarios and Requirements References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7695.1060808@gmail.com> <00b101c82848$bd7580d0$38608270$@nl> <473D9D60.6090009@gmail.com> <473DA439.9070303@inria.fr> <00d101c82860$2a3cd3a0$7eb67ae0$@nl> <473DB35E.4030406@inria.fr> In-Reply-To: <473DB35E.4030406@inria.fr> Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 16 Nov 2007 15:15:56.0733 (UTC) FILETIME=[963A36D0:01C82863] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 Agree with Emmanuel. Simone Emmanuel Baccelli wrote: > > > Teco Boot a =E9crit : >> >> MGA are special, because they are generated in a way that is=20 >> applicable for >> MANET. Not all Global Unique Address generation mechanisms are=20 >> applicable >> for MANET, but ALL MGA address generation mechanism are=20 >> applicable:-). We >> just have to work out which are applicable. >> >> A Border Router (or BR related function, as suggested) could very=20 >> well make >> differences in Global Addresses and MGA, for example MGA could = require >> roaming, e.g. using MIP functionality. For Global Addresses not being = >> MGA, >> there is no need for this. > > You are right into the solution space. For a specific solution, why=20 > not? But as far as the problem statement is concerned, this=20 > orientation is not appropriate. > > Emmanuel > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please contact us by replying to = webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- =20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 16 10: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 1It320-0001Ok-7n; Fri, 16 Nov 2007 10:22:56 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1It31z-0001Nd-OV for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 10:22:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It31z-0001MF-Dd for autoconf@ietf.org; Fri, 16 Nov 2007 10:22:55 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1It31w-0002wv-7B for autoconf@ietf.org; Fri, 16 Nov 2007 10:22:55 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-153.messagelabs.com!1195226570!4071944!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 4693 invoked from network); 16 Nov 2007 15:22:50 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-12.tower-153.messagelabs.com with SMTP; 16 Nov 2007 15:22:50 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id lAGFMo9e017655; Fri, 16 Nov 2007 08:22:50 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id lAGFMnfJ018049; Fri, 16 Nov 2007 09:22:49 -0600 (CST) 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 lAGFMlHk018008; Fri, 16 Nov 2007 09:22:48 -0600 (CST) Message-ID: <473DB5C6.9090007@gmail.com> Date: Fri, 16 Nov 2007 16:22:46 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Emmanuel Baccelli Subject: Re: DHCP, link-local addresses and AUTOCONF (was: [Autoconf] new version draft-ietf-autoconf-statement-02 (pre-release)) References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7CAC.9040806@inria.fr> In-Reply-To: <473D7CAC.9040806@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071115-0, 15/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.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 Emmanuel Baccelli wrote: > Hi all, authors, Thomas, Teco, > > Thanks for the feedback. Here's an updated version of the PS taking > into account recent comments by Thomas and Teco. Aside from fixing > various editorial details that they pointed out, the main upgrades > concern: > > > * the introduction in the terminology section of the term ICP, > standing for Internet Configuration Provider, lifting an ambiguity > about border routers' potential funtionalities in MANETs. > > * the tightening of the definition/use of "prefix" and "address" > related terms. > > * more precision in relating to existing protocols' scope as well as > the one of the protocols-yet-to-be-designed. > > * updated references > > > > I encourage everyone to continue the public reviewing and discussions > on this updated basis, until it is published (the plan is to submit > soon ;) Here are some technical comments about DHCP and (IPv4 and) IPv6 link-local addresses that could satisfy AUTOCONF needs. > Traditional solutions assume that a broadcast directly reaches every > router or host on the subnetwork, whereas this generally is not the > case in MANETs (see [2]). Do you think the link-layers making up MANETs don't have a broadcast/multicast structure? I believe the contrary. All the wireless link-layers I've played with do have a certain defined multicast/broadcast behaviour, and act according to these specs. MANETs made up of Bluetooth, WiFi and WiMAX all have a very defined multicast behaviour. What are the wireless links on which you think broadcast will not reach every host on the subnetwork? Are you sure you have configured properly that link-layer? > For example, in Fig. 1, the MANET router MR3 cannot communicate > directly with a DHCP server [4] that would be available through a > MANET border router, since the server and the MANET router are not > located on the same logical link. While some DHCP extensions (such > as the relay-agent [11]) overcome this issue in a static network, it > is not the case in a dynamic topology, as explained below. Relay is not an extension of DHCP it's builtin since long ago, implementations. > A significant proportion of the routers in the MANET may be mobile > with wireless interface(s), leading to ever changing neighbor sets > for most MANET routers (see [1]). Are they mobile at physical-layer, link-layer or network-layer? Neighbor sets in terms of ND? I would say that a significant proportion of the routers in the MANET are mobile at physical layer, little at MAC layer and not at all at IP layer and all works. > For instance, in Fig. 1, even if MR1 would be able to delegate > prefixes to MR3 with DHCP [4], it cannot be assumed that MR1 and MR3 > will not move and become unable to communicate directly. This is much misunderstanding for me. DHCP can not work either when two servers in a big fixed server farm have had their cables disconnected by some unknown reason. If we have had a commonly agreed model of mobility, at least at level IP, then we could talk about its frequency of change and how DHCP doesn't support it. But I can tell from practice that some DHCP implementations are very reliable to accomodate such changes in wireless link-layer behaviour. DHCP has many specified messages to deal with Client loosing its connectivity, even with the Server shutdown (saves leases in a file). > Network merging is a potential event that was not considered in the > design of traditional solutions, and that may greatly disrupt the > autoconfiguration mechanisms in use (see [2]). I know that DHCPv6 does prefix delegation in order for a houselhold network to "merge" into ISP's network. This happens smoothly. In IPv4 people merged networks many times with NAT and Application-Level Gateways. My PDA+laptop using IPv4 link-local addresses get merged into a hotspot very seamlessly. > Network partitioning is a potential event that was not considered in > the design of traditional solutions, and that may invalidate usual > autoconfiguration mechanisms (see [2]). What _is_ network partitioning other than not having been considered in the design of traditional solutions? How do networks partition themselves? > Examples of related issues include cases such as a standalone MANET, > whereby connection to the infrastructure is not available, possibly > due to network partitioning and loss of connectivity to a MANET > border router. The MANET must thus function without traditional > address allocation server availability. While stateless protocols > such as [5] and [3] could provide IP address configuration (for MANET > interfaces, loopback interfaces), these solutions do not provide any > mechanism for allocating "unique prefix(es)" to routers in order to > enable the configuration of host interfaces. I'm sorry, but have you checked the number of devices that run DHCP Servers even if when they're disconnected from the Internet? Or the auto-generation of IPv4 link-local address? This is obvious things one thinks about... not even mentioned in the draft. > MANET Autoconfiguration Goals > > A MANET router needs to configure IP addresses and/or prefixes on its > non-MANET interfaces. In addition, it needs to configure a link > local address, a /128 and/or an MLA on its MANET interface. Why would it configure a MLA if it had a ll and a global? Why are the global address and the link-local addresses insufficient? 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 Nov 16 10:24:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It33F-0003fo-OX; Fri, 16 Nov 2007 10:24:13 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1It33E-0003ef-Ay for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 10:24:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It33E-0003eV-1N for autoconf@ietf.org; Fri, 16 Nov 2007 10:24:12 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1It33B-00033m-6N for autoconf@ietf.org; Fri, 16 Nov 2007 10:24:12 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-128.messagelabs.com!1195226647!9899759!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 25555 invoked from network); 16 Nov 2007 15:24:07 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-10.tower-128.messagelabs.com with SMTP; 16 Nov 2007 15:24:07 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id lAGFO7Ko017870; Fri, 16 Nov 2007 08:24:07 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id lAGFO68s019059; Fri, 16 Nov 2007 09:24:06 -0600 (CST) 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 lAGFO4ag019034; Fri, 16 Nov 2007 09:24:05 -0600 (CST) Message-ID: <473DB613.9040709@gmail.com> Date: Fri, 16 Nov 2007 16:24:03 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Emmanuel Baccelli Subject: Re: [Autoconf] Re: Scenarios and Requirements References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7695.1060808@gmail.com> <00b101c82848$bd7580d0$38608270$@nl> <473D9D60.6090009@gmail.com> <473DA439.9070303@inria.fr> In-Reply-To: <473DA439.9070303@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071115-0, 15/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f 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, > > >>>>> Then I want descriptions of problems with MLA and MGA >>>>> (L=local, G=global). I think problems for the two types are >>>>> very different, as MGAs must be globally routable and >>>>> topologically correct and generation has to do with Border >>>>> Routers. >>>> Sorry what's MG/LA other than global/local? M? A? >>> ;-) That is why it is important to commonly use terminology. MLA: >>> MANET Local address (is listed in I-D) MGA: you can find out >>> yourself... >> >> Sorry. I've tried to figure out myself before questioning you. And >> I started searching MGA and there wasn't. I should have started >> searching MLA (which sounds surprisingly tongue twisting LMA of >> netlmm btw). >> >> Thus, I think maybe the PS terminology could define MGA in addition >> to MLA - it would have been clearer to one reader. >> > > There is no sense in the term MGA. What does it mean: MANET+Global? I > don't understand. Instead in PS-02, we just talk about and define > global addresses and prefixes. It makes sense and it is enough to be > precise. But somehow MLA (MANET Local Address) could lead to confusions about link-local addresses. (manet-iana defines a link-local multicast group - is an MLA that group?) >>>> It's strange to talk about topologically correct addresses when >>>> the strong assumption in MANETs is that the topology changes. >>>> In a sense any address is correct in a topology changing to >>>> follow it. >>> No, it is not. That is the problem. MGA are unique in MANET and >>> may be used for intra-MANET traffic. But for traffic with CNs, a >>> topologically correct addresses must be used. You are right on >>> topology changing in MANET, this introduces the problem! >>> >>> >>>> Or maybe one AUTOCONF requirement is to support dynamic L2 >>>> topology changes with a overlay stable L3 topologies? Or >>>> vice-versa? Or none? >>> We are in IETF here and discus Internet and IP related issues. >>> When L2 mechanisms hide mobility, that's fine. When not, we >>> (IETF) have a problem. >> >> Can we detail the when not case? >> >> I know of some MANET testbeds where the L2 hides mobility from L3, >> and that's with WiFi laptops and pdas. >> >> Can we describe a case MANET where L2 doesn't hide the mobility to >> L3? >> >>>> I think the problem (and solution) is very different if we >>>> consider the L3 topology be stable over a fixed L2 topology vs >>>> L3-variable/L2- variable. >>> O no!!! Obstacles may move also. I have lots of experience with >>> this, my test environment is spread over multiple buildings and >>> we do not have to move MN for frequently topology changes;-) Some >>> strange guys sit in iron object to go from A to B. Sometimes >>> they are delivering something to us and block some links for a >>> long time. >> >> Can we describe this scenario in the Scenarios section? It sounds >> intriguing to me, and if we try to describe it in draft then people >> may chime in and share your views. > > This scenario is already included. We are talking about dynamic > topology, coming from mobility but of course also from the > versatility of the wireless medium! Emmanuel - I think you go too fast to describe that Teco scenario as already being part of the autoconf-statement scenarios. I think it's not clear what the Teco scenario with iron objects is, for a start. His scenario seems to be completely static with a tank MN and fixed buildings (by that description I think it can easily be accomodated with DHCP.) Whereas the autoconf-statement scenarios describe movements (joining, partition, merging, mobile users). >>> Tests may be not reproducible but very similar to real world. >>> >>> >>>> For example, if we consider a MANET to be a set of PDAs >>>> physically moving around wifi range, but keeping their L2 and >>>> L3 topologies stable, then the obvious solution is DHCPv6-PD >>>> there's no need of anything else. And if this is a typical >>>> deploying scenario then we're all happy. >>> If one has also WiMAX or 3G, and there is some delivery using >>> these iron objects, traffic flows could swap to the other BR. >>> Nice if we could use this technology, isn't it? >>> >>> >>>> If on the other hand we consider a MANET to be a >>>> pda+laptop+phone personal set dynamically changing the way it >>>> intra-connects and Internet-connects then we can have a whole >>>> different set of solutions. But is this a relevant scenario, >>>> pertinent from market perspective - question mark. >>> Typed in this scenario above. I do not see any reason not >>> supporting this. >> >> If needed, I can describe this scenario in the Scenarios section of >> the PS document. > > Can you tell me how exactly this scenario is not considered by the PS > now? My scenario is user oriented, issued from a user experience, with a potential benefit to be offered to a user in a perceptible way. > We are considering this as a special case of the Connected MANET or > the Standalone MANET depending on what is the external connectivity > of the case you describe. > > Please try to check if the scenarios you are envisionning are > relevant in the sense that they create a case that is cannot be > mapped in the taxonomy described in the PS. I will check but I don't think it does. 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 Nov 16 10:29: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 1It380-00042J-6X; Fri, 16 Nov 2007 10:29:08 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1It37z-00040m-48 for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 10:29:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It37y-0003z9-Ou for autoconf@ietf.org; Fri, 16 Nov 2007 10:29:06 -0500 Received: from hpsmtp-eml14.kpnxchange.com ([213.75.38.114]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It37v-0003T2-Ah for autoconf@ietf.org; Fri, 16 Nov 2007 10:29:06 -0500 Received: from hpsmtp-eml07.kpnxchange.com ([213.75.38.107]) by hpsmtp-eml14.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 16:29:02 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml07.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 16:29:02 +0100 From: "Teco Boot" To: "'Simone Ruffino'" References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D81F5.1050502@inria.fr> <473DA3CB.8050404@telecomitalia.it> <00d201c82862$4f40c510$edc24f30$@nl> <473DB35B.3020800@telecomitalia.it> In-Reply-To: <473DB35B.3020800@telecomitalia.it> Subject: RE: [Autoconf] Review of draft-ietf-autoconf-statement-01 Date: Fri, 16 Nov 2007 16:28:48 +0100 Message-ID: <00da01c82865$629acfe0$27d06fa0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgoY1mgC0BgwrqiS8eLWANlFLtbQAAAGCzw Content-Language: nl X-OriginalArrivalTime: 16 Nov 2007 15:29:02.0319 (UTC) FILETIME=[6A791FF0:01C82865] X-Spam-Score: -1.0 (-) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 > ok, I did not get your point initially. Yes, PS talks about prefix > delegation and charter not. I think this is because charter does not > reflect yet improvements (and terminology) introduced with the work on > MANET architecture. > > However, as per address assignment, I see no misalignment. I think Prefix Delegation is solution space. You could check: draft-bernardos-autoconf-solution-space-00.txt, 4.2. What type of IP delegation: addresses or prefixes? And I wonder after MANET address assignment problems are solved, what problems with current prefix delegation protocols are left. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 16 10:34:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It3D7-0003rp-97; Fri, 16 Nov 2007 10:34:25 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1It3D6-0003re-OA for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 10:34:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It3D6-0003r6-Di for autoconf@ietf.org; Fri, 16 Nov 2007 10:34:24 -0500 Received: from hpsmtp-eml20.kpnxchange.com ([213.75.38.85]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It3D6-0001gM-1S for autoconf@ietf.org; Fri, 16 Nov 2007 10:34:24 -0500 Received: from hpsmtp-eml06.kpnxchange.com ([213.75.38.106]) by hpsmtp-eml20.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 16:34:22 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml06.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 16:34:22 +0100 From: "Teco Boot" To: "'Emmanuel Baccelli'" , References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7695.1060808@gmail.com> <00b101c82848$bd7580d0$38608270$@nl> <473D9D60.6090009@gmail.com> <473DA439.9070303@inria.fr> <00d101c82860$2a3cd3a0$7eb67ae0$@nl> <473DB35E.4030406@inria.fr> In-Reply-To: <473DB35E.4030406@inria.fr> Subject: RE: [Autoconf] Re: Scenarios and Requirements Date: Fri, 16 Nov 2007 16:34:09 +0100 Message-ID: <00db01c82866$21682df0$643889d0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgoYzSi4nSHpsxTSA6wqAoGn1hEkAAAnIiw Content-Language: nl X-OriginalArrivalTime: 16 Nov 2007 15:34:22.0553 (UTC) FILETIME=[2958F490:01C82866] X-Spam-Score: -1.0 (-) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 > > MGA are special, because they are generated in a way that is > applicable for > > MANET. Not all Global Unique Address generation mechanisms are > applicable > > for MANET, but ALL MGA address generation mechanism are applicable:- > ). We > > just have to work out which are applicable. > > > > A Border Router (or BR related function, as suggested) could very > well make > > differences in Global Addresses and MGA, for example MGA could > require > > roaming, e.g. using MIP functionality. For Global Addresses not being > MGA, > > there is no need for this. > > > > You are right into the solution space. For a specific solution, why > not? > But as far as the problem statement is concerned, this orientation is > not appropriate. Second one was example and yes, you are correct, this is solution space. First part of the text is problem space. Once again, we need to verify what current mechanisms are applicable for MGA. We won't spend a minute on research on what is applicable for GA. That is a large, large difference. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 16 10:40: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 1It3JS-0003PK-7F; Fri, 16 Nov 2007 10:40:58 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1It3JQ-0003M5-CS for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 10:40:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It3JQ-0003Lv-2N for autoconf@ietf.org; Fri, 16 Nov 2007 10:40:56 -0500 Received: from mail3-relais-sop.national.inria.fr ([192.134.164.104]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It3JK-0004WY-S4 for autoconf@ietf.org; Fri, 16 Nov 2007 10:40:56 -0500 X-IronPort-AV: E=Sophos;i="4.21,426,1188770400"; d="scan'208";a="5899271" Received: from ras75-3-82-226-221-97.fbx.proxad.net (HELO BoolfightMaN-Laptop.local) ([82.226.221.97]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Nov 2007 16:40:50 +0100 Message-ID: <473DBA01.5060505@inria.fr> Date: Fri, 16 Nov 2007 16:40:49 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org Subject: Re: [Autoconf] Re: Scenarios and Requirements References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7695.1060808@gmail.com> <00b101c82848$bd7580d0$38608270$@nl> <473D9D60.6090009@gmail.com> <473DA439.9070303@inria.fr> <473DB613.9040709@gmail.com> In-Reply-To: <473DB613.9040709@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 Alexandru Petrescu a écrit : > > Emmanuel - I think you go too fast to describe that Teco scenario as > already being part of the autoconf-statement scenarios. > > I think it's not clear what the Teco scenario with iron objects is, for > a start. His scenario seems to be completely static with a tank MN and > fixed buildings (by that description I think it can easily be > accomodated with DHCP.) Whereas the autoconf-statement scenarios > describe movements (joining, partition, merging, mobile users). > Do you want to describe exhaustively every scenario? If this iron object is a car, or if it is a tank? Or if it is a tea pot? I think this is not reasonnable. I think the problem statement has a clear taxonomy of scenarios, and I have yet to understand why the specail cases you mention cannot be mapped into the categories that are already outlined. Emmanuel _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 16 11:08: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 1It3k2-0007DE-7E; Fri, 16 Nov 2007 11:08:26 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1It3k1-0007Bb-Ho for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 11:08:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It3k1-0007Am-7C for autoconf@ietf.org; Fri, 16 Nov 2007 11:08:25 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1It3jx-0007a0-Rs for autoconf@ietf.org; Fri, 16 Nov 2007 11:08:25 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1195229301!18079624!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 4890 invoked from network); 16 Nov 2007 16:08:21 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-119.messagelabs.com with SMTP; 16 Nov 2007 16:08:21 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lAGG8KA3005102; Fri, 16 Nov 2007 09:08:20 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id lAGG8KXq006570; Fri, 16 Nov 2007 10:08:20 -0600 (CST) 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 lAGG8JlE006545; Fri, 16 Nov 2007 10:08:19 -0600 (CST) Message-ID: <473DC072.3030206@gmail.com> Date: Fri, 16 Nov 2007 17:08:18 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Emmanuel Baccelli Subject: Re: [Autoconf] Re: Scenarios and Requirements References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7695.1060808@gmail.com> <00b101c82848$bd7580d0$38608270$@nl> <473D9D60.6090009@gmail.com> <473DA439.9070303@inria.fr> <473DB613.9040709@gmail.com> <473DBA01.5060505@inria.fr> In-Reply-To: <473DBA01.5060505@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 071115-0, 15/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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: > Alexandru Petrescu a écrit : > >> >> Emmanuel - I think you go too fast to describe that Teco scenario >> as already being part of the autoconf-statement scenarios. >> >> I think it's not clear what the Teco scenario with iron objects is, >> for a start. His scenario seems to be completely static with a >> tank MN and fixed buildings (by that description I think it can >> easily be accomodated with DHCP.) Whereas the autoconf-statement >> scenarios describe movements (joining, partition, merging, mobile >> users). >> > > Do you want to describe exhaustively every scenario? If this iron > object is a car, or if it is a tank? Or if it is a tea pot? I think > this is not reasonnable. I think the problem statement has a clear > taxonomy of scenarios, and I have yet to understand why the specail > cases you mention cannot be mapped into the categories that are > already outlined. It appears too exhausting to describe each and every scenario, right :-) They look as easily mapped from one to another. They're all networks in the end :-) 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 Nov 16 11:35: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 1It4AZ-00058C-Fm; Fri, 16 Nov 2007 11:35:51 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1It4AY-00057F-Fi for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 11:35:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It4AY-00056v-5z for autoconf@ietf.org; Fri, 16 Nov 2007 11:35:50 -0500 Received: from mho-02-bos.mailhop.org ([63.208.196.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It4AS-00020v-8b for autoconf@ietf.org; Fri, 16 Nov 2007 11:35:50 -0500 Received: from aste-genev-bois-153-1-81-13.w86-203.abo.wanadoo.fr ([86.203.227.13] helo=[192.168.147.106]) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1It4AR-000JdM-Gb; Fri, 16 Nov 2007 16:35:43 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 86.203.227.13 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+sb0sFeLXcfi1xbszR/xgZ In-Reply-To: <00d101c82860$2a3cd3a0$7eb67ae0$@nl> References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7695.1060808@gmail.com> <00b101c82848$bd7580d0$38608270$@nl> <473D9D60.6090009@gmail.com> <473DA439.9070303@inria.fr> <00d101c82860$2a3cd3a0$7eb67ae0$@nl> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0B5029D1-5651-49C1-9056-1253EAD73DEE@thomasclausen.org> Content-Transfer-Encoding: 7bit From: Thomas Clausen Subject: Re: [Autoconf] Re: Scenarios and Requirements Date: Fri, 16 Nov 2007 17:35:25 +0100 To: Teco Boot X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 On 16Nov , 2007, at 3:51 PM, Teco Boot wrote: >> >> There is no sense in the term MGA. What does it mean: MANET+Global? I >> don't understand. Instead in PS-02, we just talk about and define >> global >> addresses and prefixes. It makes sense and it is enough to be >> precise. >> > Let me try to explain. > On fixed networks (or where mobility is hidden already), current > mechanisms > apply and there is no need for improvement. > In a MANET, there are problems. If there were no problems, we can stop > Autoconf. > Agreed. This is precisely the notion that is intended with the MANET architectural model, and which I find appropriate -- or else we'd be "redesigning the internet" or something. Do not want to do that. > MGA are special, because they are generated in a way that is > applicable for > MANET. Not all Global Unique Address generation mechanisms are > applicable > for MANET, but ALL MGA address generation mechanism are > applicable:-). We > just have to work out which are applicable. > Teco, I think that you are right on the money in the above. I think it captures nicely the distinction of "manet" and "! manet" > A Border Router (or BR related function, as suggested) could very > well make > differences in Global Addresses and MGA, for example MGA could require > roaming, e.g. using MIP functionality. For Global Addresses not > being MGA, > there is no need for this. > > Think of Home Address (HoA). This is also a special Global Address. > Global > Address is not HoA. > Same for CoA. > See RFC3753 for details, please read this before reacting. I am not sure that I agree with the *requirement* to make a difference between MGAs and "other GAs", but I do agree that there is value in considering it and -- as you indicate -- understanding the rationale behind e.g. 3753. -- Thomas Clausen Thomas@thomasclausen.org http://www.thomasclausen.org/ http://hipercom.thomasclausen.org/ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 16 11:45: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 1It4KN-00074E-8j; Fri, 16 Nov 2007 11:45:59 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1It4KK-0006ds-Mj for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 11:45:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It4KK-0006Tt-1V for autoconf@ietf.org; Fri, 16 Nov 2007 11:45:56 -0500 Received: from mho-02-bos.mailhop.org ([63.208.196.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It4KI-00035L-Fm for autoconf@ietf.org; Fri, 16 Nov 2007 11:45:56 -0500 Received: from aste-genev-bois-153-1-81-13.w86-203.abo.wanadoo.fr ([86.203.227.13] helo=[192.168.147.106]) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1It4KH-000MxO-Hs; Fri, 16 Nov 2007 16:45:54 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 86.203.227.13 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/JGX8rNZq9MjF6tDnLpps0 In-Reply-To: <473DB3C2.6090405@telecomitalia.it> References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7695.1060808@gmail.com> <00b101c82848$bd7580d0$38608270$@nl> <473D9D60.6090009@gmail.com> <473DA439.9070303@inria.fr> <00d101c82860$2a3cd3a0$7eb67ae0$@nl> <473DB35E.4030406@inria.fr> <473DB3C2.6090405@telecomitalia.it> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <1B345D27-0BC6-443A-80A5-2178D8CB41A2@thomasclausen.org> Content-Transfer-Encoding: quoted-printable From: Thomas Clausen Subject: Re: [Autoconf] Re: Scenarios and Requirements Date: Fri, 16 Nov 2007 17:45:32 +0100 To: Simone Ruffino X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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 I disagree. See below.... On 16Nov , 2007, at 4:14 PM, Simone Ruffino wrote: > Agree with Emmanuel. > Simone > > Emmanuel Baccelli wrote: >> >> >> Teco Boot a =E9crit : >>> >>> MGA are special, because they are generated in a way that is =20 >>> applicable for >>> MANET. Not all Global Unique Address generation mechanisms are =20 >>> applicable >>> for MANET, but ALL MGA address generation mechanism are =20 >>> applicable:-). We >>> just have to work out which are applicable. >>> At first sight, one could say "yes" to the above without blinking. =20 But, there are a number of points that could be made and which are =20 complementary. In simple terms: o MGAs are generated in a way that is applicable for MANET -- = yes. o an interface with any "normal" Global Unique Address is = "normally" communicating (directly or via a tunnel) to the upper router = from which it got the address and with respect to which this = global =20 address is topologically correct (this is what NEMO, MobileIP goes = out of =20 the way to ensure -- for good reasons, one of which being ingress = filtering) o an interface with a MGA *MAY* actually use that MGA bit = communicating to an upper router from which it did NOT get the address and = with =20 respect to which the address is not topologically correct (remember: = one =20 does not normally assume static hierarchies in MANETs, but things can = move =20 around -- and the PS I-D talked about a "border router" of sorts = handing =20 out addresses). As such, and with respect to MGAs, = ingress-filtering =20 *MAY* be impacted o .....or not, depending (obviously) on how one views the = problem. =20 But, this is then the crux of the PS I-D, is it not? To state the = problem =20 as we see it? This is simplified -- but the point is to encourage that we do not =20 disregard this viewpoint without carefully considering it first. >>> A Border Router (or BR related function, as suggested) could very =20= >>> well make >>> differences in Global Addresses and MGA, for example MGA could =20 >>> require >>> roaming, e.g. using MIP functionality. For Global Addresses not =20 >>> being MGA, >>> there is no need for this. >> >> You are right into the solution space. For a specific solution, =20 >> why not? But as far as the problem statement is concerned, this =20 >> orientation is not appropriate. As I read Teco's comment, the "could very well" bit means "maybe we =20 should think about this at this point" -- which I agree that we should. Thomas --=20 Thomas Clausen Thomas@thomasclausen.org http://www.thomasclausen.org/ http://hipercom.thomasclausen.org/ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 16 11:50:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It4P8-0007v2-5j; Fri, 16 Nov 2007 11:50:54 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1It4P6-0007lo-1r for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 11:50:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It4P5-0007je-N3 for autoconf@ietf.org; Fri, 16 Nov 2007 11:50:51 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1It4P1-0003dY-28 for autoconf@ietf.org; Fri, 16 Nov 2007 11:50:51 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-153.messagelabs.com!1195231845!5617236!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 22594 invoked from network); 16 Nov 2007 16:50:45 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-153.messagelabs.com with SMTP; 16 Nov 2007 16:50:45 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lAGGojgv018532; Fri, 16 Nov 2007 09:50:45 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id lAGGoj7b026704; Fri, 16 Nov 2007 10:50:45 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id lAGGohTK026681; Fri, 16 Nov 2007 10:50:43 -0600 (CST) Message-ID: <473DCA62.4010904@gmail.com> Date: Fri, 16 Nov 2007 17:50:42 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Thomas Clausen Subject: Re: [Autoconf] Re: Scenarios and Requirements References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7695.1060808@gmail.com> <00b101c82848$bd7580d0$38608270$@nl> <473D9D60.6090009@gmail.com> <473DA439.9070303@inria.fr> <00d101c82860$2a3cd3a0$7eb67ae0$@nl> <0B5029D1-5651-49C1-9056-1253EAD73DEE@thomasclausen.org> In-Reply-To: <0B5029D1-5651-49C1-9056-1253EAD73DEE@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071115-0, 15/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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 Thomas, hi, Thomas Clausen wrote: > > On 16Nov , 2007, at 3:51 PM, Teco Boot wrote: > >>> >>> There is no sense in the term MGA. What does it mean: >>> MANET+Global? I don't understand. Instead in PS-02, we just talk >>> about and define global addresses and prefixes. It makes sense >>> and it is enough to be precise. >>> >> Let me try to explain. On fixed networks (or where mobility is >> hidden already), current mechanisms apply and there is no need for >> improvement. In a MANET, there are problems. If there were no >> problems, we can stop Autoconf. >> > > Agreed. This is precisely the notion that is intended with the MANET > architectural model, and which I find appropriate -- or else we'd be > "redesigning the internet" or something. Do not want to do that. If you don't want to redesign the way in which addresses are assigned with respect to how routing works I'm afraid there's no much problem to be solved here, IMHO. I mean - if you want to design a new mechanism to assign an address to a host whose network will subsequently change its routing such us to be able to route towards it - then this may involve some requirements that can be laid down, problem written, etc. But, if you want to design a new mechanism to assign an address to a host whose network is pre-planned an addressing architecture - then I think there's no problem here to be solved. I think we could list the existing mechanisms allowing us to achieve that address assignment: link-local address formation, DAD, stateless, BOOTP, DHCP. I'm not seeing those listed in these documents although they're really widespread use in the networks I see. Why aren't they listed? Sometimes I think they've all been considered but discarded. Other times I think they haven't even been considered. Maybe, IMHO, maybe just, if one has a very specific scenario (very well described and agreed) then one may find some drawbacks to DHCP: for example between a PDA and a laptop who wants to be the Server? Or who's the Router? And then improve DHCP or stateless for _that_ scenario. Or go to DHC WG and MAN WG and improve these there. But I don't see such detail scenario described here. We don't even agree what to reuse :-( Alex >> MGA are special, because they are generated in a way that is >> applicable for MANET. Not all Global Unique Address generation >> mechanisms are applicable for MANET, but ALL MGA address generation >> mechanism are applicable:-). We just have to work out which are >> applicable. >> > > Teco, I think that you are right on the money in the above. I think > it captures nicely the distinction of "manet" and "! manet" > >> A Border Router (or BR related function, as suggested) could very >> well make differences in Global Addresses and MGA, for example MGA >> could require roaming, e.g. using MIP functionality. For Global >> Addresses not being MGA, there is no need for this. >> >> Think of Home Address (HoA). This is also a special Global Address. >> Global Address is not HoA. Same for CoA. See RFC3753 for details, >> please read this before reacting. > > I am not sure that I agree with the *requirement* to make a > difference between MGAs and "other GAs", but I do agree that there is > value in considering it and -- as you indicate -- understanding the > rationale behind e.g. 3753. > ______________________________________________________________________ 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 Nov 16 12:01:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It4Yw-0007IJ-Pg; Fri, 16 Nov 2007 12:01:02 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1It4Yf-0005Y6-RN for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 12:00:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It4Yb-0005S2-GM for autoconf@ietf.org; Fri, 16 Nov 2007 12:00:43 -0500 Received: from mail3-relais-sop.national.inria.fr ([192.134.164.104]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It4YY-0004f6-0j for autoconf@ietf.org; Fri, 16 Nov 2007 12:00:41 -0500 X-IronPort-AV: E=Sophos;i="4.21,426,1188770400"; d="scan'208";a="5902030" Received: from ras75-3-82-226-221-97.fbx.proxad.net (HELO BoolfightMaN-Laptop.local) ([82.226.221.97]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Nov 2007 18:00:37 +0100 Message-ID: <473DCCB4.10004@inria.fr> Date: Fri, 16 Nov 2007 18:00:36 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org Subject: Re: [Autoconf] Review of draft-ietf-autoconf-statement-01 References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D81F5.1050502@inria.fr> <473DA3CB.8050404@telecomitalia.it> <00d201c82862$4f40c510$edc24f30$@nl> <473DB35B.3020800@telecomitalia.it> <00da01c82865$629acfe0$27d06fa0$@nl> In-Reply-To: <00da01c82865$629acfe0$27d06fa0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Boot a écrit : >> ok, I did not get your point initially. Yes, PS talks about prefix >> delegation and charter not. I think this is because charter does not >> reflect yet improvements (and terminology) introduced with the work on >> MANET architecture. >> >> However, as per address assignment, I see no misalignment. > > > I think Prefix Delegation is solution space. > Prefix delegation is not a solution but rather the base of IP addressing in general. So I guess we are inside this framework for now, whether we want it or not. Emmanuel _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 16 12:58: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 1It5Sf-0007Q0-BM; Fri, 16 Nov 2007 12:58:37 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1It5Se-0007N8-Iv for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 12:58:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It5Se-0007Mv-6S for autoconf@ietf.org; Fri, 16 Nov 2007 12:58:36 -0500 Received: from hpsmtp-eml16.kpnxchange.com ([213.75.38.116]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It5Sd-0001nv-QN for autoconf@ietf.org; Fri, 16 Nov 2007 12:58:36 -0500 Received: from hpsmtp-eml03.kpnxchange.com ([213.75.38.103]) by hpsmtp-eml16.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 18:58:34 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml03.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 18:58:34 +0100 From: "Teco Boot" To: References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7695.1060808@gmail.com> <00b101c82848$bd7580d0$38608270$@nl> <473D9D60.6090009@gmail.com> <473DA439.9070303@inria.fr> <00d101c82860$2a3cd3a0$7eb67ae0$@nl> <473DB35E.4030406@inria.fr> <473DB3C2.6090405@telecomitalia.it> <1B345D27-0BC6-443A-80A5-2178D8CB41A2@thomasclausen.org> In-Reply-To: <1B345D27-0BC6-443A-80A5-2178D8CB41A2@thomasclausen.org> Subject: RE: [Autoconf] Re: Scenarios and Requirements Date: Fri, 16 Nov 2007 18:58:20 +0100 Message-ID: <00ea01c8287a$464a3a50$d2deaef0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgocCkJj2tZZQSCSA60WTGLp1/dxAAAco7g Content-Language: nl X-OriginalArrivalTime: 16 Nov 2007 17:58:34.0411 (UTC) FILETIME=[4E41B7B0:01C8287A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 > o an interface with a MGA *MAY* actually use that MGA bit communicating > to an upper router from which it did NOT get the address and with > respect to which the address is not topologically correct (remember: > one does not normally assume static hierarchies in MANETs, but things can > move around -- and the PS I-D talked about a "border router" of sorts > handing out addresses). As such, and with respect to MGAs, ingress- > filtering *MAY* be impacted I assume within a MANET there is no ingress filtering. Correct? Write down somewhere? Filters implemented with RPF checks are less harmful. But there is a problem here, I explained the relation between address generation and routing convergence before. Bytheway, I do not like this hierarchical prefix delegation mechanism, for reasons that the mechanisms breaks when topology changes. No problem for inner MANET communication, but how can we facilitate communication with the outside? I think it can be used only for MLA and not for MGA. We need both, isn't it? Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 16 13:10: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 1It5eA-0002qO-5R; Fri, 16 Nov 2007 13:10:30 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1It5e8-0002kj-K4 for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 13:10:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It5e8-0002k0-9Y for autoconf@ietf.org; Fri, 16 Nov 2007 13:10:28 -0500 Received: from hpsmtp-eml15.kpnxchange.com ([213.75.38.115]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It5e4-00042M-Vg for autoconf@ietf.org; Fri, 16 Nov 2007 13:10:28 -0500 Received: from hpsmtp-eml08.kpnxchange.com ([213.75.38.108]) by hpsmtp-eml15.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 19:10:24 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml08.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 19:10:24 +0100 From: "Teco Boot" To: "'Emmanuel Baccelli'" , References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D81F5.1050502@inria.fr> <473DA3CB.8050404@telecomitalia.it> <00d201c82862$4f40c510$edc24f30$@nl> <473DB35B.3020800@telecomitalia.it> <00da01c82865$629acfe0$27d06fa0$@nl> <473DCCB4.10004@inria.fr> In-Reply-To: <473DCCB4.10004@inria.fr> Subject: RE: [Autoconf] Review of draft-ietf-autoconf-statement-01 Date: Fri, 16 Nov 2007 19:10:10 +0100 Message-ID: <00eb01c8287b$ed0e87a0$c72b96e0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acgoclu0An4gWW27Riaj6gBBQxWOhwACJWUg Content-Language: nl X-OriginalArrivalTime: 16 Nov 2007 18:10:24.0051 (UTC) FILETIME=[F53C3030:01C8287B] X-Spam-Score: -1.0 (-) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 > -----Oorspronkelijk bericht----- > Van: Emmanuel Baccelli [mailto:Emmanuel.Baccelli@inria.fr] > Verzonden: vrijdag 16 november 2007 18:01 > Aan: autoconf@ietf.org > Onderwerp: Re: [Autoconf] Review of draft-ietf-autoconf-statement-01 >=20 >=20 >=20 > Teco Boot a =E9crit : > >> ok, I did not get your point initially. Yes, PS talks about prefix > >> delegation and charter not. I think this is because charter does = not > >> reflect yet improvements (and terminology) introduced with the work > on > >> MANET architecture. > >> > >> However, as per address assignment, I see no misalignment. > > > > > > I think Prefix Delegation is solution space. > > >=20 > Prefix delegation is not a solution but rather the base of IP > addressing > in general. So I guess we are inside this framework for now, whether > we > want it or not. >=20 Ok for /128 prefix delegation. I you want to take care of all IP addressing issues, I wish you good = luck. I want an Autoconf solution available soon. Focusing on the charter and = the real word problems helps. As mentioned before, I am not against PD. It is out there already and I think it can be reused immediately as soon as we have the address = assignment (and routing) solved. Or please specify why not. Routing is out-of-scope for Autoconf. Teco > Emmanuel >=20 >=20 > _______________________________________________ > 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 Nov 16 14:47: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 1It7AO-0007xp-AV; Fri, 16 Nov 2007 14:47:52 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1It7AM-0007wN-WB for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 14:47:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It7AM-0007wA-KF for autoconf@ietf.org; Fri, 16 Nov 2007 14:47:50 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1It7AL-0006Sc-Uq for autoconf@ietf.org; Fri, 16 Nov 2007 14:47:50 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-128.messagelabs.com!1195242508!10076350!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 312 invoked from network); 16 Nov 2007 19:48:28 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-128.messagelabs.com with SMTP; 16 Nov 2007 19:48:28 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lAGJlmcV002285; Fri, 16 Nov 2007 12:47:48 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id lAGJllLE024100; Fri, 16 Nov 2007 13:47:48 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.92]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id lAGJlkcK024085; Fri, 16 Nov 2007 13:47:46 -0600 (CST) Message-ID: <473DF3E0.3080904@gmail.com> Date: Fri, 16 Nov 2007 20:47:44 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Emmanuel Baccelli Subject: Re: [Autoconf] Review of draft-ietf-autoconf-statement-01 References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D81F5.1050502@inria.fr> <473DA3CB.8050404@telecomitalia.it> <00d201c82862$4f40c510$edc24f30$@nl> <473DB35B.3020800@telecomitalia.it> <00da01c82865$629acfe0$27d06fa0$@nl> <473DCCB4.10004@inria.fr> In-Reply-To: <473DCCB4.10004@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 071115-0, 15/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected 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: > > > Teco Boot a écrit : >>> ok, I did not get your point initially. Yes, PS talks about >>> prefix delegation and charter not. I think this is because >>> charter does not reflect yet improvements (and terminology) >>> introduced with the work on MANET architecture. >>> >>> However, as per address assignment, I see no misalignment. >> >> >> I think Prefix Delegation is solution space. >> > > Prefix delegation is not a solution but rather the base of IP > addressing in general. So I guess we are inside this framework for > now, whether we want it or not. I was reading this and thought we finally agree on DHCP-PD should be used :-) But then I doubt you really meant what I thought you meant. I think you mean that prefixes are delegated from one place to another, at an administrative level (and not necessarily DHCP-PD), and thus a basis of IP addressing in general. I think that because the autoconf-manetarch draft uses "A MANET router can be delegated zero or more prefixes" (if it meant what I thought it meant then we'd no longer question the use of DHCPv6-PD). I have this doubt also because autoconf-statement draft says "Therefore, network topology may change rather dynamically compared to traditional networks, which invalidates traditional delegation solutions that were developed for infrastructure-based networks, such as [11] [RFC3046] DHCP Relay-Agent option" (invalidating traditional delegation solutions like DHCPv6-PD?) I think autoconf-manetarch draft should not use the term "delegated zero or more prefixes" if it does not mean DHCPv6-PD. It should better use the term "administratively delegated" (as when RIPE delegates a subnet to some ISP) or some other distinctive text to avoid confusion. And autoconf-statement draft should better cite RFC 3633 "IPv6 Prefix Options for DHCPv6" instead of RFC3046 "DHCP Relay-Agent Options" when talking about delegation, because Relays don't delegate they just forward and eventually insert options. A Relay is indeed pre-configured with a prefix, administratively assigned by some administrator. This is again terminology, sorry, but without it we may misunderstand each other very easily. What do you think? Alex PS: I assume we don't talk here DNS delegation of responsibility of reverse resolution (although MANET networks should be concerned about DNS too and a prefix delegated by DHCPv6 could be accompanied by a DNS delegation for reverse resolution of that prefix as well). ______________________________________________________________________ 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 Nov 16 14:58: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 1It7KI-0004Ml-7o; Fri, 16 Nov 2007 14:58:06 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1It7KH-0004Mf-Lx for autoconf-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 14:58:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It7KH-0004MW-CP for autoconf@ietf.org; Fri, 16 Nov 2007 14:58:05 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1It7KD-0007au-90 for autoconf@ietf.org; Fri, 16 Nov 2007 14:58:05 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-119.messagelabs.com!1195243080!31370782!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 20375 invoked from network); 16 Nov 2007 19:58:00 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-119.messagelabs.com with SMTP; 16 Nov 2007 19:58:00 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lAGJvs1E004471; Fri, 16 Nov 2007 12:58:00 -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 lAGJvs18001764; Fri, 16 Nov 2007 13:57:54 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.92]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id lAGJvqNc001748; Fri, 16 Nov 2007 13:57:53 -0600 (CST) Message-ID: <473DF63F.2030505@gmail.com> Date: Fri, 16 Nov 2007 20:57:51 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Teco Boot Subject: Re: [Autoconf] Re: Scenarios and Requirements References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7695.1060808@gmail.com> <00b101c82848$bd7580d0$38608270$@nl> <473D9D60.6090009@gmail.com> <473DA439.9070303@inria.fr> <00d101c82860$2a3cd3a0$7eb67ae0$@nl> <473DB35E.4030406@inria.fr> <473DB3C2.6090405@telecomitalia.it> <1B345D27-0BC6-443A-80A5-2178D8CB41A2@thomasclausen.org> <00ea01c8287a$464a3a50$d2deaef0$@nl> In-Reply-To: <00ea01c8287a$464a3a50$d2deaef0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071115-0, 15/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.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 Teco Boot wrote: >> o an interface with a MGA *MAY* actually use that MGA bit >> communicating to an upper router from which it did NOT get the >> address and with respect to which the address is not topologically >> correct (remember: one does not normally assume static hierarchies >> in MANETs, but things > can >> move around -- and the PS I-D talked about a "border router" of >> sorts handing out addresses). As such, and with respect to MGAs, >> ingress- filtering *MAY* be impacted > > I assume within a MANET there is no ingress filtering. Correct? Write > down somewhere? In the MANETs I'm concerned about - mostly MANETs where one or two humans are in charge of all devices connecting - yes. > Filters implemented with RPF checks are less harmful. But there is a > problem here, I explained the relation between address generation and > routing convergence before. I think ingress filtering and RPF checks are popular with Access Routers where unknown people connect to. But in the MANETs I'm concerned about (my laptop is my AR) I'm not concerned about ingress filtering and RPF checks because I know in advance who and what's going to connect to it. > Bytheway, I do not like this hierarchical prefix delegation > mechanism, for reasons that the mechanisms breaks when topology > changes. What do you mean by the hierarchical prefix delegation mechanism? Do you mean DHCPv6-PD? Or do you mean administratively assign prefixes? If you mean DHCPv6-PD then it is not hierarchical at all, the prefixes can be anything the admin puts in the Server's configuration file, not necessarily in a hierarchical relationship. Administratively assigning prefixes? I think at the highest level (from space to RIPE, from RIPE to ISP and from ISP to some clients) it may indeed be hierarchical. But within a MANET (very leaf low-level) I sure think routing doesn't impose prefixes to be assigned in a hierarchical manner. I think I agree with you that a strict hierarchical assignment of prefixes to (even a fixed) MANET topology makes little sense because the MANET topology is not necessarily a tree but rather a mesh. Of course, one could have a hierarchical tree of prefixes assigned to a mesh topology, but nothing imposes it to be so. I think in the MANETs I'm concerned about the IPv6 prefixes are not hierachically assigned. That said, I don't see why discarding DHCPv6-PD on hierarchicality grounds. But probably you didn't mean to discard DHCPv6-PD? 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 Sat Nov 17 02:55:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItIWY-0002Jl-RA; Sat, 17 Nov 2007 02:55:30 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1ItIWV-0002Gs-4y for autoconf-confirm+ok@megatron.ietf.org; Sat, 17 Nov 2007 02:55:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItIWP-000281-VP for autoconf@ietf.org; Sat, 17 Nov 2007 02:55:22 -0500 Received: from hpsmtp-eml18.kpnxchange.com ([213.75.38.118]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItIWO-0004yk-Oi for autoconf@ietf.org; Sat, 17 Nov 2007 02:55:21 -0500 Received: from hpsmtp-eml09.kpnxchange.com ([213.75.38.109]) by hpsmtp-eml18.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Nov 2007 08:55:18 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml09.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Nov 2007 08:55:19 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7695.1060808@gmail.com> <00b101c82848$bd7580d0$38608270$@nl> <473D9D60.6090009@gmail.com> <473DA439.9070303@inria.fr> <00d101c82860$2a3cd3a0$7eb67ae0$@nl> <473DB35E.4030406@inria.fr> <473DB3C2.6090405@telecomitalia.it> <1B345D27-0BC6-443A-80A5-2178D8CB41A2@thomasclausen.org> <00ea01c8287a$464a3a50$d2deaef0$@nl> <473DF63F.2030505@gmail.com> In-Reply-To: <473DF63F.2030505@gmail.com> Subject: RE: [Autoconf] Re: Scenarios and Requirements Date: Sat, 17 Nov 2007 08:55:03 +0100 Message-ID: <012401c828ef$292cb630$7b862290$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acgoiv55FjjxqEu2ReSVyhly5Vsz+gAYKnKg Content-Language: nl X-OriginalArrivalTime: 17 Nov 2007 07:55:19.0168 (UTC) FILETIME=[329FB000:01C828EF] X-Spam-Score: -1.0 (-) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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 > -----Oorspronkelijk bericht----- > Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Verzonden: vrijdag 16 november 2007 20:58 > Aan: Teco Boot > CC: autoconf@ietf.org > Onderwerp: Re: [Autoconf] Re: Scenarios and Requirements > > Teco Boot wrote: > >> o an interface with a MGA *MAY* actually use that MGA bit > >> communicating to an upper router from which it did NOT get the > >> address and with respect to which the address is not topologically > >> correct (remember: one does not normally assume static hierarchies > >> in MANETs, but things > > can > >> move around -- and the PS I-D talked about a "border router" of > >> sorts handing out addresses). As such, and with respect to MGAs, > >> ingress- filtering *MAY* be impacted > > > > I assume within a MANET there is no ingress filtering. Correct? Write > > down somewhere? > > In the MANETs I'm concerned about - mostly MANETs where one or two > humans are in charge of all devices connecting - yes. We should look for protocols that can be used also in other environments. Think about a managed service, where 200 people are responsible. If we build the protocols just for your scenario, I stop putting effort on this immediately. But if we can do it jointly, for multiple scenarios, I am in. I hope same for you. Please think about all scenarios. By the way, I think you are saying that Autoconf is extremely focused on classical MANET (don't ask, read the manetarch) and not on commonly used access networks. I think the current PS misses this issue completely. I call this Border Router selection. Criteria are the path between MN and BR and also credentials. Not all border routers accept traffic from everybody. Most ISP live from paid services. I would like that some of the ISP guys provide opinions on what the requirements are. Will ISP ever support MANET? What are the conditions? > > > Filters implemented with RPF checks are less harmful. But there is a > > problem here, I explained the relation between address generation and > > routing convergence before. > > I think ingress filtering and RPF checks are popular with Access > Routers > where unknown people connect to. But in the MANETs I'm concerned about > (my laptop is my AR) I'm not concerned about ingress filtering and RPF > checks because I know in advance who and what's going to connect to it. > > > Bytheway, I do not like this hierarchical prefix delegation > > mechanism, for reasons that the mechanisms breaks when topology > > changes. > > What do you mean by the hierarchical prefix delegation mechanism? Do > you mean DHCPv6-PD? Or do you mean administratively assign prefixes? > Again, read the manetarch. When each MANET Router is DHCP server and client, it can request a prefix, use some of the space for itself and delegate parts to other MANET Routers. Deeper in MANET, prefix lengths are becoming longer. > If you mean DHCPv6-PD then it is not hierarchical at all, the prefixes > can be anything the admin puts in the Server's configuration file, not > necessarily in a hierarchical relationship. > > Administratively assigning prefixes? I think at the highest level > (from > space to RIPE, from RIPE to ISP and from ISP to some clients) it may > indeed be hierarchical. But within a MANET (very leaf low-level) I > sure > think routing doesn't impose prefixes to be assigned in a hierarchical > manner. Why not? No one can block it. Maybe we agree this is not a preferred solution, especially for MGA. For MLA it is fine, although I think there are other solutions. Maybe better ones. > > I think I agree with you that a strict hierarchical assignment of > prefixes to (even a fixed) MANET topology makes little sense because > the > MANET topology is not necessarily a tree but rather a mesh. Of course, > one could have a hierarchical tree of prefixes assigned to a mesh > topology, but nothing imposes it to be so. > > I think in the MANETs I'm concerned about the IPv6 prefixes are not > hierachically assigned. > > That said, I don't see why discarding DHCPv6-PD on hierarchicality > grounds. But probably you didn't mean to discard DHCPv6-PD? None of existing protocols shall be discarded. We shall focus on problems with current protocols. Only when no solution is found, we shall work on a new protocol. I think MLA can be generated with current mechanisms. Random, hash, DHCP; whatever you like. There is a relation with PacketBB, for example DHCP (or another managed mechanism) can provide addresses / prefixes that can be compressed. The random ones are hard to compress:-(( I think MGA has to do with border router selection. I am not aware of a selection protocol for this. I have written one down, but I throw away my idea immediately as soon as I find an existing and appropriate protocol for this. Bytheway, I have "stolen" the idea, see my I-D. And when adopted, it shall be reused as much as possible. E.g. RL2N and MIP. Cheers, Teco. > > 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 Sat Nov 17 14:11:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItT50-0005Qj-6z; Sat, 17 Nov 2007 14:11:46 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1ItT4z-0005QY-3m for autoconf-confirm+ok@megatron.ietf.org; Sat, 17 Nov 2007 14:11:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItT4y-0005QF-OH for autoconf@ietf.org; Sat, 17 Nov 2007 14:11:44 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ItT4x-0003B4-Fq for autoconf@ietf.org; Sat, 17 Nov 2007 14:11:44 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-128.messagelabs.com!1195326702!10058034!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 16307 invoked from network); 17 Nov 2007 19:11:42 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-128.messagelabs.com with SMTP; 17 Nov 2007 19:11:42 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lAHJBViO014156; Sat, 17 Nov 2007 12:11:36 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id lAHJBUlq021279; Sat, 17 Nov 2007 13:11:30 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.146]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id lAHJBSsA021267; Sat, 17 Nov 2007 13:11:29 -0600 (CST) Message-ID: <473F3CE0.50807@gmail.com> Date: Sat, 17 Nov 2007 20:11:28 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Teco Boot Subject: Re: [Autoconf] Re: Scenarios and Requirements References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7695.1060808@gmail.com> <00b101c82848$bd7580d0$38608270$@nl> <473D9D60.6090009@gmail.com> <473DA439.9070303@inria.fr> <00d101c82860$2a3cd3a0$7eb67ae0$@nl> <473DB35E.4030406@inria.fr> <473DB3C2.6090405@telecomitalia.it> <1B345D27-0BC6-443A-80A5-2178D8CB41A2@thomasclausen.org> <00ea01c8287a$464a3a50$d2deaef0$@nl> <473DF63F.2030505@gmail.com> <012401c828ef$292cb630$7b862290$@nl> In-Reply-To: <012401c828ef$292cb630$7b862290$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071117-0, 17/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c 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 Teco Boot wrote: > >> -----Oorspronkelijk bericht----- Van: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Verzonden: vrijdag 16 >> november 2007 20:58 Aan: Teco Boot CC: autoconf@ietf.org Onderwerp: >> Re: [Autoconf] Re: Scenarios and Requirements >> >> Teco Boot wrote: >>>> o an interface with a MGA *MAY* actually use that MGA bit >>>> communicating to an upper router from which it did NOT get the >>>> address and with respect to which the address is not >>>> topologically correct (remember: one does not normally assume >>>> static hierarchies in MANETs, but things >>> can >>>> move around -- and the PS I-D talked about a "border router" of >>>> sorts handing out addresses). As such, and with respect to >>>> MGAs, ingress- filtering *MAY* be impacted >>> I assume within a MANET there is no ingress filtering. Correct? >>> Write down somewhere? >> In the MANETs I'm concerned about - mostly MANETs where one or two >> humans are in charge of all devices connecting - yes. > > We should look for protocols that can be used also in other > environments. Think about a managed service, where 200 people are > responsible. If we build the protocols just for your scenario, I stop > putting effort on this immediately. But if we can do it jointly, for > multiple scenarios, I am in. I hope same for you. Please think about > all scenarios. I agree with you. I'm ready to describe the scenario I'm interested it. It involves mainly personal area networks made of PDAs, laptops, cameras, some sensors may be. This is just high-level description but more detail can easily be told. I would also like to work on reqs for scenarios that you may consider, with 200 or so people responsible for some devices. Except that I don't know how is that described? What does scenario look like? What devices are there? Are they laptops, pdas, sensors - what are they more exactly? > By the way, I think you are saying that Autoconf is extremely focused > on classical MANET (don't ask, read the manetarch) and not on > commonly used access networks. I think the current PS misses this > issue completely. I call this Border Router selection. Criteria are > the path between MN and BR and also credentials. Not all border > routers accept traffic from everybody. Most ISP live from paid > services. You mention very often Border Router - but what is it in the real life? What kind of device, what's its main application role - is it a router in a vehicle? A headmount display device? What is it? What is the application? > I would like that some of the ISP guys provide opinions on what the > requirements are. Will ISP ever support MANET? What are the > conditions? I sense the question, but I think ISP people will be more likely to respond if we asked it differently: How does an ISP support the set-top box and the wifi phone sold to a customer? Do they plan to support IPv6 for this? Do they see it as a 'MANET'? How many subnets do they expect the consumer at home to have for this set-top box + wifi phone? These are things some ISPs consider when they design their address architecture. >>> Filters implemented with RPF checks are less harmful. But there >>> is a problem here, I explained the relation between address >>> generation and routing convergence before. >> I think ingress filtering and RPF checks are popular with Access >> Routers where unknown people connect to. But in the MANETs I'm >> concerned about (my laptop is my AR) I'm not concerned about >> ingress filtering and RPF checks because I know in advance who and >> what's going to connect to it. >> >>> Bytheway, I do not like this hierarchical prefix delegation >>> mechanism, for reasons that the mechanisms breaks when topology >>> changes. >> What do you mean by the hierarchical prefix delegation mechanism? >> Do you mean DHCPv6-PD? Or do you mean administratively assign >> prefixes? >> > Again, read the manetarch. When each MANET Router is DHCP server and > client, it can request a prefix, use some of the space for itself and > delegate parts to other MANET Routers. Deeper in MANET, prefix > lengths are becoming longer. This sounds ok to me. This is a good way to make it work IMHO. >> If you mean DHCPv6-PD then it is not hierarchical at all, the >> prefixes can be anything the admin puts in the Server's >> configuration file, not necessarily in a hierarchical relationship. >> >> >> >> >> >> Administratively assigning prefixes? I think at the highest level >> (from space to RIPE, from RIPE to ISP and from ISP to some >> clients) it may indeed be hierarchical. But within a MANET (very >> leaf low-level) I sure think routing doesn't impose prefixes to be >> assigned in a hierarchical manner. > Why not? No one can block it. Maybe we agree this is not a preferred > solution, especially for MGA. For MLA it is fine, although I think > there are other solutions. Maybe better ones. YEs, right, no one can block to design a hierarchical architecture within the MANET. I wanted to say DHCPv6-PD doesn't force that hierarchical addressing architecture either (thus not a reason to discard it). I think we are in agreement here. >> I think I agree with you that a strict hierarchical assignment of >> prefixes to (even a fixed) MANET topology makes little sense >> because the MANET topology is not necessarily a tree but rather a >> mesh. Of course, one could have a hierarchical tree of prefixes >> assigned to a mesh topology, but nothing imposes it to be so. >> >> I think in the MANETs I'm concerned about the IPv6 prefixes are not >> hierachically assigned. >> >> That said, I don't see why discarding DHCPv6-PD on hierarchicality >> grounds. But probably you didn't mean to discard DHCPv6-PD? > None of existing protocols shall be discarded. We shall focus on > problems with current protocols. Only when no solution is found, we > shall work on a new protocol. > > I think MLA can be generated with current mechanisms. Random, hash, > DHCP; whatever you like. Yes, I agree, and this could be listed as: privacy addresses, DAD, IPv6-over-foo, IPv6-over-Ethernet, HBA, CGA, DHCP, BOOTP. I think this covers all known methods of autoconfiguring and forming addresses. I yet have to see the need to design a new mechanism to autoconfigure addresses. (extending one seems ok). > There is a relation with PacketBB, for example DHCP (or another > managed mechanism) can provide addresses / prefixes that can be > compressed. The random ones are hard to compress:-(( (Don't start me on PacketBB :-) PacketBB means of encoding addresses in messages is issued out of a _non-agreed_ requirement. It is pretty unique in the way it does it, it's smart, it may reduce wireless consumption (it smartly compresses address representation). But I don't think that's needed. And if we had agreed on a requirement to achieve that compression for a reduction in bandwidth consumption there are many other existing mechanisms to achieve it.) > I think MGA has to do with border router selection. I am not aware of > a selection protocol for this. I have written one down, but I throw > away my idea immediately as soon as I find an existing and > appropriate protocol for this. Sorry, I have to read it first. Until then here's what comes to my mind: you need the MR to select a BR to use as its default route? Use RFC4191 "Default Router Preferences and More-Specific Routes". It's a pretty straightforward means for a BR to communicate preferences to the MR in the Router Advertisements. I see it fit, why not? Can we extend it to adapt it to your scenario? Otherwise. If BRs and MRs run all OSPF then a certain MR will always select the best BR. Would those two fit the selection you talk about? Or do they miss something? What? Can we extend them? > Bytheway, I have "stolen" the idea, see my I-D. And when adopted, it > shall be reused as much as possible. E.g. RL2N and MIP. :-) :-) Is RL2N Routing for Low Power and Lossy Networks that BoF http://www.employees.org/~jvasseur/ ? Your I-D is titled fine but misnames BRDP (Border Router Discovery Protocol) as a protocol(?) It's good it looks at ND. I think less things could be extended (e.g. avoid AAA use) but I could remark technically separately on BRDP. (For example I'd call it better "ND extensions to achieve..." instead of BRDP. A new Protocol should involve new messages, not just extension of existing messages.) I won't hijack this thread, let's agree on AUTOCONF scenarios and requirements in detail first. 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 Sun Nov 18 17:04:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItsFZ-0000jK-Jc; Sun, 18 Nov 2007 17:04:21 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1ItsFY-0000jE-PU for autoconf-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 17:04:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItsFY-0000j5-Ah for autoconf@ietf.org; Sun, 18 Nov 2007 17:04:20 -0500 Received: from hpsmtp-eml19.kpnxchange.com ([213.75.38.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItsFT-0001E3-6q for autoconf@ietf.org; Sun, 18 Nov 2007 17:04:20 -0500 Received: from hpsmtp-eml01.kpnxchange.com ([213.75.38.101]) by hpsmtp-eml19.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Nov 2007 23:04:13 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml01.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Nov 2007 23:04:13 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7695.1060808@gmail.com> <00b101c82848$bd7580d0$38608270$@nl> <473D9D60.6090009@gmail.com> <473DA439.9070303@inria.fr> <00d101c82860$2a3cd3a0$7eb67ae0$@nl> <473DB35E.4030406@inria.fr> <473DB3C2.6090405@telecomitalia.it> <1B345D27-0BC6-443A-80A5-2178D8CB41A2@thomasclausen.org> <00ea01c8287a$464a3a50$d2deaef0$@nl> <473DF63F.2030505@gmail.com> <012401c828ef$292cb630$7b862290$@nl> <473F3CE0.50807@gmail.com> In-Reply-To: <473F3CE0.50807@gmail.com> Subject: RE: [Autoconf] Re: Scenarios and Requirements Date: Sun, 18 Nov 2007 23:04:11 +0100 Message-ID: <006a01c82a2e$f325ebb0$d971c310$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgpTbGqqPbKvSOmQua2vvi7kCothAA3BvjQ Content-Language: nl X-OriginalArrivalTime: 18 Nov 2007 22:04:13.0354 (UTC) FILETIME=[F42D70A0:01C82A2E] X-Spam-Score: -1.0 (-) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc 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 > -----Oorspronkelijk bericht----- > Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Verzonden: zaterdag 17 november 2007 20:11 > Aan: Teco Boot > CC: autoconf@ietf.org > Onderwerp: Re: [Autoconf] Re: Scenarios and Requirements > > We should look for protocols that can be used also in other > > environments. Think about a managed service, where 200 people are > > responsible. If we build the protocols just for your scenario, I stop > > putting effort on this immediately. But if we can do it jointly, for > > multiple scenarios, I am in. I hope same for you. Please think about > > all scenarios. > > I agree with you. I'm ready to describe the scenario I'm interested > it. > It involves mainly personal area networks made of PDAs, laptops, > cameras, some sensors may be. This is just high-level description but > more detail can easily be told. I think this is more or less similar to NEMO RO use cases, isn't it? Maybe we should describe were multihop connectivity applies between those devices and the Border Router, as an extension to the NEMO RO use cases. > I would also like to work on reqs for scenarios that you may consider, > with 200 or so people responsible for some devices. Except that I > don't > know how is that described? What does scenario look like? What > devices > are there? Are they laptops, pdas, sensors - what are they more > exactly? Is this important? By the way, "some devices" would be large numbers. Number of Border Routers are also large numbers. Think on regional / national / international access networks with multiple technologies, provided by multiple ISPs. Assume hotspot, WiMAX, 3G and cabling as last ad-hoc hop to Border Router. Users are personal, small business, enterprise, NGO, public safety, military and maybe more. I think it is not important to work out this kind of details, problems are similar. We never described details on laptop, pda, server etcetera when defining IP protocols. > > > By the way, I think you are saying that Autoconf is extremely focused > > on classical MANET (don't ask, read the manetarch) and not on > > commonly used access networks. I think the current PS misses this > > issue completely. I call this Border Router selection. Criteria are > > the path between MN and BR and also credentials. Not all border > > routers accept traffic from everybody. Most ISP live from paid > > services. > > You mention very often Border Router - but what is it in the real life? > What kind of device, what's its main application role - is it a > router > in a vehicle? A headmount display device? What is it? What is the > application? Border Router is described in manetarch, although I want to be more specific on this. Is it a router between two routing domains or does it provide access to Internet? The last one is a subset of the first. > > There is a relation with PacketBB, for example DHCP (or another > > managed mechanism) can provide addresses / prefixes that can be > > compressed. The random ones are hard to compress:-(( > > (Don't start me on PacketBB :-) > > PacketBB means of encoding addresses in messages is issued out of a > _non-agreed_ requirement. It is pretty unique in the way it does it, > it's smart, it may reduce wireless consumption (it smartly compresses > address representation). But I don't think that's needed. And if we > had agreed on a requirement to achieve that compression for a > reduction > in bandwidth consumption there are many other existing mechanisms to > achieve it.) Please check BGP. And reducing overhead in MANET protocol is needed for scalability. Maybe your personal interest is extreme small ad-hoc setups. My interest is the opposite. I think we can work out a common solution;-) > > > I think MGA has to do with border router selection. I am not aware of > > a selection protocol for this. I have written one down, but I throw > > away my idea immediately as soon as I find an existing and > > appropriate protocol for this. > > Sorry, I have to read it first. > > Until then here's what comes to my mind: you need the MR to select a BR > to use as its default route? The scope for Autoconf is addressing and NOT routing. But yes, BR selection and routing to that BR and from that BR back to the node has a strong relationship. > > Use RFC4191 "Default Router Preferences and More-Specific Routes". > It's > a pretty straightforward means for a BR to communicate preferences to > the MR in the Router Advertisements. I see it fit, why not? Can we > extend it to adapt it to your scenario? No, two bits may be enough for selecting an access router on a link. For MANET we need better metrics. > > Otherwise. If BRs and MRs run all OSPF then a certain MR will always > select the best BR. > > Would those two fit the selection you talk about? Or do they miss > something? What? Can we extend them? > Autoconf shall be independent of the MANET protocol (charter). We have about 5 already, more dialects to come. The problem here is when we have a Autoconf protocol, a BR could be selected but this BR could not be reachable, because it speaks another dialect. Maybe we should think of decoupling inner-MANET-routing and BR-routing. Again, this is not Autoconf. We could work on a requirements For Br Routing document and sent this to the Routing Area. Or discuss this with MANET WG (and RL2N, after BOF). > > Bytheway, I have "stolen" the idea, see my I-D. And when adopted, it > > shall be reused as much as possible. E.g. RL2N and MIP. > > :-) :-) > > Is RL2N Routing for Low Power and Lossy Networks that BoF > http://www.employees.org/~jvasseur/ ? Yepp. > > Your I-D is titled fine but misnames BRDP (Border Router Discovery > Protocol) as a protocol(?) It's good it looks at ND. NDP is a protocol, running on ICMP which is also a protocol, running on IP, which is also a protocol, running on a lower layer protocol. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 19 06:10: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 1Iu4Vw-0001iI-RV; Mon, 19 Nov 2007 06:10:04 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Iu4Vv-0001iA-C8 for autoconf-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 06:10:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu4Vu-0001ht-Sh; Mon, 19 Nov 2007 06:10:02 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu4Vu-0008OB-HH; Mon, 19 Nov 2007 06:10:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 67C982AC50; Mon, 19 Nov 2007 11:10:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu4Vu-00070j-6M; Mon, 19 Nov 2007 06:10:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Nov 2007 06:10:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: autoconf@ietf.org Subject: [Autoconf] I-D Action:draft-ietf-autoconf-statement-02.txt 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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Ad-Hoc Network Autoconfiguration Working Group of the IETF. Title : Address Autoconfiguration for MANET: Terminology and Problem Statement Author(s) : E. Baccelli, et al. Filename : draft-ietf-autoconf-statement-02.txt Pages : 19 Date : 2007-11-19 Traditional dynamic IPv6 address assignment solutions are not adapted to mobile ad hoc networks. This document elaborates on this problem, states the need for new solutions, and requirements to these solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-autoconf-statement-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-autoconf-statement-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-autoconf-statement-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-19060156.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-autoconf-statement-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-autoconf-statement-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19060156.I-D\@ietf.org> --OtherAccess-- --NextPart 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 --NextPart-- From autoconf-bounces@ietf.org Mon Nov 19 06:11:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu4XF-0002tH-Kl; Mon, 19 Nov 2007 06:11:25 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Iu4XD-0002p6-QT for autoconf-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 06:11:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu4XC-0002ni-CO for autoconf@ietf.org; Mon, 19 Nov 2007 06:11:23 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Iu4X8-0001vD-KP for autoconf@ietf.org; Mon, 19 Nov 2007 06:11:22 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1195470675!22593172!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 15442 invoked from network); 19 Nov 2007 11:11:15 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-8.tower-119.messagelabs.com with SMTP; 19 Nov 2007 11:11:15 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id lAJBBASd002482; Mon, 19 Nov 2007 04:11:15 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id lAJBB9ce002071; Mon, 19 Nov 2007 05:11:10 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id lAJBB7AP002049; Mon, 19 Nov 2007 05:11:08 -0600 (CST) Message-ID: <47416F4A.4020002@gmail.com> Date: Mon, 19 Nov 2007 12:11:06 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Teco Boot Subject: Re: [Autoconf] Re: Scenarios and Requirements References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7695.1060808@gmail.com> <00b101c82848$bd7580d0$38608270$@nl> <473D9D60.6090009@gmail.com> <473DA439.9070303@inria.fr> <00d101c82860$2a3cd3a0$7eb67ae0$@nl> <473DB35E.4030406@inria.fr> <473DB3C2.6090405@telecomitalia.it> <1B345D27-0BC6-443A-80A5-2178D8CB41A2@thomasclausen.org> <00ea01c8287a$464a3a50$d2deaef0$@nl> <473DF63F.2030505@gmail.com> <012401c828ef$292cb630$7b862290$@nl> <473F3CE0.50807@gmail.com> <006a01c82a2e$f325ebb0$d971c310$@nl> In-Reply-To: <006a01c82a2e$f325ebb0$d971c310$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071118-1, 18/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb 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 Teco, let's keep this thread on AUTOCONF Scenarios and Requirements. I snipped some parts for this reson. Teco Boot wrote: >> -----Oorspronkelijk bericht----- Van: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Verzonden: zaterdag 17 >> november 2007 20:11 Aan: Teco Boot CC: autoconf@ietf.org Onderwerp: >> Re: [Autoconf] Re: Scenarios and Requirements >>> We should look for protocols that can be used also in other >>> environments. Think about a managed service, where 200 people are >>> responsible. If we build the protocols just for your scenario, I >>> stop putting effort on this immediately. But if we can do it >>> jointly, for multiple scenarios, I am in. I hope same for you. >>> Please think about all scenarios. >> >> I agree with you. I'm ready to describe the scenario I'm >> interested it. It involves mainly personal area networks made of >> PDAs, laptops, cameras, some sensors may be. This is just >> high-level description but more detail can easily be told. > > I think this is more or less similar to NEMO RO use cases, isn't it? I think the scenario with PANs under a single administrator can have a solution as a MIP6 extensions to RO for NEMO, or a routing protocol solution - or probably no new protocol at all. But - yes - it is obvious that we talk very similar scenarios in the NEMO RO reqs and in MANET reqs and in AUTOCONF reqs. > Maybe we should describe were multihop connectivity applies between > those devices and the Border Router, as an extension to the NEMO RO > use cases. What's multihop connectivity? >> I would also like to work on reqs for scenarios that you may >> consider, with 200 or so people responsible for some devices. >> Except that I don't know how is that described? What does scenario >> look like? What devices are there? Are they laptops, pdas, >> sensors - what are they more exactly? > > Is this important? Here, in this case, I think it is important to describe the scenarios in more detail otherwise I'm afraid it's going to lead again to new mechanisms designed for less purpose. I personally I'm used to see detail scenario, then see people say how easily this can be accommodated with existing stuff then other people say where it failed after experimentation - and so on. > By the way, "some devices" would be large numbers. Number of Border > Routers are also large numbers. Think on regional / national / > international access networks with multiple technologies, provided by > multiple ISPs. Assume hotspot, WiMAX, 3G and cabling as last ad-hoc > hop to Border Router. Users are personal, small business, > enterprise, NGO, public safety, military and maybe more. I think it > is not important to work out this kind of details, problems are > similar. Ok, I kind of see, but this still looks too generic. It pretty much covers about everything leaf network one can imagine. I think you may be right to deduce that the problems are similar, but to me it is too early to say so. There are fine differences between cases. Let me tell one difference. Consider a rescue scene with vehicles in a fixed situation. Each has a mobile router within. Consider one vehicle to the the "Captain" and using a high-power WiFi Access Point to give DHCP addresses to all other vehicles. This is an easy IP configuration scenario which can easily be accommodated by existing protocols. But then there may be a requirement against the existence of that central entity and all vehicles should communicate with WiFi without Access Point. Now this is much more difficult to accommodate with existing IP protocols, because there's very little structure. New mechanisms may be needed for this. Things may be easier if all vehicles are fixed instead of moving. But, a big but, who can tell these kinds of requirements? Can we tell at least the little requirement that deals with being mobile or not mobile? Or the little requirement that tells which applications (or kinds of) are run? It may be that we go to customers and they'll say of course there's a central command and control vehicle, with a central Access Point and they absolutely need itt. The reverse may be true too: the scene should work until command unit arrival too, thus no AP for a while. Or it may be that TCP/IP connectivity is less urgent and can wait until that vehicle arrives. This kinds of requirements are important. You can formulate them however you want, in terms of teapots and spoons (such as to avoid "tanks") if you want. But make it intelligible from a protocol behaviour perspective. > We never described details on laptop, pda, server etcetera when > defining IP protocols. These people had _very_ strong requirements: they wanted to make remote computers talk to each other. That's done. But here's no requirement in my understanding (sorry if I don't see something obvious). [...] > Autoconf shall be independent of the MANET protocol (charter). We > have about 5 already, more dialects to come. We have 5 whats? 5 MANET protocols? Or 5 methods for AUTOCONF WG? Do we have any AUTOCONF solution proposal? > The problem here is when we have a Autoconf protocol, a BR could be > selected but this BR could not be reachable, because it speaks > another dialect. Let's see what an AUTOCONF protocol looks like first, no? > Maybe we should think of decoupling inner-MANET-routing and > BR-routing. Again, this is not Autoconf. We could work on a > requirements For Br Routing document and sent this to the Routing > Area. Or discuss this with MANET WG (and RL2N, after BOF). > >>> Bytheway, I have "stolen" the idea, see my I-D. And when adopted, >>> it shall be reused as much as possible. E.g. RL2N and MIP. >> >> :-) :-) >> >> Is RL2N Routing for Low Power and Lossy Networks that BoF >> http://www.employees.org/~jvasseur/ ? > > Yepp. > >> >> Your I-D is titled fine but misnames BRDP (Border Router Discovery >> Protocol) as a protocol(?) It's good it looks at ND. > NDP is a protocol, running on ICMP which is also a protocol, running > on IP, which is also a protocol, running on a lower layer protocol. We'll see separately if you want to fork a new thread :-) 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 Nov 19 07:19: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 1Iu5aj-0007Yg-0Y; Mon, 19 Nov 2007 07:19:05 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Iu5ah-0007Q2-E0 for autoconf-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 07:19:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu5ag-0007Nb-Dl for autoconf@ietf.org; Mon, 19 Nov 2007 07:19:02 -0500 Received: from hpsmtp-eml20.kpnxchange.com ([213.75.38.85]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu5ae-00034R-T7 for autoconf@ietf.org; Mon, 19 Nov 2007 07:19:01 -0500 Received: from hpsmtp-eml05.kpnxchange.com ([213.75.38.105]) by hpsmtp-eml20.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 13:18:59 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml05.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Nov 2007 13:18:59 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7695.1060808@gmail.com> <00b101c82848$bd7580d0$38608270$@nl> <473D9D60.6090009@gmail.com> <473DA439.9070303@inria.fr> <00d101c82860$2a3cd3a0$7eb67ae0$@nl> <473DB35E.4030406@inria.fr> <473DB3C2.6090405@telecomitalia.it> <1B345D27-0BC6-443A-80A5-2178D8CB41A2@thomasclausen.org> <00ea01c8287a$464a3a50$d2deaef0$@nl> <473DF63F.2030505@gmail.com> <012401c828ef$292cb630$7b862290$@nl> <473F3CE0.50807@gmail.com> <006a01c82a2e$f325ebb0$d971c310$@nl> <47416F4A.4020002@gmail.com> In-Reply-To: <47416F4A.4020002@gmail.com> Subject: RE: [Autoconf] Re: Scenarios and Requirements Date: Mon, 19 Nov 2007 13:18:56 +0100 Message-ID: <003901c82aa6$5b92e370$12b8aa50$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgqnOepS+mhAgmRRQayw8+GyKVArQAAjwAQ Content-Language: nl X-OriginalArrivalTime: 19 Nov 2007 12:18:59.0664 (UTC) FILETIME=[5D334D00:01C82AA6] X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b 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 Alex, I put some comments inline. I think the most important issue you brought up is having Autoconf also looking at PAN, where devices behind Personal MR cannot autoconfigure MGA. This use case is missing in autoconf-manetarch. More text on this inline. Teco. > -----Oorspronkelijk bericht----- > Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Verzonden: maandag 19 november 2007 12:11 > Aan: Teco Boot > CC: Alexandru Petrescu; autoconf@ietf.org > Onderwerp: Re: [Autoconf] Re: Scenarios and Requirements > > Hi Teco, let's keep this thread on AUTOCONF Scenarios and Requirements. > I snipped some parts for this reson. > > Teco Boot wrote: > >> -----Oorspronkelijk bericht----- Van: Alexandru Petrescu > >> [mailto:alexandru.petrescu@gmail.com] Verzonden: zaterdag 17 > >> november 2007 20:11 Aan: Teco Boot CC: autoconf@ietf.org Onderwerp: > >> Re: [Autoconf] Re: Scenarios and Requirements > >>> We should look for protocols that can be used also in other > >>> environments. Think about a managed service, where 200 people are > >>> responsible. If we build the protocols just for your scenario, I > >>> stop putting effort on this immediately. But if we can do it > >>> jointly, for multiple scenarios, I am in. I hope same for you. > >>> Please think about all scenarios. > >> > >> I agree with you. I'm ready to describe the scenario I'm > >> interested it. It involves mainly personal area networks made of > >> PDAs, laptops, cameras, some sensors may be. This is just > >> high-level description but more detail can easily be told. > > > > I think this is more or less similar to NEMO RO use cases, isn't it? > > I think the scenario with PANs under a single administrator can have a > solution as a MIP6 extensions to RO for NEMO, or a routing protocol > solution - or probably no new protocol at all. > > But - yes - it is obvious that we talk very similar scenarios in the > NEMO RO reqs and in MANET reqs and in AUTOCONF reqs. > > > Maybe we should describe were multihop connectivity applies between > > those devices and the Border Router, as an extension to the NEMO RO > > use cases. > > What's multihop connectivity? Where there is no direct connectivity between a node and the Border Router, e.g. gadget to smartphone to 3GPP. I am not sure we need a full blown MANET protocol for this. But there is a need for routing. Or nested NEMO. Or both. I think the Autoconf shall develop a mechanism for providing an address to the gadget. But gadget does not receive 3GPP RA and thus it cannot configure an address for it. > > >> I would also like to work on reqs for scenarios that you may > >> consider, with 200 or so people responsible for some devices. > >> Except that I don't know how is that described? What does scenario > >> look like? What devices are there? Are they laptops, pdas, > >> sensors - what are they more exactly? > > > > Is this important? > > Here, in this case, I think it is important to describe the scenarios > in > more detail otherwise I'm afraid it's going to lead again to new > mechanisms designed for less purpose. > > I personally I'm used to see detail scenario, then see people say how > easily this can be accommodated with existing stuff then other people > say where it failed after experimentation - and so on. I agree in focusing on real world problems. But I doubt if we need to write down this in RFCs. > > By the way, "some devices" would be large numbers. Number of Border > > Routers are also large numbers. Think on regional / national / > > international access networks with multiple technologies, provided by > > multiple ISPs. Assume hotspot, WiMAX, 3G and cabling as last ad-hoc > > hop to Border Router. Users are personal, small business, > > enterprise, NGO, public safety, military and maybe more. I think it > > is not important to work out this kind of details, problems are > > similar. > > Ok, I kind of see, but this still looks too generic. It pretty much > covers about everything leaf network one can imagine. > > I think you may be right to deduce that the problems are similar, but > to > me it is too early to say so. > > There are fine differences between cases. Let me tell one difference. > Consider a rescue scene with vehicles in a fixed situation. Each has a > mobile router within. Consider one vehicle to the the "Captain" and > using a high-power WiFi Access Point to give DHCP addresses to all > other > vehicles. This is an easy IP configuration scenario which can easily > be accommodated by existing protocols. Maybe IP config is easy. Providing fully meshed connectivity is a hell. There could be mountains, buildings or vehicles preventing line-of-sight. Or the captain takes his vehicle and drives to the mayor. Or other disasters for good quality radio communication. When only the captain has high power AP, there will be uni-directional links - Asymmetric Reachability. Rescue is not fixed and the problems are far more complex. Let's save lives and provide something better to the rescue teams. > But then there may be a > requirement > against the existence of that central entity and all vehicles should > communicate with WiFi without Access Point. Now this is much more > difficult to accommodate with existing IP protocols, because there's > very little structure. New mechanisms may be needed for this. Things > may be easier if all vehicles are fixed instead of moving. It is not new. We have this already. It is called MANET Routing protocol. > But, a big but, who can tell these kinds of requirements? Can we tell > at least the little requirement that deals with being mobile or not > mobile? Or the little requirement that tells which applications (or > kinds of) are run? > > It may be that we go to customers and they'll say of course there's a > central command and control vehicle, with a central Access Point and > they absolutely need itt. The reverse may be true too: the scene > should > work until command unit arrival too, thus no AP for a while. Or it may > be that TCP/IP connectivity is less urgent and can wait until that > vehicle arrives. > > This kinds of requirements are important. You can formulate them > however you want, in terms of teapots and spoons (such as to avoid > "tanks") if you want. But make it intelligible from a protocol > behaviour perspective. I think MANET technology being used is well described in manetarch. I think there is little need in providing a long list of detailed user requirements, this will costs lots of time and it brings not that much. We could think on adding more text in manetarch on non-transitive communication (X<->Y is OK, Y<->Z is OK, X<->Z is not OK), like your use case with 3GPP and Bluetooth/UWB. > > > We never described details on laptop, pda, server etcetera when > > defining IP protocols. > > These people had _very_ strong requirements: they wanted to make remote > computers talk to each other. That's done. > > But here's no requirement in my understanding (sorry if I don't see > something obvious). > > [...] > > > Autoconf shall be independent of the MANET protocol (charter). We > > have about 5 already, more dialects to come. > > We have 5 whats? 5 MANET protocols? Or 5 methods for AUTOCONF WG? 5 MANET protocols. > > Do we have any AUTOCONF solution proposal? > > > The problem here is when we have a Autoconf protocol, a BR could be > > selected but this BR could not be reachable, because it speaks > > another dialect. > > Let's see what an AUTOCONF protocol looks like first, no? When the Autoconf is independent of the routing protocol and does not provide a path between nodes and the BR, the BR could be not reachable from the nodes. Or am I missing something? > > > Maybe we should think of decoupling inner-MANET-routing and > > BR-routing. Again, this is not Autoconf. We could work on a > > requirements For Br Routing document and sent this to the Routing > > Area. Or discuss this with MANET WG (and RL2N, after BOF). > > > >>> Bytheway, I have "stolen" the idea, see my I-D. And when adopted, > >>> it shall be reused as much as possible. E.g. RL2N and MIP. > >> > >> :-) :-) > >> > >> Is RL2N Routing for Low Power and Lossy Networks that BoF > >> http://www.employees.org/~jvasseur/ ? > > > > Yepp. > > > >> > >> Your I-D is titled fine but misnames BRDP (Border Router Discovery > >> Protocol) as a protocol(?) It's good it looks at ND. > > NDP is a protocol, running on ICMP which is also a protocol, running > > on IP, which is also a protocol, running on a lower layer protocol. > > We'll see separately if you want to fork a new thread :-) > > 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 Nov 19 08:01:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu6FR-0000zU-Ha; Mon, 19 Nov 2007 08:01:09 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Iu6FP-0000oi-Tw for autoconf-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 08:01:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu6FP-0000nW-0Y for autoconf@ietf.org; Mon, 19 Nov 2007 08:01:07 -0500 Received: from mail4-relais-sop.national.inria.fr ([192.134.164.105]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu6FN-0005a2-L0 for autoconf@ietf.org; Mon, 19 Nov 2007 08:01:06 -0500 X-IronPort-AV: E=Sophos;i="4.21,436,1188770400"; d="scan'208";a="19456797" Received: from baa2333.baa.pppool.de (HELO [192.168.178.25]) ([77.128.35.51]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Nov 2007 14:01:03 +0100 Message-ID: <4741890E.1070908@inria.fr> Date: Mon, 19 Nov 2007 14:01:02 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org Subject: Re: [Autoconf] Re: Scenarios and Requirements References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7695.1060808@gmail.com> <00b101c82848$bd7580d0$38608270$@nl> <473D9D60.6090009@gmail.com> <473DA439.9070303@inria.fr> <00d101c82860$2a3cd3a0$7eb67ae0$@nl> <473DB35E.4030406@inria.fr> <473DB3C2.6090405@telecomitalia.it> <1B345D27-0BC6-443A-80A5-2178D8CB41A2@thomasclausen.org> <00ea01c8287a$464a3a50$d2deaef0$@nl> <473DF63F.2030505@gmail.com> <012401c828ef$292cb630$7b862290$@nl> <473F3CE0.50807@gmail.com> <006a01c82a2e$f325ebb0$d971c310$@nl> <47416F4A.4020002@gmail.com> <003901c82aa6$5b92e370$12b8aa50$@nl> In-Reply-To: <003901c82aa6$5b92e370$12b8aa50$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba 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. I still don't understand the term MGA. Can you check if what you mean is not the same as the term MLA defined in draft-ietf-autoconf-statement-02.txt ? Emmanuel Teco Boot a écrit : > Hi Alex, > > I put some comments inline. > I think the most important issue you brought up is having Autoconf also > looking at PAN, where devices behind Personal MR cannot autoconfigure MGA. > This use case is missing in autoconf-manetarch. More text on this inline. > > Teco. > >> -----Oorspronkelijk bericht----- >> Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> Verzonden: maandag 19 november 2007 12:11 >> Aan: Teco Boot >> CC: Alexandru Petrescu; autoconf@ietf.org >> Onderwerp: Re: [Autoconf] Re: Scenarios and Requirements >> >> Hi Teco, let's keep this thread on AUTOCONF Scenarios and Requirements. >> I snipped some parts for this reson. >> >> Teco Boot wrote: >>>> -----Oorspronkelijk bericht----- Van: Alexandru Petrescu >>>> [mailto:alexandru.petrescu@gmail.com] Verzonden: zaterdag 17 >>>> november 2007 20:11 Aan: Teco Boot CC: autoconf@ietf.org Onderwerp: >>>> Re: [Autoconf] Re: Scenarios and Requirements >>>>> We should look for protocols that can be used also in other >>>>> environments. Think about a managed service, where 200 people are >>>>> responsible. If we build the protocols just for your scenario, I >>>>> stop putting effort on this immediately. But if we can do it >>>>> jointly, for multiple scenarios, I am in. I hope same for you. >>>>> Please think about all scenarios. >>>> I agree with you. I'm ready to describe the scenario I'm >>>> interested it. It involves mainly personal area networks made of >>>> PDAs, laptops, cameras, some sensors may be. This is just >>>> high-level description but more detail can easily be told. >>> I think this is more or less similar to NEMO RO use cases, isn't it? >> I think the scenario with PANs under a single administrator can have a >> solution as a MIP6 extensions to RO for NEMO, or a routing protocol >> solution - or probably no new protocol at all. >> >> But - yes - it is obvious that we talk very similar scenarios in the >> NEMO RO reqs and in MANET reqs and in AUTOCONF reqs. >> >>> Maybe we should describe were multihop connectivity applies between >>> those devices and the Border Router, as an extension to the NEMO RO >>> use cases. >> What's multihop connectivity? > > Where there is no direct connectivity between a node and the Border Router, > e.g. gadget to smartphone to 3GPP. > I am not sure we need a full blown MANET protocol for this. But there is a > need for routing. Or nested NEMO. Or both. > > I think the Autoconf shall develop a mechanism for providing an address to > the gadget. But gadget does not receive 3GPP RA and thus it cannot configure > an address for it. > >>>> I would also like to work on reqs for scenarios that you may >>>> consider, with 200 or so people responsible for some devices. >>>> Except that I don't know how is that described? What does scenario >>>> look like? What devices are there? Are they laptops, pdas, >>>> sensors - what are they more exactly? >>> Is this important? >> Here, in this case, I think it is important to describe the scenarios >> in >> more detail otherwise I'm afraid it's going to lead again to new >> mechanisms designed for less purpose. >> >> I personally I'm used to see detail scenario, then see people say how >> easily this can be accommodated with existing stuff then other people >> say where it failed after experimentation - and so on. > > I agree in focusing on real world problems. But I doubt if we need to write > down this in RFCs. > > >>> By the way, "some devices" would be large numbers. Number of Border >>> Routers are also large numbers. Think on regional / national / >>> international access networks with multiple technologies, provided by >>> multiple ISPs. Assume hotspot, WiMAX, 3G and cabling as last ad-hoc >>> hop to Border Router. Users are personal, small business, >>> enterprise, NGO, public safety, military and maybe more. I think it >>> is not important to work out this kind of details, problems are >>> similar. >> Ok, I kind of see, but this still looks too generic. It pretty much >> covers about everything leaf network one can imagine. >> >> I think you may be right to deduce that the problems are similar, but >> to >> me it is too early to say so. >> >> There are fine differences between cases. Let me tell one difference. >> Consider a rescue scene with vehicles in a fixed situation. Each has a >> mobile router within. Consider one vehicle to the the "Captain" and >> using a high-power WiFi Access Point to give DHCP addresses to all >> other >> vehicles. This is an easy IP configuration scenario which can easily >> be accommodated by existing protocols. > > Maybe IP config is easy. Providing fully meshed connectivity is a hell. > There could be mountains, buildings or vehicles preventing line-of-sight. Or > the captain takes his vehicle and drives to the mayor. Or other disasters > for good quality radio communication. > > When only the captain has high power AP, there will be uni-directional links > - Asymmetric Reachability. > > Rescue is not fixed and the problems are far more complex. > Let's save lives and provide something better to the rescue teams. > >> But then there may be a >> requirement >> against the existence of that central entity and all vehicles should >> communicate with WiFi without Access Point. Now this is much more >> difficult to accommodate with existing IP protocols, because there's >> very little structure. New mechanisms may be needed for this. Things >> may be easier if all vehicles are fixed instead of moving. > > It is not new. We have this already. It is called MANET Routing protocol. > > >> But, a big but, who can tell these kinds of requirements? Can we tell >> at least the little requirement that deals with being mobile or not >> mobile? Or the little requirement that tells which applications (or >> kinds of) are run? >> >> It may be that we go to customers and they'll say of course there's a >> central command and control vehicle, with a central Access Point and >> they absolutely need itt. The reverse may be true too: the scene >> should >> work until command unit arrival too, thus no AP for a while. Or it may >> be that TCP/IP connectivity is less urgent and can wait until that >> vehicle arrives. >> >> This kinds of requirements are important. You can formulate them >> however you want, in terms of teapots and spoons (such as to avoid >> "tanks") if you want. But make it intelligible from a protocol >> behaviour perspective. > > I think MANET technology being used is well described in manetarch. > I think there is little need in providing a long list of detailed user > requirements, this will costs lots of time and it brings not that much. > > We could think on adding more text in manetarch on non-transitive > communication (X<->Y is OK, Y<->Z is OK, X<->Z is not OK), like your use > case with 3GPP and Bluetooth/UWB. > >>> We never described details on laptop, pda, server etcetera when >>> defining IP protocols. >> These people had _very_ strong requirements: they wanted to make remote >> computers talk to each other. That's done. >> >> But here's no requirement in my understanding (sorry if I don't see >> something obvious). >> >> [...] >> >>> Autoconf shall be independent of the MANET protocol (charter). We >>> have about 5 already, more dialects to come. >> We have 5 whats? 5 MANET protocols? Or 5 methods for AUTOCONF WG? > > 5 MANET protocols. > >> Do we have any AUTOCONF solution proposal? >> >>> The problem here is when we have a Autoconf protocol, a BR could be >>> selected but this BR could not be reachable, because it speaks >>> another dialect. >> Let's see what an AUTOCONF protocol looks like first, no? > > When the Autoconf is independent of the routing protocol and does not > provide a path between nodes and the BR, the BR could be not reachable from > the nodes. Or am I missing something? > > >>> Maybe we should think of decoupling inner-MANET-routing and >>> BR-routing. Again, this is not Autoconf. We could work on a >>> requirements For Br Routing document and sent this to the Routing >>> Area. Or discuss this with MANET WG (and RL2N, after BOF). >>> >>>>> Bytheway, I have "stolen" the idea, see my I-D. And when adopted, >>>>> it shall be reused as much as possible. E.g. RL2N and MIP. >>>> :-) :-) >>>> >>>> Is RL2N Routing for Low Power and Lossy Networks that BoF >>>> http://www.employees.org/~jvasseur/ ? >>> Yepp. >>> >>>> Your I-D is titled fine but misnames BRDP (Border Router Discovery >>>> Protocol) as a protocol(?) It's good it looks at ND. >>> NDP is a protocol, running on ICMP which is also a protocol, running >>> on IP, which is also a protocol, running on a lower layer protocol. >> We'll see separately if you want to fork a new thread :-) >> >> 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 > > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 19 08:55: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 1Iu75Z-0003FW-Uc; Mon, 19 Nov 2007 08:55:01 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Iu75Y-0003Et-E3 for autoconf-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 08:55:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu75Y-0003Ej-4X for autoconf@ietf.org; Mon, 19 Nov 2007 08:55:00 -0500 Received: from hpsmtp-eml11.kpnxchange.com ([213.75.38.111]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu75T-0002Qm-Ig for autoconf@ietf.org; Mon, 19 Nov 2007 08:55:00 -0500 Received: from hpsmtp-eml02.kpnxchange.com ([213.75.38.102]) by hpsmtp-eml11.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 14:54:54 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml02.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 14:54:53 +0100 From: "Teco Boot" To: "'Emmanuel Baccelli'" , References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7695.1060808@gmail.com> <00b101c82848$bd7580d0$38608270$@nl> <473D9D60.6090009@gmail.com> <473DA439.9070303@inria.fr> <00d101c82860$2a3cd3a0$7eb67ae0$@nl> <473DB35E.4030406@inria.fr> <473DB3C2.6090405@telecomitalia.it> <1B345D27-0BC6-443A-80A5-2178D8CB41A2@thomasclausen.org> <00ea01c8287a$464a3a50$d2deaef0$@nl> <473DF63F.2030505@gmail.com> <012401c828ef$292cb630$7b862290$@nl> <473F3CE0.50807@gmail.com> <006a01c82a2e$f325ebb0$d971c310$@nl> <47416F4A.4020002@gmail.com> <003901c82aa6$5b92e370$12b8aa50$@nl> <4741890E.1070908@inria.fr> In-Reply-To: <4741890E.1070908@inria.fr> Subject: RE: [Autoconf] Re: Scenarios and Requirements Date: Mon, 19 Nov 2007 14:54:49 +0100 Message-ID: <005601c82ab3$c16148b0$4423da10$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgqrFk9jZSdwOOFS9uJ1ImlnLVj9AAAEqqA Content-Language: nl X-OriginalArrivalTime: 19 Nov 2007 13:54:53.0963 (UTC) FILETIME=[C307A5B0:01C82AB3] X-Spam-Score: -1.0 (-) X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c 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 Hi Emmanuel, Here a suggested text: MANET Global Address (MGA) - An IP address configured on a MANET interface, and valid for communications inside the MANET and for communications with corresponding nodes on the Internet, via a Border Router. A MGA is associated with a Border Router, for being = topologically correct. Global Address is to be replaced. With MGA. Please verify definition for Global prefix. There are conditions that IP addresses are invalid for communications reaching outside the MANET. And = why is it reserved for MANET Routers? Why not using a range? (RFC3633 uses prefixes, that could be a reason). I do not like the term "Internet Configuration Provider (ICP)". Why not using DHCP Server? Or is it something else? Must this be a Router? Why? = Why can't it provide prefixes or addresses to hosts? Large infrastructures typically have separated routers and address assignment servers. I = reject text defining that these are integrated in one device. It may be, but = _not_ should be and _certainly not_ must be. On DHCP-PD, I reread the problem statement document. When all nodes = perform DHCP functions, as 3633 RR and DR, what are the problems? I don't think = this scenario is optimal, but it should work.=20 Problems could be: - BR ingress filter, relation with routing - Session continuity problem when path via BR is not available anymore - Running DHCP on some platforms - Inefficient address usage Cheers, Teco. > -----Oorspronkelijk bericht----- > Van: Emmanuel Baccelli [mailto:Emmanuel.Baccelli@inria.fr] > Verzonden: maandag 19 november 2007 14:01 > Aan: autoconf@ietf.org > Onderwerp: Re: [Autoconf] Re: Scenarios and Requirements >=20 > Hi Teco. > I still don't understand the term MGA. Can you check if what you mean > is > not the same as the term MLA defined in > draft-ietf-autoconf-statement-02.txt ? > Emmanuel >=20 > Teco Boot a =E9crit : > > Hi Alex, > > > > I put some comments inline. > > I think the most important issue you brought up is having Autoconf > also > > looking at PAN, where devices behind Personal MR cannot = autoconfigure > MGA. > > This use case is missing in autoconf-manetarch. More text on this > inline. > > > > Teco. > > > >> -----Oorspronkelijk bericht----- > >> Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > >> Verzonden: maandag 19 november 2007 12:11 > >> Aan: Teco Boot > >> CC: Alexandru Petrescu; autoconf@ietf.org > >> Onderwerp: Re: [Autoconf] Re: Scenarios and Requirements > >> > >> Hi Teco, let's keep this thread on AUTOCONF Scenarios and > Requirements. > >> I snipped some parts for this reson. > >> > >> Teco Boot wrote: > >>>> -----Oorspronkelijk bericht----- Van: Alexandru Petrescu > >>>> [mailto:alexandru.petrescu@gmail.com] Verzonden: zaterdag 17 > >>>> november 2007 20:11 Aan: Teco Boot CC: autoconf@ietf.org > Onderwerp: > >>>> Re: [Autoconf] Re: Scenarios and Requirements > >>>>> We should look for protocols that can be used also in other > >>>>> environments. Think about a managed service, where 200 people = are > >>>>> responsible. If we build the protocols just for your scenario, = I > >>>>> stop putting effort on this immediately. But if we can do it > >>>>> jointly, for multiple scenarios, I am in. I hope same for you. > >>>>> Please think about all scenarios. > >>>> I agree with you. I'm ready to describe the scenario I'm > >>>> interested it. It involves mainly personal area networks made of > >>>> PDAs, laptops, cameras, some sensors may be. This is just > >>>> high-level description but more detail can easily be told. > >>> I think this is more or less similar to NEMO RO use cases, isn't > it? > >> I think the scenario with PANs under a single administrator can = have > a > >> solution as a MIP6 extensions to RO for NEMO, or a routing protocol > >> solution - or probably no new protocol at all. > >> > >> But - yes - it is obvious that we talk very similar scenarios in = the > >> NEMO RO reqs and in MANET reqs and in AUTOCONF reqs. > >> > >>> Maybe we should describe were multihop connectivity applies = between > >>> those devices and the Border Router, as an extension to the NEMO = RO > >>> use cases. > >> What's multihop connectivity? > > > > Where there is no direct connectivity between a node and the Border > Router, > > e.g. gadget to smartphone to 3GPP. > > I am not sure we need a full blown MANET protocol for this. But = there > is a > > need for routing. Or nested NEMO. Or both. > > > > I think the Autoconf shall develop a mechanism for providing an > address to > > the gadget. But gadget does not receive 3GPP RA and thus it cannot > configure > > an address for it. > > > >>>> I would also like to work on reqs for scenarios that you may > >>>> consider, with 200 or so people responsible for some devices. > >>>> Except that I don't know how is that described? What does > scenario > >>>> look like? What devices are there? Are they laptops, pdas, > >>>> sensors - what are they more exactly? > >>> Is this important? > >> Here, in this case, I think it is important to describe the > scenarios > >> in > >> more detail otherwise I'm afraid it's going to lead again to new > >> mechanisms designed for less purpose. > >> > >> I personally I'm used to see detail scenario, then see people say > how > >> easily this can be accommodated with existing stuff then other > people > >> say where it failed after experimentation - and so on. > > > > I agree in focusing on real world problems. But I doubt if we need = to > write > > down this in RFCs. > > > > > >>> By the way, "some devices" would be large numbers. Number of = Border > >>> Routers are also large numbers. Think on regional / national / > >>> international access networks with multiple technologies, provided > by > >>> multiple ISPs. Assume hotspot, WiMAX, 3G and cabling as last ad- > hoc > >>> hop to Border Router. Users are personal, small business, > >>> enterprise, NGO, public safety, military and maybe more. I think = it > >>> is not important to work out this kind of details, problems are > >>> similar. > >> Ok, I kind of see, but this still looks too generic. It pretty = much > >> covers about everything leaf network one can imagine. > >> > >> I think you may be right to deduce that the problems are similar, > but > >> to > >> me it is too early to say so. > >> > >> There are fine differences between cases. Let me tell one > difference. > >> Consider a rescue scene with vehicles in a fixed situation. Each > has a > >> mobile router within. Consider one vehicle to the the "Captain" = and > >> using a high-power WiFi Access Point to give DHCP addresses to all > >> other > >> vehicles. This is an easy IP configuration scenario which can > easily > >> be accommodated by existing protocols. > > > > Maybe IP config is easy. Providing fully meshed connectivity is a > hell. > > There could be mountains, buildings or vehicles preventing line-of- > sight. Or > > the captain takes his vehicle and drives to the mayor. Or other > disasters > > for good quality radio communication. > > > > When only the captain has high power AP, there will be uni- > directional links > > - Asymmetric Reachability. > > > > Rescue is not fixed and the problems are far more complex. > > Let's save lives and provide something better to the rescue teams. > > > >> But then there may be a > >> requirement > >> against the existence of that central entity and all vehicles = should > >> communicate with WiFi without Access Point. Now this is much more > >> difficult to accommodate with existing IP protocols, because = there's > >> very little structure. New mechanisms may be needed for this. > Things > >> may be easier if all vehicles are fixed instead of moving. > > > > It is not new. We have this already. It is called MANET Routing > protocol. > > > > > >> But, a big but, who can tell these kinds of requirements? Can we > tell > >> at least the little requirement that deals with being mobile or not > >> mobile? Or the little requirement that tells which applications = (or > >> kinds of) are run? > >> > >> It may be that we go to customers and they'll say of course there's > a > >> central command and control vehicle, with a central Access Point = and > >> they absolutely need itt. The reverse may be true too: the scene > >> should > >> work until command unit arrival too, thus no AP for a while. Or it > may > >> be that TCP/IP connectivity is less urgent and can wait until that > >> vehicle arrives. > >> > >> This kinds of requirements are important. You can formulate them > >> however you want, in terms of teapots and spoons (such as to avoid > >> "tanks") if you want. But make it intelligible from a protocol > >> behaviour perspective. > > > > I think MANET technology being used is well described in manetarch. > > I think there is little need in providing a long list of detailed > user > > requirements, this will costs lots of time and it brings not that > much. > > > > We could think on adding more text in manetarch on non-transitive > > communication (X<->Y is OK, Y<->Z is OK, X<->Z is not OK), like your > use > > case with 3GPP and Bluetooth/UWB. > > > >>> We never described details on laptop, pda, server etcetera when > >>> defining IP protocols. > >> These people had _very_ strong requirements: they wanted to make > remote > >> computers talk to each other. That's done. > >> > >> But here's no requirement in my understanding (sorry if I don't see > >> something obvious). > >> > >> [...] > >> > >>> Autoconf shall be independent of the MANET protocol (charter). We > >>> have about 5 already, more dialects to come. > >> We have 5 whats? 5 MANET protocols? Or 5 methods for AUTOCONF WG? > > > > 5 MANET protocols. > > > >> Do we have any AUTOCONF solution proposal? > >> > >>> The problem here is when we have a Autoconf protocol, a BR could = be > >>> selected but this BR could not be reachable, because it speaks > >>> another dialect. > >> Let's see what an AUTOCONF protocol looks like first, no? > > > > When the Autoconf is independent of the routing protocol and does = not > > provide a path between nodes and the BR, the BR could be not > reachable from > > the nodes. Or am I missing something? > > > > > >>> Maybe we should think of decoupling inner-MANET-routing and > >>> BR-routing. Again, this is not Autoconf. We could work on a > >>> requirements For Br Routing document and sent this to the Routing > >>> Area. Or discuss this with MANET WG (and RL2N, after BOF). > >>> > >>>>> Bytheway, I have "stolen" the idea, see my I-D. And when = adopted, > >>>>> it shall be reused as much as possible. E.g. RL2N and MIP. > >>>> :-) :-) > >>>> > >>>> Is RL2N Routing for Low Power and Lossy Networks that BoF > >>>> http://www.employees.org/~jvasseur/ ? > >>> Yepp. > >>> > >>>> Your I-D is titled fine but misnames BRDP (Border Router = Discovery > >>>> Protocol) as a protocol(?) It's good it looks at ND. > >>> NDP is a protocol, running on ICMP which is also a protocol, > running > >>> on IP, which is also a protocol, running on a lower layer = protocol. > >> We'll see separately if you want to fork a new thread :-) > >> > >> 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 > > > > >=20 >=20 > _______________________________________________ > 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 Nov 19 09:33:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu7h2-0005Wu-0t; Mon, 19 Nov 2007 09:33:44 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Iu7gv-0005S6-Og for autoconf-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 09:33:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu7gu-0005P5-P1 for autoconf@ietf.org; Mon, 19 Nov 2007 09:33:37 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iu7gt-00045L-HU for autoconf@ietf.org; Mon, 19 Nov 2007 09:33:36 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-153.messagelabs.com!1195482814!13415068!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 6460 invoked from network); 19 Nov 2007 14:33:34 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-15.tower-153.messagelabs.com with SMTP; 19 Nov 2007 14:33:34 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id lAJEXYMj003227 for ; Mon, 19 Nov 2007 07:33:34 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id lAJEXXJe016716 for ; Mon, 19 Nov 2007 08:33:33 -0600 (CST) 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 lAJEXVNg016701 for ; Mon, 19 Nov 2007 08:33:32 -0600 (CST) Message-ID: <47419EBB.6010407@gmail.com> Date: Mon, 19 Nov 2007 15:33:31 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 CC: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-ietf-autoconf-statement-02.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071118-1, 18/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 1.6 (+) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 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 Thanks to the authors for this new draft. I have the following comments. Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Ad-Hoc Network > Autoconfiguration Working Group of the IETF. > > > Title : Address Autoconfiguration for MANET: Terminology > and Problem Statement Author(s) : E. Baccelli, et al. Filename > : draft-ietf-autoconf-statement-02.txt Pages : 19 Date : > 2007-11-19 > > Traditional dynamic IPv6 address assignment solutions are not adapted > to mobile ad hoc networks. This document elaborates on this > problem, states the need for new solutions, and requirements to these > solutions. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-autoconf-statement-02.txt [...] > Standard automatic IPv6 address assignment and prefix delegation > solutions [5][RFC4862 stateless autoconf], [3][RFC4861 ND] > [4][RFC3315 DHCPv6] do not work "as-is" on MANETs Thanks for mentioning these RFCs. Please also refer to the reference [18] (RFC3633 IPv6 Prefix Options for DHCPv6) that you already added, thanks. > Global prefix - An IP prefix delegated to a MANET router, consisting > in chunks of IP addresses valid for communications reaching outside > the MANET (as well as communications within the MANET). [...] Prefix > delegation - The process of providing a router with a set of > contiguous addresses it may manage for the purpose of configuring > interfaces or other routers. These two paragraphs being defining paragraphs: I think they should mention their relationship to DHCPv6 Prefix Delegation (RFC3633 and RFC3769) because they use precisely the same term "prefix delegation" but with a slightly different meaning. From reading this autoconf-statement-02 draft I mainly understand that you mean "prefix delegation" as some generic mechanisms to assign a prefix to a router, maybe some administrative out-of-band means too. Or, RFC3633 and RFC3769 and a bunch of other mobility-related drafts use "prefix delegation" to mean DHCPv6-PD. If would personally avoid the use of "prefix delegation" as the generic means, because it's easily confusable with DHCPv6-PD. But your reading may be different. If so, it would be clearer to clarify the relationship with DHCPv6-PD. For example, what does this mean: > Automatic configuration of IP addresses on MANET interfaces and > prefix delegation to MANET routers are necessary in a number of > deployment scenarios. Does it mean that some generic mechanism to assign prefixes to routers is needed? Or does it mean that DHCPv6-PD is needed? That's why the definitions above would benefit from clarifying. > Traditional solutions assume that a broadcast directly reaches every > router or host on the subnetwork, whereas this generally is not the > case in MANETs (see [2]). If you want to define 'MANETs' to be such that broadcast don't directly reaches every router or host on the subnetwork then you have a problem defining MANET. Please redefine MANET such link-layer broadcast reaches all hosts and routers on that link. Most wireless link-layers have a very well defined broadcast property. If in some MANET cases that broadcast property is not maintained then the MANET should be redefined such that the broadcast property is respected. For example, if in WiFi host A sees B, B sees C but C doesn't see A then please don't configure A, B and C in the IP same subnet. Please configure them as two different subnets one for A and B and the other for B and C and B as a router. > Some routers in the MANET will typically assume multihop broadcast, > and expect to receive through several intermediate relayings by peer > MANET routers. What's the scenario and requirements for multihop broadcast? Would IP multicast work ok instead of multihop broadcast? > While stateless protocols such as [5] and [3] could provide IP > address configuration (for MANET interfaces, loopback interfaces), > these solutions do not provide any mechanism for allocating "unique > prefix(es)" to routers in order to enable the configuration of host > interfaces. YEs, but stateful DHCP Prefix Delegation does provide a mechanism for allocating unique prefixes to routers in order to enable configuration of hosts interfaces. I think it makes sense to actually use reference [18] that you inserted. Maybe use it here. > A MANET router needs to configure IP addresses and prefixes as usual, > on its non-MANET interfaces as well as its attached hosts and > routers, if any. I'm not sure I understand this statement ok. I understand MANET router needing to configure IP addresses for itself (and we already have a problem here because other than DHCPv6-PD and NEMO MRs other routers don't know how to auto-configure addresses). Do you mean that the MANET router needs to configure addresses to the attached hosts too? Or that the hosts need also to configure IP addresses? I'm afraid that saying that the router configures an address on the host it may be very different than existing stateless and stateful autoconfig. Because in stateless the router puts a prefix in the RA but the host configures the address and in stateful the router may send an address but the host configures it. If I think DHCPv6-PD then I can say that the text should say: "The MANET Router should help and assist the host to auto-configure its (host's) address." Or similar, but I don't know what you really meant to say with that? > For example, in Fig. > 1, the MANET router MR3 cannot communicate directly with a DHCP > server [4] that would be available through a MANET border router, > since the server and the MANET router are not located on the same > logical link. While DHCP can to some extent overcome this issue in a > static network, it is not the case in a dynamic topology, as > explained below. > ----- MR1...MR3 > / . > +-------------+ +------------+ / . > | | p2p | MANET |/ . > | ISP Edge | Link | Border | . > | Router +---------+ Router |\ . > | | | | \ . > +-------------+ +------------+ \----- MR2 > > Fig. 1. Connected MANET router topology. I think there may be some confusions here. You're saying the MR3 can not communicate directly with the DHCP Server (the "ISP Edge Router" presumably). If they're not on the same subnet then they don't need to communicate directly. The last-hop MANET Router (presumably the non-illustrated MR2) would play the role of a Relay and the Relay would unicast the messaging to the DHCP Server (presumably the ISP Edge Router). Then you're saying that this may work in the static case but not in a dynamic topology. For one thing I'd like to say that there are many MANET-like situations where the hosts and routers are stable. Rescue scene is one of them. Are these ruled out from the AUTOCONF WG? Then, if we accept that the above network is dynamic (and we rule out the class of fixed scenes) then one wonders - what moves more precisely? Are the DHCP Server and the Border ROuter fixed entities and only the MRs move? Can we specify this? Then, if we accept that only the MANET MRs move then the DHCP problem turns into a problem of MR2 (the DHCP Relay) disappearing and maybe another MR (another DHCP Relay) take its place. Which DHCP Relay is active? How can the MR3 discover the Relay? Can it simply multicast a DHCPv6 Solicit message taking advantage of the underlying well-defined multicast behaviour? I think it can. If not all these issues I described above - then what DHCP issues do you see? 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 Nov 19 17:20:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuEz2-00044a-Dh; Mon, 19 Nov 2007 17:20:48 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuEz0-00040R-NS for autoconf-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 17:20:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuEz0-0003z5-Cl for autoconf@ietf.org; Mon, 19 Nov 2007 17:20:46 -0500 Received: from hpsmtp-eml17.kpnxchange.com ([213.75.38.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuEyz-0005ZM-Gq for autoconf@ietf.org; Mon, 19 Nov 2007 17:20:45 -0500 Received: from hpsmtp-eml03.kpnxchange.com ([213.75.38.103]) by hpsmtp-eml17.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 23:20:44 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml03.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 23:20:44 +0100 From: "Teco Boot" To: Date: Mon, 19 Nov 2007 23:20:39 +0100 Message-ID: <006901c82afa$6aa3cf10$3feb6d30$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acgq+mpGgWEKRtCQRSSLezJem7L2rw== Content-Language: nl X-OriginalArrivalTime: 19 Nov 2007 22:20:44.0057 (UTC) FILETIME=[6D187890:01C82AFA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Autoconf] Random MLA uniqueness 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, I was thinking on likelihood of collisions using ULA for MLA. When using ULA random Global_ID and Subnet_ID, we have already 56 bits. Enough for 7733248 /64 prefixes per human being (projected 2050 world population). For Cryptographically Generated Address (CGA, RFC3972) we have 59 crypto-random bits on Interface ID, 115 bits total. For Randomized Interface Identifiers (RFC3041) we have 63 random bits, 119 in total. (note that RFC4429 mentions 62 bits, reserving both U and G bits) Lets calculate worst case, with 115 bits and a MANET with 100.000 nodes (immense MANET). I think we need a big supercomputer to calculate the probability for birthday paradox;-) It is something like Pb(2^115,100000) = 1-( 2^115! / [ (2^115-100000)! . 2^115^100000] ) RFC4429 provides a formula for the upper limit: Pb(n,k) <= 1-( [(n-k+1)/n] ^ [k-1] ) Pb(2^115,100000) <= 1-( [(2^115-100000+1)/2^115] ^ [100000-1] ) I can't calculate the outcome. Has anyone a calculator with extreme long real numbers? Maybe the problem is in the random number generator. Anyway, I think someone should work on address spoofing protection. Pspoofing >>>> Pb. Some of us will tell that their birthday is on the same day as someone else, and they save on treat. Adding this information in problem statement? Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 20 08:58:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuTcH-0007ro-Tq; Tue, 20 Nov 2007 08:58:17 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuTcH-0007ri-HP for autoconf-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 08:58:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuTcH-0007ra-6X for autoconf@ietf.org; Tue, 20 Nov 2007 08:58:17 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuTcG-0003Ky-HR for autoconf@ietf.org; Tue, 20 Nov 2007 08:58:17 -0500 Received: from epmmp2 (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 <0JRT00KAE5GX3G@mailout2.samsung.com> for autoconf@ietf.org; Tue, 20 Nov 2007 22:58:09 +0900 (KST) Received: from Shubhranshu ([107.108.209.125]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0JRT00A675GWN5@mmp2.samsung.com> for autoconf@ietf.org; Tue, 20 Nov 2007 22:58:10 +0900 (KST) Date: Tue, 20 Nov 2007 19:29:18 +0530 From: Shubhranshu Subject: Re: [Autoconf] Random MLA uniqueness To: Teco Boot Message-id: <02a101c82b7d$8ca3cab0$7dd16c6b@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: 2.2 (++) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 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="===============0853236504==" Errors-To: autoconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0853236504== Content-type: multipart/alternative; boundary="Boundary_(ID_ddf9+QKej80Bjy6cKz2AGQ)" This is a multi-part message in MIME format. --Boundary_(ID_ddf9+QKej80Bjy6cKz2AGQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hello Teco, Please see below comments. ----- Original Message ----- From: "Teco Boot" > RFC4429 provides a formula for the upper limit: > Pb(n,k) <= 1-( [(n-k+1)/n] ^ [k-1] ) > Pb(2^115,100000) <= 1-( [(2^115-100000+1)/2^115] ^ [100000-1] ) > I can't calculate the outcome. Has anyone a calculator with extreme long > real numbers? > > Maybe the problem is in the random number generator. > Anyway, I think someone should work on address spoofing protection. > Pspoofing >>>> Pb. > Some of us will tell that their birthday is on the same day as someone else, > and they save on treat. > > Adding this information in problem statement? If you (and others) think these should be added then I'd be fine too. But before that here are some of my thoughts. MLA is a specific solution for local addresses for MANET nodes. Do you think it would be appropriate to assume at this point that Autoconf will standardize MLA as its solution ? Since unless you assume that (or at least show your inclination / biasness towards this approach), I can't understand how this would help to include all these in the WG's problem statement document. Now, assume that finally the Autoconf WG standardizes this as solution. In that case, won't it be appropriate for that particular solution document to provide all these details ? Besides, concerns / problems related to these possible address conflict is well understood and written. Please refer to the ULA RFC. - Shubhranshu > > Teco. --Boundary_(ID_ddf9+QKej80Bjy6cKz2AGQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hello Teco,
 
Please see below comments.
 
----- Original Message -----
From: "Teco Boot" <teco@inf-net.nl>

<snip>
 
> RFC4429 provides a formula for the upper limit:
>  Pb(n,k) <= 1-( [(n-k+1)/n] ^ [k-1] )
>  Pb(2^115,100000) <= 1-( [(2^115-100000+1)/2^115] ^ [100000-1] )
> I can't calculate the outcome. Has anyone a calculator with extreme long
> real numbers?
>
> Maybe the problem is in the random number generator.
> Anyway, I think someone should work on address spoofing protection.
> Pspoofing >>>> Pb.
> Some of us will tell that their birthday is on the same day as someone else,
> and they save on treat.
>
> Adding this information in problem statement?
 
If you (and others) think these should be added then I'd be fine too. But  
before that here are some of my thoughts. MLA is a specific solution for
local addresses for MANET nodes. Do you think it would be appropriate
to assume at this point that Autoconf will standardize MLA as its
solution ? Since unless you assume that (or at least show your
inclination / biasness towards this approach), I can't understand how this
would help to include all these in the WG's problem statement document.
Now, assume that finally the Autoconf WG standardizes this as solution.
In that case, won't it be appropriate for that particular solution document
to provide all these details ?
 
Besides, concerns / problems related to these possible address conflict is
well understood and written. Please refer to the ULA RFC.
 
- Shubhranshu

>
> Teco.
 --Boundary_(ID_ddf9+QKej80Bjy6cKz2AGQ)-- --===============0853236504== 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 --===============0853236504==-- From autoconf-bounces@ietf.org Tue Nov 20 09:10: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 1IuTnx-0004YA-Ed; Tue, 20 Nov 2007 09:10:21 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuTnw-0004Y3-7i for autoconf-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 09:10:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuTnv-0004Xt-U9 for autoconf@ietf.org; Tue, 20 Nov 2007 09:10:19 -0500 Received: from mail1-relais-roc.national.inria.fr ([192.134.164.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuTns-000395-AZ for autoconf@ietf.org; Tue, 20 Nov 2007 09:10:19 -0500 X-IronPort-AV: E=Sophos;i="4.21,441,1188770400"; d="scan'208";a="4703316" Received: from z0213.pia.fu-berlin.de (HELO BoolfightMaN-Laptop.local) ([87.77.2.19]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Nov 2007 15:10:12 +0100 Message-ID: <4742EAB4.2070101@inria.fr> Date: Tue, 20 Nov 2007 15:09:56 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org Subject: Re: [Autoconf] Re: Scenarios and Requirements References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7695.1060808@gmail.com> <00b101c82848$bd7580d0$38608270$@nl> <473D9D60.6090009@gmail.com> <473DA439.9070303@inria.fr> <00d101c82860$2a3cd3a0$7eb67ae0$@nl> <473DB35E.4030406@inria.fr> <473DB3C2.6090405@telecomitalia.it> <1B345D27-0BC6-443A-80A5-2178D8CB41A2@thomasclausen.org> <00ea01c8287a$464a3a50$d2deaef0$@nl> <473DF63F.2030505@gmail.com> <012401c828ef$292cb630$7b862290$@nl> <473F3CE0.50807@gmail.com> <006a01c82a2e$f325ebb0$d971c310$@nl> <47416F4A.4020002@gmail.com> <003901c82aa6$5b92e370$12b8aa50$@nl> <4741890E.1070908@inria.fr> <005601c82ab3$c16148b0$4423da10$@nl> In-Reply-To: <005601c82ab3$c16148b0$4423da10$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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, Teco Boot a écrit : > > MANET Global Address (MGA) - An IP address configured on a MANET > interface, and valid for communications inside the MANET and for > communications with corresponding nodes on the Internet, via a > Border Router. A MGA is associated with a Border Router, for being > topologically correct. > > > Please verify definition for Global prefix. There are conditions that IP > addresses are invalid for communications reaching outside the MANET. And why > is it reserved for MANET Routers? Why not using a range? (RFC3633 uses > prefixes, that could be a reason). OK, I see what you mean. I think that we do not need to create new terms other than global prefix and global address. We just need to make sure that people understand what these terms mean in the context of MANETs. > > I do not like the term "Internet Configuration Provider (ICP)". Why not > using DHCP Server? Or is it something else? Must this be a Router? Why? Why > can't it provide prefixes or addresses to hosts? Large infrastructures > typically have separated routers and address assignment servers. I reject > text defining that these are integrated in one device. It may be, but _not_ > should be and _certainly not_ must be. > OK. So maybe we could talk about an "entity" instead of a "router"? This would be more general I agree. > On DHCP-PD, I reread the problem statement document. When all nodes perform > DHCP functions, as 3633 RR and DR, what are the problems? I don't think this > scenario is optimal, but it should work. > Problems could be: > - BR ingress filter, relation with routing > - Session continuity problem when path via BR is not available anymore > - Running DHCP on some platforms > - Inefficient address usage Yes, especially you'd get into trouble if no server is reachable and the MANET is not "full mesh". This is the case of most standalone MANETs, for instance. Emmanuel _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 20 09:22: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 1IuTze-0003mO-DN; Tue, 20 Nov 2007 09:22:26 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuTzd-0003jD-4i for autoconf-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 09:22:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuTzc-0003iE-PL for autoconf@ietf.org; Tue, 20 Nov 2007 09:22:24 -0500 Received: from hpsmtp-eml14.kpnxchange.com ([213.75.38.114]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuTzc-00045N-8b for autoconf@ietf.org; Tue, 20 Nov 2007 09:22:24 -0500 Received: from hpsmtp-eml02.kpnxchange.com ([213.75.38.102]) by hpsmtp-eml14.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 15:22:23 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml02.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 15:21:47 +0100 From: "Teco Boot" To: "'Shubhranshu'" References: <02a101c82b7d$8ca3cab0$7dd16c6b@sisodomain.com> In-Reply-To: <02a101c82b7d$8ca3cab0$7dd16c6b@sisodomain.com> Subject: RE: [Autoconf] Random MLA uniqueness Date: Tue, 20 Nov 2007 15:21:40 +0100 Message-ID: <00a201c82b80$aca4aa20$05edfe60$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgrfXvrMzYAsDFoQY23VXoGQdMRfQAALAlA Content-Language: nl X-OriginalArrivalTime: 20 Nov 2007 14:21:47.0704 (UTC) FILETIME=[AF4EBB80:01C82B80] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 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 If this is all well understood and written down, and there are no = problems, what the hell are we doing in Autoconf? 1) shall we use random ULA on each node? 2) shall we use random subnet_ID? 3) How can we optimize for efficiency, e.g. compact transport using PacketBB? For 3), I can imagine someone comes up with a listen mode for capturing = an existing Global_ID and Subnet_ID, so the MLA transfer over PacketBB = needs only 64 bits (a win of 7 octets per address). (oeps, I did;-) I think this is the first an easiest part of Autoconf. I suggest moving forward with this approach as quickly as possible. As a second phase, we can work on looking at existing DHCP-PD solutions, also for MLA usage. This would further optimize transport over PacketBB. = I am sure we can use this, I am not sure there are no problems or restrictions. Then we shall verify existing candidate solutions for MGA. I think this = is the tough one, as now we have to deal with requirements from ISPs. And = even in the most simple MANET (Alex his phone and laptop, using 3GPP, WiMAX = and Bluetooth) there are problems with selecting the MGA for sessions, as = now we have a relation between MGA and BR. I think in almost every real life = MANET, this problem occurs. In simulations or in lab environments, we can = simply disable all ingress filters and AAA. By the way, ISPs are heavily involved in MIP / NEMO based solutions. Listening to them can help us a lot. Teco. Van: Shubhranshu [mailto:shubhranshu@samsung.com]=20 Verzonden: dinsdag 20 november 2007 14:59 Aan: Teco Boot CC: autoconf@ietf.org Onderwerp: Re: [Autoconf] Random MLA uniqueness Hello Teco,=20 =A0 Please see below comments. =A0 ----- Original Message -----=20 From: "Teco Boot" =A0 > RFC4429 provides a formula for the upper limit: >=A0 Pb(n,k) <=3D 1-( [(n-k+1)/n] ^ [k-1] ) >=A0 Pb(2^115,100000) <=3D 1-( [(2^115-100000+1)/2^115] ^ [100000-1] ) > I can't calculate the outcome. Has anyone a calculator with extreme = long > real numbers? >=20 > Maybe the problem is in the random number generator. > Anyway, I think someone should work on address spoofing protection. > Pspoofing >>>> Pb. > Some of us will tell that their birthday is on the same day as someone else, > and they save on treat. >=20 > Adding this information in problem statement? =A0 If you (and others)=A0think=A0these should be added then I'd be=A0fine = too.=A0But=A0=A0 before that here are some of my thoughts. MLA is a specific solution for local addresses for MANET nodes. Do you=A0think it would be appropriate to assume at this point=A0that Autoconf will standardize MLA as its solution ? Since unless you assume that (or at least show your=20 inclination / biasness=A0towards this approach),=A0I can't = understand=A0how this would help=A0to include all these in the WG's=A0problem statement = document.=20 Now, assume that finally the Autoconf WG standardizes = this=A0as=A0solution.=20 In that case, won't it be appropriate for that particular solution = document to provide all these details ? =A0 Besides, concerns / problems=A0related to these=A0possible address = conflict=A0is well understood and written. Please refer to the ULA RFC.=20 =A0 - Shubhranshu >=20 > Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 20 09:28: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 1IuU5s-00069H-9A; Tue, 20 Nov 2007 09:28:52 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuU5q-00067W-PB for autoconf-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 09:28:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuU5q-000652-Cu for autoconf@ietf.org; Tue, 20 Nov 2007 09:28:50 -0500 Received: from mail1-relais-roc.national.inria.fr ([192.134.164.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuU5m-0003eK-TE for autoconf@ietf.org; Tue, 20 Nov 2007 09:28:50 -0500 X-IronPort-AV: E=Sophos;i="4.21,441,1188770400"; d="scan'208";a="4704654" Received: from z0213.pia.fu-berlin.de (HELO BoolfightMaN-Laptop.local) ([87.77.2.19]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Nov 2007 15:28:46 +0100 Message-ID: <4742EF1C.1030704@inria.fr> Date: Tue, 20 Nov 2007 15:28:44 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-ietf-autoconf-statement-02.txt References: <47419EBB.6010407@gmail.com> In-Reply-To: <47419EBB.6010407@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de 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, thanks for your feedback, Alexandru Petrescu a écrit : > > If would personally avoid the use of "prefix delegation" as the generic > means, because it's easily confusable with DHCPv6-PD. But your reading > may be different. If so, it would be clearer to clarify the relationship > with DHCPv6-PD. > > For example, what does this mean: >> Automatic configuration of IP addresses on MANET interfaces and prefix >> delegation to MANET routers are necessary in a number of deployment >> scenarios. > > Does it mean that some generic mechanism to assign prefixes to routers > is needed? Or does it mean that DHCPv6-PD is needed? That's why the > definitions above would benefit from clarifying. > What would you suggest we use to replace the generic terms "prefix delegation". I didn't know it was such DHCP tainted. I though it was just a generic term, at the base of Internet addressing schemes. >> Traditional solutions assume that a broadcast directly reaches every >> router or host on the subnetwork, whereas this generally is not the >> case in MANETs (see [2]). > > If you want to define 'MANETs' to be such that broadcast don't directly > reaches every router or host on the subnetwork then you have a problem > defining MANET. Please redefine MANET such link-layer broadcast reaches > all hosts and routers on that link. > I think you sould read the architecture document ;) We are not defining MANETs in the PS, we are mentioning their properties in reality, and why you get new issues due to these specific properties. > Most wireless link-layers have a very well defined broadcast property. > If in some MANET cases that broadcast property is not maintained then > the MANET should be redefined such that the broadcast property is > respected. > > For example, if in WiFi host A sees B, B sees C but C doesn't see A then > please don't configure A, B and C in the IP same subnet. Please > configure them as two different subnets one for A and B and the other > for B and C and B as a router. > >> Some routers in the MANET will typically assume multihop broadcast, >> and expect to receive through several intermediate relayings by peer >> MANET routers. > > What's the scenario and requirements for multihop broadcast? Would IP > multicast work ok instead of multihop broadcast? > >> While stateless protocols such as [5] and [3] could provide IP address >> configuration (for MANET interfaces, loopback interfaces), these >> solutions do not provide any mechanism for allocating "unique >> prefix(es)" to routers in order to enable the configuration of host >> interfaces. > > YEs, but stateful DHCP Prefix Delegation does provide a mechanism for > allocating unique prefixes to routers in order to enable configuration > of hosts interfaces. I think it makes sense to actually use reference > [18] that you inserted. Maybe use it here. > OK >> A MANET router needs to configure IP addresses and prefixes as usual, >> on its non-MANET interfaces as well as its attached hosts and >> routers, if any. > > I'm not sure I understand this statement ok. I understand MANET router > needing to configure IP addresses for itself (and we already have a > problem here because other than DHCPv6-PD and NEMO MRs other routers > don't know how to auto-configure addresses). > > Do you mean that the MANET router needs to configure addresses to the > attached hosts too? Or that the hosts need also to configure IP addresses? > > I'm afraid that saying that the router configures an address on the host > it may be very different than existing stateless and stateful > autoconfig. Because in stateless the router puts a prefix in the RA but > the host configures the address and in stateful the router may send an > address but the host configures it. > > If I think DHCPv6-PD then I can say that the text should say: > > "The MANET Router should help and assist the host to auto-configure its > (host's) address." > > Or similar, but I don't know what you really meant to say with that? Again, I suggest you take another look at the architecture document. Hosts and routers attached to the MANET router via a non-MANET interface behave like "classical IP" with usual protocols. What we are discussing is what happens on MANET interfaces, between MANET routers. > >> For example, in Fig. >> 1, the MANET router MR3 cannot communicate directly with a DHCP >> server [4] that would be available through a MANET border router, >> since the server and the MANET router are not located on the same >> logical link. While DHCP can to some extent overcome this issue in a >> static network, it is not the case in a dynamic topology, as >> explained below. >> ----- MR1...MR3 >> / . >> +-------------+ +------------+ / . >> | | p2p | MANET |/ . >> | ISP Edge | Link | Border | . >> | Router +---------+ Router |\ . >> | | | | \ . >> +-------------+ +------------+ \----- MR2 >> >> Fig. 1. Connected MANET router topology. > > I think there may be some confusions here. > > You're saying the MR3 can not communicate directly with the DHCP Server > (the "ISP Edge Router" presumably). If they're not on the same subnet > then they don't need to communicate directly. The last-hop MANET Router > (presumably the non-illustrated MR2) would play the role of a Relay and > the Relay would unicast the messaging to the DHCP Server (presumably the > ISP Edge Router). > > Then you're saying that this may work in the static case but not in a > dynamic topology. For one thing I'd like to say that there are many > MANET-like situations where the hosts and routers are stable. Rescue > scene is one of them. Are these ruled out from the AUTOCONF WG? > No this is not ruled out. But neither is the case where MANET routers move around. > Then, if we accept that the above network is dynamic (and we rule out > the class of fixed scenes) then one wonders - what moves more precisely? > Are the DHCP Server and the Border ROuter fixed entities and only the > MRs move? Can we specify this? > Potentially every entity can move relatively to another. I think this is clearly stated in many places in the draft. > Then, if we accept that only the MANET MRs move then the DHCP problem > turns into a problem of MR2 (the DHCP Relay) disappearing and maybe > another MR (another DHCP Relay) take its place. Which DHCP Relay is > active? How can the MR3 discover the Relay? Can it simply multicast a > DHCPv6 Solicit message taking advantage of the underlying well-defined > multicast behaviour? I think it can. > Once again, there is no such "underlying well-defined multicast behaviour". Read the architecture draft. Cheers Emmanuel _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 20 09:55:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuUVL-0000yB-Tx; Tue, 20 Nov 2007 09:55:11 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuUVK-0000y5-H0 for autoconf-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 09:55:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuUVK-0000xx-4e for autoconf@ietf.org; Tue, 20 Nov 2007 09:55:10 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IuUVI-0004wQ-Qz for autoconf@ietf.org; Tue, 20 Nov 2007 09:55:10 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-153.messagelabs.com!1195570507!6117377!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 2553 invoked from network); 20 Nov 2007 14:55:07 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-13.tower-153.messagelabs.com with SMTP; 20 Nov 2007 14:55:07 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id lAKEt7sd023732; Tue, 20 Nov 2007 07:55:07 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id lAKEt6KC021447; Tue, 20 Nov 2007 08:55:06 -0600 (CST) 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 lAKEt3ms021429; Tue, 20 Nov 2007 08:55:04 -0600 (CST) Message-ID: <4742F547.8090108@gmail.com> Date: Tue, 20 Nov 2007 15:55:03 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Emmanuel Baccelli Subject: Re: [Autoconf] I-D Action:draft-ietf-autoconf-statement-02.txt References: <47419EBB.6010407@gmail.com> <4742EF1C.1030704@inria.fr> In-Reply-To: <4742EF1C.1030704@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 071119-1, 19/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 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 Emmanuel, thanks for the mail. Emmanuel Baccelli wrote: > Hi Alex, > thanks for your feedback, > > Alexandru Petrescu a écrit : >> >> If would personally avoid the use of "prefix delegation" as the generic >> means, because it's easily confusable with DHCPv6-PD. But your reading >> may be different. If so, it would be clearer to clarify the relationship >> with DHCPv6-PD. >> >> For example, what does this mean: >>> Automatic configuration of IP addresses on MANET interfaces and >>> prefix delegation to MANET routers are necessary in a number of >>> deployment scenarios. >> >> Does it mean that some generic mechanism to assign prefixes to routers >> is needed? Or does it mean that DHCPv6-PD is needed? That's why the >> definitions above would benefit from clarifying. >> > > What would you suggest we use to replace the generic terms "prefix > delegation". I didn't know it was such DHCP tainted. I though it was > just a generic term, at the base of Internet addressing schemes. I was thinking maybe something like 'admninistratively assigned by a human network planner' or maybe 'statically and manually configured' depending on context. Other people may use different? >>> Traditional solutions assume that a broadcast directly reaches every >>> router or host on the subnetwork, whereas this generally is not the >>> case in MANETs (see [2]). >> >> If you want to define 'MANETs' to be such that broadcast don't directly >> reaches every router or host on the subnetwork then you have a problem >> defining MANET. Please redefine MANET such link-layer broadcast reaches >> all hosts and routers on that link. >> > > I think you sould read the architecture document ;) We are not defining > MANETs in the PS, we are mentioning their properties in reality, and why > you get new issues due to these specific properties. I've read it, commented on it in the MANET WG and didn't get anybody to share that view. >> Most wireless link-layers have a very well defined broadcast property. >> If in some MANET cases that broadcast property is not maintained then >> the MANET should be redefined such that the broadcast property is >> respected. >> >> For example, if in WiFi host A sees B, B sees C but C doesn't see A then >> please don't configure A, B and C in the IP same subnet. Please >> configure them as two different subnets one for A and B and the other >> for B and C and B as a router. >> >>> Some routers in the MANET will typically assume multihop broadcast, >>> and expect to receive through several intermediate relayings by peer >>> MANET routers. >> >> What's the scenario and requirements for multihop broadcast? Would IP >> multicast work ok instead of multihop broadcast? >> >>> While stateless protocols such as [5] and [3] could provide IP >>> address configuration (for MANET interfaces, loopback interfaces), >>> these solutions do not provide any mechanism for allocating "unique >>> prefix(es)" to routers in order to enable the configuration of host >>> interfaces. >> >> YEs, but stateful DHCP Prefix Delegation does provide a mechanism for >> allocating unique prefixes to routers in order to enable configuration >> of hosts interfaces. I think it makes sense to actually use reference >> [18] that you inserted. Maybe use it here. >> > > OK > >>> A MANET router needs to configure IP addresses and prefixes as usual, >>> on its non-MANET interfaces as well as its attached hosts and >>> routers, if any. >> >> I'm not sure I understand this statement ok. I understand MANET router >> needing to configure IP addresses for itself (and we already have a >> problem here because other than DHCPv6-PD and NEMO MRs other routers >> don't know how to auto-configure addresses). >> >> Do you mean that the MANET router needs to configure addresses to the >> attached hosts too? Or that the hosts need also to configure IP >> addresses? >> >> I'm afraid that saying that the router configures an address on the host >> it may be very different than existing stateless and stateful >> autoconfig. Because in stateless the router puts a prefix in the RA but >> the host configures the address and in stateful the router may send an >> address but the host configures it. >> >> If I think DHCPv6-PD then I can say that the text should say: >> >> "The MANET Router should help and assist the host to auto-configure its >> (host's) address." >> >> Or similar, but I don't know what you really meant to say with that? > > Again, I suggest you take another look at the architecture document. > Hosts and routers attached to the MANET router via a non-MANET interface > behave like "classical IP" with usual protocols. What we are discussing > is what happens on MANET interfaces, between MANET routers. So it's been decided that a MANET router will configure an address for the MANET host? This is what I understand when I read "A MANET router needs to configure IP addresses and prefixes as usual, on its non-MANET interfaces as well as its attached hosts and routers, if any." I thought maybe a MANET router can just deliver a prefix in the RA and the MANET host will configure its address. Or via some DAD-like mechanism. Is it already decided that the MANET router configures an address and gives it to the MANET host somehow? Sorry if I miss something. >>> For example, in Fig. >>> 1, the MANET router MR3 cannot communicate directly with a DHCP >>> server [4] that would be available through a MANET border router, >>> since the server and the MANET router are not located on the same >>> logical link. While DHCP can to some extent overcome this issue in a >>> static network, it is not the case in a dynamic topology, as >>> explained below. >>> ----- MR1...MR3 >>> / . >>> +-------------+ +------------+ / . >>> | | p2p | MANET |/ . >>> | ISP Edge | Link | Border | . >>> | Router +---------+ Router |\ . >>> | | | | \ . >>> +-------------+ +------------+ \----- MR2 >>> >>> Fig. 1. Connected MANET router topology. >> >> I think there may be some confusions here. >> >> You're saying the MR3 can not communicate directly with the DHCP Server >> (the "ISP Edge Router" presumably). If they're not on the same subnet >> then they don't need to communicate directly. The last-hop MANET Router >> (presumably the non-illustrated MR2) would play the role of a Relay and >> the Relay would unicast the messaging to the DHCP Server (presumably the >> ISP Edge Router). >> >> Then you're saying that this may work in the static case but not in a >> dynamic topology. For one thing I'd like to say that there are many >> MANET-like situations where the hosts and routers are stable. Rescue >> scene is one of them. Are these ruled out from the AUTOCONF WG? >> > > No this is not ruled out. Ok. > But neither is the case where MANET routers move around. Ok. But how do the MANET routers move around? Also, in Figure1 above the ISP Edge Router and MANET Border Router don't move? Or does the MANET Border Router move? >> Then, if we accept that the above network is dynamic (and we rule out >> the class of fixed scenes) then one wonders - what moves more precisely? >> Are the DHCP Server and the Border ROuter fixed entities and only the >> MRs move? Can we specify this? >> > > Potentially every entity can move relatively to another. I think this is > clearly stated in many places in the draft. Yes, it is. But if we don't know _how_ do they move around and _how_ do they move with respect to their wireless link layer capabilities then it is completely uncapable to be dealt with. For example, if we knew that each MR will never get out of the link-layer's wifi range, or that when it gets out of the wifi range it must auto-configure an address... Or similar things. If we just say that they 'move' then it is no indication for a problem or protocol. Routers can move and there's simply to problem to be solved. >> Then, if we accept that only the MANET MRs move then the DHCP problem >> turns into a problem of MR2 (the DHCP Relay) disappearing and maybe >> another MR (another DHCP Relay) take its place. Which DHCP Relay is >> active? How can the MR3 discover the Relay? Can it simply multicast a >> DHCPv6 Solicit message taking advantage of the underlying well-defined >> multicast behaviour? I think it can. >> > > Once again, there is no such "underlying well-defined multicast > behaviour". Read the architecture draft. I think you're right. The autoconf-manetarch does seem to take into account the underlying well-defined multicast behaviour I'm talking about: > Link-local Multicast/Broadcast Scope > On a MANET interface, a packet sent to a link-local multicast or > all-ones broadcast address reaches the MANET interfaces of > neighboring MANET routers, regardless of their configured > addresses. That is what I meant ^. In the Fig.1 scenario above the MR3 will send an IP message to network-layer multicast address which will have a link-layer header link-local multicast destination address, the MR2-Relay will IP-unicast it to the Server. I think this scheme can accommodate the Figure1 above. But if you're just saying that things will move around then it will not work - no other thing will work either, risking maybe in the worst the case that even the new protocol one is about to design for AUTOCONF WG will probably not work when routers move around. 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 Nov 20 10:03:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuUcv-0005yW-Qn; Tue, 20 Nov 2007 10:03:01 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuUcu-0005yR-Oy for autoconf-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 10:03:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuUcu-0005yD-E7 for autoconf@ietf.org; Tue, 20 Nov 2007 10:03:00 -0500 Received: from hpsmtp-eml19.kpnxchange.com ([213.75.38.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuUct-0005E7-HJ for autoconf@ietf.org; Tue, 20 Nov 2007 10:03:00 -0500 Received: from hpsmtp-eml10.kpnxchange.com ([213.75.38.110]) by hpsmtp-eml19.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 16:02:58 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml10.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 16:02:55 +0100 From: "Teco Boot" To: "'Emmanuel Baccelli'" , References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7695.1060808@gmail.com> <00b101c82848$bd7580d0$38608270$@nl> <473D9D60.6090009@gmail.com> <473DA439.9070303@inria.fr> <00d101c82860$2a3cd3a0$7eb67ae0$@nl> <473DB35E.4030406@inria.fr> <473DB3C2.6090405@telecomitalia.it> <1B345D27-0BC6-443A-80A5-2178D8CB41A2@thomasclausen.org> <00ea01c8287a$464a3a50$d2deaef0$@nl> <473DF63F.2030505@gmail.com> <012401c828ef$292cb630$7b862290$@nl> <473F3CE0.50807@gmail.com> <006a01c82a2e$f325ebb0$d971c310$@nl> <47416F4A.4020002@gmail.com> <003901c82aa6$5b92e370$12b8aa50$@nl> <4741890E.1070908@inria.fr> <005601c82ab3$c16148b0$4423da10$@nl> <4742EAB4.2070101@inria.fr> In-Reply-To: <4742EAB4.2070101@inria.fr> Subject: RE: [Autoconf] Re: Scenarios and Requirements Date: Tue, 20 Nov 2007 16:02:50 +0100 Message-ID: <00a301c82b86$6bb64ae0$4322e0a0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgrfzFrCOoRE5i2SIu9V7eEhf5ZQwAAZUkw Content-Language: nl X-OriginalArrivalTime: 20 Nov 2007 15:02:55.0576 (UTC) FILETIME=[6E461D80:01C82B86] X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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 > -----Oorspronkelijk bericht----- > Van: Emmanuel Baccelli [mailto:Emmanuel.Baccelli@inria.fr] > Verzonden: dinsdag 20 november 2007 15:10 > Aan: autoconf@ietf.org > Onderwerp: Re: [Autoconf] Re: Scenarios and Requirements >=20 > Hi Teco, >=20 > Teco Boot a =E9crit : > > > > MANET Global Address (MGA) - An IP address configured on a MANET > > interface, and valid for communications inside the MANET and > for > > communications with corresponding nodes on the Internet, via a > > Border Router. A MGA is associated with a Border Router, for > being > > topologically correct. > > > > > > Please verify definition for Global prefix. There are conditions = that > IP > > addresses are invalid for communications reaching outside the MANET. > And why > > is it reserved for MANET Routers? Why not using a range? (RFC3633 > uses > > prefixes, that could be a reason). >=20 > OK, I see what you mean. I think that we do not need to create new > terms > other than global prefix and global address. We just need to make sure > that people understand what these terms mean in the context of MANETs. Do you agree on the definition for MGA, being used for GA? >=20 > > > > I do not like the term "Internet Configuration Provider (ICP)". Why > not > > using DHCP Server? Or is it something else? Must this be a Router? > Why? Why > > can't it provide prefixes or addresses to hosts? Large > infrastructures > > typically have separated routers and address assignment servers. I > reject > > text defining that these are integrated in one device. It may be, = but > _not_ > > should be and _certainly not_ must be. > > >=20 > OK. So maybe we could talk about an "entity" instead of a "router"? > This > would be more general I agree. First, I want to know why we can't use the term DHCP server. I really = can't follow why we are not considering DHCP-PD.=20 >=20 > > On DHCP-PD, I reread the problem statement document. When all nodes > perform > > DHCP functions, as 3633 RR and DR, what are the problems? I don't > think this > > scenario is optimal, but it should work. > > Problems could be: > > - BR ingress filter, relation with routing > > - Session continuity problem when path via BR is not available > anymore > > - Running DHCP on some platforms > > - Inefficient address usage >=20 > Yes, especially you'd get into trouble if no server is reachable and > the > MANET is not "full mesh". This is the case of most standalone MANETs, > for instance. I think DHCP can perfectly being used, as long as it is reachable. If no DHCP is reachable, I assume the MANET is standalone, OK? So there = is no need for GA. When there is a DHCP reachable (single hop, using link local or MLA), it = can provide an MLA. Using such an MLA can be more efficient for transport = over PacketBB related to random MLA (see different thread for details). I think MLA can be relatively static, e.g. using long DHCP lease times. Reachability to DHCP server is needed every now and then. The question is, can this DHCP provided address also be used as GA? So = now we are back to the problem that GA is associated with a BR. Here, we = have the relation between GA and BR.=20 In MIP & NEMO, we use the term Mobile Network Prefix (MNP) and Home = Address (HoA) for a similar topic, these are globally unique (guaranteed by some mechanism), and they are associated with a HA. I'll keep using MGA for GA associated with BR. The problem is almost equivalent. Keep in mind that the real stuff runs all these protocols, not MIP or = NEMO or MANET. So there are MNP, HoA, multiple CoA (each associated with a = tunnel to HA), MLA and multiple MGA (each associated with a xxxx to BR). Don't = say this is not confusing. And I do not agree in using GA for all of = those!!!!! Teco. >=20 > Emmanuel >=20 >=20 > _______________________________________________ > 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 Nov 20 10:19: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 1IuUtE-0004hs-4x; Tue, 20 Nov 2007 10:19:52 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuUtD-0004hm-6Z for autoconf-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 10:19:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuUtC-0004hd-Ry for autoconf@ietf.org; Tue, 20 Nov 2007 10:19:50 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IuUtC-0005oB-9N for autoconf@ietf.org; Tue, 20 Nov 2007 10:19:50 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-153.messagelabs.com!1195571988!9811821!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 13240 invoked from network); 20 Nov 2007 15:19:49 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-5.tower-153.messagelabs.com with SMTP; 20 Nov 2007 15:19:49 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id lAKFJhMZ024582 for ; Tue, 20 Nov 2007 08:19:48 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id lAKFJhb6016073 for ; Tue, 20 Nov 2007 09:19:43 -0600 (CST) 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 lAKFJfCx016055 for ; Tue, 20 Nov 2007 09:19:42 -0600 (CST) Message-ID: <4742FB0D.40208@gmail.com> Date: Tue, 20 Nov 2007 16:19:41 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) 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 071119-1, 19/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Autoconf] Multicast confusion between MANET Arch and AUTOCONF Problem Statement 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 think there may be a confusion with respect to the interpretation of multicast in draft-ietf-autoconf-manetarch-07.txt vs draft-ietf-autoconf-statement-02.txt. It seems as if the manetarch accepts that link-layers have a well defined multicast behaviour whereas the problem statement doesn't. autoconf-statement: > Traditional solutions assume that a broadcast directly reaches every > router or host on the subnetwork, whereas this generally is not the > case in MANETs (see [2]). So a broadcasted message (a special case of multicast) will not reach every host on the MANET subnet. [2] autoconf-manetarch: > Link-local Multicast/Broadcast Scope On a MANET interface, a packet > sent to a link-local multicast or all-ones broadcast address reaches > the MANET interfaces of neighboring MANET routers... So it actually does. I personally think that the autoconf-manetarch definition is more inline with how I see relationships between link-layer multicast and IP multicast. Or maybe we could define 'subnet' to be a set of hosts and routers linked together by the same link-layer technology where a multicast behaviour is well defined. Or similar? What do you think? 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 Nov 20 10:40: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 1IuVDS-00065D-HC; Tue, 20 Nov 2007 10:40:46 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuVDR-000658-Rd for autoconf-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 10:40:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuVDR-00064m-Gw for autoconf@ietf.org; Tue, 20 Nov 2007 10:40:45 -0500 Received: from hpsmtp-eml19.kpnxchange.com ([213.75.38.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuVDO-0006bl-Lu for autoconf@ietf.org; Tue, 20 Nov 2007 10:40:43 -0500 Received: from hpsmtp-eml08.kpnxchange.com ([213.75.38.108]) by hpsmtp-eml19.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 16:40:41 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml08.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 16:40:27 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" , References: <4742FB0D.40208@gmail.com> In-Reply-To: <4742FB0D.40208@gmail.com> Subject: RE: [Autoconf] Multicast confusion between MANET Arch and AUTOCONF Problem Statement Date: Tue, 20 Nov 2007 16:40:22 +0100 Message-ID: <00b701c82b8b$a9a524c0$fcef6e40$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgriOIp7D/VtzBvT9uFen2G0WRmSgAAX4DA Content-Language: nl X-OriginalArrivalTime: 20 Nov 2007 15:40:27.0317 (UTC) FILETIME=[AC6A8650:01C82B8B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 I think the confusion is related with having two models, e.g. 802.11 BSS/ESS and IBSS. BSS/ESS has coordination function and the IP subnet model works quite well. IBSS is also called ad-hoc mode. With IBSS, fully mesh is not guaranteed. Here we use the MANET protocols for end-to-end connectivity. Now, the MANET protocols are evolved and can be used to connect nodes on different segments, like classical IP routing protocols. Maybe the two documents are describing the IBSS / ad-hoc mode. I agree on adding text that there is a need for ad-hoc networking for the other mode also. Just look at your desk and see the need for this;-) Teco. > -----Oorspronkelijk bericht----- > Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Verzonden: dinsdag 20 november 2007 16:20 > Aan: autoconf@ietf.org > Onderwerp: [Autoconf] Multicast confusion between MANET Arch and > AUTOCONF Problem Statement > > I think there may be a confusion with respect to the interpretation of > multicast in draft-ietf-autoconf-manetarch-07.txt vs > draft-ietf-autoconf-statement-02.txt. > > It seems as if the manetarch accepts that link-layers have a well > defined multicast behaviour whereas the problem statement doesn't. > > autoconf-statement: > > Traditional solutions assume that a broadcast directly reaches every > > router or host on the subnetwork, whereas this generally is not the > > case in MANETs (see [2]). > > So a broadcasted message (a special case of multicast) will not reach > every host on the MANET subnet. > > [2] autoconf-manetarch: > > Link-local Multicast/Broadcast Scope On a MANET interface, a packet > > sent to a link-local multicast or all-ones broadcast address reaches > > the MANET interfaces of neighboring MANET routers... > > So it actually does. > > I personally think that the autoconf-manetarch definition is more > inline > with how I see relationships between link-layer multicast and IP > multicast. > > Or maybe we could define 'subnet' to be a set of hosts and routers > linked together by the same link-layer technology where a multicast > behaviour is well defined. Or similar? > > What do you think? > > 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 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 20 10:49:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuVMB-00005S-5G; Tue, 20 Nov 2007 10:49:47 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuVMA-00005N-5a for autoconf-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 10:49:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuVM9-00005F-PP for autoconf@ietf.org; Tue, 20 Nov 2007 10:49:45 -0500 Received: from mail92.messagelabs.com ([194.106.220.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IuVM9-0006qv-6y for autoconf@ietf.org; Tue, 20 Nov 2007 10:49:45 -0500 X-VirusChecked: Checked X-Env-Sender: Ronald.intVelt@tno.nl X-Msg-Ref: server-6.tower-92.messagelabs.com!1195573743!32010517!1 X-StarScan-Version: 5.5.12.14.2; banners=tno.nl,-,- X-Originating-IP: [134.221.2.2] Received: (qmail 31439 invoked from network); 20 Nov 2007 15:49:03 -0000 Received: from zeus.tno.nl (HELO zeus.tno.nl) (134.221.2.2) by server-6.tower-92.messagelabs.com with SMTP; 20 Nov 2007 15:49:03 -0000 Received: from ms-dt01thalia.tsn.tno.nl (ms-dt01thalia.tno.nl [134.221.225.157]) by zeus.tno.nl (8.11.7p1+Sun/8.11.7) with ESMTP id lAKFn3002529 for ; Tue, 20 Nov 2007 16:49:03 +0100 (MET) 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] Multicast confusion between MANET Arch and AUTOCONFProblem Statement Date: Tue, 20 Nov 2007 16:49:02 +0100 Message-ID: <7877C5C0B5CC894AB26113CF06CF88631EA662@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <4742FB0D.40208@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Multicast confusion between MANET Arch and AUTOCONFProblem Statement thread-index: AcgriNgeSfACGnF1RfW0m3kQw6vN8gAApArg References: <4742FB0D.40208@gmail.com> From: "Velt, R. (Ronald) in 't" To: X-Spam-Score: 1.8 (+) 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=20Alex,=20 >=20-----Original=20Message----- >=20From:=20Alexandru=20Petrescu=20[mailto:alexandru.petrescu@gmail.com]=20= >=20Sent:=20dinsdag=2020=20november=202007=2016:20 >=20To:=20autoconf@ietf.org >=20Subject:=20[Autoconf]=20Multicast=20confusion=20between=20MANET=20Arch= =20 >=20and=20AUTOCONFProblem=20Statement >=20 >=20I=20think=20there=20may=20be=20a=20confusion=20with=20respect=20to=20t= he=20 >=20interpretation=20of=20multicast=20in=20 >=20draft-ietf-autoconf-manetarch-07.txt=20vs=20 >=20draft-ietf-autoconf-statement-02.txt. >=20 >=20It=20seems=20as=20if=20the=20manetarch=20accepts=20that=20link-layers=20= have=20a=20 >=20well=20defined=20multicast=20behaviour=20whereas=20the=20problem=20 >=20statement=20doesn't. >=20 >=20autoconf-statement: >=20>=20Traditional=20solutions=20assume=20that=20a=20broadcast=20directly= =20 >=20reaches=20every=20 >=20>=20router=20or=20host=20on=20the=20subnetwork,=20whereas=20this=20gen= erally=20is=20not=20the=20 >=20>=20case=20in=20MANETs=20(see=20[2]). >=20 >=20So=20a=20broadcasted=20message=20(a=20special=20case=20of=20multicast)= =20will=20 >=20not=20reach=20every=20host=20on=20the=20MANET=20subnet. "link"=20versus=20"subnetwork"=20are=20distinct=20notions,=20aren't=20they= ?=20What=20is left=20of=20a=20"subnetwork"=20in=20an=20environment=20where=20\128=20(\32= =20for=20IPv4) prefixes=20are=20configured=20on=20MANET=20interfaces?=20If=20your=20local= =20interface=20is the=20only=20one=20in=20the=20subnet,=20then=20all=20interfaces=20in=20the= =20subnet=20are trivially=20reachable=20:-)=20"Link"=20is=20something=20else... >=20 >=20[2]=20autoconf-manetarch: >=20>=20Link-local=20Multicast/Broadcast=20Scope=20On=20a=20MANET=20interf= ace,=20a=20packet=20 >=20>=20sent=20to=20a=20link-local=20multicast=20or=20all-ones=20broadcast= =20 >=20address=20reaches=20 >=20>=20the=20MANET=20interfaces=20of=20neighboring=20MANET=20routers... >=20 >=20So=20it=20actually=20does. > No,=20not=20all=20interfaces=20of=20all=20MANET=20routers.=20Just=20those=20= of=20the *neighbo(u)ring*=20MANET=20routers.=20See=20MANET=20architecture=20for=20a= =20definition of=20neighbo(u)r. =20 >=20I=20personally=20think=20that=20the=20autoconf-manetarch=20definition=20= is=20 >=20more=20inline=20with=20how=20I=20see=20relationships=20between=20link-= layer=20 >=20multicast=20and=20IP=20multicast. >=20 >=20Or=20maybe=20we=20could=20define=20'subnet'=20to=20be=20a=20set=20of=20= hosts=20and=20 >=20routers=20linked=20together=20by=20the=20same=20link-layer=20technolog= y=20 >=20where=20a=20multicast=20behaviour=20is=20well=20defined.=20=20Or=20sim= ilar? >=20 >=20What=20do=20you=20think? >=20 >=20Alex Just=20my=202=20cents, Ronald This=20e-mail=20and=20its=20contents=20are=20subject=20to=20the=20DISCLAIM= ER=20at=20http://www.tno.nl/disclaimer/email.html _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 20 10:51:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuVNl-0008GO-Cq; Tue, 20 Nov 2007 10:51:25 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuVNk-0008GJ-PT for autoconf-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 10:51:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuVNk-0008GB-Ek for autoconf@ietf.org; Tue, 20 Nov 2007 10:51:24 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IuVNk-0006tx-0M for autoconf@ietf.org; Tue, 20 Nov 2007 10:51:24 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1195573882!22703408!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 9801 invoked from network); 20 Nov 2007 15:51:22 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-7.tower-119.messagelabs.com with SMTP; 20 Nov 2007 15:51:22 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id lAKFpMWv006711; Tue, 20 Nov 2007 08:51:22 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id lAKFpLZW012093; Tue, 20 Nov 2007 09:51:21 -0600 (CST) 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 lAKFpJ8V012057; Tue, 20 Nov 2007 09:51:20 -0600 (CST) Message-ID: <47430276.5040408@gmail.com> Date: Tue, 20 Nov 2007 16:51:18 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Teco Boot Subject: Re: [Autoconf] Multicast confusion between MANET Arch and AUTOCONF Problem Statement References: <4742FB0D.40208@gmail.com> <00b701c82b8b$a9a524c0$fcef6e40$@nl> In-Reply-To: <00b701c82b8b$a9a524c0$fcef6e40$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071119-1, 19/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 Thanks Teco, sounds as what I would suppose too... but I'll wait for comments from authors see what the intended meaning was. Teco Boot wrote: > I think the confusion is related with having two models, e.g. 802.11 BSS/ESS > and IBSS. BSS/ESS has coordination function and the IP subnet model works > quite well. IBSS is also called ad-hoc mode. I think in wifi's both adhoc and infrastructure modes the link-layer's multicast behaviour is well defined. If a more-than-50meters extension of an adhoc wifi network not accompanied by the right IP subnet structuring then there's obviously a problem with the IP subnet structuring: every 50m there should be one different IP subnet and there should be routers in between the 50meters areas. > With IBSS, fully mesh is not guaranteed. Here we use the MANET protocols for > end-to-end connectivity. > > Now, the MANET protocols are evolved and can be used to connect nodes on > different segments, like classical IP routing protocols. > > Maybe the two documents are describing the IBSS / ad-hoc mode. I doubt so too, let's see from authors. 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 Nov 20 11:12:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuVhp-0005lV-3e; Tue, 20 Nov 2007 11:12:09 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuVhn-0005l8-Iz for autoconf-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 11:12:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuVhn-0005kf-0i for autoconf@ietf.org; Tue, 20 Nov 2007 11:12:07 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IuVhi-0006sG-PD for autoconf@ietf.org; Tue, 20 Nov 2007 11:12:06 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-153.messagelabs.com!1195575121!13573772!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 7839 invoked from network); 20 Nov 2007 16:12:01 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-153.messagelabs.com with SMTP; 20 Nov 2007 16:12:01 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lAKGC1hW018395; Tue, 20 Nov 2007 09:12:01 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id lAKGC0jv018996; Tue, 20 Nov 2007 10:12:00 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id lAKGBxTx018968; Tue, 20 Nov 2007 10:11:59 -0600 (CST) Message-ID: <4743074E.5060309@gmail.com> Date: Tue, 20 Nov 2007 17:11:58 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Velt, R. (Ronald) in 't" Subject: Re: [Autoconf] Multicast confusion between MANET Arch and AUTOCONFProblem Statement References: <4742FB0D.40208@gmail.com> <7877C5C0B5CC894AB26113CF06CF88631EA662@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <7877C5C0B5CC894AB26113CF06CF88631EA662@ms-dt01thalia.tsn.tno.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071119-1, 19/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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 Velt, R. (Ronald) in 't wrote: > Hi Alex, > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: dinsdag 20 november >> 2007 16:20 To: autoconf@ietf.org Subject: [Autoconf] Multicast >> confusion between MANET Arch and AUTOCONFProblem Statement >> >> I think there may be a confusion with respect to the interpretation >> of multicast in draft-ietf-autoconf-manetarch-07.txt vs >> draft-ietf-autoconf-statement-02.txt. >> >> It seems as if the manetarch accepts that link-layers have a well >> defined multicast behaviour whereas the problem statement doesn't. >> >> autoconf-statement: >>> Traditional solutions assume that a broadcast directly >> reaches every >>> router or host on the subnetwork, whereas this generally is not >>> the case in MANETs (see [2]). >> So a broadcasted message (a special case of multicast) will not >> reach every host on the MANET subnet. > > "link" versus "subnetwork" are distinct notions, aren't they? What is > left of a "subnetwork" in an environment where \128 (\32 for IPv4) > prefixes are configured on MANET interfaces? If your local interface > is the only one in the subnet, then all interfaces in the subnet are > trivially reachable :-) "Link" is something else... Right... :-) But this sounds as special cases. Maybe simple a 1-1 mapping between link and subnet would be easier. Just have a link and a subnet be the same, and a simple prefix assigned to it. And see these problems first. The MANET I'd build would surely have a prefix for a subnet on a link and /128 addresses for each entity. This should work. >> [2] autoconf-manetarch: >>> Link-local Multicast/Broadcast Scope On a MANET interface, a >>> packet sent to a link-local multicast or all-ones broadcast >> address reaches >>> the MANET interfaces of neighboring MANET routers... >> So it actually does. >> > > No, not all interfaces of all MANET routers. Just those of the > *neighbo(u)ring* MANET routers. See MANET architecture for a > definition of neighbo(u)r. Ok, manetarch: > Neighbor In the context of routing, two routers are neighbors if one > can send/receive routing protocol IP packets to the other without > passing through any intermediaries at the same layer. Ok but in the Internet Area a Neighbor is from rfc4861: > neighbors - nodes attached to the same link. This different 'Neighbor' definition is potentially another source of confusion when talking to each other. I think manetarch may mean actually that a Neighbor is an entity within a close physical distance, whereas an RFC4861 Neighbor is not necessarily close by. BEsides, the definition above is unclear because of that "at the same layer". Which layer? IP? Link? Would a link-layer device bridging messages to a remote-distance entity make this latter a Neighbor? Wouldn't it sound better like: "CloseEntity: two routers are closeentities if one can send/receive link-layer multicast messages to/from the other". If we don't clarify this it will always pop up as a confusing item when saying 'Neighbor'. Thanks, 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 Nov 20 11:28: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 1IuVy3-0004aL-MZ; Tue, 20 Nov 2007 11:28:55 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuVy2-0004XV-Dz for autoconf-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 11:28:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuVy2-0004XG-3t for autoconf@ietf.org; Tue, 20 Nov 2007 11:28:54 -0500 Received: from hpsmtp-eml18.kpnxchange.com ([213.75.38.118]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuVy0-00088X-Bq for autoconf@ietf.org; Tue, 20 Nov 2007 11:28:52 -0500 Received: from hpsmtp-eml10.kpnxchange.com ([213.75.38.110]) by hpsmtp-eml18.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 17:28:50 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml10.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 17:28:49 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" , "'Velt, R. \(Ronald\) in 't'" References: <4742FB0D.40208@gmail.com> <7877C5C0B5CC894AB26113CF06CF88631EA662@ms-dt01thalia.tsn.tno.nl> <4743074E.5060309@gmail.com> In-Reply-To: <4743074E.5060309@gmail.com> Subject: RE: [Autoconf] Multicast confusion between MANET Arch and AUTOCONFProblem Statement Date: Tue, 20 Nov 2007 17:28:45 +0100 Message-ID: <00cf01c82b92$6bd57530$43805f90$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgrkDEnw+JEQ9ykS6mUw+TuJvgWlQAAfk5w Content-Language: nl X-OriginalArrivalTime: 20 Nov 2007 16:28:50.0046 (UTC) FILETIME=[6E93D1E0:01C82B92] 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 > Wouldn't it sound better like: "CloseEntity: two routers are > closeentities if one can send/receive link-layer multicast messages > to/from the other". > > If we don't clarify this it will always pop up as a confusing item when > saying 'Neighbor'. Now you are confusing me. Neighbors on satcom link could not be that close, but can hear each other. If not, they are not neighbors. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 20 11:43: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 1IuWCB-0005pF-AK; Tue, 20 Nov 2007 11:43:31 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuWCA-0005pA-R2 for autoconf-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 11:43:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuWCA-0005p2-HS for autoconf@ietf.org; Tue, 20 Nov 2007 11:43:30 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IuWC7-0007h9-9Q for autoconf@ietf.org; Tue, 20 Nov 2007 11:43:30 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-119.messagelabs.com!1195577006!33888665!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 23227 invoked from network); 20 Nov 2007 16:43:26 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-4.tower-119.messagelabs.com with SMTP; 20 Nov 2007 16:43:26 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id lAKGhFLx013570; Tue, 20 Nov 2007 09:43:20 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id lAKGhEqw001670; Tue, 20 Nov 2007 10:43:14 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id lAKGhC34001639; Tue, 20 Nov 2007 10:43:12 -0600 (CST) Message-ID: <47430E9F.8010507@gmail.com> Date: Tue, 20 Nov 2007 17:43:11 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Teco Boot Subject: Re: [Autoconf] Multicast confusion between MANET Arch and AUTOCONFProblem Statement References: <4742FB0D.40208@gmail.com> <7877C5C0B5CC894AB26113CF06CF88631EA662@ms-dt01thalia.tsn.tno.nl> <4743074E.5060309@gmail.com> <00cf01c82b92$6bd57530$43805f90$@nl> In-Reply-To: <00cf01c82b92$6bd57530$43805f90$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071119-1, 19/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Teco Boot wrote: >> Wouldn't it sound better like: "CloseEntity: two routers are >> closeentities if one can send/receive link-layer multicast messages >> to/from the other". >> >> If we don't clarify this it will always pop up as a confusing item >> when saying 'Neighbor'. > > Now you are confusing me. Neighbors on satcom link could not be that > close, but can hear each other. Right, and that's the Internet Area ND rfc4861 definition of a Neighbor. > If not, they are not neighbors. Right, and they can't be "closeentities" because they're remote :-) How else can we define 'Neighbor' in accordance to rfc4861? How else can we define new AUTOCONF entity terms? Does SATCOM or IP-over-DVB/MPEG2 or IP-over-UDLR have a definition one could reuse? 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 Nov 20 11:49: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 1IuWIJ-0005xW-CZ; Tue, 20 Nov 2007 11:49:51 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuWIH-0005qh-Df for autoconf-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 11:49:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuWIH-0005qZ-43 for autoconf@ietf.org; Tue, 20 Nov 2007 11:49:49 -0500 Received: from hpsmtp-eml13.kpnxchange.com ([213.75.38.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuWIE-0007rV-Lx for autoconf@ietf.org; Tue, 20 Nov 2007 11:49:49 -0500 Received: from hpsmtp-eml05.kpnxchange.com ([213.75.38.105]) by hpsmtp-eml13.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 17:49:45 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml05.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Nov 2007 17:49:45 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <4742FB0D.40208@gmail.com> <7877C5C0B5CC894AB26113CF06CF88631EA662@ms-dt01thalia.tsn.tno.nl> <4743074E.5060309@gmail.com> <00cf01c82b92$6bd57530$43805f90$@nl> <47430E9F.8010507@gmail.com> In-Reply-To: <47430E9F.8010507@gmail.com> Subject: RE: [Autoconf] Multicast confusion between MANET Arch and AUTOCONFProblem Statement Date: Tue, 20 Nov 2007 17:49:40 +0100 Message-ID: <00d801c82b95$57e36160$07aa2420$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgrlHngopAImqcXRxuY7SBel6LtOgAAGE5A Content-Language: nl X-OriginalArrivalTime: 20 Nov 2007 16:49:45.0418 (UTC) FILETIME=[5AD662A0:01C82B95] X-Spam-Score: -1.0 (-) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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 > -----Oorspronkelijk bericht----- > Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Verzonden: dinsdag 20 november 2007 17:43 > Aan: Teco Boot > CC: 'Velt, R. (Ronald) in 't'; autoconf@ietf.org > Onderwerp: Re: [Autoconf] Multicast confusion between MANET Arch and > AUTOCONFProblem Statement > > Teco Boot wrote: > >> Wouldn't it sound better like: "CloseEntity: two routers are > >> closeentities if one can send/receive link-layer multicast messages > >> to/from the other". > >> > >> If we don't clarify this it will always pop up as a confusing item > >> when saying 'Neighbor'. > > > > Now you are confusing me. Neighbors on satcom link could not be that > > close, but can hear each other. > > Right, and that's the Internet Area ND rfc4861 definition of a > Neighbor. > > > If not, they are not neighbors. > > Right, and they can't be "closeentities" because they're remote :-) > > How else can we define 'Neighbor' in accordance to rfc4861? > > How else can we define new AUTOCONF entity terms? > > Does SATCOM or IP-over-DVB/MPEG2 or IP-over-UDLR have a definition one > could reuse? Let's stick on MANET and use for example NHDP definition: Symmetric link - A link where both MANET interfaces are heard by the other. 1-hop neighbor - A node X is a 1-hop neighbor of a node Y if a MANET interface of node X is heard by a MANET interface of node Y. Symmetric 1-hop neighbor - A node X is a symmetric 1-hop neighbor of a node Y if a symmetric link exists between a MANET interface on node X and a MANET interface on node Y. Symmetric 2-hop neighbor - A node X is a symmetric 2-hop neighbor of a node Y if node X is a symmetric 1-hop neighbor of a symmetric 1-hop neighbor of node Y, but is not node Y itself. 1-hop neighborhood - The 1-hop neighborhood of a node X is the set of the 1-hop neighbors of node X. Symmetric 1-hop neighborhood - The symmetric 1-hop neighborhood of a node X is the set of the symmetric 1-hop neighbors of node X. Symmetric 2-hop neighborhood - The symmetric 2-hop neighborhood of a node X is the set of the symmetric 2-hop neighbors of node X. (This may include nodes in the 1-hop neighborhood, or even in the symmetric 1-hop neighborhood, of node X.) Teco > > 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 Nov 20 12: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 1IuWp3-0003kt-MY; Tue, 20 Nov 2007 12:23:41 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuWp2-0003kY-OS for autoconf-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 12:23:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuWp2-0003kO-1V for autoconf@ietf.org; Tue, 20 Nov 2007 12:23:40 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IuWoz-0000ha-Fl for autoconf@ietf.org; Tue, 20 Nov 2007 12:23:40 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-153.messagelabs.com!1195579416!9826833!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 17474 invoked from network); 20 Nov 2007 17:23:36 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-5.tower-153.messagelabs.com with SMTP; 20 Nov 2007 17:23:36 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id lAKHNVM5021132; Tue, 20 Nov 2007 10:23:35 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id lAKHNUnl004874; Tue, 20 Nov 2007 11:23:30 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id lAKHNSts004854; Tue, 20 Nov 2007 11:23:29 -0600 (CST) Message-ID: <47431810.1010909@gmail.com> Date: Tue, 20 Nov 2007 18:23:28 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Teco Boot Subject: Re: [Autoconf] Multicast confusion between MANET Arch and AUTOCONFProblem Statement References: <4742FB0D.40208@gmail.com> <7877C5C0B5CC894AB26113CF06CF88631EA662@ms-dt01thalia.tsn.tno.nl> <4743074E.5060309@gmail.com> <00cf01c82b92$6bd57530$43805f90$@nl> <47430E9F.8010507@gmail.com> <00d801c82b95$57e36160$07aa2420$@nl> In-Reply-To: <00d801c82b95$57e36160$07aa2420$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071119-1, 19/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 Teco Boot wrote: >> -----Oorspronkelijk bericht----- >> Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> Verzonden: dinsdag 20 november 2007 17:43 >> Aan: Teco Boot >> CC: 'Velt, R. (Ronald) in 't'; autoconf@ietf.org >> Onderwerp: Re: [Autoconf] Multicast confusion between MANET Arch and >> AUTOCONFProblem Statement >> >> Teco Boot wrote: >>>> Wouldn't it sound better like: "CloseEntity: two routers are >>>> closeentities if one can send/receive link-layer multicast messages >>>> to/from the other". >>>> >>>> If we don't clarify this it will always pop up as a confusing item >>>> when saying 'Neighbor'. >>> Now you are confusing me. Neighbors on satcom link could not be that >>> close, but can hear each other. >> Right, and that's the Internet Area ND rfc4861 definition of a >> Neighbor. >> >>> If not, they are not neighbors. >> Right, and they can't be "closeentities" because they're remote :-) >> >> How else can we define 'Neighbor' in accordance to rfc4861? >> >> How else can we define new AUTOCONF entity terms? >> >> Does SATCOM or IP-over-DVB/MPEG2 or IP-over-UDLR have a definition one >> could reuse? > > Let's stick on MANET and use for example NHDP definition: > > Symmetric link - A link where both MANET interfaces are heard by the > other. > > 1-hop neighbor - A node X is a 1-hop neighbor of a node Y if a MANET > interface of node X is heard by a MANET interface of node Y. Risking to say 'neighbor' abbreviating '1-hop neighbor' and confusing that 'neighbor' with a Neighbor of RFC 4861. What does 'hearing' mean. It sounds as a radio concept. Alex > Symmetric 1-hop neighbor - A node X is a symmetric 1-hop neighbor of > a node Y if a symmetric link exists between a MANET interface on > node X and a MANET interface on node Y. > > Symmetric 2-hop neighbor - A node X is a symmetric 2-hop neighbor of > a node Y if node X is a symmetric 1-hop neighbor of a symmetric > 1-hop neighbor of node Y, but is not node Y itself. > > 1-hop neighborhood - The 1-hop neighborhood of a node X is the set > of the 1-hop neighbors of node X. > > Symmetric 1-hop neighborhood - The symmetric 1-hop neighborhood of a > node X is the set of the symmetric 1-hop neighbors of node X. > > Symmetric 2-hop neighborhood - The symmetric 2-hop neighborhood of a > node X is the set of the symmetric 2-hop neighbors of node X. > (This may include nodes in the 1-hop neighborhood, or even in the > symmetric 1-hop neighborhood, of node X.) > > Teco > >> Alex >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ > > ______________________________________________________________________ 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 Nov 20 12:31: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 1IuWwe-0008J6-5m; Tue, 20 Nov 2007 12:31:32 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuWwc-0008CP-JM for autoconf-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 12:31:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuWwb-0008CG-UF for autoconf@ietf.org; Tue, 20 Nov 2007 12:31:29 -0500 Received: from hpsmtp-eml12.kpnxchange.com ([213.75.38.112]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuWwb-0001o5-FX for autoconf@ietf.org; Tue, 20 Nov 2007 12:31:29 -0500 Received: from hpsmtp-eml05.kpnxchange.com ([213.75.38.105]) by hpsmtp-eml12.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 18:31:28 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml05.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Nov 2007 18:31:28 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <4742FB0D.40208@gmail.com> <7877C5C0B5CC894AB26113CF06CF88631EA662@ms-dt01thalia.tsn.tno.nl> <4743074E.5060309@gmail.com> <00cf01c82b92$6bd57530$43805f90$@nl> <47430E9F.8010507@gmail.com> <00d801c82b95$57e36160$07aa2420$@nl> <47431810.1010909@gmail.com> In-Reply-To: <47431810.1010909@gmail.com> Subject: RE: [Autoconf] Multicast confusion between MANET Arch and AUTOCONFProblem Statement Date: Tue, 20 Nov 2007 18:31:23 +0100 Message-ID: <00e701c82b9b$2babbe20$83033a60$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgrmhbyvSEpPav4SzyQvdlCNohkpAAAG4xg Content-Language: nl X-OriginalArrivalTime: 20 Nov 2007 17:31:28.0339 (UTC) FILETIME=[2EB1D230:01C82B9B] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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 > > > > Let's stick on MANET and use for example NHDP definition: > > > > Symmetric link - A link where both MANET interfaces are heard by > the > > other. > > > > 1-hop neighbor - A node X is a 1-hop neighbor of a node Y if a > MANET > > interface of node X is heard by a MANET interface of node Y. > > Risking to say 'neighbor' abbreviating '1-hop neighbor' and confusing > that 'neighbor' with a Neighbor of RFC 4861. Yes, I would say "neighbor" is "Symmetric 1-hop neighbor" unless otherwise specified. In many cases, it is just a generic term for some node that is somewhat reachable. > > What does 'hearing' mean. It sounds as a radio concept. Not by definition. I would imagine IP over acoustics. Then we can hear how chatty a protocol is! Teco. > > Alex > > > Symmetric 1-hop neighbor - A node X is a symmetric 1-hop neighbor > of > > a node Y if a symmetric link exists between a MANET interface > on > > node X and a MANET interface on node Y. > > > > Symmetric 2-hop neighbor - A node X is a symmetric 2-hop neighbor > of > > a node Y if node X is a symmetric 1-hop neighbor of a symmetric > > 1-hop neighbor of node Y, but is not node Y itself. > > > > 1-hop neighborhood - The 1-hop neighborhood of a node X is the > set > > of the 1-hop neighbors of node X. > > > > Symmetric 1-hop neighborhood - The symmetric 1-hop neighborhood > of a > > node X is the set of the symmetric 1-hop neighbors of node X. > > > > Symmetric 2-hop neighborhood - The symmetric 2-hop neighborhood > of a > > node X is the set of the symmetric 2-hop neighbors of node X. > > (This may include nodes in the 1-hop neighborhood, or even in > the > > symmetric 1-hop neighborhood, of node X.) > > > > Teco > > > >> Alex > >> > >> > ______________________________________________________________________ > >> This email has been scanned by the MessageLabs Email Security > System. > >> For more information please visit http://www.messagelabs.com/email > >> > ______________________________________________________________________ > > > > > > > ______________________________________________________________________ > 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 Nov 20 12:39:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuX4G-0007jZ-9x; Tue, 20 Nov 2007 12:39:24 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuX4E-0007jR-JP for autoconf-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 12:39:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuX4D-0007jJ-Qn for autoconf@ietf.org; Tue, 20 Nov 2007 12:39:21 -0500 Received: from mail4-relais-sop.national.inria.fr ([192.134.164.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuX4A-0001Jl-9M for autoconf@ietf.org; Tue, 20 Nov 2007 12:39:21 -0500 X-IronPort-AV: E=Sophos;i="4.21,442,1188770400"; d="scan'208";a="19506904" Received: from z0213.pia.fu-berlin.de (HELO BoolfightMaN-Laptop.local) ([87.77.2.19]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Nov 2007 18:39:16 +0100 Message-ID: <47431BC0.7000204@inria.fr> Date: Tue, 20 Nov 2007 18:39:12 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org Subject: Re: [Autoconf] Re: Scenarios and Requirements References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7695.1060808@gmail.com> <00b101c82848$bd7580d0$38608270$@nl> <473D9D60.6090009@gmail.com> <473DA439.9070303@inria.fr> <00d101c82860$2a3cd3a0$7eb67ae0$@nl> <473DB35E.4030406@inria.fr> <473DB3C2.6090405@telecomitalia.it> <1B345D27-0BC6-443A-80A5-2178D8CB41A2@thomasclausen.org> <00ea01c8287a$464a3a50$d2deaef0$@nl> <473DF63F.2030505@gmail.com> <012401c828ef$292cb630$7b862290$@nl> <473F3CE0.50807@gmail.com> <006a01c82a2e$f325ebb0$d971c310$@nl> <47416F4A.4020002@gmail.com> <003901c82aa6$5b92e370$12b8aa50$@nl> <4741890E.1070908@inria.fr> <005601c82ab3$c16148b0$4423da10$@nl> <4742EAB4.2070101@inria.fr> <00a301c82b86$6bb64ae0$4322e0a0$@nl> In-Reply-To: <00a301c82b86$6bb64ae0$4322e0a0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 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, Teco Boot a écrit : >> -----Oorspronkelijk bericht----- >> Van: Emmanuel Baccelli [mailto:Emmanuel.Baccelli@inria.fr] >> Verzonden: dinsdag 20 november 2007 15:10 >> Aan: autoconf@ietf.org >> Onderwerp: Re: [Autoconf] Re: Scenarios and Requirements >> >> Hi Teco, >> >> Teco Boot a écrit : >>> MANET Global Address (MGA) - An IP address configured on a MANET >>> interface, and valid for communications inside the MANET and >> for >>> communications with corresponding nodes on the Internet, via a >>> Border Router. A MGA is associated with a Border Router, for >> being >>> topologically correct. >>> >>> >>> Please verify definition for Global prefix. There are conditions that >> IP >>> addresses are invalid for communications reaching outside the MANET. >> And why >>> is it reserved for MANET Routers? Why not using a range? (RFC3633 >> uses >>> prefixes, that could be a reason). >> OK, I see what you mean. I think that we do not need to create new >> terms >> other than global prefix and global address. We just need to make sure >> that people understand what these terms mean in the context of MANETs. > > Do you agree on the definition for MGA, being used for GA? > Yes. I think it is good. I am working as we speak on -03. The definition for global address will be this one. >>> I do not like the term "Internet Configuration Provider (ICP)". Why >> not >>> using DHCP Server? Or is it something else? Must this be a Router? >> Why? Why >>> can't it provide prefixes or addresses to hosts? Large >> infrastructures >>> typically have separated routers and address assignment servers. I >> reject >>> text defining that these are integrated in one device. It may be, but >> _not_ >>> should be and _certainly not_ must be. >>> >> OK. So maybe we could talk about an "entity" instead of a "router"? >> This >> would be more general I agree. > > First, I want to know why we can't use the term DHCP server. I really can't > follow why we are not considering DHCP-PD. > DHCP is a solution. We are not talking a solution in particular. We are talking about a fundamental problem, so the vocabulary has to be generic, and precise at the same time. An ICP can be a DHCP server, no problem. Soo you agree with the following definition? Internet Configuration Provider (ICP) - An entity that can provide routers requesting configuration with addresses or prefixes derived from a global prefix. > >>> On DHCP-PD, I reread the problem statement document. When all nodes >> perform >>> DHCP functions, as 3633 RR and DR, what are the problems? I don't >> think this >>> scenario is optimal, but it should work. >>> Problems could be: >>> - BR ingress filter, relation with routing >>> - Session continuity problem when path via BR is not available >> anymore >>> - Running DHCP on some platforms >>> - Inefficient address usage >> Yes, especially you'd get into trouble if no server is reachable and >> the >> MANET is not "full mesh". This is the case of most standalone MANETs, >> for instance. > > I think DHCP can perfectly being used, as long as it is reachable. > If no DHCP is reachable, I assume the MANET is standalone, OK? So there is > no need for GA. > When there is a DHCP reachable (single hop, using link local or MLA), it can > provide an MLA. Using such an MLA can be more efficient for transport over > PacketBB related to random MLA (see different thread for details). > I think MLA can be relatively static, e.g. using long DHCP lease times. > Reachability to DHCP server is needed every now and then. > I agree that DHCP is a strong candidate for part of the solution to the connected MANET case. But it is only a candidate, and it does not solve everything. Do you agree on this? _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 20 12:42:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuX6z-0002tf-JF; Tue, 20 Nov 2007 12:42:13 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuX6y-0002rq-Pp for autoconf-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 12:42:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuX6y-0002rc-FP for autoconf@ietf.org; Tue, 20 Nov 2007 12:42:12 -0500 Received: from mail4-relais-sop.national.inria.fr ([192.134.164.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuX6u-0001OI-Pw for autoconf@ietf.org; Tue, 20 Nov 2007 12:42:12 -0500 X-IronPort-AV: E=Sophos;i="4.21,442,1188770400"; d="scan'208";a="19507028" Received: from z0213.pia.fu-berlin.de (HELO BoolfightMaN-Laptop.local) ([87.77.2.19]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Nov 2007 18:42:07 +0100 Message-ID: <47431C6F.5090809@inria.fr> Date: Tue, 20 Nov 2007 18:42:07 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org Subject: Re: [Autoconf] Multicast confusion between MANET Arch and AUTOCONFProblem Statement References: <4742FB0D.40208@gmail.com> <7877C5C0B5CC894AB26113CF06CF88631EA662@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <7877C5C0B5CC894AB26113CF06CF88631EA662@ms-dt01thalia.tsn.tno.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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 agree with Ronald. If there was already an easy definition of what is a "MANET link" then the architecture document would not be needed, would it? Emmanuel Velt, R. (Ronald) in 't a écrit : > Hi Alex, > >> -----Original Message----- >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> Sent: dinsdag 20 november 2007 16:20 >> To: autoconf@ietf.org >> Subject: [Autoconf] Multicast confusion between MANET Arch >> and AUTOCONFProblem Statement >> >> I think there may be a confusion with respect to the >> interpretation of multicast in >> draft-ietf-autoconf-manetarch-07.txt vs >> draft-ietf-autoconf-statement-02.txt. >> >> It seems as if the manetarch accepts that link-layers have a >> well defined multicast behaviour whereas the problem >> statement doesn't. >> >> autoconf-statement: >>> Traditional solutions assume that a broadcast directly >> reaches every >>> router or host on the subnetwork, whereas this generally is not the >>> case in MANETs (see [2]). >> So a broadcasted message (a special case of multicast) will >> not reach every host on the MANET subnet. > > "link" versus "subnetwork" are distinct notions, aren't they? What is > left of a "subnetwork" in an environment where \128 (\32 for IPv4) > prefixes are configured on MANET interfaces? If your local interface is > the only one in the subnet, then all interfaces in the subnet are > trivially reachable :-) "Link" is something else... > >> [2] autoconf-manetarch: >>> Link-local Multicast/Broadcast Scope On a MANET interface, a packet >>> sent to a link-local multicast or all-ones broadcast >> address reaches >>> the MANET interfaces of neighboring MANET routers... >> So it actually does. >> > > No, not all interfaces of all MANET routers. Just those of the > *neighbo(u)ring* MANET routers. See MANET architecture for a definition > of neighbo(u)r. > >> I personally think that the autoconf-manetarch definition is >> more inline with how I see relationships between link-layer >> multicast and IP multicast. >> >> Or maybe we could define 'subnet' to be a set of hosts and >> routers linked together by the same link-layer technology >> where a multicast behaviour is well defined. Or similar? >> >> What do you think? >> >> Alex > > Just my 2 cents, > Ronald > > > This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://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 Nov 20 12: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 1IuXNM-0006AE-Bu; Tue, 20 Nov 2007 12:59:08 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuXNL-0006A6-Eu for autoconf-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 12:59:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuXNL-00069y-2e for autoconf@ietf.org; Tue, 20 Nov 2007 12:59:07 -0500 Received: from mail4-relais-sop.national.inria.fr ([192.134.164.105]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuXNJ-0002vC-Ns for autoconf@ietf.org; Tue, 20 Nov 2007 12:59:06 -0500 X-IronPort-AV: E=Sophos;i="4.21,442,1188770400"; d="scan'208";a="19507706" Received: from z0213.pia.fu-berlin.de (HELO BoolfightMaN-Laptop.local) ([87.77.2.19]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Nov 2007 18:59:03 +0100 Message-ID: <47432066.5010304@inria.fr> Date: Tue, 20 Nov 2007 18:59:02 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-ietf-autoconf-statement-02.txt References: <47419EBB.6010407@gmail.com> <4742EF1C.1030704@inria.fr> <4742F547.8090108@gmail.com> In-Reply-To: <4742F547.8090108@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 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 Alexandru Petrescu a écrit : >> >> What would you suggest we use to replace the generic terms "prefix >> delegation". I didn't know it was such DHCP tainted. I though it was >> just a generic term, at the base of Internet addressing schemes. > > I was thinking maybe something like 'admninistratively assigned by a > human network planner' or maybe 'statically and manually configured' > depending on context. Other people may use different? > Well, it may be done automatically too right? So I'm afraid what you propose is not approriate... >>>> Traditional solutions assume that a broadcast directly reaches every >>>> router or host on the subnetwork, whereas this generally is not the >>>> case in MANETs (see [2]). >>> >>> If you want to define 'MANETs' to be such that broadcast don't directly >>> reaches every router or host on the subnetwork then you have a problem >>> defining MANET. Please redefine MANET such link-layer broadcast reaches >>> all hosts and routers on that link. >>> >> >> I think you sould read the architecture document ;) We are not >> defining MANETs in the PS, we are mentioning their properties in >> reality, and why you get new issues due to these specific properties. > > I've read it, commented on it in the MANET WG and didn't get anybody to > share that view. > Sorry that you feel so alone ;) >>> Most wireless link-layers have a very well defined broadcast property. >>> If in some MANET cases that broadcast property is not maintained then >>> the MANET should be redefined such that the broadcast property is >>> respected. >>> >>> For example, if in WiFi host A sees B, B sees C but C doesn't see A then >>> please don't configure A, B and C in the IP same subnet. Please >>> configure them as two different subnets one for A and B and the other >>> for B and C and B as a router. >>> >>>> Some routers in the MANET will typically assume multihop broadcast, >>>> and expect to receive through several intermediate relayings by peer >>>> MANET routers. >>> >>> What's the scenario and requirements for multihop broadcast? Would IP >>> multicast work ok instead of multihop broadcast? >>> >>>> While stateless protocols such as [5] and [3] could provide IP >>>> address configuration (for MANET interfaces, loopback interfaces), >>>> these solutions do not provide any mechanism for allocating "unique >>>> prefix(es)" to routers in order to enable the configuration of host >>>> interfaces. >>> >>> YEs, but stateful DHCP Prefix Delegation does provide a mechanism for >>> allocating unique prefixes to routers in order to enable configuration >>> of hosts interfaces. I think it makes sense to actually use reference >>> [18] that you inserted. Maybe use it here. >>> >> >> OK >> >>>> A MANET router needs to configure IP addresses and prefixes as usual, >>>> on its non-MANET interfaces as well as its attached hosts and >>>> routers, if any. >>> >>> I'm not sure I understand this statement ok. I understand MANET router >>> needing to configure IP addresses for itself (and we already have a >>> problem here because other than DHCPv6-PD and NEMO MRs other routers >>> don't know how to auto-configure addresses). >>> >>> Do you mean that the MANET router needs to configure addresses to the >>> attached hosts too? Or that the hosts need also to configure IP >>> addresses? >>> >>> I'm afraid that saying that the router configures an address on the host >>> it may be very different than existing stateless and stateful >>> autoconfig. Because in stateless the router puts a prefix in the RA but >>> the host configures the address and in stateful the router may send an >>> address but the host configures it. >>> >>> If I think DHCPv6-PD then I can say that the text should say: >>> >>> "The MANET Router should help and assist the host to auto-configure its >>> (host's) address." >>> >>> Or similar, but I don't know what you really meant to say with that? >> >> Again, I suggest you take another look at the architecture document. >> Hosts and routers attached to the MANET router via a non-MANET >> interface behave like "classical IP" with usual protocols. What we are >> discussing is what happens on MANET interfaces, between MANET routers. > > So it's been decided that a MANET router will configure an address for > the MANET host? This is what I understand when I read "A MANET router > needs to configure IP addresses and prefixes as usual, on its non-MANET > interfaces as well as its attached hosts and routers, if any." > > I thought maybe a MANET router can just deliver a prefix in the RA and > the MANET host will configure its address. Or via some DAD-like mechanism. > > Is it already decided that the MANET router configures an address and > gives it to the MANET host somehow? Sorry if I miss something. > For now there is no such thing as a "MANET host" defined anywhere... Look again. >>>> For example, in Fig. >>>> 1, the MANET router MR3 cannot communicate directly with a DHCP >>>> server [4] that would be available through a MANET border router, >>>> since the server and the MANET router are not located on the same >>>> logical link. While DHCP can to some extent overcome this issue >>>> in a >>>> static network, it is not the case in a dynamic topology, as >>>> explained below. >>>> ----- MR1...MR3 >>>> / . >>>> +-------------+ +------------+ / . >>>> | | p2p | MANET |/ . >>>> | ISP Edge | Link | Border | . >>>> | Router +---------+ Router |\ . >>>> | | | | \ . >>>> +-------------+ +------------+ \----- MR2 >>>> >>>> Fig. 1. Connected MANET router topology. >>> >>> I think there may be some confusions here. >>> >>> You're saying the MR3 can not communicate directly with the DHCP Server >>> (the "ISP Edge Router" presumably). If they're not on the same subnet >>> then they don't need to communicate directly. The last-hop MANET Router >>> (presumably the non-illustrated MR2) would play the role of a Relay and >>> the Relay would unicast the messaging to the DHCP Server (presumably the >>> ISP Edge Router). >>> >>> Then you're saying that this may work in the static case but not in a >>> dynamic topology. For one thing I'd like to say that there are many >>> MANET-like situations where the hosts and routers are stable. Rescue >>> scene is one of them. Are these ruled out from the AUTOCONF WG? >>> >> >> No this is not ruled out. > > Ok. > >> But neither is the case where MANET routers move around. > > Ok. But how do the MANET routers move around? > > Also, in Figure1 above the ISP Edge Router and MANET Border Router don't > move? Or does the MANET Border Router move? Can you tell me the difference from the point of view of the MANET? There is relative mobility, that's enough to have some unsolved issues here. But it is true that in general MANET routers are more likely to be mobile than ISP edge routers ;) > >>> Then, if we accept that the above network is dynamic (and we rule out >>> the class of fixed scenes) then one wonders - what moves more precisely? >>> Are the DHCP Server and the Border ROuter fixed entities and only the >>> MRs move? Can we specify this? >>> >> >> Potentially every entity can move relatively to another. I think this >> is clearly stated in many places in the draft. > > Yes, it is. But if we don't know _how_ do they move around and _how_ do > they move with respect to their wireless link layer capabilities then it > is completely uncapable to be dealt with. > > For example, if we knew that each MR will never get out of the > link-layer's wifi range, or that when it gets out of the wifi range it > must auto-configure an address... Or similar things. > > If we just say that they 'move' then it is no indication for a problem > or protocol. Routers can move and there's simply to problem to be solved. > As to how they move, well I don't know. Do you want to describe every mobility model? Good luck ;) But one thing is sure: they are not assumed to be limited by the same wifi range. >>> Then, if we accept that only the MANET MRs move then the DHCP problem >>> turns into a problem of MR2 (the DHCP Relay) disappearing and maybe >>> another MR (another DHCP Relay) take its place. Which DHCP Relay is >>> active? How can the MR3 discover the Relay? Can it simply multicast a >>> DHCPv6 Solicit message taking advantage of the underlying well-defined >>> multicast behaviour? I think it can. >>> >> >> Once again, there is no such "underlying well-defined multicast >> behaviour". Read the architecture draft. > > I think you're right. The autoconf-manetarch does seem to take into > account the underlying well-defined multicast behaviour I'm talking about: >> Link-local Multicast/Broadcast Scope >> On a MANET interface, a packet sent to a link-local multicast or >> all-ones broadcast address reaches the MANET interfaces of >> neighboring MANET routers, regardless of their configured >> addresses. > > That is what I meant ^. In the Fig.1 scenario above the MR3 will send > an IP message to network-layer multicast address which will have a > link-layer header link-local multicast destination address, the > MR2-Relay will IP-unicast it to the Server. I think there is a misunderstanding here. Maybe there will be at some point a protocol that will relay some messages in order to reach the server. But there is none for now. So you do not have the behaviour that you describe, and among other things this is why there is a problem! Emmanuel _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 20 13:00:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuXOF-0006jV-D1; Tue, 20 Nov 2007 13:00:03 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuXOD-0006h3-Kf for autoconf-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 13:00:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuXOD-0006gf-3I for autoconf@ietf.org; Tue, 20 Nov 2007 13:00:01 -0500 Received: from rn-out-0910.google.com ([64.233.170.184] helo=rn-out-0102.google.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuXOA-000213-No for autoconf@ietf.org; Tue, 20 Nov 2007 13:00:01 -0500 Received: by rn-out-0102.google.com with SMTP id a46so1413169rne for ; Tue, 20 Nov 2007 09:59:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=n+07QOrqaPesooTit0929dbSGLPIwdCOwI0GpuwX6co=; b=ET6ayuz/s0PFSxlLD+kWAERsZPpZ8co+TtNwcP6pn6YXqxoY2GjompOHxV5dcvCam9LjbBJAWUCLStccZqkTl8Zgw+4yW0Vg8jP9dXSBUteSor+2Sts0IMQ74v189AkLuRuB4QTCZXa84ikYIdr75jEZzbT5IBfBqFpG4CQHoeo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=o5FHaa/rtOmsUzawf+U+5eUnJmi5OiTTbga6tpdrLZqmdMKn+9u/5s5I3AgQG7guSobrkaX9Am2yJNyz9pevnlJpkT14mtQedPtbBEDvJGtS7DicH4mypHWgF5RdFN7K9V8VqwapO4hQUXwHzCQkEs40SLe9AcjQ7V9roz5kolk= Received: by 10.143.160.1 with SMTP id m1mr1686229wfo.1195581596817; Tue, 20 Nov 2007 09:59:56 -0800 (PST) Received: by 10.142.88.17 with HTTP; Tue, 20 Nov 2007 09:59:56 -0800 (PST) Message-ID: Date: Wed, 21 Nov 2007 02:59:56 +0900 From: Shubhranshu To: teco@inf-net.nl Subject: Re: [Autoconf] Random MLA uniqueness In-Reply-To: <00a201c82b80$aca4aa20$05edfe60$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <02a101c82b7d$8ca3cab0$7dd16c6b@sisodomain.com> <00a201c82b80$aca4aa20$05edfe60$@nl> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 below: On 11/20/07, Teco Boot wrote: > If this is all well understood and written down, and there are no problems, > what the hell are we doing in Autoconf? > 1) shall we use random ULA on each node? > 2) shall we use random subnet_ID? > 3) How can we optimize for efficiency, e.g. compact transport using > PacketBB? > > For 3), I can imagine someone comes up with a listen mode for capturing an > existing Global_ID and Subnet_ID, so the MLA transfer over PacketBB needs > only 64 bits (a win of 7 octets per address). > (oeps, I did;-) > > I think this is the first an easiest part of Autoconf. I suggest moving > forward with this approach as quickly as possible. hmm... now I am confused, "moving forward with this approach" ? Weren't you talking about including some text for the PS I-D ? But now seems you are proposing some solution !! Why do you think I pointed to the ULA RFC, because I was talking about ULA (and not MLA, which COULD be a specific MANET solution and exact format and other details are yet to be specified, may be). If you want to discuss solution specific details, using MLA, etc then it would be better to start separate thread, preferably with a pointer to the specific I-D or some relevant text. Coming back to your original thoughts (refer to your first mail with the same subject), as I said I'd be fine with including those or similar text but first we need to clarify those questions that I sent you before. - Shubhranshu > > As a second phase, we can work on looking at existing DHCP-PD solutions, > also for MLA usage. This would further optimize transport over PacketBB. I > am sure we can use this, I am not sure there are no problems or > restrictions. > > Then we shall verify existing candidate solutions for MGA. I think this is > the tough one, as now we have to deal with requirements from ISPs. And even > in the most simple MANET (Alex his phone and laptop, using 3GPP, WiMAX and > Bluetooth) there are problems with selecting the MGA for sessions, as now we > have a relation between MGA and BR. I think in almost every real life MANET, > this problem occurs. In simulations or in lab environments, we can simply > disable all ingress filters and AAA. > > By the way, ISPs are heavily involved in MIP / NEMO based solutions. > Listening to them can help us a lot. > > Teco. > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 20 13:22:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuXjg-0006EB-Qf; Tue, 20 Nov 2007 13:22:12 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuXje-0006Cy-3Z for autoconf-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 13:22:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuXjd-0006AO-9D for autoconf@ietf.org; Tue, 20 Nov 2007 13:22:09 -0500 Received: from hpsmtp-eml15.kpnxchange.com ([213.75.38.115]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuXja-000341-2x for autoconf@ietf.org; Tue, 20 Nov 2007 13:22:09 -0500 Received: from hpsmtp-eml05.kpnxchange.com ([213.75.38.105]) by hpsmtp-eml15.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 19:22:05 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml05.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Nov 2007 19:22:04 +0100 From: "Teco Boot" To: "'Shubhranshu'" References: <02a101c82b7d$8ca3cab0$7dd16c6b@sisodomain.com> <00a201c82b80$aca4aa20$05edfe60$@nl> In-Reply-To: Subject: RE: [Autoconf] Random MLA uniqueness Date: Tue, 20 Nov 2007 19:21:56 +0100 Message-ID: <00eb01c82ba2$3d817610$b8846230$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgrnypTJ+gyghPcRRultm8rQMIB9gAAbexA Content-Language: nl X-OriginalArrivalTime: 20 Nov 2007 18:22:05.0199 (UTC) FILETIME=[40CDE1F0:01C82BA2] X-Spam-Score: -1.0 (-) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 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 Inline. > -----Oorspronkelijk bericht----- > Van: Shubhranshu [mailto:shubranshu@gmail.com] > Verzonden: dinsdag 20 november 2007 19:00 > Aan: teco@inf-net.nl > CC: autoconf@ietf.org > Onderwerp: Re: [Autoconf] Random MLA uniqueness > > Please see below: > > On 11/20/07, Teco Boot wrote: > > If this is all well understood and written down, and there are no > problems, > > what the hell are we doing in Autoconf? > > 1) shall we use random ULA on each node? > > 2) shall we use random subnet_ID? > > 3) How can we optimize for efficiency, e.g. compact transport using > > PacketBB? > > > > For 3), I can imagine someone comes up with a listen mode for > capturing an > > existing Global_ID and Subnet_ID, so the MLA transfer over PacketBB > needs > > only 64 bits (a win of 7 octets per address). > > (oeps, I did;-) > > > > I think this is the first an easiest part of Autoconf. I suggest > moving > > forward with this approach as quickly as possible. > > > hmm... now I am confused, "moving forward with this approach" ? > Weren't you talking about including some text for the PS I-D ? But now > seems you are proposing some solution !! Why do you think I pointed to > the ULA RFC, because I was talking about ULA (and not MLA, which COULD > be a specific MANET solution and exact format and other details are > yet to be specified, may be). I do not prefer "making problems". I want the PS to describe in detail what the current problems are, based on what is needed (charter) and what available mechanisms can be used. We don't need (and are not even allowed by the charter) do define something similar than what we currently have. After adding text in PS on using ULA for MLA, and we agreed on this text, and only after that, I suggest moving forward with it. Of course we could wait for describing problems with using DHCP and on Internet connectivity, but I do not see a reason for waiting. I you prefer to wait, I am fine. I wonder what and others think on this, including co-chair and AD. > > If you want to discuss solution specific details, using MLA, etc then > it would be better to start separate thread, preferably with a pointer > to the specific I-D or some relevant text. I have written one line on this in my Autoconf solution. I am willing to help writing a WG document for it. Teco. > > Coming back to your original thoughts (refer to your first mail with > the same subject), as I said I'd be fine with including those or > similar text but first we need to clarify those questions that I sent > you before. > > - Shubhranshu > > > > > > As a second phase, we can work on looking at existing DHCP-PD > solutions, > > also for MLA usage. This would further optimize transport over > PacketBB. I > > am sure we can use this, I am not sure there are no problems or > > restrictions. > > > > Then we shall verify existing candidate solutions for MGA. I think > this is > > the tough one, as now we have to deal with requirements from ISPs. > And even > > in the most simple MANET (Alex his phone and laptop, using 3GPP, > WiMAX and > > Bluetooth) there are problems with selecting the MGA for sessions, as > now we > > have a relation between MGA and BR. I think in almost every real life > MANET, > > this problem occurs. In simulations or in lab environments, we can > simply > > disable all ingress filters and AAA. > > > > By the way, ISPs are heavily involved in MIP / NEMO based solutions. > > Listening to them can help us a lot. > > > > Teco. > > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 20 13:40:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuY11-0001aX-1e; Tue, 20 Nov 2007 13:40:08 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuY0z-0001XN-MY for autoconf-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 13:40:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuY0z-0001X9-Bd for autoconf@ietf.org; Tue, 20 Nov 2007 13:40:05 -0500 Received: from hpsmtp-eml19.kpnxchange.com ([213.75.38.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuY0y-0005Jn-3Z for autoconf@ietf.org; Tue, 20 Nov 2007 13:40:04 -0500 Received: from hpsmtp-eml09.kpnxchange.com ([213.75.38.109]) by hpsmtp-eml19.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 19:40:02 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml09.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 19:40:02 +0100 From: "Teco Boot" To: "'Emmanuel Baccelli'" , References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7695.1060808@gmail.com> <00b101c82848$bd7580d0$38608270$@nl> <473D9D60.6090009@gmail.com> <473DA439.9070303@inria.fr> <00d101c82860$2a3cd3a0$7eb67ae0$@nl> <473DB35E.4030406@inria.fr> <473DB3C2.6090405@telecomitalia.it> <1B345D27-0BC6-443A-80A5-2178D8CB41A2@thomasclausen.org> <00ea01c8287a$464a3a50$d2deaef0$@nl> <473DF63F.2030505@gmail.com> <012401c828ef$292cb630$7b862290$@nl> <473F3CE0.50807@gmail.com> <006a01c82a2e$f325ebb0$d971c310$@nl> <47416F4A.4020002@gmail.com> <003901c82aa6$5b92e370$12b8aa50$@nl> <4741890E.1070908@inria.fr> <005601c82ab3$c16148b0$4423da10$@nl> <4742EAB4.2070101@inria.fr> <00a301c82b86$6bb64ae0$4322e0a0$@nl> <47431BC0.7000204@inria.fr> In-Reply-To: <47431BC0.7000204@inria.fr> Subject: RE: [Autoconf] Re: Scenarios and Requirements Date: Tue, 20 Nov 2007 19:39:55 +0100 Message-ID: <00ed01c82ba4$bfed9af0$3fc8d0d0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgrnF554lFo0OxOSlGElUlm7cE3YgABnMag Content-Language: nl X-OriginalArrivalTime: 20 Nov 2007 18:40:02.0498 (UTC) FILETIME=[C2ECAA20:01C82BA4] X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 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 Hi Emmanuel, Inline. > -----Oorspronkelijk bericht----- > Van: Emmanuel Baccelli [mailto:Emmanuel.Baccelli@inria.fr] > Verzonden: dinsdag 20 november 2007 18:39 > Aan: autoconf@ietf.org > Onderwerp: Re: [Autoconf] Re: Scenarios and Requirements >=20 > Hi Teco, >=20 > Teco Boot a =E9crit : > >> -----Oorspronkelijk bericht----- > >> Van: Emmanuel Baccelli [mailto:Emmanuel.Baccelli@inria.fr] > >> Verzonden: dinsdag 20 november 2007 15:10 > >> Aan: autoconf@ietf.org > >> Onderwerp: Re: [Autoconf] Re: Scenarios and Requirements > >> > >> Hi Teco, > >> > >> Teco Boot a =E9crit : > >>> MANET Global Address (MGA) - An IP address configured on a > MANET > >>> interface, and valid for communications inside the MANET and > >> for > >>> communications with corresponding nodes on the Internet, via > a > >>> Border Router. A MGA is associated with a Border Router, for > >> being > >>> topologically correct. > >>> > >>> > >>> Please verify definition for Global prefix. There are conditions > that > >> IP > >>> addresses are invalid for communications reaching outside the > MANET. > >> And why > >>> is it reserved for MANET Routers? Why not using a range? (RFC3633 > >> uses > >>> prefixes, that could be a reason). > >> OK, I see what you mean. I think that we do not need to create new > >> terms > >> other than global prefix and global address. We just need to make > sure > >> that people understand what these terms mean in the context of > MANETs. > > > > Do you agree on the definition for MGA, being used for GA? > > >=20 > Yes. I think it is good. I am working as we speak on -03. The > definition > for global address will be this one. Only the M prepended ;-) >=20 > >>> I do not like the term "Internet Configuration Provider (ICP)". = Why > >> not > >>> using DHCP Server? Or is it something else? Must this be a Router? > >> Why? Why > >>> can't it provide prefixes or addresses to hosts? Large > >> infrastructures > >>> typically have separated routers and address assignment servers. I > >> reject > >>> text defining that these are integrated in one device. It may be, > but > >> _not_ > >>> should be and _certainly not_ must be. > >>> > >> OK. So maybe we could talk about an "entity" instead of a "router"? > >> This > >> would be more general I agree. > > > > First, I want to know why we can't use the term DHCP server. I = really > can't > > follow why we are not considering DHCP-PD. > > >=20 > DHCP is a solution. We are not talking a solution in particular. We = are > talking about a fundamental problem, so the vocabulary has to be > generic, and precise at the same time. An ICP can be a DHCP server, no > problem. Soo you agree with the following definition? >=20 > Internet Configuration Provider (ICP) - An entity that can provide > routers requesting configuration with addresses or prefixes > derived from a global prefix. >=20 Yes and no. We have lots of fundamental problems. Let's discuss the length of an = IPv8 address;-) If you want to use a generic term for a DHCP server, or AAA server = providing addresses, OK. But would use this term a lot, as problems cannot be defined, as we do = not know what it is. For example, using AAA has very different problems than DHCP. I prefer being very accurate when describing problems. It helps the discussions. On the definition, please change routers into nodes. And find other text for the reply. If a node request configuration, the reply is configuration and not limited to addresses or prefixes. Or use Address and Prefix Providing Entity. Both AAA and DHCP provides more = than that. And for very good reasons. > > > >>> On DHCP-PD, I reread the problem statement document. When all = nodes > >> perform > >>> DHCP functions, as 3633 RR and DR, what are the problems? I don't > >> think this > >>> scenario is optimal, but it should work. > >>> Problems could be: > >>> - BR ingress filter, relation with routing > >>> - Session continuity problem when path via BR is not available > >> anymore > >>> - Running DHCP on some platforms > >>> - Inefficient address usage > >> Yes, especially you'd get into trouble if no server is reachable = and > >> the > >> MANET is not "full mesh". This is the case of most standalone > MANETs, > >> for instance. > > > > I think DHCP can perfectly being used, as long as it is reachable. > > If no DHCP is reachable, I assume the MANET is standalone, OK? So > there is > > no need for GA. > > When there is a DHCP reachable (single hop, using link local or = MLA), > it can > > provide an MLA. Using such an MLA can be more efficient for = transport > over > > PacketBB related to random MLA (see different thread for details). > > I think MLA can be relatively static, e.g. using long DHCP lease > times. > > Reachability to DHCP server is needed every now and then. > > >=20 > I agree that DHCP is a strong candidate for part of the solution to = the > connected MANET case. But it is only a candidate, and it does not = solve > everything. Do you agree on this? Yes, please add this in the PS document, that DHCP is indeed a = candidate. And when there is no problem, we could use it starting today and we can = stop Autoconf. I expect problems, our job is writing them down first and then solve, = after selecting one out of the candidates. I think this is our job. Maybe add AAA, e.g. radius? I expect some problems, but it has good = aspects also. I think ISP prefer secured access and AAA is invented for it. Teco. >=20 >=20 >=20 > _______________________________________________ > 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 Nov 20 13:54:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuYEd-0003Ni-US; Tue, 20 Nov 2007 13:54:11 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuYEc-0003NW-KN for autoconf-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 13:54:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuYEc-0003N4-9S for autoconf@ietf.org; Tue, 20 Nov 2007 13:54:10 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IuYEb-0005k0-IG for autoconf@ietf.org; Tue, 20 Nov 2007 13:54:09 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-3.tower-153.messagelabs.com!1195584848!9735818!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 30858 invoked from network); 20 Nov 2007 18:54:08 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-153.messagelabs.com with SMTP; 20 Nov 2007 18:54:08 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lAKIs8H9005710; Tue, 20 Nov 2007 11:54:08 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id lAKIs7Xa008996; Tue, 20 Nov 2007 12:54:07 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.89]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id lAKIs6ga008981; Tue, 20 Nov 2007 12:54:06 -0600 (CST) Message-ID: <47432D4D.9000106@gmail.com> Date: Tue, 20 Nov 2007 19:54:05 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Teco Boot Subject: Re: [Autoconf] Multicast confusion between MANET Arch and AUTOCONFProblem Statement References: <4742FB0D.40208@gmail.com> <7877C5C0B5CC894AB26113CF06CF88631EA662@ms-dt01thalia.tsn.tno.nl> <4743074E.5060309@gmail.com> <00cf01c82b92$6bd57530$43805f90$@nl> <47430E9F.8010507@gmail.com> <00d801c82b95$57e36160$07aa2420$@nl> <47431810.1010909@gmail.com> <00e701c82b9b$2babbe20$83033a60$@nl> In-Reply-To: <00e701c82b9b$2babbe20$83033a60$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071119-1, 19/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected 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 Teco Boot wrote: >>> Let's stick on MANET and use for example NHDP definition: >>> >>> Symmetric link - A link where both MANET interfaces are heard by >>> >>> >> the >>> other. >>> >>> 1-hop neighbor - A node X is a 1-hop neighbor of a node Y if a >> MANET >>> interface of node X is heard by a MANET interface of node Y. >> Risking to say 'neighbor' abbreviating '1-hop neighbor' and >> confusing that 'neighbor' with a Neighbor of RFC 4861. > > Yes, I would say "neighbor" is "Symmetric 1-hop neighbor" unless > otherwise specified. In many cases, it is just a generic term for > some node that is somewhat reachable. That is your opinion and I respect it. My opinion is that a Neighbor is something that runs ND. And whenever I'll say that your Symmetric 1-hop neighbor multicasts a RS or receives a multicast RA you'll say this autoconfig doesn't work in MANET - _because_ a MANET Neighbor is different :-) This is a strong sign to me that I can't understand and be understood in this space. >> What does 'hearing' mean. It sounds as a radio concept. > > Not by definition. I would imagine IP over acoustics. Then we can > hear how chatty a protocol is! Acoustics? Hehe :-) Somebody interested in wireless high quality audio will not run IP over it, not even a MAC - not these days. (compare the audio output by a 5GHz MAC-free wireless headphone to that of a bluetooth MAC-based audio profile headphones). Electronics need to develop more to create a need for MAC and for IP over acoustics :-) 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 Nov 20 14:12:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuYW2-0002Mi-If; Tue, 20 Nov 2007 14:12:10 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuYW0-0002MI-FG for autoconf-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 14:12:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuYVz-0002M2-Oy for autoconf@ietf.org; Tue, 20 Nov 2007 14:12:07 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IuYVw-00057a-1W for autoconf@ietf.org; Tue, 20 Nov 2007 14:12:07 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-128.messagelabs.com!1195585922!22216953!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 24128 invoked from network); 20 Nov 2007 19:12:02 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-128.messagelabs.com with SMTP; 20 Nov 2007 19:12:02 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lAKJBuiT010435; Tue, 20 Nov 2007 12:11:56 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id lAKJBuGp020812; Tue, 20 Nov 2007 13:11:56 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.89]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id lAKJBssb020789; Tue, 20 Nov 2007 13:11:55 -0600 (CST) Message-ID: <47433179.1080705@gmail.com> Date: Tue, 20 Nov 2007 20:11:53 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Emmanuel Baccelli Subject: Re: [Autoconf] Multicast confusion between MANET Arch and AUTOCONF Problem Statement References: <4742FB0D.40208@gmail.com> <7877C5C0B5CC894AB26113CF06CF88631EA662@ms-dt01thalia.tsn.tno.nl> <47431C6F.5090809@inria.fr> In-Reply-To: <47431C6F.5090809@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 071119-1, 19/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) 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 Emmanuel Baccelli wrote: > I agree with Ronald. If there was already an easy definition of what > is a "MANET link" then the architecture document would not be needed, > would it? I agree with Ronald too that more special mappings between subnets and links can be made: two subnets on one link, or two links on one subnet. But I would like the description of the link we're dealing with to be more precisely described. We can't simply say that we deal with all types of wireless and wired links. That's way too generic. Saying a link is asymmetric (X reaches Y, Y reaches Z but Z doesn't reach X) without saying at _what_ layer is it asymmetric: IP or MAC? I suppose you mean WiFi MAC adhoc mode being asymmetric (3 laptops with wifi cards in adhoc mode placed linearly at 50m between each). That is a problem for the link-layer, which can be solved by using a 802.1d bridge on the Y node. If we want to solve that problem at IP layer then the first thought is to make a subnet between X and Y and another one between Y and Z. I think this is a good IP solution. But obviously if one makes an IP datagram repeater on Y we obviously get a link-layer structuring problem with too many packets in the air and no multicast structure. I'm trying to say there are simple solutions to that asymmetric reachability problem that only involve good simple address planning, not any new protocol. But if we don't have good agreed definitions then it all turns round and round. Sorry, I can't seem to make myself clear... Alex > Emmanuel > > Velt, R. (Ronald) in 't a écrit : >> Hi Alex, >>> -----Original Message----- From: Alexandru Petrescu >>> [mailto:alexandru.petrescu@gmail.com] Sent: dinsdag 20 november >>> 2007 16:20 To: autoconf@ietf.org Subject: [Autoconf] Multicast >>> confusion between MANET Arch and AUTOCONFProblem Statement >>> >>> I think there may be a confusion with respect to the >>> interpretation of multicast in >>> draft-ietf-autoconf-manetarch-07.txt vs >>> draft-ietf-autoconf-statement-02.txt. >>> >>> It seems as if the manetarch accepts that link-layers have a well >>> defined multicast behaviour whereas the problem statement >>> doesn't. >>> >>> autoconf-statement: >>>> Traditional solutions assume that a broadcast directly >>> reaches every >>>> router or host on the subnetwork, whereas this generally is not >>>> the case in MANETs (see [2]). >>> So a broadcasted message (a special case of multicast) will not >>> reach every host on the MANET subnet. >> >> "link" versus "subnetwork" are distinct notions, aren't they? What >> is left of a "subnetwork" in an environment where \128 (\32 for >> IPv4) prefixes are configured on MANET interfaces? If your local >> interface is the only one in the subnet, then all interfaces in the >> subnet are trivially reachable :-) "Link" is something else... >> >>> [2] autoconf-manetarch: >>>> Link-local Multicast/Broadcast Scope On a MANET interface, a >>>> packet sent to a link-local multicast or all-ones broadcast >>> address reaches >>>> the MANET interfaces of neighboring MANET routers... >>> So it actually does. >>> >> >> No, not all interfaces of all MANET routers. Just those of the >> *neighbo(u)ring* MANET routers. See MANET architecture for a >> definition of neighbo(u)r. >> >>> I personally think that the autoconf-manetarch definition is more >>> inline with how I see relationships between link-layer multicast >>> and IP multicast. >>> >>> Or maybe we could define 'subnet' to be a set of hosts and >>> routers linked together by the same link-layer technology where a >>> multicast behaviour is well defined. Or similar? >>> >>> What do you think? >>> >>> Alex >> >> Just my 2 cents, Ronald >> >> >> This e-mail and its contents are subject to the DISCLAIMER at >> http://www.tno.nl/disclaimer/email.html >> >> >> _______________________________________________ Autoconf mailing >> list Autoconf@ietf.org >> https://www1.ietf.org/mailman/listinfo/autoconf >> >> > > > _______________________________________________ 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 Nov 20 14:18:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuYbs-0001Wj-8p; Tue, 20 Nov 2007 14:18:12 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuYbq-0001PE-Rg for autoconf-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 14:18:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuYbq-0001MZ-BJ for autoconf@ietf.org; Tue, 20 Nov 2007 14:18:10 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IuYbh-0005Ve-H1 for autoconf@ietf.org; Tue, 20 Nov 2007 14:18:10 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-153.messagelabs.com!1195586280!9840743!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 32713 invoked from network); 20 Nov 2007 19:18:00 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-153.messagelabs.com with SMTP; 20 Nov 2007 19:18:00 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lAKJI0Kf012189; Tue, 20 Nov 2007 12:18:00 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id lAKJHx80025262; Tue, 20 Nov 2007 13:17:59 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.89]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id lAKJHwdE025250; Tue, 20 Nov 2007 13:17:58 -0600 (CST) Message-ID: <474332E5.2050707@gmail.com> Date: Tue, 20 Nov 2007 20:17:57 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Emmanuel Baccelli Subject: Re: [Autoconf] Re: Scenarios and Requirements References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7695.1060808@gmail.com> <00b101c82848$bd7580d0$38608270$@nl> <473D9D60.6090009@gmail.com> <473DA439.9070303@inria.fr> <00d101c82860$2a3cd3a0$7eb67ae0$@nl> <473DB35E.4030406@inria.fr> <473DB3C2.6090405@telecomitalia.it> <1B345D27-0BC6-443A-80A5-2178D8CB41A2@thomasclausen.org> <00ea01c8287a$464a3a50$d2deaef0$@nl> <473DF63F.2030505@gmail.com> <012401c828ef$292cb630$7b862290$@nl> <473F3CE0.50807@gmail.com> <006a01c82a2e$f325ebb0$d971c310$@nl> <47416F4A.4020002@gmail.com> <003901c82aa6$5b92e370$12b8aa50$@nl> <4741890E.1070908@inria.fr> <005601c82ab3$c16148b0$4423da10$@nl> <4742EAB4.2070101@inria.fr> <00a301c82b86$6bb64ae0$4322e0a0$@nl> <47431BC0.7000204@inria.fr> In-Reply-To: <47431BC0.7000204@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 071119-1, 19/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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 Teco, > > Teco Boot a écrit : >>> -----Oorspronkelijk bericht----- Van: Emmanuel Baccelli >>> [mailto:Emmanuel.Baccelli@inria.fr] Verzonden: dinsdag 20 >>> november 2007 15:10 Aan: autoconf@ietf.org Onderwerp: Re: >>> [Autoconf] Re: Scenarios and Requirements >>> >>> Hi Teco, >>> >>> Teco Boot a écrit : >>>> MANET Global Address (MGA) - An IP address configured on a >>>> MANET interface, and valid for communications inside the MANET >>>> and >>> for >>>> communications with corresponding nodes on the Internet, via a >>>> Border Router. A MGA is associated with a Border Router, for >>> being >>>> topologically correct. >>>> >>>> >>>> Please verify definition for Global prefix. There are >>>> conditions that >>> IP >>>> addresses are invalid for communications reaching outside the >>>> MANET. >>> And why >>>> is it reserved for MANET Routers? Why not using a range? >>>> (RFC3633 >>> uses >>>> prefixes, that could be a reason). >>> OK, I see what you mean. I think that we do not need to create >>> new terms other than global prefix and global address. We just >>> need to make sure that people understand what these terms mean in >>> the context of MANETs. >> >> Do you agree on the definition for MGA, being used for GA? >> > > Yes. I think it is good. I am working as we speak on -03. The > definition for global address will be this one. > >>>> I do not like the term "Internet Configuration Provider (ICP)". >>>> Why >>> not >>>> using DHCP Server? Or is it something else? Must this be a >>>> Router? >>> Why? Why >>>> can't it provide prefixes or addresses to hosts? Large >>> infrastructures >>>> typically have separated routers and address assignment >>>> servers. I >>> reject >>>> text defining that these are integrated in one device. It may >>>> be, but >>> _not_ >>>> should be and _certainly not_ must be. >>>> >>> OK. So maybe we could talk about an "entity" instead of a >>> "router"? This would be more general I agree. >> >> First, I want to know why we can't use the term DHCP server. I >> really can't follow why we are not considering DHCP-PD. > > DHCP is a solution. We are not talking a solution in particular. We > are talking about a fundamental problem, so the vocabulary has to be > generic, and precise at the same time. Sorry, I don't see any fundamental problems. I don't think we can solve any problem by stating from the start it's 'fundamental'. I will not work on any fundamental problem. > An ICP can be a DHCP server, no problem. Soo you agree with the > following definition? > > Internet Configuration Provider (ICP) - An entity that can provide > routers requesting configuration with addresses or prefixes derived > from a global prefix. I'd agree if you added "typically a DHCP Server". >>>> On DHCP-PD, I reread the problem statement document. When all >>>> nodes >>> perform >>>> DHCP functions, as 3633 RR and DR, what are the problems? I >>>> don't >>> think this >>>> scenario is optimal, but it should work. Problems could be: - >>>> BR ingress filter, relation with routing - Session continuity >>>> problem when path via BR is not available >>> anymore >>>> - Running DHCP on some platforms - Inefficient address usage >>> Yes, especially you'd get into trouble if no server is reachable >>> and the MANET is not "full mesh". This is the case of most >>> standalone MANETs, for instance. >> >> I think DHCP can perfectly being used, as long as it is reachable. >> If no DHCP is reachable, I assume the MANET is standalone, OK? So >> there is no need for GA. When there is a DHCP reachable (single >> hop, using link local or MLA), it can provide an MLA. Using such an >> MLA can be more efficient for transport over PacketBB related to >> random MLA (see different thread for details). I think MLA can be >> relatively static, e.g. using long DHCP lease times. Reachability >> to DHCP server is needed every now and then. >> > > I agree that DHCP is a strong candidate for part of the solution to > the connected MANET case. But it is only a candidate, and it does not > solve everything. Do you agree on this? It is a good candidate. It may solve many scenarios. I haven't seen a scenario where it wouldn't work, and where stateless autoconf wouldn't work, but I'm interested to learn it. 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 Nov 20 14:19:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuYdE-0007or-2d; Tue, 20 Nov 2007 14:19:36 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuYdD-0007og-Kf for autoconf-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 14:19:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuYdD-0007oQ-A9 for autoconf@ietf.org; Tue, 20 Nov 2007 14:19:35 -0500 Received: from hpsmtp-eml17.kpnxchange.com ([213.75.38.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuYdA-0005iA-1n for autoconf@ietf.org; Tue, 20 Nov 2007 14:19:35 -0500 Received: from hpsmtp-eml03.kpnxchange.com ([213.75.38.103]) by hpsmtp-eml17.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 20:19:31 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml03.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 20:19:30 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <4742FB0D.40208@gmail.com> <7877C5C0B5CC894AB26113CF06CF88631EA662@ms-dt01thalia.tsn.tno.nl> <4743074E.5060309@gmail.com> <00cf01c82b92$6bd57530$43805f90$@nl> <47430E9F.8010507@gmail.com> <00d801c82b95$57e36160$07aa2420$@nl> <47431810.1010909@gmail.com> <00e701c82b9b$2babbe20$83033a60$@nl> <47432D4D.9000106@gmail.com> In-Reply-To: <47432D4D.9000106@gmail.com> Subject: RE: [Autoconf] Multicast confusion between MANET Arch and AUTOCONFProblem Statement Date: Tue, 20 Nov 2007 20:19:24 +0100 Message-ID: <00ef01c82baa$436471b0$ca2d5510$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgrpryrlvjMgGXPTV6AY/UdO7+3SwAAIcpw Content-Language: nl X-OriginalArrivalTime: 20 Nov 2007 19:19:30.0972 (UTC) FILETIME=[46A51DC0:01C82BAA] X-Spam-Score: -1.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 Hi Alex, I think we agree on that the current PS is focused on "classical MANET". And it misses another ad-hoc network type, e.g. using ad-hoc multihop connectivity to the Internet. But don't say the term Neighbor is not clearly defined in a "classical MANET" context. I am with you on the fact that the term Neighbor is well defined in NDP context also. This shall be included as the other type of ad-hoc network is described. Maybe we need consensus in Autoconf working on this type of network first. Teco. > -----Oorspronkelijk bericht----- > Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Verzonden: dinsdag 20 november 2007 19:54 > Aan: Teco Boot > CC: autoconf@ietf.org > Onderwerp: Re: [Autoconf] Multicast confusion between MANET Arch and > AUTOCONFProblem Statement > > Teco Boot wrote: > >>> Let's stick on MANET and use for example NHDP definition: > >>> > >>> Symmetric link - A link where both MANET interfaces are heard by > >>> > >>> > >> the > >>> other. > >>> > >>> 1-hop neighbor - A node X is a 1-hop neighbor of a node Y if a > >> MANET > >>> interface of node X is heard by a MANET interface of node Y. > >> Risking to say 'neighbor' abbreviating '1-hop neighbor' and > >> confusing that 'neighbor' with a Neighbor of RFC 4861. > > > > Yes, I would say "neighbor" is "Symmetric 1-hop neighbor" unless > > otherwise specified. In many cases, it is just a generic term for > > some node that is somewhat reachable. > > That is your opinion and I respect it. > > My opinion is that a Neighbor is something that runs ND. And whenever > I'll say that your Symmetric 1-hop neighbor multicasts a RS or receives > a multicast RA you'll say this autoconfig doesn't work in MANET - > _because_ a MANET Neighbor is different :-) > > This is a strong sign to me that I can't understand and be understood > in > this space. > > >> What does 'hearing' mean. It sounds as a radio concept. > > > > Not by definition. I would imagine IP over acoustics. Then we can > > hear how chatty a protocol is! > > Acoustics? Hehe :-) > > Somebody interested in wireless high quality audio will not run IP over > it, not even a MAC - not these days. (compare the audio output by a > 5GHz > MAC-free wireless headphone to that of a bluetooth MAC-based audio > profile headphones). Electronics need to develop more to create a need > for MAC and for IP over acoustics :-) > > 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 Nov 20 14:34:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuYrn-0000uN-US; Tue, 20 Nov 2007 14:34:39 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuYrl-0000jj-QZ for autoconf-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 14:34:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuYrl-0000fi-Ap for autoconf@ietf.org; Tue, 20 Nov 2007 14:34:37 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IuYri-0006K1-7I for autoconf@ietf.org; Tue, 20 Nov 2007 14:34:37 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-119.messagelabs.com!1195587273!36251391!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 5200 invoked from network); 20 Nov 2007 19:34:33 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-14.tower-119.messagelabs.com with SMTP; 20 Nov 2007 19:34:33 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id lAKJYW0t026369; Tue, 20 Nov 2007 12:34:33 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id lAKJYWNm004531; Tue, 20 Nov 2007 13:34:32 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.89]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id lAKJYTR0004493; Tue, 20 Nov 2007 13:34:30 -0600 (CST) Message-ID: <474336C4.2040309@gmail.com> Date: Tue, 20 Nov 2007 20:34:28 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Emmanuel Baccelli Subject: Re: [Autoconf] I-D Action:draft-ietf-autoconf-statement-02.txt References: <47419EBB.6010407@gmail.com> <4742EF1C.1030704@inria.fr> <4742F547.8090108@gmail.com> <47432066.5010304@inria.fr> In-Reply-To: <47432066.5010304@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 071119-1, 19/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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: > Alexandru Petrescu a écrit : >>> >>> What would you suggest we use to replace the generic terms >>> "prefix delegation". I didn't know it was such DHCP tainted. I >>> though it was just a generic term, at the base of Internet >>> addressing schemes. >> >> I was thinking maybe something like 'admninistratively assigned by >> a human network planner' or maybe 'statically and manually >> configured' depending on context. Other people may use different? >> > Well, it may be done automatically too right? So I'm afraid what you > propose is not approriate... I don't think there's no means to automatically administratively assign prefixes to a machine remotely (other than DHCPv6-PD and some use of Router Renumbering). If you think there's a method for automatically administratively assigning of prefixes please say so, thanks, I don't know what is intended. [large snip] >>>>> For example, in Fig. >>>>> 1, the MANET router MR3 cannot communicate directly with a DHCP >>>>> server [4] that would be available through a MANET border router, >>>>> since the server and the MANET router are not located on the same >>>>> logical link. While DHCP can to some extent overcome this issue >>>>> in a >>>>> static network, it is not the case in a dynamic topology, as >>>>> explained below. >>>>> ----- MR1...MR3 >>>>> / . >>>>> +-------------+ +------------+ / . >>>>> | | p2p | MANET |/ . >>>>> | ISP Edge | Link | Border | . >>>>> | Router +---------+ Router |\ . >>>>> | | | | \ . >>>>> +-------------+ +------------+ \----- MR2 >>>>> >>>>> Fig. 1. Connected MANET router topology. >>>> >> I think you're right. The autoconf-manetarch does seem to take >> into account the underlying well-defined multicast behaviour I'm >> talking about: >>> Link-local Multicast/Broadcast Scope On a MANET interface, a >>> packet sent to a link-local multicast or all-ones broadcast >>> address reaches the MANET interfaces of neighboring MANET >>> routers, regardless of their configured addresses. >> >> That is what I meant ^. In the Fig.1 scenario above the MR3 will >> send an IP message to network-layer multicast address which will >> have a link-layer header link-local multicast destination address, >> the MR2-Relay will IP-unicast it to the Server. > > I think there is a misunderstanding here. Maybe there will be at some > point a protocol that will relay some messages in order to reach the > server. But there is none for now. So you do not have the behaviour > that you describe, and among other things this is why there is a > problem! Emmanuel, already a DHCP Relay (a new MR2 between MR1 and MR3 in the figure above) relays messages as I described in the paragraph above - it's DHCP terminology and implementation. Can we agree on this. If you want I can make a separate thread. IF we run this and find some problems with DHCP because something moves somehow then I'm all years. 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 Nov 20 14:39: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 1IuYwN-0002Y9-S9; Tue, 20 Nov 2007 14:39:23 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuYwL-0002WL-Pc for autoconf-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 14:39:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuYwL-0002Vb-Db for autoconf@ietf.org; Tue, 20 Nov 2007 14:39:21 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IuYwK-0007se-So for autoconf@ietf.org; Tue, 20 Nov 2007 14:39:21 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1195587559!22798400!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 17763 invoked from network); 20 Nov 2007 19:39:19 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-119.messagelabs.com with SMTP; 20 Nov 2007 19:39:19 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lAKJdDgn018657; Tue, 20 Nov 2007 12:39:19 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id lAKJdDLJ020861; Tue, 20 Nov 2007 13:39:13 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.89]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id lAKJdBlP020848; Tue, 20 Nov 2007 13:39:12 -0600 (CST) Message-ID: <474337DE.9070107@gmail.com> Date: Tue, 20 Nov 2007 20:39:10 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Teco Boot Subject: Re: [Autoconf] Multicast confusion between MANET Arch and AUTOCONFProblem Statement References: <4742FB0D.40208@gmail.com> <7877C5C0B5CC894AB26113CF06CF88631EA662@ms-dt01thalia.tsn.tno.nl> <4743074E.5060309@gmail.com> <00cf01c82b92$6bd57530$43805f90$@nl> <47430E9F.8010507@gmail.com> <00d801c82b95$57e36160$07aa2420$@nl> <47431810.1010909@gmail.com> <00e701c82b9b$2babbe20$83033a60$@nl> <47432D4D.9000106@gmail.com> <00ef01c82baa$436471b0$ca2d5510$@nl> In-Reply-To: <00ef01c82baa$436471b0$ca2d5510$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071119-1, 19/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected 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 Teco Boot wrote: > Hi Alex, > > I think we agree on that the current PS is focused on "classical MANET". And > it misses another ad-hoc network type, e.g. using ad-hoc multihop > connectivity to the Internet. > But don't say the term Neighbor is not clearly defined in a "classical > MANET" context. > > I am with you on the fact that the term Neighbor is well defined in NDP > context also. > This shall be included as the other type of ad-hoc network is described. > Maybe we need consensus in Autoconf working on this type of network first. I completely disagree with you on this topic. I think we should look for consensus in the WG. My preferred question is whether people agree that the Neighbor runs Neighbor Discovery. Other questions can be formulated. Alex > > Teco. > > >> -----Oorspronkelijk bericht----- >> Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> Verzonden: dinsdag 20 november 2007 19:54 >> Aan: Teco Boot >> CC: autoconf@ietf.org >> Onderwerp: Re: [Autoconf] Multicast confusion between MANET Arch and >> AUTOCONFProblem Statement >> >> Teco Boot wrote: >>>>> Let's stick on MANET and use for example NHDP definition: >>>>> >>>>> Symmetric link - A link where both MANET interfaces are heard by >>>>> >>>>> >>>> the >>>>> other. >>>>> >>>>> 1-hop neighbor - A node X is a 1-hop neighbor of a node Y if a >>>> MANET >>>>> interface of node X is heard by a MANET interface of node Y. >>>> Risking to say 'neighbor' abbreviating '1-hop neighbor' and >>>> confusing that 'neighbor' with a Neighbor of RFC 4861. >>> Yes, I would say "neighbor" is "Symmetric 1-hop neighbor" unless >>> otherwise specified. In many cases, it is just a generic term for >>> some node that is somewhat reachable. >> That is your opinion and I respect it. >> >> My opinion is that a Neighbor is something that runs ND. And whenever >> I'll say that your Symmetric 1-hop neighbor multicasts a RS or receives >> a multicast RA you'll say this autoconfig doesn't work in MANET - >> _because_ a MANET Neighbor is different :-) >> >> This is a strong sign to me that I can't understand and be understood >> in >> this space. >> >>>> What does 'hearing' mean. It sounds as a radio concept. >>> Not by definition. I would imagine IP over acoustics. Then we can >>> hear how chatty a protocol is! >> Acoustics? Hehe :-) >> >> Somebody interested in wireless high quality audio will not run IP over >> it, not even a MAC - not these days. (compare the audio output by a >> 5GHz >> MAC-free wireless headphone to that of a bluetooth MAC-based audio >> profile headphones). Electronics need to develop more to create a need >> for MAC and for IP over acoustics :-) >> >> Alex >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ > > ______________________________________________________________________ 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 Nov 20 14:42: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 1IuYzV-00057O-Dy; Tue, 20 Nov 2007 14:42:37 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuYzU-00057I-FM for autoconf-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 14:42:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuYzU-00057A-5m for autoconf@ietf.org; Tue, 20 Nov 2007 14:42:36 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IuYzO-0006ao-Rt for autoconf@ietf.org; Tue, 20 Nov 2007 14:42:36 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-119.messagelabs.com!1195587750!21623755!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 20813 invoked from network); 20 Nov 2007 19:42:30 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-119.messagelabs.com with SMTP; 20 Nov 2007 19:42:30 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lAKJgT8H019479; Tue, 20 Nov 2007 12:42:29 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id lAKJgT3A010430; Tue, 20 Nov 2007 13:42:29 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.89]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id lAKJgRxr010394; Tue, 20 Nov 2007 13:42:28 -0600 (CST) Message-ID: <474338A3.4080706@gmail.com> Date: Tue, 20 Nov 2007 20:42:27 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Emmanuel Baccelli Subject: Re: [Autoconf] I-D Action:draft-ietf-autoconf-statement-02.txt References: <47419EBB.6010407@gmail.com> <4742EF1C.1030704@inria.fr> <4742F547.8090108@gmail.com> <47432066.5010304@inria.fr> <474336C4.2040309@gmail.com> In-Reply-To: <474336C4.2040309@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 071119-1, 19/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 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 Alexandru Petrescu wrote: > Emmanuel Baccelli wrote: > >> Alexandru Petrescu a écrit : >>>> >>>> What would you suggest we use to replace the generic terms "prefix >>>> delegation". I didn't know it was such DHCP tainted. I though it was >>>> just a generic term, at the base of Internet addressing schemes. >>> >>> I was thinking maybe something like 'admninistratively assigned by a >>> human network planner' or maybe 'statically and manually configured' >>> depending on context. Other people may use different? >>> >> Well, it may be done automatically too right? So I'm afraid what you >> propose is not approriate... > > I don't think there's no means to automatically administratively assign --------------------- ^strike 'no', I meant 'any'. > prefixes to a machine remotely (other than DHCPv6-PD and some use of > Router Renumbering). > > If you think there's a method for automatically administratively > assigning of prefixes please say so, thanks, I don't know what is intended. Do you think there's any means to automatically administratively assign prefixes? Alex > > [large snip] > > >>>>> For example, in Fig. > >>>>> 1, the MANET router MR3 cannot communicate directly with a DHCP > >>>>> server [4] that would be available through a MANET border router, > >>>>> since the server and the MANET router are not located on the same > >>>>> logical link. While DHCP can to some extent overcome this issue > >>>>> in a > >>>>> static network, it is not the case in a dynamic topology, as > >>>>> explained below. > >>>>> ----- MR1...MR3 > >>>>> / . > >>>>> +-------------+ +------------+ / . > >>>>> | | p2p | MANET |/ . > >>>>> | ISP Edge | Link | Border | . > >>>>> | Router +---------+ Router |\ . > >>>>> | | | | \ . > >>>>> +-------------+ +------------+ \----- MR2 > >>>>> > >>>>> Fig. 1. Connected MANET router topology. > >>>> >>> I think you're right. The autoconf-manetarch does seem to take into >>> account the underlying well-defined multicast behaviour I'm talking >>> about: >>>> Link-local Multicast/Broadcast Scope On a MANET interface, a packet >>>> sent to a link-local multicast or all-ones broadcast address reaches >>>> the MANET interfaces of neighboring MANET routers, regardless of >>>> their configured addresses. >>> >>> That is what I meant ^. In the Fig.1 scenario above the MR3 will >>> send an IP message to network-layer multicast address which will have >>> a link-layer header link-local multicast destination address, the >>> MR2-Relay will IP-unicast it to the Server. >> >> I think there is a misunderstanding here. Maybe there will be at some >> point a protocol that will relay some messages in order to reach the >> server. But there is none for now. So you do not have the behaviour >> that you describe, and among other things this is why there is a problem! > > Emmanuel, already a DHCP Relay (a new MR2 between MR1 and MR3 in the > figure above) relays messages as I described in the paragraph above - > it's DHCP terminology and implementation. > > Can we agree on this. > > If you want I can make a separate thread. > > IF we run this and find some problems with DHCP because something moves > somehow then I'm all years. > > 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 > ______________________________________________________________________ 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 Nov 20 19:25: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 1IudOs-0000AD-Sn; Tue, 20 Nov 2007 19:25:06 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IudOr-0008Ry-Pm for autoconf-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 19:25:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IudOr-0008Lg-9P for autoconf@ietf.org; Tue, 20 Nov 2007 19:25:05 -0500 Received: from smtp03.uc3m.es ([163.117.176.133] helo=smtp.uc3m.es) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IudOq-0003ac-BG for autoconf@ietf.org; Tue, 20 Nov 2007 19:25:04 -0500 Received: from [192.168.0.4] (82.159.23.147.dyn.user.ono.com [82.159.23.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.uc3m.es (Postfix) with ESMTP id CD63F23CF20 for ; Wed, 21 Nov 2007 01:25:02 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: autoconf@ietf.org Organization: Universidad Carlos III de Madrid Date: Wed, 21 Nov 2007 01:24:47 +0100 Message-Id: <1195604687.5119.43.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Subject: [Autoconf] Comments on draft-ietf-autoconf-statement-02.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1447016919==" Errors-To: autoconf-bounces@ietf.org --===============1447016919== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-XhsP7FkNH2UVLKE+9zkM" --=-XhsP7FkNH2UVLKE+9zkM Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi all, Thanks for the new version of the draft. Some comments below (I hope I don't repeat any already brought on the ML): - "Connected MANET - A mobile ad hoc network, which contains at least one ICP." --> I'm not sure a connected MANET should necessarily contain one ICP, at least as I understand what an ICP is. As I see it, an ICP can be -- going to solution space -- a DHCP server in the infrastructure (and therefore not _contained_ in the MANET). Maybe it's just myself not reading the definition properly. - "Another example of such a scenario is coverage extension of a fixed wide-area wireless network, where one or more mobile routers in the MANET are connected to the Internet through technologies such as UMTS or WiMAX." --> I think the term mobile router may lead to confusion, I'd prefer MANET router, since mobile router is usually related to NEMO (RFC 3963). - (Section 4.1.2 Dynamic Topology Support) "Moreover, possible frequent reconfiguration due to intermittent reachability cause [5] to be less efficient than expected, due to large amounts of control signalling." --> I think I'm missing something here, can [5] (RFC 4862) be used in a multihop environment? I don't clearly the comment on [5] and dynamic topology. - (Section 4.1.3 Network Merging Support) "For instance, [5] and [3] test address uniqueness via messages that are sent to neighbors only, and as such cannot detect the presence of duplicate addresses configured within the network but located several hops away. However, since MANETs are generally multi-hop, detection of duplicate addresses over several hops is a feature that may be required for MANET interface address assignment (see Section 4.2.2)." --> Again, I think I'm missing something here, I see network merging has more to do with the in-service uniqueness requirement that with the multi-hop nature (of course, everything is related ...). - (Section 4.2.2 Prefix and Address Uniqueness Requirements) "Phenomena such as MANET merging and MANET partitioning may bring the need for checking the uniqueness (within the specified scope) of addresses or prefixes that are already assigned and used." --> I'd remove "and MANET partitioning", since IMHO only merging may produce duplicates, right? - (Section 4.2.2 Prefix and Address Uniqueness Requirements) "For instance, if (i) is extremely low and (ii) significant, then checking pre-service uniqueness of addresses and prefixes may not be used." --> shouldn't it say ... checking in-service uniqueness of addresses ...? I thought pre-service is assumed to be always required to avoid duplicate addresses when a MANET router joins the network (and therefore avoid routing problems, etc...). - (Section 5 Solutions Considerations) "Solutions must achieve their task with (i) low overhead, due to scarse bandwidth, and (ii) low delay/convergence time, due to the dynamicity of the topology." --> Are we assuming always "scarse bandwidth"? IMHO this is scenario-specific, and although I agree on the requirement of low overhead in general, how important this issue is depends on the particular scenario. IMHO, Section 5 as it is now does not really fulfils the goal of providing solutions considerations. I really think that performing such an analysis without going more deeply into the details (such as in draft-bernardos-autoconf-evaluation-considerations-01.txt) is very hard. As I see it (this is my personal view on that), either we extend this section or we remove it. Hope these comments help. Kind Regards, Carlos J. --=20 =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-XhsP7FkNH2UVLKE+9zkM Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHQ3rPNdy6TdFwT2cRAih7AJwIFwIsWABgIE5JojmSF+fG3xETgACeMyR2 W//ST2l8eRMZJMh1hRtcsks= =GzE7 -----END PGP SIGNATURE----- --=-XhsP7FkNH2UVLKE+9zkM-- --===============1447016919== 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 --===============1447016919==-- From autoconf-bounces@ietf.org Wed Nov 21 03:57: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 1IulPB-0005uv-1B; Wed, 21 Nov 2007 03:57:57 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IulP9-0005uq-Ls for autoconf-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 03:57:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IulP9-0005ui-A7 for autoconf@ietf.org; Wed, 21 Nov 2007 03:57:55 -0500 Received: from mail4-relais-sop.national.inria.fr ([192.134.164.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IulP5-0005HH-L0 for autoconf@ietf.org; Wed, 21 Nov 2007 03:57:55 -0500 X-IronPort-AV: E=Sophos;i="4.21,445,1188770400"; d="scan'208";a="19524208" Received: from vad99.v.pppool.de (HELO [192.168.178.25]) ([89.57.173.153]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Nov 2007 09:57:50 +0100 Message-ID: <4743F30C.7010700@inria.fr> Date: Wed, 21 Nov 2007 09:57:48 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org Subject: Re: [Autoconf] Random MLA uniqueness References: <02a101c82b7d$8ca3cab0$7dd16c6b@sisodomain.com> <00a201c82b80$aca4aa20$05edfe60$@nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 a écrit : > Please see below: > > On 11/20/07, Teco Boot wrote: >> If this is all well understood and written down, and there are no problems, >> what the hell are we doing in Autoconf? >> 1) shall we use random ULA on each node? >> 2) shall we use random subnet_ID? >> 3) How can we optimize for efficiency, e.g. compact transport using >> PacketBB? >> >> For 3), I can imagine someone comes up with a listen mode for capturing an >> existing Global_ID and Subnet_ID, so the MLA transfer over PacketBB needs >> only 64 bits (a win of 7 octets per address). >> (oeps, I did;-) >> >> I think this is the first an easiest part of Autoconf. I suggest moving >> forward with this approach as quickly as possible. > > > hmm... now I am confused, "moving forward with this approach" ? > Weren't you talking about including some text for the PS I-D ? But now > seems you are proposing some solution !! Why do you think I pointed to > the ULA RFC, because I was talking about ULA (and not MLA, which COULD > be a specific MANET solution and exact format and other details are > yet to be specified, may be). > I agree with Shubhranshu. What is this MLA that is being talked about here? Does it correspond to the definition in the PS? If so then this is not a solution. In any case let's concentrate on the problems, and not on the solutions just yet. Emmanuel _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 21 04:09:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IulaV-00075p-Hp; Wed, 21 Nov 2007 04:09:39 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IulaU-00075j-Qh for autoconf-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 04:09:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IulaT-00075W-VS for autoconf@ietf.org; Wed, 21 Nov 2007 04:09:38 -0500 Received: from maile.telecomitalia.it ([156.54.233.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IulaS-0000o4-I0 for autoconf@ietf.org; Wed, 21 Nov 2007 04:09:37 -0500 thread-index: AcgsHjvjaZoiv5iwQp2TovdzbemhXA== Received: from ptpxch008ba020.idc.cww.telecomitalia.it ([156.54.240.51]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 10:09:34 +0100 Received: from PTPXCH029BA020.idc.cww.telecomitalia.it ([156.54.240.46]) by ptpxch008ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 10:09:34 +0100 Received: from [10.229.4.26] ([10.229.4.26]) by PTPXCH029BA020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 10:09:32 +0100 Message-ID: <4743F55F.2040402@telecomitalia.it> Date: Wed, 21 Nov 2007 10:07:43 +0100 Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2929 From: "Simone Ruffino" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Teco Boot" Subject: Re: [Autoconf] Re: Scenarios and Requirements References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7695.1060808@gmail.com> <00b101c82848$bd7580d0$38608270$@nl> <473D9D60.6090009@gmail.com> <473DA439.9070303@inria.fr> <00d101c82860$2a3cd3a0$7eb67ae0$@nl> <473DB35E.4030406@inria.fr> <473DB3C2.6090405@telecomitalia.it> <1B345D27-0BC6-443A-80A5-2178D8CB41A2@thomasclausen.org> <00ea01c8287a$464a3a50$d2deaef0$@nl> <473DF63F.2030505@gmail.com> <012401c828ef$292cb630$7b862290$@nl> <473F3CE0.50807@gmail.com> <006a01c82a2e$f325ebb0$d971c310$@nl> <47416F4A.4020002@gmail.com> <003901c82aa6$5b92e370$12b8aa50$@nl> <4741890E.1070908@inria.fr> <005601c82ab3$c16148b0$4423da10$@nl> <4742EAB4.2070101@inria.fr> <00a301c82b86$6bb64ae0$4322e0a0$@nl> <47431BC0.7000204@inria.fr> <00ed01c82ba4$bfed9af0$3fc8d0d0$@nl> In-Reply-To: <00ed01c82ba4$bfed9af0$3fc8d0d0$@nl> Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 21 Nov 2007 09:09:32.0746 (UTC) FILETIME=[3AD0C2A0:01C82C1E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 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 Hi all, see inline. Simone Teco Boot wrote: > Hi Emmanuel, Inline. > > =20 >> -----Oorspronkelijk bericht----- >> Van: Emmanuel Baccelli [mailto:Emmanuel.Baccelli@inria.fr] >> Verzonden: dinsdag 20 november 2007 18:39 >> Aan: autoconf@ietf.org >> Onderwerp: Re: [Autoconf] Re: Scenarios and Requirements >> >> Hi Teco, >> >> Teco Boot a =E9crit : >> =20 >>>> -----Oorspronkelijk bericht----- >>>> Van: Emmanuel Baccelli [mailto:Emmanuel.Baccelli@inria.fr] >>>> Verzonden: dinsdag 20 november 2007 15:10 >>>> Aan: autoconf@ietf.org >>>> Onderwerp: Re: [Autoconf] Re: Scenarios and Requirements >>>> >>>> Hi Teco, >>>> >>>> Teco Boot a =E9crit : >>>> =20 >>>>> MANET Global Address (MGA) - An IP address configured on a >>>>> =20 >> MANET >> =20 >>>>> interface, and valid for communications inside the MANET and >>>>> =20 >>>> for >>>> =20 >>>>> communications with corresponding nodes on the Internet, via >>>>> =20 >> a >> =20 >>>>> Border Router. A MGA is associated with a Border Router, for >>>>> =20 >>>> being >>>> =20 >>>>> topologically correct. >>>>> >>>>> >>>>> Please verify definition for Global prefix. There are conditions >>>>> =20 >> that >> =20 >>>> IP >>>> =20 >>>>> addresses are invalid for communications reaching outside the >>>>> =20 >> MANET. >> =20 >>>> And why >>>> =20 >>>>> is it reserved for MANET Routers? Why not using a range? (RFC3633 >>>>> =20 >>>> uses >>>> =20 >>>>> prefixes, that could be a reason). >>>>> =20 >>>> OK, I see what you mean. I think that we do not need to create new >>>> terms >>>> other than global prefix and global address. We just need to make >>>> =20 >> sure >> =20 >>>> that people understand what these terms mean in the context of >>>> =20 >> MANETs. >> =20 >>> Do you agree on the definition for MGA, being used for GA? >>> >>> =20 >> Yes. I think it is good. I am working as we speak on -03. The >> definition >> for global address will be this one. >> =20 > > Only the M prepended ;-) > =20 I also like Teco's text, but I don't understand yet, why we need to=20 define MGA. Aren't we actually re-defining standard, well-known,=20 well-established IPv6 GA? Are MGA different from IPv6 GA to any extent?=20 Do we really need to have a new acronym here? I raise again this issue, because, in my opinion, this particular=20 definition can generate more confusion. Suggestion : so not have a definition for MGA or GA at all. > =20 >>>>> I do not like the term "Internet Configuration Provider (ICP)". = Why >>>>> =20 >>>> not >>>> =20 >>>>> using DHCP Server? Or is it something else? Must this be a Router? >>>>> =20 >>>> Why? Why >>>> =20 >>>>> can't it provide prefixes or addresses to hosts? Large >>>>> =20 >>>> infrastructures >>>> =20 >>>>> typically have separated routers and address assignment servers. I >>>>> =20 >>>> reject >>>> =20 >>>>> text defining that these are integrated in one device. It may be, >>>>> =20 >> but >> =20 >>>> _not_ >>>> =20 >>>>> should be and _certainly not_ must be. >>>>> >>>>> =20 >>>> OK. So maybe we could talk about an "entity" instead of a "router"? >>>> This >>>> would be more general I agree. >>>> =20 >>> First, I want to know why we can't use the term DHCP server. I = really >>> =20 >> can't >> =20 >>> follow why we are not considering DHCP-PD. >>> >>> =20 >> DHCP is a solution. We are not talking a solution in particular. We = are >> talking about a fundamental problem, so the vocabulary has to be >> generic, and precise at the same time. An ICP can be a DHCP server, = no >> problem. Soo you agree with the following definition? >> >> Internet Configuration Provider (ICP) - An entity that can provide >> routers requesting configuration with addresses or prefixes >> derived from a global prefix. >> >> =20 > > =20 Emmanuel, I also think that ICP is not clear. If it is an entity=20 external to MANETs, we should really write that it can be a DHCP=20 servero, or a AAA server. If your goal is using it to define "connected" vs. "disconnected"=20 MANET, I think that it is not appropriate: to me, the difference is that = a "connected" MANET has *at least* one MANET border router that routes=20 packet towards/from an external network, s.a. the Internet. > Yes and no. > We have lots of fundamental problems. Let's discuss the length of an = IPv8 > address;-) > If you want to use a generic term for a DHCP server, or AAA server = providing > addresses, OK. > But would use this term a lot, as problems cannot be defined, as we do = not > know what it is. > For example, using AAA has very different problems than DHCP. > > I prefer being very accurate when describing problems. It helps the > discussions. > > On the definition, please change routers into nodes. > And find other text for the reply. If a node request configuration, = the > reply is configuration and not limited to addresses or prefixes. Or = use > Address and Prefix Providing Entity. Both AAA and DHCP provides more = than > that. And for very good reasons. > > =20 > -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please contact us by replying to = webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- =20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 21 04:15:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iulfu-00061Y-O7; Wed, 21 Nov 2007 04:15:14 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Iulft-00061N-Ot for autoconf-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 04:15:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iulft-00061A-DW for autoconf@ietf.org; Wed, 21 Nov 2007 04:15:13 -0500 Received: from mail4-relais-sop.national.inria.fr ([192.134.164.105]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iulfs-0000ya-TD for autoconf@ietf.org; Wed, 21 Nov 2007 04:15:13 -0500 X-IronPort-AV: E=Sophos;i="4.21,445,1188770400"; d="scan'208";a="19524945" Received: from vad99.v.pppool.de (HELO [192.168.178.25]) ([89.57.173.153]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Nov 2007 10:15:11 +0100 Message-ID: <4743F71E.3090705@inria.fr> Date: Wed, 21 Nov 2007 10:15:10 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org Subject: Re: [Autoconf] Re: Scenarios and Requirements References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7695.1060808@gmail.com> <00b101c82848$bd7580d0$38608270$@nl> <473D9D60.6090009@gmail.com> <473DA439.9070303@inria.fr> <00d101c82860$2a3cd3a0$7eb67ae0$@nl> <473DB35E.4030406@inria.fr> <473DB3C2.6090405@telecomitalia.it> <1B345D27-0BC6-443A-80A5-2178D8CB41A2@thomasclausen.org> <00ea01c8287a$464a3a50$d2deaef0$@nl> <473DF63F.2030505@gmail.com> <012401c828ef$292cb630$7b862290$@nl> <473F3CE0.50807@gmail.com> <006a01c82a2e$f325ebb0$d971c310$@nl> <47416F4A.4020002@gmail.com> <003901c82aa6$5b92e370$12b8aa50$@nl> <4741890E.1070908@inria.fr> <005601c82ab3$c16148b0$4423da10$@nl> <4742EAB4.2070101@inria.fr> <00a301c82b86$6bb64ae0$4322e0a0$@nl> <47431BC0.7000204@inria.fr> <474332E5.2050707@gmail.com> In-Reply-To: <474332E5.2050707@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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 Alexandru Petrescu a écrit : >>> >>> First, I want to know why we can't use the term DHCP server. I really >>> can't follow why we are not considering DHCP-PD. >> >> DHCP is a solution. We are not talking a solution in particular. We >> are talking about a fundamental problem, so the vocabulary has to be >> generic, and precise at the same time. > > Sorry, I don't see any fundamental problems. > > I don't think we can solve any problem by stating from the start it's > 'fundamental'. > > I will not work on any fundamental problem. > I see. I guess we are still at this point were it is not understood that there is a problem regarding semi-broadcast... >> An ICP can be a DHCP server, no problem. Soo you agree with the >> following definition? >> >> Internet Configuration Provider (ICP) - An entity that can provide >> routers requesting configuration with addresses or prefixes derived >> from a global prefix. > > I'd agree if you added "typically a DHCP Server". OK, this is possible. In -03 i will add "for example a DHCP Server". > >>>>> On DHCP-PD, I reread the problem statement document. When all nodes >>>> perform >>>>> DHCP functions, as 3633 RR and DR, what are the problems? I don't >>>> think this >>>>> scenario is optimal, but it should work. Problems could be: - BR >>>>> ingress filter, relation with routing - Session continuity problem >>>>> when path via BR is not available >>>> anymore >>>>> - Running DHCP on some platforms - Inefficient address usage >>>> Yes, especially you'd get into trouble if no server is reachable >>>> and the MANET is not "full mesh". This is the case of most >>>> standalone MANETs, for instance. >>> >>> I think DHCP can perfectly being used, as long as it is reachable. If >>> no DHCP is reachable, I assume the MANET is standalone, OK? So there >>> is no need for GA. When there is a DHCP reachable (single hop, using >>> link local or MLA), it can provide an MLA. Using such an >>> MLA can be more efficient for transport over PacketBB related to >>> random MLA (see different thread for details). I think MLA can be >>> relatively static, e.g. using long DHCP lease times. Reachability to >>> DHCP server is needed every now and then. >>> >> >> I agree that DHCP is a strong candidate for part of the solution to >> the connected MANET case. But it is only a candidate, and it does not >> solve everything. Do you agree on this? > > It is a good candidate. It may solve many scenarios. I haven't seen a > scenario where it wouldn't work, and where stateless autoconf wouldn't > work, but I'm interested to learn it. > Are you saying that there is no issues using DHCP and ND with - dynamic topology - semi-broadcast behavior - network merging/partitionning Are you saying that? Emmanuel _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 21 04:17: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 1IuliT-00011c-3D; Wed, 21 Nov 2007 04:17:53 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuliR-00011J-T5 for autoconf-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 04:17:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuliR-000117-Gb for autoconf@ietf.org; Wed, 21 Nov 2007 04:17:51 -0500 Received: from mail4-relais-sop.national.inria.fr ([192.134.164.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuliO-0005yo-7q for autoconf@ietf.org; Wed, 21 Nov 2007 04:17:51 -0500 X-IronPort-AV: E=Sophos;i="4.21,445,1188770400"; d="scan'208";a="19525056" Received: from vad99.v.pppool.de (HELO [192.168.178.25]) ([89.57.173.153]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Nov 2007 10:17:47 +0100 Message-ID: <4743F7B9.8000907@inria.fr> Date: Wed, 21 Nov 2007 10:17:45 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org Subject: Re: [Autoconf] Multicast confusion between MANET Arch and AUTOCONFProblem Statement References: <4742FB0D.40208@gmail.com> <7877C5C0B5CC894AB26113CF06CF88631EA662@ms-dt01thalia.tsn.tno.nl> <4743074E.5060309@gmail.com> <00cf01c82b92$6bd57530$43805f90$@nl> <47430E9F.8010507@gmail.com> <00d801c82b95$57e36160$07aa2420$@nl> <47431810.1010909@gmail.com> <00e701c82b9b$2babbe20$83033a60$@nl> <47432D4D.9000106@gmail.com> <00ef01c82baa$436471b0$ca2d5510$@nl> In-Reply-To: <00ef01c82baa$436471b0$ca2d5510$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 Boot a écrit : > Hi Alex, > > I think we agree on that the current PS is focused on "classical MANET". And > it misses another ad-hoc network type, e.g. using ad-hoc multihop > connectivity to the Internet. I do not agree with this judgement. Can you tell me what is the difference between the connected MANET scenario explicitely described in th scope of the PS, and what you mean by"ad hoc multihop connectivity to the Internet"? Emmanuel _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 21 04:42: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 1Ium6U-0003Fd-5T; Wed, 21 Nov 2007 04:42:42 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Ium6R-0003Ew-MA for autoconf-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 04:42:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ium6R-0003Ei-74 for autoconf@ietf.org; Wed, 21 Nov 2007 04:42:39 -0500 Received: from mail4-relais-sop.national.inria.fr ([192.134.164.105]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ium6Q-0001g4-1q for autoconf@ietf.org; Wed, 21 Nov 2007 04:42:38 -0500 X-IronPort-AV: E=Sophos;i="4.21,445,1188770400"; d="scan'208";a="19525989" Received: from vad99.v.pppool.de (HELO [192.168.178.25]) ([89.57.173.153]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Nov 2007 10:42:36 +0100 Message-ID: <4743FD8B.4040006@inria.fr> Date: Wed, 21 Nov 2007 10:42:35 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org Subject: Re: [Autoconf] Comments on draft-ietf-autoconf-statement-02.txt References: <1195604687.5119.43.camel@localhost> In-Reply-To: <1195604687.5119.43.camel@localhost> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 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 Cralos thanks for your feedback, Carlos Jesús Bernardos Cano a écrit : > Hi all, > > Thanks for the new version of the draft. Some comments below (I hope I > don't repeat any already brought on the ML): > > - "Connected MANET - A mobile ad hoc network, which contains at least > one ICP." --> I'm not sure a connected MANET should necessarily contain > one ICP, at least as I understand what an ICP is. As I see it, an ICP > can be -- going to solution space -- a DHCP server in the infrastructure > (and therefore not _contained_ in the MANET). Maybe it's just myself not > reading the definition properly. > OK, I agree. Maybe a more precise way would be to say instead that a connected MANET can reach an ICP? > - "Another example of such a scenario is coverage extension of a fixed > wide-area wireless network, where one or more mobile routers in the > MANET are connected to the Internet through technologies such as UMTS or > WiMAX." --> I think the term mobile router may lead to confusion, I'd > prefer MANET router, since mobile router is usually related to NEMO (RFC > 3963). Agreed. > > - (Section 4.1.2 Dynamic Topology Support) "Moreover, possible frequent > reconfiguration due to intermittent reachability cause [5] to be less > efficient than expected, due to large amounts of control signalling." > --> I think I'm missing something here, can [5] (RFC 4862) be used in a > multihop environment? I don't clearly the comment on [5] and dynamic > topology. > > - (Section 4.1.3 Network Merging Support) "For instance, [5] and [3] > test address uniqueness via messages that are sent to neighbors only, > and as such cannot detect the presence of duplicate addresses configured > within the network but located several hops away. However, since MANETs > are generally multi-hop, detection of duplicate addresses over several > hops is a feature that may be required for MANET interface address > assignment (see Section 4.2.2)." --> Again, I think I'm missing > something here, I see network merging has more to do with the in-service > uniqueness requirement that with the multi-hop nature (of course, > everything is related ...). > I see what you mean. How about replacing the word "assignment" by "(re)assignment"? > - (Section 4.2.2 Prefix and Address Uniqueness Requirements) "Phenomena > such as MANET merging and MANET partitioning may bring the need for > checking the uniqueness (within the specified scope) of addresses or > prefixes that are already assigned and used." --> I'd remove "and MANET > partitioning", since IMHO only merging may produce duplicates, right? > Agreed. I guess the order was more intended to be partitionning=>merging=>problems ;) But it may be clearer to just talk about merging here. > - (Section 4.2.2 Prefix and Address Uniqueness Requirements) "For > instance, if (i) is extremely low and (ii) significant, then checking > pre-service uniqueness of addresses and prefixes may not be used." --> > shouldn't it say ... checking in-service uniqueness of addresses ...? I > thought pre-service is assumed to be always required to avoid duplicate > addresses when a MANET router joins the network (and therefore avoid > routing problems, etc...). You are right. This is a typo that eluded me. > > - (Section 5 Solutions Considerations) "Solutions must achieve their > task with (i) low overhead, due to scarse bandwidth, and (ii) low > delay/convergence time, due to the dynamicity of the topology." --> Are > we assuming always "scarse bandwidth"? IMHO this is scenario-specific, > and although I agree on the requirement of low overhead in general, how > important this issue is depends on the particular scenario. IMHO, > Section 5 as it is now does not really fulfils the goal of providing > solutions considerations. I really think that performing such an > analysis without going more deeply into the details (such as in > draft-bernardos-autoconf-evaluation-considerations-01.txt) is very hard. > As I see it (this is my personal view on that), either we extend this > section or we remove it. > We agree that low control overhead is a generic requirement. If you see other generic requirements that are missing here, please tell us and it will be mentionned in this section. Emmanuel _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 21 05:07:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IumUH-0003gG-RM; Wed, 21 Nov 2007 05:07:17 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IumUG-0003Zv-EN for autoconf-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 05:07:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IumUE-0003SL-3O for autoconf@ietf.org; Wed, 21 Nov 2007 05:07:14 -0500 Received: from maild.telecomitalia.it ([156.54.233.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IumUC-0002U9-HF for autoconf@ietf.org; Wed, 21 Nov 2007 05:07:13 -0500 thread-index: AcgsJkZQ0U9hlcSTQqa5yqjYCnjteQ== Received: from ptpxch009ba020.idc.cww.telecomitalia.it ([156.54.240.52]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 11:07:07 +0100 Received: from PTPXCH029BA020.idc.cww.telecomitalia.it ([156.54.240.46]) by ptpxch009ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 11:07:07 +0100 Received: from [10.229.4.26] ([10.229.4.26]) by PTPXCH029BA020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 11:07:06 +0100 Message-ID: <474402DE.1010805@telecomitalia.it> Date: Wed, 21 Nov 2007 11:05:18 +0100 Content-Class: urn:content-classes:message From: "Simone Ruffino" Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2929 User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Subject: Re: [Autoconf] Comments on draft-ietf-autoconf-statement-02.txt References: <1195604687.5119.43.camel@localhost> In-Reply-To: <1195604687.5119.43.camel@localhost> Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 21 Nov 2007 10:07:06.0344 (UTC) FILETIME=[4551FE80:01C82C26] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 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 Carlos and thanks for your comments. See below my comments, Regs, Simone Carlos Jes=FAs Bernardos Cano wrote: > Hi all, > > Thanks for the new version of the draft. Some comments below (I hope = I > don't repeat any already brought on the ML): > > - "Connected MANET - A mobile ad hoc network, which contains at = least > one ICP." --> I'm not sure a connected MANET should necessarily = contain > one ICP, at least as I understand what an ICP is. As I see it, an ICP > can be -- going to solution space -- a DHCP server in the = infrastructure > (and therefore not _contained_ in the MANET). Maybe it's just myself = not > reading the definition properly. > =20 ICP is not clearly defined. In a previous post, I already commented on = this. > - "Another example of such a scenario is coverage extension of a = fixed > wide-area wireless network, where one or more mobile routers in the > MANET are connected to the Internet through technologies such as UMTS = or > WiMAX." --> I think the term mobile router may lead to confusion, I'd > prefer MANET router, since mobile router is usually related to NEMO = (RFC > 3963). > > =20 I agree. Suggestion: s / "mobile routers in the MANET"/ "MANET routers". > - (Section 4.1.2 Dynamic Topology Support) "Moreover, possible = frequent > reconfiguration due to intermittent reachability cause [5] to be less > efficient than expected, due to large amounts of control signalling." > --> I think I'm missing something here, can [5] (RFC 4862) be used in = a > multihop environment? I don't clearly the comment on [5] and dynamic > topology. > =20 Reading this statement again (sorry, we wrote this sentence a time=20 ago...), I think that we "zipped" our thoughts in one sentence, leaving=20 out some detail. IIRC, I think here the problem is not the "multi-hop" environment=20 (incidentally, if you think of "normal" ISP network, which are=20 multi-hop, rfc4862 perfectly works). The problem here is the "intermittent reachability": if MANET router=20 experiences bad connectivity to its neighbors, it _could_ be forced, for = example, to repeat DAD on MANET interface much more times than in=20 managed networks, thus bringing inefficiency. Emmanuel, can you add some details here ? Is my understanding correct ? > - (Section 4.1.3 Network Merging Support) "For instance, [5] and [3] > test address uniqueness via messages that are sent to neighbors only, > and as such cannot detect the presence of duplicate addresses = configured > within the network but located several hops away. However, since = MANETs > are generally multi-hop, detection of duplicate addresses over several > hops is a feature that may be required for MANET interface address > assignment (see Section 4.2.2)." --> Again, I think I'm missing > something here, I see network merging has more to do with the = in-service > uniqueness requirement that with the multi-hop nature (of course, > everything is related ...). > > - (Section 4.2.2 Prefix and Address Uniqueness Requirements) = "Phenomena > such as MANET merging and MANET partitioning may bring the need for > checking the uniqueness (within the specified scope) of addresses or > prefixes that are already assigned and used." --> I'd remove "and = MANET > partitioning", since IMHO only merging may produce duplicates, right? > > - (Section 4.2.2 Prefix and Address Uniqueness Requirements) "For > instance, if (i) is extremely low and (ii) significant, then checking > pre-service uniqueness of addresses and prefixes may not be used." --> > shouldn't it say ... checking in-service uniqueness of addresses ...? = I > thought pre-service is assumed to be always required to avoid = duplicate > addresses when a MANET router joins the network (and therefore avoid > routing problems, etc...). > > - (Section 5 Solutions Considerations) "Solutions must achieve their > task with (i) low overhead, due to scarse bandwidth, and (ii) low > delay/convergence time, due to the dynamicity of the topology." --> = Are > we assuming always "scarse bandwidth"? IMHO this is scenario-specific, > and although I agree on the requirement of low overhead in general, = how > important this issue is depends on the particular scenario. IMHO, > Section 5 as it is now does not really fulfils the goal of providing > solutions considerations. I really think that performing such an > analysis without going more deeply into the details (such as in > draft-bernardos-autoconf-evaluation-considerations-01.txt) is very = hard. > As I see it (this is my personal view on that), either we extend this > section or we remove it. > =20 In my opinion, some text that summarizes general requirements for=20 solutions is needed in the PS. Going too much into details here could be = not appropriate. Suggestion: keep it as it is, making only punctual corrections, such as=20 the one you suggested on the bandwidth. > Hope these comments help. > > Kind Regards, > > Carlos J. > > =20 > = ------------------------------------------------------------------------ > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf > =20 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please contact us by replying to = webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- =20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 21 05:25: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 1IummJ-0000sk-8r; Wed, 21 Nov 2007 05:25:55 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IummG-0000sd-Li for autoconf-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 05:25:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IummG-0000sV-8w for autoconf@ietf.org; Wed, 21 Nov 2007 05:25:52 -0500 Received: from smtp01.uc3m.es ([163.117.176.131] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IummC-0007oH-04 for autoconf@ietf.org; Wed, 21 Nov 2007 05:25:52 -0500 Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.uc3m.es (Postfix) with ESMTP id F1376247773; Wed, 21 Nov 2007 11:25:46 +0100 (CET) Subject: Re: [Autoconf] Comments on draft-ietf-autoconf-statement-02.txt From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Emmanuel Baccelli In-Reply-To: <4743FD8B.4040006@inria.fr> References: <1195604687.5119.43.camel@localhost> <4743FD8B.4040006@inria.fr> Organization: Universidad Carlos III de Madrid Date: Wed, 21 Nov 2007 11:25:47 +0100 Message-Id: <1195640747.4670.23.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 X-Spam-Score: -4.0 (----) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1129980768==" Errors-To: autoconf-bounces@ietf.org --===============1129980768== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-dhx6RXcPjK59ANDq+G1P" --=-dhx6RXcPjK59ANDq+G1P Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Emmanuel, See below... El mi=E9, 21-11-2007 a las 10:42 +0100, Emmanuel Baccelli escribi=F3: > Hi Cralos thanks for your feedback, >=20 > Carlos Jes=FAs Bernardos Cano a =E9crit : > > Hi all, > >=20 > > Thanks for the new version of the draft. Some comments below (I hope I > > don't repeat any already brought on the ML): > >=20 > > - "Connected MANET - A mobile ad hoc network, which contains at least > > one ICP." --> I'm not sure a connected MANET should necessarily contain > > one ICP, at least as I understand what an ICP is. As I see it, an ICP > > can be -- going to solution space -- a DHCP server in the infrastructur= e > > (and therefore not _contained_ in the MANET). Maybe it's just myself no= t > > reading the definition properly. > >=20 >=20 > OK, I agree. Maybe a more precise way would be to say instead that a=20 > connected MANET can reach an ICP? That's a possibility, although I'm not 100% convinced about current ICP definition (as Simone also comments). I have to think more about it before providing a suggestion... >=20 > > - "Another example of such a scenario is coverage extension of a fixed > > wide-area wireless network, where one or more mobile routers in the > > MANET are connected to the Internet through technologies such as UMTS o= r > > WiMAX." --> I think the term mobile router may lead to confusion, I'd > > prefer MANET router, since mobile router is usually related to NEMO (RF= C > > 3963). >=20 > Agreed. >=20 > >=20 > > - (Section 4.1.2 Dynamic Topology Support) "Moreover, possible frequen= t > > reconfiguration due to intermittent reachability cause [5] to be less > > efficient than expected, due to large amounts of control signalling." > > --> I think I'm missing something here, can [5] (RFC 4862) be used in a > > multihop environment? I don't clearly the comment on [5] and dynamic > > topology. > >=20 > > - (Section 4.1.3 Network Merging Support) "For instance, [5] and [3] > > test address uniqueness via messages that are sent to neighbors only, > > and as such cannot detect the presence of duplicate addresses configure= d > > within the network but located several hops away. However, since MANET= s > > are generally multi-hop, detection of duplicate addresses over several > > hops is a feature that may be required for MANET interface address > > assignment (see Section 4.2.2)." --> Again, I think I'm missing > > something here, I see network merging has more to do with the in-servic= e > > uniqueness requirement that with the multi-hop nature (of course, > > everything is related ...). > >=20 >=20 > I see what you mean. How about replacing the word "assignment" by=20 > "(re)assignment"? I'll address this in my reply to Simone's mail. >=20 > > - (Section 4.2.2 Prefix and Address Uniqueness Requirements) "Phenomen= a > > such as MANET merging and MANET partitioning may bring the need for > > checking the uniqueness (within the specified scope) of addresses or > > prefixes that are already assigned and used." --> I'd remove "and MANET > > partitioning", since IMHO only merging may produce duplicates, right? > >=20 >=20 > Agreed. I guess the order was more intended to be=20 > partitionning=3D>merging=3D>problems ;) But it may be clearer to just tal= k=20 > about merging here. >=20 > > - (Section 4.2.2 Prefix and Address Uniqueness Requirements) "For > > instance, if (i) is extremely low and (ii) significant, then checking > > pre-service uniqueness of addresses and prefixes may not be used." --> > > shouldn't it say ... checking in-service uniqueness of addresses ...? I > > thought pre-service is assumed to be always required to avoid duplicate > > addresses when a MANET router joins the network (and therefore avoid > > routing problems, etc...). >=20 > You are right. This is a typo that eluded me. >=20 > >=20 > > - (Section 5 Solutions Considerations) "Solutions must achieve their > > task with (i) low overhead, due to scarse bandwidth, and (ii) low > > delay/convergence time, due to the dynamicity of the topology." --> Are > > we assuming always "scarse bandwidth"? IMHO this is scenario-specific, > > and although I agree on the requirement of low overhead in general, how > > important this issue is depends on the particular scenario. IMHO, > > Section 5 as it is now does not really fulfils the goal of providing > > solutions considerations. I really think that performing such an > > analysis without going more deeply into the details (such as in > > draft-bernardos-autoconf-evaluation-considerations-01.txt) is very hard= . > > As I see it (this is my personal view on that), either we extend this > > section or we remove it. > >=20 >=20 > We agree that low control overhead is a generic requirement. If you see=20 > other generic requirements that are missing here, please tell us and it=20 > will be mentionned in this section. I'll also address this in my reply to Simone's mail. Regards, Carlos >=20 > Emmanuel >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf --=20 =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-dhx6RXcPjK59ANDq+G1P Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHRAerNdy6TdFwT2cRAqERAJ0ZeHNKVa48jQHIvwCuJxM04SxI/wCgg0qs E+ZYOQ5F+HtiINOwQXN+AlU= =igIT -----END PGP SIGNATURE----- --=-dhx6RXcPjK59ANDq+G1P-- --===============1129980768== 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 --===============1129980768==-- From autoconf-bounces@ietf.org Wed Nov 21 05:34:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IumuX-0005kZ-6b; Wed, 21 Nov 2007 05:34:25 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IumuW-0005kU-AQ for autoconf-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 05:34:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IumuV-0005kM-VB for autoconf@ietf.org; Wed, 21 Nov 2007 05:34:24 -0500 Received: from smtp02.uc3m.es ([163.117.176.132] helo=smtp.uc3m.es) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IumuU-0003EK-OZ for autoconf@ietf.org; Wed, 21 Nov 2007 05:34:23 -0500 Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.uc3m.es (Postfix) with ESMTP id 85252254216; Wed, 21 Nov 2007 11:34:21 +0100 (CET) Subject: Re: [Autoconf] Comments on draft-ietf-autoconf-statement-02.txt From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Simone Ruffino In-Reply-To: <474402DE.1010805@telecomitalia.it> References: <1195604687.5119.43.camel@localhost> <474402DE.1010805@telecomitalia.it> Organization: Universidad Carlos III de Madrid Date: Wed, 21 Nov 2007 11:34:21 +0100 Message-Id: <1195641261.4670.33.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 X-Spam-Score: 1.8 (+) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1999065363==" Errors-To: autoconf-bounces@ietf.org --===============1999065363== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-8uJLYEjwtw5KPwEKjWcy" --=-8uJLYEjwtw5KPwEKjWcy Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Simone, My comments inline... El mi=E9, 21-11-2007 a las 11:05 +0100, Simone Ruffino escribi=F3: > Hi Carlos and thanks for your comments. > See below my comments, > Regs, > Simone >=20 > Carlos Jes=FAs Bernardos Cano wrote: > > Hi all, > > > > Thanks for the new version of the draft. Some comments below (I hope I > > don't repeat any already brought on the ML): > > > > - "Connected MANET - A mobile ad hoc network, which contains at least > > one ICP." --> I'm not sure a connected MANET should necessarily contain > > one ICP, at least as I understand what an ICP is. As I see it, an ICP > > can be -- going to solution space -- a DHCP server in the infrastructur= e > > (and therefore not _contained_ in the MANET). Maybe it's just myself no= t > > reading the definition properly. > > =20 >=20 > ICP is not clearly defined. In a previous post, I already commented on th= is. Agree, we should work on this definition. I don't have a suggestion yet... >=20 > > - "Another example of such a scenario is coverage extension of a fixed > > wide-area wireless network, where one or more mobile routers in the > > MANET are connected to the Internet through technologies such as UMTS o= r > > WiMAX." --> I think the term mobile router may lead to confusion, I'd > > prefer MANET router, since mobile router is usually related to NEMO (RF= C > > 3963). > > > > =20 >=20 > I agree. > Suggestion: s / "mobile routers in the MANET"/ "MANET routers". Agree. >=20 >=20 >=20 > > - (Section 4.1.2 Dynamic Topology Support) "Moreover, possible frequen= t > > reconfiguration due to intermittent reachability cause [5] to be less > > efficient than expected, due to large amounts of control signalling." > > --> I think I'm missing something here, can [5] (RFC 4862) be used in a > > multihop environment? I don't clearly the comment on [5] and dynamic > > topology. > > =20 >=20 > Reading this statement again (sorry, we wrote this sentence a time=20 > ago...), I think that we "zipped" our thoughts in one sentence, leaving=20 > out some detail. > IIRC, I think here the problem is not the "multi-hop" environment=20 > (incidentally, if you think of "normal" ISP network, which are=20 > multi-hop, rfc4862 perfectly works). > The problem here is the "intermittent reachability": if MANET router=20 > experiences bad connectivity to its neighbors, it _could_ be forced, for=20 > example, to repeat DAD on MANET interface much more times than in=20 > managed networks, thus bringing inefficiency. Yes, and it's not only that, but the fact that if we assume the same IPv6 prefix is used for all the nodes within the MANET (again, that depends on the model we are thinking of), DAD as it is defined for non-MANET networks will not ensure the address uniqueness, so we need some kind of in-service mechanism. Even if a pre-service address uniqueness mechanism is used, duplications might happen as a result of merging. >=20 > Emmanuel, can you add some details here ? Is my understanding correct ? >=20 > > - (Section 4.1.3 Network Merging Support) "For instance, [5] and [3] > > test address uniqueness via messages that are sent to neighbors only, > > and as such cannot detect the presence of duplicate addresses configure= d > > within the network but located several hops away. However, since MANET= s > > are generally multi-hop, detection of duplicate addresses over several > > hops is a feature that may be required for MANET interface address > > assignment (see Section 4.2.2)." --> Again, I think I'm missing > > something here, I see network merging has more to do with the in-servic= e > > uniqueness requirement that with the multi-hop nature (of course, > > everything is related ...). > > > > - (Section 4.2.2 Prefix and Address Uniqueness Requirements) "Phenomen= a > > such as MANET merging and MANET partitioning may bring the need for > > checking the uniqueness (within the specified scope) of addresses or > > prefixes that are already assigned and used." --> I'd remove "and MANET > > partitioning", since IMHO only merging may produce duplicates, right? > > > > - (Section 4.2.2 Prefix and Address Uniqueness Requirements) "For > > instance, if (i) is extremely low and (ii) significant, then checking > > pre-service uniqueness of addresses and prefixes may not be used." --> > > shouldn't it say ... checking in-service uniqueness of addresses ...? I > > thought pre-service is assumed to be always required to avoid duplicate > > addresses when a MANET router joins the network (and therefore avoid > > routing problems, etc...). > > > > - (Section 5 Solutions Considerations) "Solutions must achieve their > > task with (i) low overhead, due to scarse bandwidth, and (ii) low > > delay/convergence time, due to the dynamicity of the topology." --> Are > > we assuming always "scarse bandwidth"? IMHO this is scenario-specific, > > and although I agree on the requirement of low overhead in general, how > > important this issue is depends on the particular scenario. IMHO, > > Section 5 as it is now does not really fulfils the goal of providing > > solutions considerations. I really think that performing such an > > analysis without going more deeply into the details (such as in > > draft-bernardos-autoconf-evaluation-considerations-01.txt) is very hard= . > > As I see it (this is my personal view on that), either we extend this > > section or we remove it. > > =20 >=20 > In my opinion, some text that summarizes general requirements for=20 > solutions is needed in the PS. Going too much into details here could be=20 > not appropriate. I agree that going too much into details maybe is not the right approach (that's the reason we worked on that on a separate document), but I'm not completely sure that addressing these issues just in a generic way is possible without leaving important things out. That's why I was suggesting the possibility of removing the section. As it is now, a reader may think: "OK, overhead is an issue, but also routing protocol dependency, and the scalability, and the address space utilisation, etc..." Regards, Carlos > Suggestion: keep it as it is, making only punctual corrections, such as=20 > the one you suggested on the bandwidth. >=20 >=20 > > Hope these comments help. > > > > Kind Regards, > > > > Carlos J. > > > > =20 > > -----------------------------------------------------------------------= - > > > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www1.ietf.org/mailman/listinfo/autoconf > > =20 > -------------------------------------------------------------------- >=20 > CONFIDENTIALITY NOTICE >=20 > This message and its attachments are addressed solely to the persons abov= e and may contain confidential information. If you have received the messag= e in error, be informed that any use of the content hereof is prohibited. P= lease return it immediately to the sender and delete the message. Should yo= u have any questions, please contact us by replying to webmaster@telecomita= lia.it. >=20 > Thank you >=20 > www.telecomitalia.it >=20 > -------------------------------------------------------------------- > =20 --=20 =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-8uJLYEjwtw5KPwEKjWcy Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHRAmtNdy6TdFwT2cRArWZAKC3Wg35NWpd+6omCkYAGKejQNv5vwCfdU/n vYS34zL8UBTltWZqOOnleuY= =p+Nd -----END PGP SIGNATURE----- --=-8uJLYEjwtw5KPwEKjWcy-- --===============1999065363== 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 --===============1999065363==-- From autoconf-bounces@ietf.org Wed Nov 21 05:43: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 1Iun3i-0004Xt-RG; Wed, 21 Nov 2007 05:43:54 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Iun3g-0004Fl-RA for autoconf-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 05:43:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iun3g-0004A8-8p for autoconf@ietf.org; Wed, 21 Nov 2007 05:43:52 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Iun3d-0008MK-QT for autoconf@ietf.org; Wed, 21 Nov 2007 05:43:52 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-119.messagelabs.com!1195641828!28857377!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 24557 invoked from network); 21 Nov 2007 10:43:48 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-5.tower-119.messagelabs.com with SMTP; 21 Nov 2007 10:43:48 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id lALAhmrT010019; Wed, 21 Nov 2007 03:43:48 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id lALAhlah005028; Wed, 21 Nov 2007 04:43:47 -0600 (CST) 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 lALAhiKG005007; Wed, 21 Nov 2007 04:43:45 -0600 (CST) Message-ID: <47440BE0.4000706@gmail.com> Date: Wed, 21 Nov 2007 11:43:44 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: cjbc@it.uc3m.es Subject: Re: [Autoconf] Comments on draft-ietf-autoconf-statement-02.txt References: <1195604687.5119.43.camel@localhost> <474402DE.1010805@telecomitalia.it> <1195641261.4670.33.camel@localhost> In-Reply-To: <1195641261.4670.33.camel@localhost> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 071120-0, 20/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 Carlos Jesús Bernardos Cano wrote: [...] >> Simone wrote: >> Reading this statement again (sorry, we wrote this sentence a time >> ago...), I think that we "zipped" our thoughts in one sentence, >> leaving out some detail. IIRC, I think here the problem is not the >> "multi-hop" environment (incidentally, if you think of "normal" ISP >> network, which are multi-hop, rfc4862 perfectly works). The problem >> here is the "intermittent reachability": if MANET router >> experiences bad connectivity to its neighbors, it _could_ be >> forced, for example, to repeat DAD on MANET interface much more >> times than in managed networks, thus bringing inefficiency. > > Yes, and it's not only that, but the fact that if we assume the same > IPv6 prefix is used for all the nodes within the MANET (again, that > depends on the model we are thinking of), DAD as it is defined for > non-MANET networks will not ensure the address uniqueness, I don't understand... if the entire MANET has only one prefix and only one subnet then DAD will surely ensure address uniqueness. Simone says that if a MANET router has bad connectivity to its neighbor then it could be forced to repeat DAD more often than if the connectivity was stable. But isn't this true for _any_ protocol? If connectivity is troublesome then IP protocols will break, including any new one. DAD has a timer and variables (eg count of NS messages to send before deciding there's no NA) that can be tweaked to accommodate a certain level of intermitency in connectivity. 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 Nov 21 06:06:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IunPF-0006oR-IB; Wed, 21 Nov 2007 06:06:09 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IunPF-0006oI-4i for autoconf-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 06:06:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IunPC-0006ex-Dc for autoconf@ietf.org; Wed, 21 Nov 2007 06:06:06 -0500 Received: from server9.hosting2go.nl ([83.137.192.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IunP4-0000bZ-SA for autoconf@ietf.org; Wed, 21 Nov 2007 06:06:03 -0500 Received: (qmail 24827 invoked from network); 21 Nov 2007 12:05:50 +0100 Received: from unknown (HELO M90Teco) (217.169.232.211) by server9.hosting2go.nl with SMTP; 21 Nov 2007 12:05:49 +0100 From: "Teco Boot" To: "'Emmanuel Baccelli'" References: <02a101c82b7d$8ca3cab0$7dd16c6b@sisodomain.com> <00a201c82b80$aca4aa20$05edfe60$@nl> <4743F30C.7010700@inria.fr> In-Reply-To: <4743F30C.7010700@inria.fr> Date: Wed, 21 Nov 2007 12:05:13 +0100 Message-ID: <001f01c82c2e$7681e080$6385a180$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgsHLlT3SkiNLP0TCmy3qwk+wQghAADvxYg Content-Language: nl X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: autoconf@ietf.org Subject: [Autoconf] MLA and MGA 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 Emmanuel, More on MLA and MGA terminology: please read charter, both address types are referred in the text. I don't care which terms are used, but I want specific terms for specific usages. GA is far from specific, e.g. MNN address, CoA, and HoA are all GA. Are they all MGA? I don't think so. Charter describes two additional attributes for MGA, added to GA: Text: globally routable unique addresses. Additional attributes: 1) Unique. This excludes for example anycast. 2) Routable. This implies a relation with routing (or reachability, if you want) For the last one, a generated GA for being used could have two states, routable or not routable. This depends on connectivity between MNR and the BR, associated with that BR. I think we should remove any essential difference between charter and problem statement. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 21 06:28: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 1Iunkp-00087c-EG; Wed, 21 Nov 2007 06:28:27 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Iunko-00087L-BR for autoconf-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 06:28:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iunkn-000876-RI for autoconf@ietf.org; Wed, 21 Nov 2007 06:28:25 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iunkm-0004wg-QO for autoconf@ietf.org; Wed, 21 Nov 2007 06:28:25 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-153.messagelabs.com!1195644503!10391394!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 597 invoked from network); 21 Nov 2007 11:28:23 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-14.tower-153.messagelabs.com with SMTP; 21 Nov 2007 11:28:23 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id lALBSMV4011951; Wed, 21 Nov 2007 04:28:23 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id lALBSMqM002446; Wed, 21 Nov 2007 05:28:22 -0600 (CST) 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 lALBSKDs002433; Wed, 21 Nov 2007 05:28:21 -0600 (CST) Message-ID: <47441653.5030101@gmail.com> Date: Wed, 21 Nov 2007 12:28:19 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Emmanuel Baccelli Subject: Re: [Autoconf] Re: Scenarios and Requirements References: <7.0.0.16.2.20071116130938.05163c18@ie.niigata-u.ac.jp> <008001c82838$50f37030$f2da5090$@nl> <473D7695.1060808@gmail.com> <00b101c82848$bd7580d0$38608270$@nl> <473D9D60.6090009@gmail.com> <473DA439.9070303@inria.fr> <00d101c82860$2a3cd3a0$7eb67ae0$@nl> <473DB35E.4030406@inria.fr> <473DB3C2.6090405@telecomitalia.it> <1B345D27-0BC6-443A-80A5-2178D8CB41A2@thomasclausen.org> <00ea01c8287a$464a3a50$d2deaef0$@nl> <473DF63F.2030505@gmail.com> <012401c828ef$292cb630$7b862290$@nl> <473F3CE0.50807@gmail.com> <006a01c82a2e$f325ebb0$d971c310$@nl> <47416F4A.4020002@gmail.com> <003901c82aa6$5b92e370$12b8aa50$@nl> <4741890E.1070908@inria.fr> <005601c82ab3$c16148b0$4423da10$@nl> <4742EAB4.2070101@inria.fr> <00a301c82b86$6bb64ae0$4322e0a0$@nl> <47431BC0.7000204@inria.fr> <474332E5.2050707@gmail.com> <4743F71E.3090705@inria.fr> In-Reply-To: <4743F71E.3090705@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 071120-0, 20/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac 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: > > > Alexandru Petrescu a écrit : >>>> >>>> First, I want to know why we can't use the term DHCP server. I >>>> really can't follow why we are not considering DHCP-PD. >>> >>> DHCP is a solution. We are not talking a solution in particular. >>> We are talking about a fundamental problem, so the vocabulary has >>> to be generic, and precise at the same time. >> >> Sorry, I don't see any fundamental problems. >> >> I don't think we can solve any problem by stating from the start >> it's 'fundamental'. >> >> I will not work on any fundamental problem. >> > > I see. I guess we are still at this point were it is not understood > that there is a problem regarding semi-broadcast... I had a private exchange with Teco recently. We were looking on mail (not real life) at a wifi scenario placed linearly A-C-B with 50m in between. Supposedly A is too far from B to hear it, range being 50m. And then see how to make it work with IPv6. There are several possibilities: a single adhoc essid and a single subnet. Two adhoc essids (A-C and C-B) and a single subnet. C could have one or two interfaces. A single ap-mode essid managed by C as access point. A single subnet or two different subnets (A-C and C-B). Which of these configurations do you think would work? I personally think two subnets and C with two interfaces will surely work; and C as AP and a single subnet will also work. For others combinations I have some doubts. (in these we're considering laptops/pdas/phones with pcmcia or centrino cards, no external antenna - a dedicated 10dbi wifi antenna can extend the range into kilometersbecause a wifi Yagi antenna was reported to hear as far as to 9km, way out of our testing possibilities). >>> An ICP can be a DHCP server, no problem. Soo you agree with the >>> following definition? >>> >>> Internet Configuration Provider (ICP) - An entity that can >>> provide routers requesting configuration with addresses or >>> prefixes derived from a global prefix. >> >> I'd agree if you added "typically a DHCP Server". > > OK, this is possible. In -03 i will add "for example a DHCP Server". Thanks. More DHCP text in the draft that I don't agree with: > For example, in Fig. 1, the MANET router MR3 cannot communicate > directly with a DHCP server [4] that would be available through a > MANET border router, since the server and the MANET router are not > located on the same logical link. While DHCP can to some extent > overcome this issue in a static network, it is not the case in a > dynamic topology, as explained below. [Figure 1 and explanation > following] I think even in a dynamic topology DHCP works. In the figure you pictured there's an entity missing in the picture. It's a MR that you replaced with 3 dots. It's MR4, the last hop router towards the MR3 on which you want to allocate a prefix. That router is the DHCP Relay. Imagine that topology is fixed one moment. DHCP works ok for MR3. Then topology starts to move, MR4 moves away and MR5 takes its place. Nothing else moved. Now MR4 will re-start DHCP (basically send Solicit again), MR5 will relay it to the server and so on. Of course, MR5 must be pre-configured as a Relay with the DHCP Server's address. In this movement scenarion DHCP works ok. What is the movement scenario where you think DHCP doesn't work? >>>>>> On DHCP-PD, I reread the problem statement document. When >>>>>> all nodes >>>>> perform >>>>>> DHCP functions, as 3633 RR and DR, what are the problems? I >>>>>> don't >>>>> think this >>>>>> scenario is optimal, but it should work. Problems could be: >>>>>> - BR ingress filter, relation with routing - Session >>>>>> continuity problem when path via BR is not available >>>>> anymore >>>>>> - Running DHCP on some platforms - Inefficient address >>>>>> usage >>>>> Yes, especially you'd get into trouble if no server is >>>>> reachable and the MANET is not "full mesh". This is the case >>>>> of most standalone MANETs, for instance. >>>> >>>> I think DHCP can perfectly being used, as long as it is >>>> reachable. If no DHCP is reachable, I assume the MANET is >>>> standalone, OK? So there is no need for GA. When there is a >>>> DHCP reachable (single hop, using link local or MLA), it can >>>> provide an MLA. Using such an MLA can be more efficient for >>>> transport over PacketBB related to random MLA (see different >>>> thread for details). I think MLA can be relatively static, e.g. >>>> using long DHCP lease times. Reachability to DHCP server is >>>> needed every now and then. >>>> >>> >>> I agree that DHCP is a strong candidate for part of the solution >>> to the connected MANET case. But it is only a candidate, and it >>> does not solve everything. Do you agree on this? >> >> It is a good candidate. It may solve many scenarios. I haven't >> seen a scenario where it wouldn't work, and where stateless >> autoconf wouldn't work, but I'm interested to learn it. >> > > Are you saying that there is no issues using DHCP and ND with - > dynamic topology - semi-broadcast behavior - network > merging/partitionning (I think there are some issues with DHCP Prefix Delegation and DHCP Relay relating to routing..) The issues of DHCP and ND have nothing to do with eg dynamic topology as long as we don't say precisely what _is_ dynamic topology, how things move at IP layer and what are the ranges and control points. Semi-broadcast behaviour is a MANET term, experimented with WiFi links. I'm wondering whether 'semi-broadcast' appears in 802.11 specs, and to which wifi term would it correspond. Could someone explain what "[SBI] exhibits time-varying asymmetric reachability and spatially distributed MANET routers" means in terms of 802.11 standards and implementations? Or in terms of ND and ARP and DHCP? From that we can discuss. Network merging/partitioning are terms that appear to be specific to MANET networks. At the same time they look very simmilar to how networks are automatically built (NAT, DHCP, ND, stateless, link-local addresses)with various PDA devices. However no relationship is made between the two, that's why I don't understand what is 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 Wed Nov 21 06:49:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuo4v-00015l-0O; Wed, 21 Nov 2007 06:49:13 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Iuo4t-00015f-AO for autoconf-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 06:49:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuo4s-00015X-Rt for autoconf@ietf.org; Wed, 21 Nov 2007 06:49:10 -0500 Received: from an-out-0708.google.com ([209.85.132.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iuo4p-00021S-0x for autoconf@ietf.org; Wed, 21 Nov 2007 06:49:10 -0500 Received: by an-out-0708.google.com with SMTP id d11so571559and for ; Wed, 21 Nov 2007 03:49:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=tc7lrGV80ilaI/BHgSY2kBkeBW1fXrty5J+6R57SgTk=; b=faw4qCcDqYn2wbbthkth7waqdftv+uSLpATrDSuVPFLl9Kfc488j1CObpN+jnvvNiN2ia7ZLsJiJ4a2MwfFRkL0rg3RxGcHb+LgSK054HDMY0xJlJeVJFGhY/xUVoFJiSTN9BQgFauDjjJJ1DQVDwaVd3qYQZx7pCF2XqGrflhc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=YlqFhU+0nwmRzmo/bG/a+ttnB1DcX8clwxjP5svnmhgLfWVtEzTHglN5bjwELnOkNV9S/MlLFJp+SB7QhtfJladxBmSZcxChDFDXYCIWYEI2p6Wdoy/QYzJU+MHEHRUQySo/TtQi1RdgHupTDJrGN2dJ3eniP7fYyUcWrWHBwyw= Received: by 10.100.41.16 with SMTP id o16mr9552519ano.1195645746704; Wed, 21 Nov 2007 03:49:06 -0800 (PST) Received: by 10.100.229.8 with HTTP; Wed, 21 Nov 2007 03:49:06 -0800 (PST) Message-ID: Date: Wed, 21 Nov 2007 17:19:06 +0530 From: Shubhranshu To: "Jari Arkko" , iesg-secretary@ietf.org, autoconf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: Thomas Clausen Subject: [Autoconf] Request to publish draft-ietf-autoconf-manetarch-07.txt 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 This is a request to publish draft-ietf-autoconf-manetarch-07.txt . I am the shepherding WG chair for this document. Please find below the shepherd write-up for this document: Shepherd Write-Up: ================ 1. Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready to forward to the IESG for publication? YES. 2. Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? YES, the ID has been adequately reviewed from both key WG members and key non-WG members. NO, there is no concern about the reviews. 3. Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? NO. 4. Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up. NO. 5. How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? GOOD consensus exists behind this document. 6. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email to the Responsible Area Director. NO. There were no objections raised during the extended WGLC 7. Have the chairs verified that the document adheres to all of the ID Checklist items ? YES. 8. Is the document split into normative and informative references? Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (note here that the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.) NO, the document has only informative references and does not split into normative and informative references. 9. What is the intended status of the document? (e.g., Proposed Standard, Informational?) Informational. 10. * Technical Summary The document discusses Mobile Ad hoc NETworks (MANETs). It presents the initial motivation for MANET and describes unaccustomed characteristics and challenges. It also defines a MANET, other MANET entities, and MANET architectural concepts. * Working Group Summary It was required to have the MANET architecture well understood and documented before focusing on the solution space. Lot of discussion focused on the addressing and prefix model for MANET, which was then integrated and is reflected in this version of the document. * Protocol Quality This document is the result of a very long discussion and interaction among the members of the Internet area in general and MANET group in particular. The document describes the MANET architecture which has evolved over the past several years based on the long MANET protocol design and implementation experiences. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 21 08:23:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IupYJ-00043P-Sh; Wed, 21 Nov 2007 08:23:39 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IupYJ-00043F-6Y for autoconf-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 08:23:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IupYI-000437-PL for autoconf@ietf.org; Wed, 21 Nov 2007 08:23:38 -0500 Received: from mail4-relais-sop.national.inria.fr ([192.134.164.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IupYF-0004gO-3l for autoconf@ietf.org; Wed, 21 Nov 2007 08:23:38 -0500 X-IronPort-AV: E=Sophos;i="4.21,446,1188770400"; d="scan'208";a="19534212" Received: from vad99.v.pppool.de (HELO [192.168.178.25]) ([89.57.173.153]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Nov 2007 14:23:32 +0100 Message-ID: <47443152.5070807@inria.fr> Date: Wed, 21 Nov 2007 14:23:30 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org Subject: Re: [Autoconf] I-D Action:draft-ietf-autoconf-statement-02.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 Alexandru Petrescu a écrit : > Emmanuel Baccelli wrote: >> >> >> Alexandru Petrescu a écrit : >>> Alexandru Petrescu wrote: >>>> Emmanuel Baccelli wrote: >>>> >>>>> Alexandru Petrescu a écrit : >>>>>>> >>>>>>> What would you suggest we use to replace the generic terms "prefix delegation". I didn't know it was such DHCP tainted. I though it was just a generic term, at the base of Internet addressing schemes. >>>>>> >>>>>> I was thinking maybe something like 'admninistratively assigned by a human network planner' or maybe 'statically and manually configured' depending on context. Other people may use different? >>>>>> >>>>> Well, it may be done automatically too right? So I'm afraid what you >>>>> propose is not approriate... >>>> >>>> I don't think there's no means to automatically administratively assign >>> --------------------- ^strike 'no', I meant 'any'. >>>> prefixes to a machine remotely (other than DHCPv6-PD and some use of >>>> Router Renumbering). >>>> >>>> If you think there's a method for automatically administratively >>>> assigning of prefixes please say so, thanks, I don't know what is intended. >>> >>> Do you think there's any means to automatically administratively assign prefixes? >>> >>> Alex >> >> I also think that DHCP is a candidate to solve part of the problem, and it is clearly said in the draft. OK. But what I don't understand is that it seems you have the impression the draft forbids DHCP as part of a solution. What is said in the draft about not being able to use DHCP as part of a solution? Please tell me. > > I've replied publicly to this. It's about the draft saying that DHCP can not accommodate the dynamic networks: > >> > For example, in Fig. >> 1, the MANET router MR3 cannot communicate directly with a DHCP >> server [4] that would be available through a MANET border router, >> since the server and the MANET router are not located on the same >> logical link. While DHCP can to some extent overcome this issue in a >> static network, it is not the case in a dynamic topology, as >> explained below. > I'm sorry but if DHCP worked "as-is" on MANETs then it would have been used off the shelf since long ago by people who need automatic address configuration on MANETs. This is not the case. So there must be a reason why, don't you think? Emmanuel _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 21 08:39: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 1Iupna-0000Fu-Rv; Wed, 21 Nov 2007 08:39:26 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IupnZ-00005O-AI for autoconf-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 08:39:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IupnY-0008R4-Pm for autoconf@ietf.org; Wed, 21 Nov 2007 08:39:24 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IupnY-0000rR-9R for autoconf@ietf.org; Wed, 21 Nov 2007 08:39:24 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-153.messagelabs.com!1195652362!4705629!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 30749 invoked from network); 21 Nov 2007 13:39:22 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-12.tower-153.messagelabs.com with SMTP; 21 Nov 2007 13:39:22 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id lALDdMpp028095; Wed, 21 Nov 2007 06:39:22 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id lALDdLXF021516; Wed, 21 Nov 2007 07:39:22 -0600 (CST) 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 lALDdKcB021505; Wed, 21 Nov 2007 07:39:20 -0600 (CST) Message-ID: <47443507.6020105@gmail.com> Date: Wed, 21 Nov 2007 14:39:19 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Shubhranshu Subject: Re: [Autoconf] Request to publish draft-ietf-autoconf-manetarch-07.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071120-0, 20/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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: [...] > 4. Do you have any specific concerns/issues with this document that > you believe > the ADs and/or IESG should be aware of? For example, perhaps you are > uncomfortable with certain parts of the document, or have concerns > whether there really is a need for it. In any event, if your issues > have been discussed in the WG and the WG has indicated it that it > still wishes to advance the document, detail those concerns in the > write-up. > > NO. No? I've just raised yesterday an issue about multicast interpretation confusion between manetarch and problem statement documents. HAs that been solved already? A decision made? The issue is here, and the following thread keeps the subject: http://www1.ietf.org/mail-archive/web/autoconf/current/msg00771.html Was there a decision made with respect to this issue? It seems like the confusing issue around multicast that I've raised is completely ignored?? Alex PS: I removed IESG from Cc to not create further problems. But you understand what I mean. ______________________________________________________________________ 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 Nov 21 09:03: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 1IuqAq-0006K4-UJ; Wed, 21 Nov 2007 09:03:28 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuqAo-0005z2-TH for autoconf-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 09:03:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuqAo-0005tn-DB for autoconf@ietf.org; Wed, 21 Nov 2007 09:03:26 -0500 Received: from mail4-relais-sop.national.inria.fr ([192.134.164.105]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuqAn-0001oA-Uu for autoconf@ietf.org; Wed, 21 Nov 2007 09:03:26 -0500 X-IronPort-AV: E=Sophos;i="4.21,446,1188770400"; d="scan'208";a="19535828" Received: from vad99.v.pppool.de (HELO [192.168.178.25]) ([89.57.173.153]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Nov 2007 15:03:24 +0100 Message-ID: <47443AAB.4070009@inria.fr> Date: Wed, 21 Nov 2007 15:03:23 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org References: <47443152.5070807@inria.fr> <474435BA.5020208@motorola.com> In-Reply-To: <474435BA.5020208@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [Autoconf] tentative draft-ietf-autoconf-problem-statement-03.txt 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 All, after the feedback received from Alex, Teco, Carlos, Ronald, Thomas (thanks to all of you), a tentative -03 is available on a server reachable at http://djincoda.free.fr/autoconf-PS/draft-ietf-autoconf-problem-statement-03.txt Highlights about the updates include: - the definition of the term ICP is more precise - even more explicit mention that DHCP etc. may be part of a solution - typos corrected here and there - global address terminology updated - more precision regarding issues developped in 4.1.x Alex, you were suggesting to write up a paragraph about even more details on DHCP shortcomings. Can you propose some text and a place to put it in -03 ? Otherwise, please take -03 as the base for further discussions as of now. Cheers Emmanuel Alexandru Petrescu a écrit : > Emmanuel Baccelli wrote: > [...] >> > I've replied publicly to this. It's about the draft saying that >> DHCP can not accommodate the dynamic networks: >> > >> >> > For example, in Fig. >> >> 1, the MANET router MR3 cannot communicate directly with a DHCP >> >> server [4] that would be available through a MANET border router, >> >> since the server and the MANET router are not located on the same >> >> logical link. While DHCP can to some extent overcome this >> issue in a >> >> static network, it is not the case in a dynamic topology, as >> >> explained below. >> > >> >> I'm sorry but if DHCP worked "as-is" on MANETs then it would have been >> used off the shelf since long ago by people who need automatic address >> configuration on MANETs. This is not the case. So there must be a >> reason why, don't you think? > > There may be a reason. Can we see it? Can one enumerate the issues > with DHCP not working in MANETs? > > As I said earlier, I can see palpable issues with DHCP Prefix Delegation > not updating its routing table when delegating a prefix through a Relay. > Or maybe an issue with decisions about who _is_ the DHCP Server in a > set of entities that could all be. But nobody describes these. > > Alex > > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 21 09:10:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuqHR-00084g-TF; Wed, 21 Nov 2007 09:10:17 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuqHP-00084W-KO for autoconf-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 09:10:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuqHO-00084O-Le for autoconf@ietf.org; Wed, 21 Nov 2007 09:10:14 -0500 Received: from smtp03.uc3m.es ([163.117.176.133] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuqHL-0006Bu-Qn for autoconf@ietf.org; Wed, 21 Nov 2007 09:10:14 -0500 Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.uc3m.es (Postfix) with ESMTP id AD9C023EF8C; Wed, 21 Nov 2007 15:02:09 +0100 (CET) Subject: Re: [Autoconf] Comments on draft-ietf-autoconf-statement-02.txt From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Alexandru Petrescu In-Reply-To: <47440BE0.4000706@gmail.com> References: <1195604687.5119.43.camel@localhost> <474402DE.1010805@telecomitalia.it> <1195641261.4670.33.camel@localhost> <47440BE0.4000706@gmail.com> Organization: Universidad Carlos III de Madrid Date: Wed, 21 Nov 2007 15:02:10 +0100 Message-Id: <1195653730.4670.43.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 X-Spam-Score: -4.0 (----) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1613899953==" Errors-To: autoconf-bounces@ietf.org --===============1613899953== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-jo2g6Yjm6Y9ftEBAb7zu" --=-jo2g6Yjm6Y9ftEBAb7zu Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Alex, El mi=E9, 21-11-2007 a las 11:43 +0100, Alexandru Petrescu escribi=F3: > Carlos Jes=FAs Bernardos Cano wrote: > [...] > >> Simone wrote: > >> Reading this statement again (sorry, we wrote this sentence a time > >> ago...), I think that we "zipped" our thoughts in one sentence, > >> leaving out some detail. IIRC, I think here the problem is not the > >> "multi-hop" environment (incidentally, if you think of "normal" ISP > >> network, which are multi-hop, rfc4862 perfectly works). The problem > >> here is the "intermittent reachability": if MANET router=20 > >> experiences bad connectivity to its neighbors, it _could_ be > >> forced, for example, to repeat DAD on MANET interface much more > >> times than in managed networks, thus bringing inefficiency. > >=20 > > Yes, and it's not only that, but the fact that if we assume the same=20 > > IPv6 prefix is used for all the nodes within the MANET (again, that=20 > > depends on the model we are thinking of), DAD as it is defined for=20 > > non-MANET networks will not ensure the address uniqueness, >=20 > I don't understand... if the entire MANET has only one prefix and only > one subnet then DAD will surely ensure address uniqueness. I'm referring to the model where in a multi-hop network ("classic" MANET model), nodes configure addresses belonging to the same address prefix (not judging if this model makes sense or not). In this case, the DAD protocol doesn't work, right? If then we add merging, things get more complicated... Regards, Carlos >=20 > Simone says that if a MANET router has bad connectivity to > its neighbor then it could be forced to repeat DAD more often than if > the connectivity was stable. But isn't this true for _any_ protocol? > If connectivity is troublesome then IP protocols will break, including > any new one. >=20 > DAD has a timer and variables (eg count of NS messages to send before > deciding there's no NA) that can be tweaked to accommodate a certain > level of intermitency in connectivity. >=20 > Alex >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email=20 > ______________________________________________________________________ --=20 =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-jo2g6Yjm6Y9ftEBAb7zu Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHRDpiNdy6TdFwT2cRAnK0AKDSZ/HubuZUSQez4w2DeW0JQANC1QCffdv2 3ZL7zpT0IqdhWnJYiTtqqP8= =leS/ -----END PGP SIGNATURE----- --=-jo2g6Yjm6Y9ftEBAb7zu-- --===============1613899953== 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 --===============1613899953==-- From autoconf-bounces@ietf.org Wed Nov 21 09:12:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuqJA-0001tl-2E; Wed, 21 Nov 2007 09:12:04 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuqJ8-0001mH-N0 for autoconf-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 09:12:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuqJ8-0001kT-Ac for autoconf@ietf.org; Wed, 21 Nov 2007 09:12:02 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IuqJ5-0006Es-0w for autoconf@ietf.org; Wed, 21 Nov 2007 09:12:02 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1195654318!22891897!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 8222 invoked from network); 21 Nov 2007 14:11:58 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-8.tower-119.messagelabs.com with SMTP; 21 Nov 2007 14:11:58 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id lALEBvjD020864 for ; Wed, 21 Nov 2007 07:11:57 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id lALEBvWm015577 for ; Wed, 21 Nov 2007 08:11:57 -0600 (CST) 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 lALEBthd015500 for ; Wed, 21 Nov 2007 08:11:56 -0600 (CST) Message-ID: <47443CA6.5030800@gmail.com> Date: Wed, 21 Nov 2007 15:11:50 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) 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 071120-0, 20/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [Autoconf] Potential issues with MANET arch document 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've been asked privately why I think there are some issues with the manetarch document. HEre are some more: > Semi-Broadcast Interface (SBI) > A broadcast capable interface that may exhibit asymmetric > reachability. Multiple access wireless radio interfaces are often > SBI. Note that since a SBI *may* exhibit asymmetric reachability, > it also may not. Please explain more what a SBI interface is. If this SBI comes from a wifi experience please explain in wifi terms. The 802.11/wifi standards and implementation don't use this term, so I'm really confused by this term altogether. Please explain how asymmetric reachability matches UDLR concepts. Please explain what "Multiple access wireless radio interfaces" mean: a interface connected to multiple radios? Or several types of interfaces? Please explain what asymmetric means in terms of asymmetric bandwidth, asymmetric MTU, asymmetric fragmentation; like when we talk ADSL or PMTU. > 4.2.1. Semi-Broadcast Interface > > Given a wireless SBI that exhibits time-varying asymmetric > reachability and spatially distributed MANET routers, each MANET > router may have a different unique partial view of the MANET. Please explain what "time-varying asymmetric reachability and spatially distributed MANET routers mean". That's my last mail. 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 Nov 21 09:14: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 1IuqLN-00041H-Oh; Wed, 21 Nov 2007 09:14:21 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuqLM-0003yS-JJ for autoconf-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 09:14:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuqLM-0003xw-9V for autoconf@ietf.org; Wed, 21 Nov 2007 09:14:20 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IuqLI-0006I8-T9 for autoconf@ietf.org; Wed, 21 Nov 2007 09:14:20 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-128.messagelabs.com!1195654455!21371030!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 32704 invoked from network); 21 Nov 2007 14:14:15 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-15.tower-128.messagelabs.com with SMTP; 21 Nov 2007 14:14:15 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id lALEEDN0021206; Wed, 21 Nov 2007 07:14:15 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id lALEECs5016791; Wed, 21 Nov 2007 08:14:12 -0600 (CST) 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 lALEEAD2016696; Wed, 21 Nov 2007 08:14:11 -0600 (CST) Message-ID: <47443D2C.2070406@gmail.com> Date: Wed, 21 Nov 2007 15:14:04 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Emmanuel Baccelli Subject: Re: [Autoconf] tentative draft-ietf-autoconf-problem-statement-03.txt References: <47443152.5070807@inria.fr> <474435BA.5020208@motorola.com> <47443AAB.4070009@inria.fr> In-Reply-To: <47443AAB.4070009@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071120-0, 20/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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: > All, > > after the feedback received from Alex, Teco, Carlos, Ronald, Thomas > (thanks to all of you), a tentative -03 is available on a server > reachable at > http://djincoda.free.fr/autoconf-PS/draft-ietf-autoconf-problem-statement-03.txt > > > Highlights about the updates include: > > - the definition of the term ICP is more precise > - even more explicit mention that DHCP etc. may be part of a solution > - typos corrected here and there > - global address terminology updated > - more precision regarding issues developped in 4.1.x > > Alex, you were suggesting to write up a paragraph about even more > details on DHCP shortcomings. Can you propose some text and a place to > put it in -03 ? YEs, I can. Remark though I will no longer post on this list. I will send you privately the DHCP shortcomings text. > Otherwise, please take -03 as the base for further discussions as of now. Thanks, 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 Nov 21 09:46: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 1Iuqqe-0006N7-Cl; Wed, 21 Nov 2007 09:46:40 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Iuqqd-0006Iu-4T for autoconf-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 09:46:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuqqc-0006Gs-QO for autoconf@ietf.org; Wed, 21 Nov 2007 09:46:38 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuqqW-00078y-Re for autoconf@ietf.org; Wed, 21 Nov 2007 09:46:38 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 21 Nov 2007 09:46:32 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lALEkWrF016358; Wed, 21 Nov 2007 09:46:32 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lALEkWKH019723; Wed, 21 Nov 2007 14:46:32 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 09:46:30 -0500 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] Request to publish draft-ietf-autoconf-manetarch-07.txt Date: Wed, 21 Nov 2007 09:46:30 -0500 Message-ID: <7FB7EE0A621BA44B8B69E5F0A09DC76404F8C206@xmb-rtp-208.amer.cisco.com> In-Reply-To: <47443507.6020105@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Request to publish draft-ietf-autoconf-manetarch-07.txt Thread-Index: AcgsRADU/Jwd43PGQhORi6LtcRt8vgACP5kg From: "Stan Ratliff (sratliff)" To: "Alexandru Petrescu" , "Shubhranshu" X-OriginalArrivalTime: 21 Nov 2007 14:46:30.0942 (UTC) FILETIME=[4DCCA3E0:01C82C4D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2033; t=1195656392; x=1196520392; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20=22Stan=20Ratliff=20(sratliff)=22=20 |Subject:=20RE=3A=20[Autoconf]=20Request=20to=20publish=20draft-ietf-auto conf-manetarch-07.txt |Sender:=20 |To:=20=22Alexandru=20Petrescu=22=20, =0A=20 =20=20=20=20=20=20=20=22Shubhranshu=22=20; bh=g3hknJLdemQtXiVkwSD+xvtaaNekn/UM5IHVUB/5d6E=; b=nH1XwxWB5esckSyDT0JyFXvv1VaWQWOieAL7v32TxXRn95GFVC9JNL4sBusgELkgant6FK3c isET+VCEcXDf6v5dmktcFr8HBJr8AOnQA2Mgn6ASetaanA7c5j2hKjvR; Authentication-Results: rtp-dkim-2; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.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 agree with Alex -- there is a sufficient amount of confusion or difference of opinion that I think it's premature to push the draft at this time.=20 Regards, Stan=20 >-----Original Message----- >From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 >Sent: Wednesday, November 21, 2007 8:39 AM >To: Shubhranshu >Cc: autoconf@ietf.org >Subject: Re: [Autoconf] Request to publish=20 >draft-ietf-autoconf-manetarch-07.txt > > >Shubhranshu wrote: >[...] >> 4. Do you have any specific concerns/issues with this=20 >document that >> you believe >> the ADs and/or IESG should be aware of? For example, perhaps you are >> uncomfortable with certain parts of the document, or have concerns >> whether there really is a need for it. In any event, if your issues >> have been discussed in the WG and the WG has indicated it that it >> still wishes to advance the document, detail those concerns in the >> write-up. >>=20 >> NO. > >No? > >I've just raised yesterday an issue about multicast interpretation=20 >confusion between manetarch and problem statement documents. HAs that=20 >been solved already? A decision made? The issue is here, and the=20 >following thread keeps the subject: >http://www1.ietf.org/mail-archive/web/autoconf/current/msg00771.html > >Was there a decision made with respect to this issue? It=20 >seems like the=20 >confusing issue around multicast that I've raised is=20 >completely ignored?? > >Alex >PS: I removed IESG from Cc to not create further problems. But you > understand what I mean. > > >______________________________________________________________________ >This email has been scanned by the MessageLabs Email Security System. >For more information please visit http://www.messagelabs.com/email=20 >______________________________________________________________________ > > >_______________________________________________ >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 Wed Nov 21 09:54:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuqyS-0002ra-NF; Wed, 21 Nov 2007 09:54:44 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IuqyR-0002rT-66 for autoconf-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 09:54:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuqyQ-0002rL-RO for autoconf@ietf.org; Wed, 21 Nov 2007 09:54:42 -0500 Received: from smtp2.bae.co.uk ([20.133.0.12]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuqyQ-0003DH-4w for autoconf@ietf.org; Wed, 21 Nov 2007 09:54:42 -0500 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id lALEse23012112 for ; Wed, 21 Nov 2007 14:54:40 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id lALEseQM029907 for ; Wed, 21 Nov 2007 14:54:40 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 21 Nov 2007 14:54:40 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 21 Nov 2007 14:54:40 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Autoconf] Request to publish draft-ietf-autoconf-manetarch-07.txt Date: Wed, 21 Nov 2007 14:54:39 -0000 Message-ID: In-Reply-To: <7FB7EE0A621BA44B8B69E5F0A09DC76404F8C206@xmb-rtp-208.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Request to publish draft-ietf-autoconf-manetarch-07.txt Thread-Index: AcgsRADU/Jwd43PGQhORi6LtcRt8vgACP5kgAAAlCyA= References: <47443507.6020105@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76404F8C206@xmb-rtp-208.amer.cisco.com> From: "Dearlove, Christopher (UK)" To: "Stan Ratliff (sratliff)" , "Alexandru Petrescu" , "Shubhranshu" X-OriginalArrivalTime: 21 Nov 2007 14:54:40.0357 (UTC) FILETIME=[71837150:01C82C4E] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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'm seeing a lot of disussion on the problem statement, but this is about the architecture document. Putting aside failures to understand the basic principles of wireless communications, what's the confusion on the architecture document? (Please note that's a question, not a statement either way.) -----Original Message----- From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 Sent: 21 November 2007 14:47 To: Alexandru Petrescu; Shubhranshu Cc: autoconf@ietf.org Subject: RE: [Autoconf] Request to publish draft-ietf-autoconf-manetarch-07.txt *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 I agree with Alex -- there is a sufficient amount of confusion or difference of opinion that I think it's premature to push the draft at this time.=20 Regards, Stan=20 >-----Original Message----- >From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 >Sent: Wednesday, November 21, 2007 8:39 AM >To: Shubhranshu >Cc: autoconf@ietf.org >Subject: Re: [Autoconf] Request to publish=20 >draft-ietf-autoconf-manetarch-07.txt > > >Shubhranshu wrote: >[...] >> 4. Do you have any specific concerns/issues with this=20 >document that >> you believe >> the ADs and/or IESG should be aware of? For example, perhaps you are >> uncomfortable with certain parts of the document, or have concerns >> whether there really is a need for it. In any event, if your issues >> have been discussed in the WG and the WG has indicated it that it >> still wishes to advance the document, detail those concerns in the >> write-up. >>=20 >> NO. > >No? > >I've just raised yesterday an issue about multicast interpretation=20 >confusion between manetarch and problem statement documents. HAs that=20 >been solved already? A decision made? The issue is here, and the=20 >following thread keeps the subject: >http://www1.ietf.org/mail-archive/web/autoconf/current/msg00771.html > >Was there a decision made with respect to this issue? It=20 >seems like the=20 >confusing issue around multicast that I've raised is=20 >completely ignored?? > >Alex >PS: I removed IESG from Cc to not create further problems. But you > understand what I mean. > > >______________________________________________________________________ >This email has been scanned by the MessageLabs Email Security System. >For more information please visit http://www.messagelabs.com/email=20 >______________________________________________________________________ > > >_______________________________________________ >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 ******************************************************************** 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 Wed Nov 21 10:03:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iur6k-0002f6-Ml; Wed, 21 Nov 2007 10:03:18 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Iur6i-0002TX-RW for autoconf-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 10:03:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iur6i-0002RG-GM for autoconf@ietf.org; Wed, 21 Nov 2007 10:03:16 -0500 Received: from maile.telecomitalia.it ([156.54.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iur6c-0007kz-D0 for autoconf@ietf.org; Wed, 21 Nov 2007 10:03:16 -0500 thread-index: AcgsT5yn5gmEkPRlSIuq/kXDU+7r6g== Received: from ptpxch010ba020.idc.cww.telecomitalia.it ([156.54.240.53]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 16:03:02 +0100 Received: from ptpxch004ba020.idc.cww.telecomitalia.it ([156.54.240.43]) by ptpxch010ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 16:03:01 +0100 Received: from [10.229.4.26] ([10.229.4.26]) by ptpxch004ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 16:03:00 +0100 Message-ID: <47444837.1070601@telecomitalia.it> Date: Wed, 21 Nov 2007 16:01:11 +0100 Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2929 From: "Simone Ruffino" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Alexandru Petrescu" Subject: Re: [Autoconf] tentative draft-ietf-autoconf-problem-statement-03.txt References: <47443152.5070807@inria.fr> <474435BA.5020208@motorola.com> <47443AAB.4070009@inria.fr> <47443D2C.2070406@gmail.com> In-Reply-To: <47443D2C.2070406@gmail.com> Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 21 Nov 2007 15:03:00.0939 (UTC) FILETIME=[9BE231B0:01C82C4F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 Alexandru Petrescu wrote: > Emmanuel Baccelli wrote: >> All, >> >> after the feedback received from Alex, Teco, Carlos, Ronald, Thomas=20 >> (thanks to all of you), a tentative -03 is available on a server=20 >> reachable at=20 >> = http://djincoda.free.fr/autoconf-PS/draft-ietf-autoconf-problem-statement= -03.txt=20 >> >> >> Highlights about the updates include: >> >> - the definition of the term ICP is more precise >> - even more explicit mention that DHCP etc. may be part of a solution >> - typos corrected here and there >> - global address terminology updated >> - more precision regarding issues developped in 4.1.x >> >> Alex, you were suggesting to write up a paragraph about even more=20 >> details on DHCP shortcomings. Can you propose some text and a place=20 >> to put it in -03 ? > > YEs, I can. Remark though I will no longer post on this list. I will = > send you privately the DHCP shortcomings text. > Alex, my suggestion is to post them here, instead. Because they can be=20 part of the problems we're going to describe. >> Otherwise, please take -03 as the base for further discussions as of=20 >> now. > > Thanks, > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email=20 > ______________________________________________________________________ > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please contact us by replying to = webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- =20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 21 10:10:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IurDv-0004gY-PP; Wed, 21 Nov 2007 10:10:43 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IurDu-0004gR-JV for autoconf-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 10:10:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IurDu-0004gJ-9m for autoconf@ietf.org; Wed, 21 Nov 2007 10:10:42 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IurDr-0007wP-BO for autoconf@ietf.org; Wed, 21 Nov 2007 10:10:42 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-3.tower-128.messagelabs.com!1195657620!7285671!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 5731 invoked from network); 21 Nov 2007 15:07:00 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-3.tower-128.messagelabs.com with SMTP; 21 Nov 2007 15:07:00 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id lALF6sRr012401; Wed, 21 Nov 2007 08:06:54 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id lALF6riO017800; Wed, 21 Nov 2007 09:06:53 -0600 (CST) 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 lALF6p5d017772; Wed, 21 Nov 2007 09:06:52 -0600 (CST) Message-ID: <4744498A.2090704@gmail.com> Date: Wed, 21 Nov 2007 16:06:50 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Simone Ruffino Subject: Re: [Autoconf] tentative draft-ietf-autoconf-problem-statement-03.txt References: <47443152.5070807@inria.fr> <474435BA.5020208@motorola.com> <47443AAB.4070009@inria.fr> <47443D2C.2070406@gmail.com> <47444837.1070601@telecomitalia.it> In-Reply-To: <47444837.1070601@telecomitalia.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071120-0, 20/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 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 This is what I've just sent to Emmanuel about noticed shortcomings of DHCP in some MANET-like deployemnts. Alex > For the following text: > > For example, in Fig. 1, the MANET router MR3 cannot communicate > directly with a DHCP server [4] that would be available through a > border router, since the border router and MR3 are not located on > the same logical link. While DHCP can to some extent overcome this > issue in a static network, it is not the case in a dynamic > topology, as explained below. On the other hand IPv6 Stateless > Address Autoconfiguration [5] and Neighbor Discovery for IPv6 [3] > do not account for potential address duplication beyond a single > multicast-capable link. > > > ----- MR1...MR3 > / . > +-------------+ +------------+ / . > | | p2p | |/ . (MANET) > | ISP Edge | Link | Border | . > | Router +---------+ Router |\ . > | | | | \ . > +-------------+ +------------+ \----- MR2 > > Fig. 1. Connected MANET router topology. > > With the following: > > For example, in Figure 1, we assume that the "p2p Link" > (point-to-point link) and the links BR-MR1, MR1-MR2 and MR2-MR3 all > have distinctive IP subnets assigned. The MR3 needs to be assigned > an IPv6 prefix. The MANET router MR3 does not yet know the IP > address of the DHCPv6 Server, so it needs to discover it by using > link-layer multicast mechanisms and IP-layer multicast. It is > possible for MR2 to run DHCP Relay software. In this case the MR3 > would send a DHCP Solicit message (IP dst address is a IP multicast > address), message preceded by a header containing a link-layer > multicast address as destination. The Solicit message would be > further sent by MR2 (DHCP Relay) to the the ISP Edge Router (DHCP > Server). After this initial step the next DHCPv6 exchanges would > be performed such that the MR3 obtains a prefix. > > > ----- MR1-MR2-MR3 > / . > +-------------+ +------------+ / . > | | p2p | |/ . (MANET) > | ISP Edge | Link | Border | . > | Router +---------+ Router |\ . > | | | | \ . > +-------------+ +------------+ \----- MRn > > Fig. 1. Connected MANET router topology. > > This is a DHCP behaviour that would work in this MANET topology. > However, there may be at least the following two issues: > > -in the group of MANET Routers described above there should be a > dynamic decision of roles about who is a Relay and at what moment. > If MR2 disappears from its place and another MR takes its place > then that router should receive the DHCPv6 Solicit sent by MR3 and > relay it to the DHCPv6 Server. > > -some implementations of DHCPv6 Prefix Delegation will not update > routes on the DHCP Server with respect to the allocated prefix. > Or, when assigning prefixes that don't respect a hierarchical > structure it is necessary when using a Relay to add a new routing > table entry at the DHCP Server whenever a new prefix is assigned > to a new MANET Router. This route should point to the Relay > address. > > These are two issues that appear in the topology pictured in Figure > 1. In this figure the DHCP Server, Border Router, MR1 and MR3 are > assumed to be stable non-moving (only MR2 moves). If we consider > that any entities will also move then there may be more DHCP issues > that could be identified. Simone Ruffino wrote: > > > Alexandru Petrescu wrote: >> Emmanuel Baccelli wrote: >>> All, >>> >>> after the feedback received from Alex, Teco, Carlos, Ronald, Thomas >>> (thanks to all of you), a tentative -03 is available on a server >>> reachable at >>> http://djincoda.free.fr/autoconf-PS/draft-ietf-autoconf-problem-statement-03.txt >>> >>> >>> Highlights about the updates include: >>> >>> - the definition of the term ICP is more precise >>> - even more explicit mention that DHCP etc. may be part of a solution >>> - typos corrected here and there >>> - global address terminology updated >>> - more precision regarding issues developped in 4.1.x >>> >>> Alex, you were suggesting to write up a paragraph about even more >>> details on DHCP shortcomings. Can you propose some text and a place >>> to put it in -03 ? >> >> YEs, I can. Remark though I will no longer post on this list. I will >> send you privately the DHCP shortcomings text. >> > > Alex, my suggestion is to post them here, instead. Because they can be > part of the problems we're going to describe. > >>> Otherwise, please take -03 as the base for further discussions as of >>> now. >> >> Thanks, >> >> 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 > -------------------------------------------------------------------- > > CONFIDENTIALITY NOTICE > > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received the > message in error, be informed that any use of the content hereof is > prohibited. Please return it immediately to the sender and delete the > message. Should you have any questions, please contact us by replying to > webmaster@telecomitalia.it. > > Thank you > > www.telecomitalia.it > > -------------------------------------------------------------------- > ______________________________________________________________________ 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 Nov 21 10:15:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IurIW-00033O-FR; Wed, 21 Nov 2007 10:15:28 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IurIV-00033G-91 for autoconf-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 10:15:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IurIU-000337-Tx for autoconf@ietf.org; Wed, 21 Nov 2007 10:15:26 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IurIU-0004Au-9K for autoconf@ietf.org; Wed, 21 Nov 2007 10:15:26 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 21 Nov 2007 10:15:26 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lALFFPMY020954; Wed, 21 Nov 2007 10:15:25 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lALFFGKh000080; Wed, 21 Nov 2007 15:15:25 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 10:15:08 -0500 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] Request to publish draft-ietf-autoconf-manetarch-07.txt Date: Wed, 21 Nov 2007 10:15:06 -0500 Message-ID: <7FB7EE0A621BA44B8B69E5F0A09DC76404F8C22F@xmb-rtp-208.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Request to publish draft-ietf-autoconf-manetarch-07.txt Thread-Index: AcgsRADU/Jwd43PGQhORi6LtcRt8vgACP5kgAAAlCyAAAI7HIA== From: "Stan Ratliff (sratliff)" To: "Dearlove, Christopher (UK)" , "Alexandru Petrescu" , "Shubhranshu" X-OriginalArrivalTime: 21 Nov 2007 15:15:08.0221 (UTC) FILETIME=[4D609ED0:01C82C51] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5081; t=1195658126; x=1196522126; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20=22Stan=20Ratliff=20(sratliff)=22=20 |Subject:=20RE=3A=20[Autoconf]=20Request=20to=20publish=20draft-ietf-auto conf-manetarch-07.txt |Sender:=20 |To:=20=22Dearlove, =20Christopher=20(UK)=22=20, =0A=20=20=20=20=20=20=20=20=22Alexandru=20Petrescu=22=20, =0A=20=20=20=20=20=20=20=20=22Shubhranshu=22=20; bh=GtNYMB8b1j/46XE/a7vvNVHzBQlpdBC815zmOVBh6Rg=; b=BGFQOcf5gwwhC8DnRk8pQ3GO+7nkK9Oia/Ff/Zz9Bkou7gt/7R4iFH9ZLrECsW642g9GEC18 dh1vR8+a9Ab3eHga1wqa3bWNwMa/H2DxG0z0i0EpXGUNESGq7anSbrJh; Authentication-Results: rtp-dkim-1; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d 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 Chris,=20 As you mention, the discussion is focused on the problem statement.=20 However, I think the concern is that there may be differences in the=20 two, and until the WG reaches consensus as to whether or not that's the case, it would perhaps be best to hold off on pushing the=20 architecture document. Now as to the misunderstanding -- as I understand it, Alex fairly=20 succinctly expressed the confusion : >> >>I've just raised yesterday an issue about multicast interpretation=20 >>confusion between manetarch and problem statement documents.=20 >>Has that been solved already? A decision made? The issue is=20 >>here, and the following thread keeps the subject: >>http://www1.ietf.org/mail-archive/web/autoconf/current/msg00771.html >> >>Was there a decision made with respect to this issue? It seems like=20 >>the confusing issue around multicast that I've raised is=20 >>completely ignored?? >> I don't have a strong opinion on the subject one way or the other (and=20 *that* should be a surprise to the list!); but given the level of discussion recently, I just thought we should see if we can close on a common=20 understanding before proceeding.=20 Regards, Stan >-----Original Message----- >From: Dearlove, Christopher (UK)=20 >[mailto:Chris.Dearlove@baesystems.com]=20 >Sent: Wednesday, November 21, 2007 9:55 AM >To: Stan Ratliff (sratliff); Alexandru Petrescu; Shubhranshu >Cc: autoconf@ietf.org >Subject: RE: [Autoconf] Request to publish=20 >draft-ietf-autoconf-manetarch-07.txt > > >I'm seeing a lot of disussion on the problem statement, >but this is about the architecture document. Putting aside >failures to understand the basic principles of wireless >communications, what's the confusion on the architecture >document? > >(Please note that's a question, not a statement either way.) > > >-----Original Message----- >From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 >Sent: 21 November 2007 14:47 >To: Alexandru Petrescu; Shubhranshu >Cc: autoconf@ietf.org >Subject: RE: [Autoconf] Request to publish >draft-ietf-autoconf-manetarch-07.txt > > > *** WARNING *** > >This mail has originated outside your organization, >either from an external partner or the Global Internet.=20 > Keep this in mind if you answer this message.=20 > >I agree with Alex -- there is a sufficient amount of confusion >or difference of opinion that I think it's premature to push the >draft at this time.=20 > >Regards, >Stan=20 > >>-----Original Message----- >>From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 >>Sent: Wednesday, November 21, 2007 8:39 AM >>To: Shubhranshu >>Cc: autoconf@ietf.org >>Subject: Re: [Autoconf] Request to publish=20 >>draft-ietf-autoconf-manetarch-07.txt >> >> >>Shubhranshu wrote: >>[...] >>> 4. Do you have any specific concerns/issues with this=20 >>document that >>> you believe >>> the ADs and/or IESG should be aware of? For example, perhaps you are >>> uncomfortable with certain parts of the document, or have concerns >>> whether there really is a need for it. In any event, if your issues >>> have been discussed in the WG and the WG has indicated it that it >>> still wishes to advance the document, detail those concerns in the >>> write-up. >>>=20 >>> NO. >> >>No? >> >>I've just raised yesterday an issue about multicast interpretation=20 >>confusion between manetarch and problem statement documents. =20 >HAs that=20 >>been solved already? A decision made? The issue is here, and the=20 >>following thread keeps the subject: >>http://www1.ietf.org/mail-archive/web/autoconf/current/msg00771.html >> >>Was there a decision made with respect to this issue? It=20 >>seems like the=20 >>confusing issue around multicast that I've raised is=20 >>completely ignored?? >> >>Alex >>PS: I removed IESG from Cc to not create further problems. But you >> understand what I mean. >> >> >>______________________________________________________________________ >>This email has been scanned by the MessageLabs Email Security System. >>For more information please visit http://www.messagelabs.com/email=20 >>______________________________________________________________________ >> >> >>_______________________________________________ >>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 > > >******************************************************************** >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 Wed Nov 21 10:22:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IurOs-0002x9-VR; Wed, 21 Nov 2007 10:22:03 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IurOo-0002ux-P2 for autoconf-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 10:21:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IurOo-0002up-FB for autoconf@ietf.org; Wed, 21 Nov 2007 10:21:58 -0500 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IurOk-0008Fd-F5 for autoconf@ietf.org; Wed, 21 Nov 2007 10:21:58 -0500 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id lALFLnK8029834 for ; Wed, 21 Nov 2007 15:21:49 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id lALFLoKa018452 for ; Wed, 21 Nov 2007 15:21:50 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 21 Nov 2007 15:21:49 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 21 Nov 2007 15:21:49 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Autoconf] Request to publish draft-ietf-autoconf-manetarch-07.txt Date: Wed, 21 Nov 2007 15:21:48 -0000 Message-ID: In-Reply-To: <7FB7EE0A621BA44B8B69E5F0A09DC76404F8C22F@xmb-rtp-208.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Request to publish draft-ietf-autoconf-manetarch-07.txt Thread-Index: AcgsRADU/Jwd43PGQhORi6LtcRt8vgACP5kgAAAlCyAAAI7HIAAAdMUg References: <7FB7EE0A621BA44B8B69E5F0A09DC76404F8C22F@xmb-rtp-208.amer.cisco.com> From: "Dearlove, Christopher (UK)" To: "Stan Ratliff (sratliff)" , "Alexandru Petrescu" , "Shubhranshu" X-OriginalArrivalTime: 21 Nov 2007 15:21:49.0043 (UTC) FILETIME=[3C493430:01C82C52] X-Spam-Score: -4.0 (----) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 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 think the linked reference comes under the exclusion clause I noted. If that is the only issue, I don't see any reason to postpone. If there are any others, what are they? -----Original Message----- From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 Sent: 21 November 2007 15:15 To: Dearlove, Christopher (UK); Alexandru Petrescu; Shubhranshu Cc: autoconf@ietf.org Subject: RE: [Autoconf] Request to publish draft-ietf-autoconf-manetarch-07.txt *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 Chris,=20 As you mention, the discussion is focused on the problem statement.=20 However, I think the concern is that there may be differences in the=20 two, and until the WG reaches consensus as to whether or not that's the case, it would perhaps be best to hold off on pushing the=20 architecture document. Now as to the misunderstanding -- as I understand it, Alex fairly=20 succinctly expressed the confusion : >> >>I've just raised yesterday an issue about multicast interpretation=20 >>confusion between manetarch and problem statement documents.=20 >>Has that been solved already? A decision made? The issue is=20 >>here, and the following thread keeps the subject: >>http://www1.ietf.org/mail-archive/web/autoconf/current/msg00771.html >> >>Was there a decision made with respect to this issue? It seems like=20 >>the confusing issue around multicast that I've raised is=20 >>completely ignored?? >> I don't have a strong opinion on the subject one way or the other (and=20 *that* should be a surprise to the list!); but given the level of discussion recently, I just thought we should see if we can close on a common=20 understanding before proceeding.=20 Regards, Stan >-----Original Message----- >From: Dearlove, Christopher (UK)=20 >[mailto:Chris.Dearlove@baesystems.com]=20 >Sent: Wednesday, November 21, 2007 9:55 AM >To: Stan Ratliff (sratliff); Alexandru Petrescu; Shubhranshu >Cc: autoconf@ietf.org >Subject: RE: [Autoconf] Request to publish=20 >draft-ietf-autoconf-manetarch-07.txt > > >I'm seeing a lot of disussion on the problem statement, >but this is about the architecture document. Putting aside >failures to understand the basic principles of wireless >communications, what's the confusion on the architecture >document? > >(Please note that's a question, not a statement either way.) > > >-----Original Message----- >From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]=20 >Sent: 21 November 2007 14:47 >To: Alexandru Petrescu; Shubhranshu >Cc: autoconf@ietf.org >Subject: RE: [Autoconf] Request to publish >draft-ietf-autoconf-manetarch-07.txt > > > *** WARNING *** > >This mail has originated outside your organization, >either from an external partner or the Global Internet.=20 > Keep this in mind if you answer this message.=20 > >I agree with Alex -- there is a sufficient amount of confusion >or difference of opinion that I think it's premature to push the >draft at this time.=20 > >Regards, >Stan=20 > >>-----Original Message----- >>From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 >>Sent: Wednesday, November 21, 2007 8:39 AM >>To: Shubhranshu >>Cc: autoconf@ietf.org >>Subject: Re: [Autoconf] Request to publish=20 >>draft-ietf-autoconf-manetarch-07.txt >> >> >>Shubhranshu wrote: >>[...] >>> 4. Do you have any specific concerns/issues with this=20 >>document that >>> you believe >>> the ADs and/or IESG should be aware of? For example, perhaps you are >>> uncomfortable with certain parts of the document, or have concerns >>> whether there really is a need for it. In any event, if your issues >>> have been discussed in the WG and the WG has indicated it that it >>> still wishes to advance the document, detail those concerns in the >>> write-up. >>>=20 >>> NO. >> >>No? >> >>I've just raised yesterday an issue about multicast interpretation=20 >>confusion between manetarch and problem statement documents. =20 >HAs that=20 >>been solved already? A decision made? The issue is here, and the=20 >>following thread keeps the subject: >>http://www1.ietf.org/mail-archive/web/autoconf/current/msg00771.html >> >>Was there a decision made with respect to this issue? It=20 >>seems like the=20 >>confusing issue around multicast that I've raised is=20 >>completely ignored?? >> >>Alex >>PS: I removed IESG from Cc to not create further problems. But you >> understand what I mean. >> >> >>______________________________________________________________________ >>This email has been scanned by the MessageLabs Email Security System. >>For more information please visit http://www.messagelabs.com/email=20 >>______________________________________________________________________ >> >> >>_______________________________________________ >>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 > > >******************************************************************** >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. >******************************************************************** > ******************************************************************** 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 Wed Nov 21 11:09:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ius8S-0001Ty-Sr; Wed, 21 Nov 2007 11:09:08 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Ius8R-0001Tp-LS for autoconf-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 11:09:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ius8R-0001Th-A2 for autoconf@ietf.org; Wed, 21 Nov 2007 11:09:07 -0500 Received: from mail4-relais-sop.national.inria.fr ([192.134.164.105]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ius8Q-0006ZF-7x for autoconf@ietf.org; Wed, 21 Nov 2007 11:09:07 -0500 X-IronPort-AV: E=Sophos;i="4.21,447,1188770400"; d="scan'208";a="19541175" Received: from pericui.inria.fr (HELO localhost) ([128.93.24.186]) by mail4-relais-sop.national.inria.fr with ESMTP; 21 Nov 2007 17:09:05 +0100 Received: from 212.201.107.50 ([212.201.107.50]) by pops-rocq.inria.fr (Horde MIME library) with HTTP; Wed, 21 Nov 2007 17:09:05 +0100 Message-ID: <20071121170905.xklagnuc08gskcow@pops-rocq.inria.fr> Date: Wed, 21 Nov 2007 17:09:05 +0100 From: Emmanuel Baccelli To: autoconf@ietf.org Subject: Re: [Autoconf] tentative draft-ietf-autoconf-problem-statement-03.txt References: <47443152.5070807@inria.fr> <474435BA.5020208@motorola.com> <47443AAB.4070009@inria.fr> <47443D2C.2070406@gmail.com> <47444837.1070601@telecomitalia.it> <4744498A.2090704@gmail.com> In-Reply-To: <4744498A.2090704@gmail.com> 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.3) X-Spam-Score: 1.8 (+) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 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, thanks for your contribution. Could you revise the text you propose so =20 that it focuses more on issues, and so that it also elaborates on the =20 additional problems there are when everything is potentially mobile? =20 It is a case that is envisionned too ;) Emmanuel Alexandru Petrescu a ?it : > This is what I've just sent to Emmanuel about noticed shortcomings of > DHCP in some MANET-like deployemnts. > > Alex > >> For the following text: >> >> For example, in Fig. 1, the MANET router MR3 cannot communicate >> directly with a DHCP server [4] that would be available through a >> border router, since the border router and MR3 are not located on >> the same logical link. While DHCP can to some extent overcome this >> issue in a static network, it is not the case in a dynamic >> topology, as explained below. On the other hand IPv6 Stateless >> Address Autoconfiguration [5] and Neighbor Discovery for IPv6 [3] >> do not account for potential address duplication beyond a single >> multicast-capable link. >> >> >> ----- MR1...MR3 >> / . >> +-------------+ +------------+ / . >> | | p2p | |/ . (MANET) >> | ISP Edge | Link | Border | . >> | Router +---------+ Router |\ . >> | | | | \ . >> +-------------+ +------------+ \----- MR2 >> >> Fig. 1. Connected MANET router topology. >> >> With the following: >> >> For example, in Figure 1, we assume that the "p2p Link" >> (point-to-point link) and the links BR-MR1, MR1-MR2 and MR2-MR3 all >> have distinctive IP subnets assigned. The MR3 needs to be assigned >> an IPv6 prefix. The MANET router MR3 does not yet know the IP >> address of the DHCPv6 Server, so it needs to discover it by using >> link-layer multicast mechanisms and IP-layer multicast. It is >> possible for MR2 to run DHCP Relay software. In this case the MR3 >> would send a DHCP Solicit message (IP dst address is a IP multicast >> address), message preceded by a header containing a link-layer >> multicast address as destination. The Solicit message would be >> further sent by MR2 (DHCP Relay) to the the ISP Edge Router (DHCP >> Server). After this initial step the next DHCPv6 exchanges would >> be performed such that the MR3 obtains a prefix. >> >> >> ----- MR1-MR2-MR3 >> / . >> +-------------+ +------------+ / . >> | | p2p | |/ . (MANET) >> | ISP Edge | Link | Border | . >> | Router +---------+ Router |\ . >> | | | | \ . >> +-------------+ +------------+ \----- MRn >> >> Fig. 1. Connected MANET router topology. >> >> This is a DHCP behaviour that would work in this MANET topology. >> However, there may be at least the following two issues: >> >> -in the group of MANET Routers described above there should be a >> dynamic decision of roles about who is a Relay and at what moment. >> If MR2 disappears from its place and another MR takes its place >> then that router should receive the DHCPv6 Solicit sent by MR3 and >> relay it to the DHCPv6 Server. >> >> -some implementations of DHCPv6 Prefix Delegation will not update >> routes on the DHCP Server with respect to the allocated prefix. >> Or, when assigning prefixes that don't respect a hierarchical >> structure it is necessary when using a Relay to add a new routing >> table entry at the DHCP Server whenever a new prefix is assigned >> to a new MANET Router. This route should point to the Relay >> address. >> >> These are two issues that appear in the topology pictured in Figure >> 1. In this figure the DHCP Server, Border Router, MR1 and MR3 are >> assumed to be stable non-moving (only MR2 moves). If we consider >> that any entities will also move then there may be more DHCP issues >> that could be identified. > > Simone Ruffino wrote: >> >> >> Alexandru Petrescu wrote: >>> Emmanuel Baccelli wrote: >>>> All, >>>> >>>> after the feedback received from Alex, Teco, Carlos, Ronald, =20 >>>> Thomas (thanks to all of you), a tentative -03 is available on a =20 >>>> server reachable at =20 >>>> http://djincoda.free.fr/autoconf-PS/draft-ietf-autoconf-problem-stateme= nt-03.txt Highlights about the updates =20 >>>> include: >>>> >>>> - the definition of the term ICP is more precise >>>> - even more explicit mention that DHCP etc. may be part of a solution >>>> - typos corrected here and there >>>> - global address terminology updated >>>> - more precision regarding issues developped in 4.1.x >>>> >>>> Alex, you were suggesting to write up a paragraph about even more =20 >>>> details on DHCP shortcomings. Can you propose some text and a =20 >>>> place to put it in -03 ? >>> >>> YEs, I can. Remark though I will no longer post on this list. I =20 >>> will send you privately the DHCP shortcomings text. >>> >> >> Alex, my suggestion is to post them here, instead. Because they can =20 >> be part of the problems we're going to describe. >> >>>> Otherwise, please take -03 as the base for further discussions as of no= w. >>> >>> Thanks, >>> >>> Alex >>> >>> >>> ______________________________________________________________________ >>> This email has been scanned by the MessageLabs Email Security System. >>> For more information please visit http://www.messagelabs.com/email =20 >>> =20 >>> ______________________________________________________________________ >>> >>> >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> https://www1.ietf.org/mailman/listinfo/autoconf >> -------------------------------------------------------------------- >> >> CONFIDENTIALITY NOTICE >> >> This message and its attachments are addressed solely to the =20 >> persons above and may contain confidential information. If you have =20 >> received the message in error, be informed that any use of the =20 >> content hereof is prohibited. Please return it immediately to the =20 >> sender and delete the message. Should you have any questions, =20 >> please contact us by replying to webmaster@telecomitalia.it. >> >> Thank you >> >> www.telecomitalia.it >> >> -------------------------------------------------------------------- >> > > > ______________________________________________________________________ > 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 ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 22 01:04:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv5BF-0003PC-If; Thu, 22 Nov 2007 01:04:53 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Iv5BE-0003Oz-77 for autoconf-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 01:04:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv5BD-0003Or-Rq for autoconf@ietf.org; Thu, 22 Nov 2007 01:04:51 -0500 Received: from an-out-0708.google.com ([209.85.132.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iv5BB-0001oF-Fe for autoconf@ietf.org; Thu, 22 Nov 2007 01:04:51 -0500 Received: by an-out-0708.google.com with SMTP id d11so633590and for ; Wed, 21 Nov 2007 22:04:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=w3EtdF4zV2WzRa0H2mchwfa9htywWTfpZ7NjrRPihGo=; b=rKc9luP3KQwVP+RoqidZKb3R4SELmdfydL/oeeHhy38rU21/qyLvtQ+jy6iYPW9P0ppPTdmtc0syENPAbkwWKO6vcXfXt7WtxxOpPz9wTaXc6PiLAtw/HaJX9t1ULOwyJqr6MDFAyOx5qrASWgDXCVv8FWeZkyAdZ0Yoe3ipQbE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=IlSPLVOFC801Y/Kl0skkXnufUbfLNUphWrIhqFm5VXqxKwX4WaCGPcxRoI4yitvcHjNtQaataliHhsqlTu7NdDAWfHL2VB1SsPTHSrSyzecsZc5pkjCfDJ0WJWibnQdfJdvO7FdSfVOHnZZ0T/a4zQ7IH5ahVFZhpqqHClmIgfg= Received: by 10.100.208.11 with SMTP id f11mr11363832ang.1195711489212; Wed, 21 Nov 2007 22:04:49 -0800 (PST) Received: by 10.100.229.8 with HTTP; Wed, 21 Nov 2007 22:04:49 -0800 (PST) Message-ID: Date: Thu, 22 Nov 2007 11:34:49 +0530 From: Shubhranshu To: alexandru.petrescu@gmail.com Subject: Re: [Autoconf] Request to publish draft-ietf-autoconf-manetarch-07.txt MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 Alex, ----- Original Message ----- From: "Alexandru Petrescu" To: "Shubhranshu" > > Shubhranshu wrote: > [...] >> 4. Do you have any specific concerns/issues with this document that >> you believe >> the ADs and/or IESG should be aware of? For example, perhaps you are >> uncomfortable with certain parts of the document, or have concerns >> whether there really is a need for it. In any event, if your issues >> have been discussed in the WG and the WG has indicated it that it >> still wishes to advance the document, detail those concerns in the >> write-up. >> >> NO. > > No? > > I've just raised yesterday an issue about multicast interpretation > confusion between manetarch and problem statement documents. HAs that > been solved already? A decision made? The issue is here, and the > following thread keeps the subject: > http://www1.ietf.org/mail-archive/web/autoconf/current/msg00771.html > > Was there a decision made with respect to this issue? It seems like the > confusing issue around multicast that I've raised is completely ignored?? > If the community thinks there are issues that really needs to be addressed before moving this document forward then I'd be willing to ask for postponement. Why do you think there is a WGLC in the process ? I remember you saying at the WG mailing list, about a couple of weeks after WGLC for this ID ended, that you have some comments on section 5.1 but "Otherwise - yes, I'm fine with the document." !! According to the ID authors those comments were minor in nature and is addressed in the later version. I am not sure if you or anyone would not have any confusion or new thoughts even after, say, one year of further discussions. > Alex > PS: I removed IESG from Cc to not create further problems. But you > understand what I mean. Irrespective of you keep them in CC or not, they are aware of the status. - Shubhranshu _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 22 02:19:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv6Lh-0005W7-GT; Thu, 22 Nov 2007 02:19:45 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Iv6Lf-0005SS-5p for autoconf-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 02:19:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv6Le-0005S2-39 for autoconf@ietf.org; Thu, 22 Nov 2007 02:19:42 -0500 Received: from server9.hosting2go.nl ([83.137.192.232]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iv6Ld-0000t4-2s for autoconf@ietf.org; Thu, 22 Nov 2007 02:19:41 -0500 Received: (qmail 1748 invoked from network); 22 Nov 2007 08:19:39 +0100 Received: from unknown (HELO M90Teco) (217.169.232.211) by server9.hosting2go.nl with SMTP; 22 Nov 2007 08:19:38 +0100 From: "Teco Boot" To: "'Vijay Devarapalli'" , "'Pascal Thubert \(pthubert\)'" References: <483735.10786.qm@web84112.mail.mud.yahoo.com><470167CD.8020601@gmail.com><8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr><473DC6F2.9060509@gmail.com><664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr><47417205.7070805@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337.emea.cisco.com> <006a01c82b48$de794bb0$9b6be310$@nl> <47432B43.5020100@azairenet.com> <7892795E1A87F04CADFCCF41FADD00FC04CEB847@xmb-ams-337.emea.cisco.com> <47447F8F.3050103@azairenet.com> In-Reply-To: <47447F8F.3050103@azairenet.com> Date: Thu, 22 Nov 2007 08:18:59 +0100 Message-ID: <005f01c82cd8$062d2880$12877980$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgscFjtJMR+v5f4S32anoKfQLuvyAAZW4pA Content-Language: nl X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: autoconf@ietf.org, mext@ietf.org Subject: [Autoconf] RE: [MEXT] Prefix Delegation documents 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 Thanks for the clarifications. I wanted to know, as Prefix Delegation is being worked on in Autoconf also. If Autoconf comes up with a third solution, it could be difficult to manage in environments with equipment is both Mobile Router (NEMO) and MANET Router (Autoconf). Are others also studying this overlap in functionality? Maybe there are some issues with PD and DSMIPv6. Has anyone looked at this? I suggest to keep the PD discussion in MEXT. Teco. > -----Oorspronkelijk bericht----- > Van: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Verzonden: woensdag 21 november 2007 19:57 > Aan: Pascal Thubert (pthubert) > CC: Teco Boot; mext@ietf.org > Onderwerp: Re: [MEXT] Prefix Delegation documents > > Pascal Thubert (pthubert) wrote: > > Hi Vijay > > > > My proposal to break the tie is this: > > > > - move draft-ietf-nemo-dhcpv6-pd-02.txt to informational track as it > > documents a way to use DHCP-PD but does not need new exchanges. Last > I > > checked, some components were still missing but Ralph knows better. > > > > - focus on draft-ietf-nemo-prefix-delegation-02.txt for standard > track. > > The draft is agnostic to the delegation mechanism in the backend and > > does not have dependencies. It proposes an integrated mechanism that > > fits the general MIP6 / NEMO approach and formats. > > > > What do you think? > > I am fine with this approach. > > For draft-ietf-nemo-prefix-delegation-02.txt, I would like to > simplify the mechanism a bit, by removing the Mobile Network > Prefix Confirm option. Just use the Mobile Network Prefix > option for the home agent to send the prefix to the mobile > router. I actually don't understand the need for the Mobile > Network Prefix Confirm option. > > Vijay > > > > > Pascal > > > >> -----Original Message----- > >> From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] > >> Sent: Tuesday, November 20, 2007 7:45 PM > >> To: Teco Boot > >> Cc: Pascal Thubert (pthubert); mext@ietf.org > >> Subject: Re: [MEXT] Re: [nemo] Prefix Delegation documents > >> > >> Teco Boot wrote: > >>> Hi Pascal, > >>> Question on WG documents for prefix delegation. There are two of > > them: > >>> 1: draft-ietf-nemo-prefix-delegation-02.txt (August 21, 2007) > >>> 2: draft-ietf-nemo-dhcpv6-pd-02.txt (September 28, 2006) > >>> Are we still working on both solutions? > >> We have a sort of stalemate on this. I believe Jari (AD) would > prefer > >> one solution in this space. I think the earlier decision by the NEMO > >> WG was to standardize both solutions. Not sure what the consensus is > >> right now. > >> > >> IMO, we should standardize one ASAP. Without a prefix delegation > >> mechanism the only possible solution now is to pre-configure the > >> mobile network prefix on the mobile router. This is not sufficient. > >> > >> Vijay _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 22 03:37:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv7YT-00027a-Dv; Thu, 22 Nov 2007 03:37:01 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Iv7YS-00027P-Pf for autoconf-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 03:37:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv7YM-00026F-MD for autoconf@ietf.org; Thu, 22 Nov 2007 03:36:54 -0500 Received: from an-out-0708.google.com ([209.85.132.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iv7YI-00076A-Vk for autoconf@ietf.org; Thu, 22 Nov 2007 03:36:54 -0500 Received: by an-out-0708.google.com with SMTP id d11so640318and for ; Thu, 22 Nov 2007 00:36:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=uItsUehB70ZSOOUacqhgCG9Jc5DdsutEXLJWWmYcIHQ=; b=SOxcAopUnSOVA/MQwzhBDj0PzQ6SmPbZFunAw8sU9guj/6P9/MsH+u9jZ4qKsRB0uQxZpxSEJ/wXL16tkCOlRC3dS5OAoMRe8OUinQXNEap6TmrG6Qbjeal/rgcoNVHVfrD96iKvo62q1bQudpLjXSenN7ZoxlrnOfa4dlVPylo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=DGxanbmoyAgsACbS+70eSE6b45PfHG29G58LJ2ZNfad6hucgtt7DIsHA4UC6Eus17tJ0rFL8BJmkLg7wk047n7yfPqjbwHeX4eue2S0JIl2qhTyDiy1C2V9ZBN9lv4RkO2jZhzuwkhaj66qGb5b32owsIJ6n5kyOf0JMTuTqr+Y= Received: by 10.100.194.17 with SMTP id r17mr11636715anf.1195720610704; Thu, 22 Nov 2007 00:36:50 -0800 (PST) Received: by 10.100.229.8 with HTTP; Thu, 22 Nov 2007 00:36:50 -0800 (PST) Message-ID: Date: Thu, 22 Nov 2007 14:06:50 +0530 From: Shubhranshu To: alexandru.petrescu@gmail.com Subject: Re: [Autoconf] tentative draft-ietf-autoconf-problem-statement-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: autoconf@ietf.org, Emmanuel.Baccelli@inria.fr 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: "Alexandru Petrescu" > This is what I've just sent to Emmanuel about noticed shortcomings of > DHCP in some MANET-like deployemnts. > > Alex > >> For the following text: >> >> For example, in Fig. 1, the MANET router MR3 cannot communicate >> directly with a DHCP server [4] that would be available through a >> border router, since the border router and MR3 are not located on >> the same logical link. While DHCP can to some extent overcome this >> issue in a static network, it is not the case in a dynamic >> topology, as explained below. On the other hand IPv6 Stateless >> Address Autoconfiguration [5] and Neighbor Discovery for IPv6 [3] >> do not account for potential address duplication beyond a single >> multicast-capable link. I can see the problem being described here but yes I agree that it needs to be expanded, to further calrify things. See below. >> For example, in Figure 1, we assume that the "p2p Link" >> (point-to-point link) and the links BR-MR1, MR1-MR2 and MR2-MR3 all >> have distinctive IP subnets assigned. The MR3 needs to be assigned >> an IPv6 prefix. The MANET router MR3 does not yet know the IP >> address of the DHCPv6 Server, so it needs to discover it by using >> link-layer multicast mechanisms and IP-layer multicast. It is >> possible for MR2 to run DHCP Relay software. In this case the MR3 >> would send a DHCP Solicit message (IP dst address is a IP multicast >> address), message preceded by a header containing a link-layer >> multicast address as destination. The Solicit message would be >> further sent by MR2 (DHCP Relay) to the the ISP Edge Router (DHCP >> Server). After this initial step the next DHCPv6 exchanges would >> be performed such that the MR3 obtains a prefix. Looks like you are proposing that the problem statement assume or suggest this way of solving the problems. Are you proposing text for the problem ID or for the solution ID? >> >> >> ----- MR1-MR2-MR3 >> / . >> +-------------+ +------------+ / . >> | | p2p | |/ . (MANET) >> | ISP Edge | Link | Border | . >> | Router +---------+ Router |\ . >> | | | | \ . >> +-------------+ +------------+ \----- MRn >> >> Fig. 1. Connected MANET router topology. >> >> This is a DHCP behaviour that would work in this MANET topology. >> However, there may be at least the following two issues: >> >> -in the group of MANET Routers described above there should be a >> dynamic decision of roles about who is a Relay and at what moment. >> If MR2 disappears from its place and another MR takes its place >> then that router should receive the DHCPv6 Solicit sent by MR3 and >> relay it to the DHCPv6 Server. Agree, this is one of the issue. And one possible solution of this may be, as for an example "Each MANET router should act as a dynamic DHCP relay". >> >> -some implementations of DHCPv6 Prefix Delegation will not update >> routes on the DHCP Server with respect to the allocated prefix. >> Or, when assigning prefixes that don't respect a hierarchical >> structure it is necessary when using a Relay to add a new routing >> table entry at the DHCP Server whenever a new prefix is assigned >> to a new MANET Router. This route should point to the Relay >> address. Hmmm.... again I see lots of text which I think would make a good content of a proposed solution document. >> >> These are two issues that appear in the topology pictured in Figure >> 1. In this figure the DHCP Server, Border Router, MR1 and MR3 are >> assumed to be stable non-moving (only MR2 moves). If we consider >> that any entities will also move then there may be more DHCP issues >> that could be identified. > Yes. - Shubhranshu _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 22 04:39: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 1Iv8XL-0001fS-B3; Thu, 22 Nov 2007 04:39:55 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Iv84q-0004JZ-Ll for autoconf-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 04:10:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv84p-0004JC-I8 for autoconf@ietf.org; Thu, 22 Nov 2007 04:10:27 -0500 Received: from mho-01-bos.mailhop.org ([63.208.196.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iv84o-00057w-1i for autoconf@ietf.org; Thu, 22 Nov 2007 04:10:27 -0500 Received: from sphinx.lix.polytechnique.fr ([129.104.11.1] helo=[192.168.112.180]) by mho-01-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Iv84g-000C77-Ur; Thu, 22 Nov 2007 09:10:25 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 129.104.11.1 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/ua42mv5TtgPZeB2ff/yln Mime-Version: 1.0 (Apple Message framework v752.3) References: <920B8B05FB49A04699188E04302FE87D28B7E79BD8@NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com> Content-Type: multipart/mixed; boundary=Apple-Mail-5-519609794 Message-Id: From: Thomas Clausen Date: Thu, 22 Nov 2007 10:10:58 +0100 To: autoconf@ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9539b1edcd07f10aacae58a32374aa7f X-Mailman-Approved-At: Thu, 22 Nov 2007 04:39:53 -0500 Subject: [Autoconf] From Dave Thaler: Review of draft-ietf-autoconf-statement-02.txt 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 --Apple-Mail-5-519609794 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Dear all, Dave Thaler kindly offered to review draft-ietf-autoconf-statement, =20 and share his opinions with the working group. As always, Dave has =20 interesting insights, and we owe him thanks for his efforts in =20 sharing those with us. He asked that I forward them to the 'list -- =20 and I hope we will all review them carefully and take them into =20 consideration and act upon them. Sincerely, Thomas Begin forwarded message: > From: Dave Thaler > Date: November 21, 2007 10:34:11 PM CEST > To: "Emmanuel.Baccelli@inria.fr" , =20 > "Mase@ie.niigata-u.ac.jp" , =20 > "Simone.Ruffino@telecomitalia.it" =20 > , Shubhranshu Singh =20 > > Cc: Thomas Heide Clausen , Thomas Narten =20 > , Jari Arkko > Subject: Review of draft-ietf-autoconf-statement-02.txt > > I reviewed this draft today to see if I thought it was ready for WGLC. > > > > In my opinion, it is definitely not ready for WGLC and there are =20 > enough issues that, after being addressed, I expect that one would =20 > absolutely need to Last Call it again. Hence the only benefit to a =20= > WGLC would just be to get people to read it. In my view, that is =20 > unnecessary=85 asking specific people (e.g., me, Thomas [Nartan], =20 > etc) to review it is more productive than just requesting a general =20= > WGLC in order to get people to read it. > > > > My detailed comments are in the marked up doc attached. If anyone =20 > wants to read them and cannot read doc format, let me know and I=92m =20= > happy to send you HTML format (but it=92s harder to read that way and =20= > in the past folks seem to have been ok with doc format). > > > > I am not currently subscribed to the autoconf list, so am not =20 > posting to the list, but feel free to forward this to the list as =20 > desired. > > > > To summarize the two main technical problems (but there are others): > > > > 1) The document is supposed to be a problem statement, and it does =20 > not really state what the problem is. It concludes that existing =20 > solutions can=92t work, but provides no discussion of this to =20 > motivate that conclusion. That is what, in my view, is the point =20 > of a problem statement document and as such should be a significant =20= > contribution. This is the main reason why I feel it needs =20 > significant work before WGLC. > > > > 2) The document is supposed to be a problem statement, and it does =20 > not really state that there is a problem. Much of the discussion =20 > centers around the point about duplicate address detection. The =20 > document does not say there is any problem. It says that IF there =20 > is some requirement, then there may be a problem, but provides no =20 > evidence there actually is any. Again, this is, in my view, the =20 > point of a problem statement document and as such should be a =20 > significant contribution. > > > > -Dave > --Apple-Mail-5-519609794 Content-Transfer-Encoding: base64 Content-Type: application/msword; x-unix-mode=0666; name=draft-ietf-autoconf-statement-02.doc Content-Disposition: attachment; filename=draft-ietf-autoconf-statement-02.doc 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAADAAAAAAEAAAAAAAAA EAAAAgEAAAEAAAD+////AAAAAP0AAAD+AAAA/wAAAP////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAI2AJBAAA8BK/AAAAAAAAEAAAAAAABgAA85cAAA4AYmpiam2lbaUAAAAAAAAAAAAAAAAAAAAA AAAJBBYALvIAAA/PAAAPzwAAanwAAAAAAAAAAAAAAAAAAIgTAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAKQAAAAAAPwEAAAAAAAA/AQAAPwE AAAAAAAA/AQAAAAAAAAUBQAAdgUAAGwNAACsAAAAGA4AABQAAAAAAAAAAAAAACwOAAAAAAAANLEA AAAAAAA0sQAAAAAAADSxAAAAAAAANLEAACwAAABgsQAAPAEAACwOAAAAAAAAWNAAANoBAACosgAA AAAAAKiyAAAAAAAAqLIAAAAAAACosgAAAAAAAKiyAAAAAAAAqLIAAAAAAACosgAAAAAAAKiyAAAA AAAAs88AAAIAAAC1zwAAAAAAALXPAAAAAAAAtc8AAAAAAAC1zwAAAAAAALXPAAAAAAAAtc8AACQA AAAy0gAAaAIAAJrUAABWAAAA2c8AABUAAAAAAAAAAAAAAAAAAAAAAAAA/AQAABgAAACltQAA8gEA AAAAAAAAAAAAAAAAAAAAAACosgAAAAAAAKiyAAAAAAAAl7cAAEwBAADjuAAAqAAAANnPAAAAAAAA AAAAAAAAAAD8BAAAAAAAAPwEAAAAAAAAqLIAAAAAAAAAAAAAAAAAAKiyAAAAAAAA7s8AAC4AAACX zwAAAAAAAJfPAAAAAAAAl88AAAAAAACLuQAAyAUAAPwEAAAAAAAAqLIAAAAAAAD8BAAAAAAAAKiy AAAAAAAAs88AAAAAAAAAAAAAAAAAAJfPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAApbUAAAAAAACzzwAAAAAAAAAAAAAAAAAAl88AAAAAAAAAAAAA AAAAAJfPAAAAAAAA/AQAAAAAAAD8BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAl88AAAAAAACosgAAAAAAAJyyAAAMAAAA4AjCu4Qs yAEAAAAAAAAAADSxAAAAAAAAU78AAHAPAACXzwAAAAAAAAAAAAAAAAAAl88AABwAAAAc0AAAPAAA AFjQAAAAAAAAl88AAAAAAADw1AAAAAAAAMPOAADEAAAA8NQAAAAAAACXzwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAPDUAAAAAAAAAAAAAAAAAACKCgAA4gIAAJfPAAAAAAAAqLIAAKAAAABIswAAcgAAAJfP AAAAAAAAurMAAFwAAAAWtAAAjwEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqLIA AAAAAACosgAAAAAAAKiyAAAAAAAA2c8AAAAAAADZzwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAh88AABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKiyAAAA AAAAqLIAAAAAAACosgAAAAAAAFjQAAAAAAAApbUAAAAAAACltQAAAAAAAKW1AAAAAAAApbUAAAAA AAAAAAAAAAAAACwOAAAAAAAALA4AAAAAAAAsDgAAJIoAAFCYAADkGAAALA4AAAAAAAAsDgAAAAAA ACwOAAAAAAAAUJgAAAAAAAAsDgAAAAAAACwOAAAAAAAALA4AAAAAAAD8BAAAAAAAAPwEAAAAAAAA /AQAAAAAAAD8BAAAAAAAAPwEAAAAAAAA/AQAAAAAAAD/////AAAAAAIADAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0NTUFO RVQgQXV0b2NvbmZpZ3VyYXRpb24gKEF1dG9jb25mKSAgICAgICAgICAgICAgICAgICAgIEUuIEJh Y2NlbGxpIChFZC4pDUludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBJTlJJQQ1FeHBpcmVzOiBNYXkgMjIsIDIwMDggICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEsuIE1hc2UNICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTmlpZ2F0YSBVbml2ZXJz aXR5DSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgUy4gUnVmZmlubw0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgVGVsZWNvbSBJdGFsaWENICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFMuIFNpbmdoDSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgU2Ftc3VuZw0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgTm92ZW1iZXIgMTksIDIwMDcNDQ0gQWRkcmVzcyBBdXRvY29uZmlndXJhdGlvbiBm b3IgTUFORVQ6IFRlcm1pbm9sb2d5IGFuZCBQcm9ibGVtIFN0YXRlbWVudA0gICAgICAgICAgICAg ICAgICAgIGRyYWZ0LWlldGYtYXV0b2NvbmYtc3RhdGVtZW50LTAyDQ1TdGF0dXMgb2YgdGhpcyBN ZW1vDQ0gICBCeSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJl cHJlc2VudHMgdGhhdCBhbnkNICAgYXBwbGljYWJsZSBwYXRlbnQgb3Igb3RoZXIgSVBSIGNsYWlt cyBvZiB3aGljaCBoZSBvciBzaGUgaXMgYXdhcmUNICAgaGF2ZSBiZWVuIG9yIHdpbGwgYmUgZGlz Y2xvc2VkLCBhbmQgYW55IG9mIHdoaWNoIGhlIG9yIHNoZSBiZWNvbWVzDSAgIGF3YXJlIHdpbGwg YmUgZGlzY2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIEJDUCA3OS4NDSAg IEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVu Z2luZWVyaW5nDSAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2lu ZyBncm91cHMuICBOb3RlIHRoYXQNICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUg d29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtDSAgIERyYWZ0cy4NDSAgIEludGVybmV0LURy YWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRo cw0gICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIg ZG9jdW1lbnRzIGF0IGFueQ0gICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50 ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0gICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3Ro ZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iDQ0gICBUaGUgbGlzdCBvZiBjdXJyZW50IElu dGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNICAgaHR0cDovL3d3dy5pZXRmLm9yZy9p ZXRmLzFpZC1hYnN0cmFjdHMudHh0Lg0NICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hh ZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0gICBodHRwOi8vd3d3LmlldGYub3Jn L3NoYWRvdy5odG1sLg0NICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBNYXkg MjIsIDIwMDguDQ1Db3B5cmlnaHQgTm90aWNlDQ0gICBDb3B5cmlnaHQgKEMpIFRoZSBJRVRGIFRy dXN0ICgyMDA3KS4NDQ0NDQ0NDQ0NQmFjY2VsbGkgKEVkLiksIGV0IGFsLiAgICBFeHBpcmVzIE1h eSAyMiwgMjAwOCAgICAgICAgICAgICAgICAgIFtQYWdlIDFdDQwNSW50ZXJuZXQtRHJhZnQgICAg ICBNQU5FVCBBdXRvY29uZiBQcm9ibGVtIFN0YXRlbWVudCAgICAgICBOb3ZlbWJlciAyMDA3DQ0N QWJzdHJhY3QNDSAgIFRyYWRpdGlvbmFsIGR5bmFtaWMgSVB2NiBhZGRyZXNzIGFzc2lnbm1lbnQg c29sdXRpb25zIGFyZSBub3QgYWRhcHRlZA0gICB0byBtb2JpbGUgYWQgaG9jIG5ldHdvcmtzLiAg BVRoaXMgZG9jdW1lbnQgZWxhYm9yYXRlcyBvbiB0aGlzIHByb2JsZW0sDSAgIHN0YXRlcyB0aGUg bmVlZCBmb3IgbmV3IHNvbHV0aW9ucywgYW5kIHJlcXVpcmVtZW50cyB0byB0aGVzZQ0gICBzb2x1 dGlvbnMuDQ0NVGFibGUgb2YgQ29udGVudHMNDSAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMw0gICAyLiAgVGVybWlu b2xvZ3kgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDQNICAgMy4gIERlcGxveW1lbnQgU2NlbmFyaW9zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICA2DSAgICAgMy4xLiAgQ29ubmVjdGVkIE1BTkVUICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNg0gICAgIDMuMi4gIFN0YW5kYWxvbmUg TUFORVQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDYNICAgICAz LjMuICBEZXBsb3ltZW50IFNjZW5hcmlvcyBTZWxlY3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICA2DSAgIDQuICBQcm9ibGVtIFN0YXRlbWVudCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNw0gICAgIDQuMS4gIE1BTkVUIEF1dG9jb25maWd1cmF0 aW9uIEdvYWxzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcNICAgICAgIDQuMS4xLiAg TXVsdGktaG9wIFN1cHBvcnQgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3 DSAgICAgICA0LjEuMi4gIER5bmFtaWMgVG9wb2xvZ3kgU3VwcG9ydCAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgOA0gICAgICAgNC4xLjMuICBOZXR3b3JrIE1lcmdpbmcgU3VwcG9ydCAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgNICAgICAgIDQuMS40LiAgTmV0d29yayBQ YXJ0aXRpb25pbmcgU3VwcG9ydCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5DSAgICAgNC4y LiAgTUFORVQgQXV0b2NvbmZpZ3VyYXRpb24gSXNzdWVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgOQ0gICAgICAgNC4yLjEuICBBZGRyZXNzIGFuZCBQcmVmaXggR2VuZXJhdGlvbiAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMTANICAgICAgIDQuMi4yLiAgUHJlZml4IGFuZCBBZGRyZXNz IFVuaXF1ZW5lc3MgUmVxdWlyZW1lbnRzIC4gLiAuIC4gLiAuIDEwDSAgICAgICA0LjIuMy4gIElu dGVybmV0IENvbmZpZ3VyYXRpb24gUHJvdmlkZXIgUmVsYXRlZCBJc3N1ZXMgLiAuIC4gLiAxMQ0g ICA1LiAgU29sdXRpb25zIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMTINICAgNi4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEzDSAgIDcuICBJQU5BIENvbnNpZGVyYXRpb25z ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNA0gICA4LiAgSW5m b3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMTUNICAgQ29udHJpYnV0b3JzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDE3DSAgIEF1dGhvcnMnIEFkZHJlc3NlcyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOA0gICBJbnRlbGxlY3R1YWwgUHJv cGVydHkgYW5kIENvcHlyaWdodCBTdGF0ZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTkNDQ0N DQ0NDQ0NDQ0NDQ0NDQ0NQmFjY2VsbGkgKEVkLiksIGV0IGFsLiAgICBFeHBpcmVzIE1heSAyMiwg MjAwOCAgICAgICAgICAgICAgICAgIFtQYWdlIDJdDQwNSW50ZXJuZXQtRHJhZnQgICAgICBNQU5F VCBBdXRvY29uZiBQcm9ibGVtIFN0YXRlbWVudCAgICAgICBOb3ZlbWJlciAyMDA3DQ0NMS4gIElu dHJvZHVjdGlvbg0NICAgQSBNb2JpbGUgQWQgaG9jIE5FVHdvcmsgKGFsc28ga25vd24gYXMgYSBN QU5FVCBbMV0pIGNvbnNpc3RzIG9mIGENICAgbG9vc2VseSBjb25uZWN0ZWQgc2V0IG9mIE1BTkVU IHJvdXRlcnMuICBFYWNoIE1BTkVUIHJvdXRlciBlbWJvZGllcw0gICBJUCByb3V0aW5nL2Zvcndh cmRpbmcgZnVuY3Rpb25hbGl0eSBhbmQgbWF5IGFsc28gaW5jb3Jwb3JhdGUgaG9zdA0gICBmdW5j dGlvbmFsaXR5IFsyXS4gIFRoZXNlIHJvdXRlcnMgZHluYW1pY2FsbHkgc2VsZi1vcmdhbml6ZSBh bmQNICAgbWFpbnRhaW4gYSByb3V0aW5nIHN0cnVjdHVyZSBhbW9uZyB0aGVtc2VsdmVzLCByZWdh cmRsZXNzIG9mIHRoZQ0gICBhdmFpbGFiaWxpdHkgb2YgYSBjb25uZWN0aW9uIHRvIGFueSBpbmZy YXN0cnVjdHVyZS4NDSAgIE1BTkVUIHJvdXRlcnMgbWF5IGJlIG1vYmlsZSBhbmQgbWF5IGNvbW11 bmljYXRlIG92ZXIgc3ltbWV0cmljIG9yDSAgIGFzc3ltZXRyaWMgd2lyZWxlc3MgbGlua3MuICBU aGV5IG1heSB0aHVzIGpvaW4gYW5kIGxlYXZlIHRoZSBNQU5FVCBhdA0gICBhbnkgdGltZSwgYXQg YSByYXRlIHRoYXQgY2FuIGJlIHN1YnN0YW50aWFsbHkgaGlnaGVyIHRoYW4gaW4gdXN1YWwNICAg bmV0d29ya3MuDQ0gICBIb3dldmVyLCBwcmlvciB0byBwYXJ0aWNpcGF0aW9uIGluIElQIGNvbW11 bmljYXRpb24sIGVhY2ggTUFORVQNICAgcm91dGVyIHRoYXQgZG9lcyBub3QgYmVuZWZpdCBmcm9t IGFwcHJvcHJpYXRlIHN0YXRpYyBjb25maWd1cmF0aW9uDSAgIG5lZWRzIHRvIGF1dG9tYXRpY2Fs bHkgYWNxdWlyZSBhdCBsZWFzdCBvbmUgSVAgYWRkcmVzcywgYW5kIG1heSBhbHNvDSAgIG5lZWQg dG8gYmUgZGVsZWdhdGVkIGFuIElQIHByZWZpeC4gIFRoaXMgYWRkcmVzcyBvciBhbmQgdGhpcyBw cmVmaXggbWF5DSAgIGJlIHJlcXVpcmVkIHRvIGJlIHVuaXF1ZSB3aXRoaW4gYSBnaXZlbiBzY29w ZSwgb3IgdG8gYmUgdG9wb2xvZ2ljYWxseQ0gICBhcHByb3ByaWF0ZS4NDSAgIFN0YW5kYXJkIGF1 dG9tYXRpYyBJUHY2BSBhZGRyZXNzIGFzc2lnbm1lbnQgYW5kIHByZWZpeCBkZWxlZ2F0aW9uDSAg IHNvbHV0aW9ucyBbNV0sIFszXSAFWzRdIGRvIG5vdCB3b3JrICJhcy1pcyIgb24gTUFORVRzIGR1 ZSB0byBhZCBob2MNICAgbmV0d29ya3MnIHVuaXF1ZSBjaGFyYWN0ZXJpc3RpY3MgBVsyBV0uICBU aGVyZWZvcmUgbmV3IG9yIG1vZGlmaWVkDSAgIG1lY2hhbmlzbXMgYXJlIG5lZWRlZCBmb3Igb3Bl cmF0aW9uIHdpdGhpbiBNQU5FVCBzY29wZQUsIGFuZCB0aGlzDSAgIGRvY3VtZW50IHRodXMgZGV0 YWlscyBhbmQgY2F0ZWdvcml6ZXMgdGhlIGlzc3VlcyB0aGF0IG5lZWQgdG8gYmUNICAgYWRkcmVz c2VkLg0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ1CYWNjZWxsaSAoRWQuKSwgZXQgYWwuICAgIEV4 cGlyZXMgTWF5IDIyLCAyMDA4ICAgICAgICAgICAgICAgICAgW1BhZ2UgM10NDA1JbnRlcm5ldC1E cmFmdCAgICAgIE1BTkVUIEF1dG9jb25mIFByb2JsZW0gU3RhdGVtZW50ICAgICAgIE5vdmVtYmVy IDIwMDcNDQ0yLiAgVGVybWlub2xvZ3kNDSAgIFRoaXMgZG9jdW1lbnQgdXNlcyB0aGUgdGVybWlu b2xvZ3kgZGVmaW5lZCBpbiBbMl0sIGFzIHdlbGwgYXMgdGhlDSAgIGZvbGxvd2luZyB0ZXJtcyA6 DQ0gICBNQU5FVCBMb2NhbCBQcmVmaXggKE1MUCkgIC0gQW4gSVAgcHJlZml4IGRlbGVnYXRlZCB0 byBhIE1BTkVUIHJvdXRlciwNICAgICAgY29uc2lzdGluZyBpbiBvZiBjaHVua3Mgb2YgSVAgYWRk cmVzc2VzIHZhbGlkIGZvciBjb21tdW5pY2F0aW9ucw0gICAgICBpbnNpZGUgBXRoZSBNQU5FVC4N DSAgIE1BTkVUIExvY2FsIEFkZHJlc3MgKE1MQSkgIC0gQW4gSVAgYWRkcmVzcyBjb25maWd1cmVk IG9uIGEgTUFORVQNICAgICAgaW50ZXJmYWNlLCBhbmQgdmFsaWQgZm9yIGNvbW11bmljYXRpb25z IGluc2lkZSB0aGUgTUFORVQuDQ0gICBHbG9iYWwgcHJlZml4ICAtIEFuIElQIHByZWZpeCBkZWxl Z2F0ZWQgdG8gYSBNQU5FVCByb3V0ZXIsIGNvbnNpc3RpbmcNICAgICAgaW4gY2h1bmtzIG9mIElQ IGFkZHJlc3NlcyB2YWxpZCBmb3IgY29tbXVuaWNhdGlvbnMgcmVhY2hpbmcNICAgICAgb3V0c2lk ZSB0aGUgTUFORVQgKGFzIHdlbGwgYXMgY29tbXVuaWNhdGlvbnMgd2l0aGluIHRoZSBNQU5FVCku DQ0gICBHbG9iYWwgYWRkcmVzcyAgLSBBbiBJUCBhZGRyZXNzIGNvbmZpZ3VyZWQgb24gYW4gaW50 ZXJmYWNlIGFuZCB2YWxpZA0gICAgICBmb3IgY29tbXVuaWNhdGlvbnMgcmVhY2hpbmcgb3V0c2lk ZSB0aGUgTUFORVQgKGFzIHdlbGwgYXMNICAgICAgY29tbXVuaWNhdGlvbnMgd2l0aGluIHRoZSBN QU5FVCkuDQ0gICBJbnRlcm5ldCBDb25maWd1cmF0aW9uIFByb3ZpZGVyIChJQ1ApICAtIEEgcm91 dGVyIHNlcnZlciAFdGhhdCBjYW4gcHJvdmlkZQ0gICAgICBvdGhlciByb3V0ZXJzIHJlcXVlc3Rp bmcgY29uZmlndXJhdGlvbiB3aXRoIGFkZHJlc3NlcyBvciBwcmVmaXhlcw0gICAgICBkZXJpdmVk IGZyb20gYSBnbG9iYWwgcHJlZml4Lg0NICAgQ29ubmVjdGVkIE1BTkVUICAtIEEgbW9iaWxlIGFk IGhvYyBuZXR3b3JrLCB3aGljaCB0aGF0IGNvbnRhaW5zIGF0IGxlYXN0DSAgICAgIG9uZSBJQ1Au DQ0gICBTdGFuZGFsb25lIE1BTkVUICAtIEEgbW9iaWxlIGFkIGhvYyBuZXR3b3JrLCB3aGljaCB0 aGF0IGRvZXMgbm90IGNvbnRhaW4NICAgICAgYW55IElDUC4NDSAgIE5ldHdvcmsgbWVyZ2luZ2Vy ICAtIFRoZSBwcm9jZXNzIGJ5IHdoaWNoIHR3byBvciBtb3JlIHByZXZpb3VzbHkNICAgICAgZGlz am9pbnQgYWQgaG9jIG5ldHdvcmtzIGdldCBjb25uZWN0ZWQuDQ0gICBOZXR3b3JrIHBhcnRpdGlv bmluZyAgLSBUaGUgcHJvY2VzcyBieSB3aGljaCBhbiBhZCBob2MgbmV0d29yayBzcGxpdHMNICAg ICAgaW50byB0d28gb3IgbW9yZSBkaXNjb25uZWN0ZWQgYWQgaG9jIG5ldHdvcmtzLg0NICAgQWRk cmVzcyBnZW5lcmF0aW9uICAtIFRoZSBwcm9jZXNzIG9mIHNlbGVjdGluZyBhIHRlbnRhdGl2ZSBh ZGRyZXNzDSAgICAgIHdpdGggdGhlIHB1cnBvc2Ugb2YgY29uZmlndXJpbmcgYW4gaW50ZXJmYWNl Lg0NICAgQWRkcmVzcyBhc3NpZ25tZW50ICAtIFRoZSBwcm9jZXNzIG9mIGNvbmZpZ3VyaW5nIGFu IGludGVyZmFjZSB3aXRoIGENICAgICAgZ2l2ZW4gYWRkcmVzcy4NDSAgIFByZWZpeCBkZWxlZ2F0 aW9uICAtIFRoZSBwcm9jZXNzIG9mIHByb3ZpZGluZyBhIHJvdXRlciB3aXRoIGEgc2V0IG9mDSAg ICAgIGNvbnRpZ3VvdXMgYWRkcmVzc2VzcHJlZml4IAVpdCBtYXkgbWFuYWdlIGZvciB0aGUgcHVy cG9zZSBvZiBjb25maWd1cmluZw0gICAgICBpbnRlcmZhY2VzIG9yIG90aGVyIHJvdXRlcnMuDQ0N DQ0NDUJhY2NlbGxpIChFZC4pLCBldCBhbC4gICAgRXhwaXJlcyBNYXkgMjIsIDIwMDggICAgICAg ICAgICAgICAgICBbUGFnZSA0XQ0MDUludGVybmV0LURyYWZ0ICAgICAgTUFORVQgQXV0b2NvbmYg UHJvYmxlbSBTdGF0ZW1lbnQgICAgICAgTm92ZW1iZXIgMjAwNw0NDSAgIFByZS1zZXJ2aWNlIGFk ZHJlc3MgdW5pcXVlbmVzcyAgLSBUaGUgcHJvcGVydHkgb2YgYW4gYWRkcmVzcyB3aGljaCB0aGF0 IGlzDSAgICAgIGFzc2lnbmVkIGF0IG1vc3Qgb25jZSB3aXRoaW4gYSBnaXZlbiBzY29wZSwgYW5k IHdoaWNoIGlzIHVuaXF1ZSwNICAgICAgYmVmb3JlIGl0IGlzIGJlaW5nIHVzZWQsIGJ1dCBkb2Vz IG5vdCBuZWNlc3NhcmlseSByZW1haW4gdW5pcXVlIG92ZXIgdGltZS4NDSAgIEluLXNlcnZpY2Ug YWRkcmVzcyB1bmlxdWVuZXNzICAtIFRoZSBwcm9wZXJ0eSBvZiBhbiBhZGRyZXNzIHdoaWNoIHRo YXQgd2FzDSAgICAgIGFzc2lnbmVkIGF0IG1vc3Qgb25jZSB3aXRoaW4gYSBnaXZlbiBzY29wZSwg YW5kIHdoaWNoIHJlbWFpbnMNICAgICAgdW5pcXVlIG92ZXIgdGltZSwgYWZ0ZXIgdGhlIGFkZHJl c3MgaGFzIHN0YXJ0ZWQgYmVpbmcgdXNlZC4NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0N DQ0NDQ0NDQ0NDQ0NDQ1CYWNjZWxsaSAoRWQuKSwgZXQgYWwuICAgIEV4cGlyZXMgTWF5IDIyLCAy MDA4ICAgICAgICAgICAgICAgICAgW1BhZ2UgNV0NDA1JbnRlcm5ldC1EcmFmdCAgICAgIE1BTkVU IEF1dG9jb25mIFByb2JsZW0gU3RhdGVtZW50ICAgICAgIE5vdmVtYmVyIDIwMDcNDQ0zLiAgRGVw bG95bWVudCBTY2VuYXJpb3MNDSAgIEF1dG9tYXRpYyBjb25maWd1cmF0aW9uIG9mIElQIGFkZHJl c3NlcyBvbiBNQU5FVCBpbnRlcmZhY2VzIGFuZA0gICBwcmVmaXggZGVsZWdhdGlvbiB0byBNQU5F VCByb3V0ZXJzIGFyZSBuZWNlc3NhcnkgaW4gYSBudW1iZXIgb2YNICAgZGVwbG95bWVudCBzY2Vu YXJpb3MuICBUaGlzIHNlY3Rpb24gb3V0bGluZXMgdGhlIGRpZmZlcmVudCBjYXRlZ29yaWVzDSAg IG9mIHNjZW5hcmlvcyB0aGF0IGFyZSBjb25zaWRlcmVkLg0NMy4xLiAgQ29ubmVjdGVkIE1BTkVU DQ0gICBDb25uZWN0ZWQgTUFORVRzIGFyZSBtb2JpbGUgYWQgaG9jIG5ldHdvcmtzIHdoaWNoIHRo YXQgY29udGFpbiBhdCBsZWFzdA0gICBvbmUgSUNQLCBpLmUuLCBhIHJvdXRlciBzZXJ2ZXIgBXRo YXQgY2FuIHByb3ZpZGUgb3RoZXIgcm91dGVycyByZXF1ZXN0aW5nDSAgIGNvbmZpZ3VyYXRpb24g d2l0aCBhZGRyZXNzZXMgb3IgcHJlZml4ZXMgZGVyaXZlZCBmcm9tIGEgZ2xvYmFsDSAgIHByZWZp eC4gIFJvdXRlcnMgam9pbmluZyBhIGNvbm5lY3RlZCBNQU5FVCBtYXkgZWl0aGVyIChpKSBoYXZl IG5vDSAgIHByZXZpb3VzIGNvbmZpZ3VyYXRpb24sIG9yIChpaSkgYWxyZWFkeSBvd24gcHJlLWNv bmZpZ3VyZWQgbG9jYWwgb3INICAgZ2xvYmFsIElQIGFkZHJlc3NlcyAob3IgcHJlZml4ZXMpLg0N ICAgVHlwaWNhbCBpbnN0YW5jZXMgb2YgdGhpcyBzY2VuYXJpbyBpbmNsdWRlIHB1YmxpYyB3aXJl bGVzcyBuZXR3b3Jrcw0gICBvZiBzY2F0dGVyZWQgZml4ZWQgV0xBTiBBY2Nlc3MgUG9pbnRzIHBh cnRpY2lwYXRpbmcgaW4gYSBNQU5FVCBvZg0gICBtb2JpbGUgdXNlcnNyb3V0ZXJzLCBhbmQgYWN0 aW5nIGFzIE1BTkVUIGJvcmRlciByb3V0ZXJzLiAgQW5vdGhlciBleGFtcGxlIG9mDSAgIHN1Y2gg YSBzY2VuYXJpbyBpcyBjb3ZlcmFnZSBleHRlbnNpb24gb2YgYSBmaXhlZCB3aWRlLWFyZWEgd2ly ZWxlc3MNICAgbmV0d29yaywgd2hlcmUgb25lIG9yIG1vcmUgbW9iaWxlIHJvdXRlcnMgaW4gdGhl IE1BTkVUIGFyZSBjb25uZWN0ZWQNICAgdG8gdGhlIEludGVybmV0IHRocm91Z2ggdGVjaG5vbG9n aWVzIHN1Y2ggYXMgVU1UUyBvciBXaU1BWC4NDTMuMi4gIFN0YW5kYWxvbmUgTUFORVQNDSAgIFN0 YW5kYWxvbmUgTUFORVRzIGFyZSBtb2JpbGUgYWQgaG9jIG5ldHdvcmtzIHdoaWNoIHRoYXQgZG8g bm90IGNvbnRhaW4gYW55DSAgIElDUCwgaS5lLiB3aGljaCBkbyBub3QgY29udGFpbiBhbnkgcm91 dGVyIHNlcnZlciBhYmxlIHRvIHByb3ZpZGUgb3RoZXINICAgcm91dGVycyByZXF1ZXN0aW5nIGNv bmZpZ3VyYXRpb24gd2l0aCBhZGRyZXNzZXMgb3IgcHJlZml4ZXMgZGVyaXZlZA0gICBmcm9tIGEg Z2xvYmFsIHByZWZpeC4gIEFnYWluLCByb3V0ZXJzIGpvaW5pbmcgYSBzdGFuZGFsb25lIE1BTkVU IG1heQ0gICBlaXRoZXIgaGF2ZSAoaSkgbm8gcHJldmlvdXMgY29uZmlndXJhdGlvbiwgb3IgKGlp KSBwcmUtY29uZmlndXJlZA0gICBsb2NhbCBvciBnbG9iYWwgSVAgYWRkcmVzc2VzIChvciBwcmVm aXhlcykuICBEdWUgdG8gcG90ZW50aWFsIG5ldHdvcmsNICAgcGFydGl0aW9ucyBhbmQgbWVyZ2Vy cywgc3RhbmRhbG9uZSBNQU5FVHMgbWF5IGJlIGNvbXBvc2VkIG9mIHJvdXRlcnMNICAgb2YgZWl0 aGVyIHR5cGVzLg0NICAgVHlwaWNhbCBpbnN0YW5jZXMgb2YgdGhpcyBzY2VuYXJpbyBpbmNsdWRl IHByaXZhdGUgb3IgdGVtcG9yYXJ5DSAgIG5ldHdvcmtzLCBzZXQtdXAgaW4gYXJlYXMgd2hlcmUg bmVpdGhlciB3aXJlbGVzcyBjb3ZlcmFnZSBub3IgbmV0d29yaw0gICBpbmZyYXN0cnVjdHVyZSBl eGlzdCAoZS5nLiwgZW1lcmdlbmN5IG5ldHdvcmtzIGZvciBkaXNhc3RlciByZWNvdmVyeSwNICAg b3IgY29uZmVyZW5jZS1yb29tIG5ldHdvcmtzKS4NDTMuMy4gIERlcGxveW1lbnQgU2NlbmFyaW9z IFNlbGVjdGlvbg0NICAgQm90aCAiU3RhbmRhbG9uZSBNQU5FVCIgYW5kICJDb25uZWN0ZWQgTUFO RVQiIHNjZW5hcmlvcyBhcmUgdG8gYmUNICAgYWRkcmVzc2VkIGJ5IHNvbHV0aW9ucyBmb3IgTUFO RVQgYXV0b2NvbmZpZ3VyYXRpb24uICBOb3RlIHRoYXQNICAgc29sdXRpb25zIHNob3VsZCBhbHNv IGFpbSBhdCBhZGRyZXNzaW5nIGNhc2VzIHdoZXJlIGEgTUFORVQgdHJhbnNpdGlvbnMNICAgZnJv bSBvbmUgc2NlbmFyaW8gdG8gYW4gb3RoZXIuDQ0NDQ0NDUJhY2NlbGxpIChFZC4pLCBldCBhbC4g ICAgRXhwaXJlcyBNYXkgMjIsIDIwMDggICAgICAgICAgICAgICAgICBbUGFnZSA2XQ0MDUludGVy bmV0LURyYWZ0ICAgICAgTUFORVQgQXV0b2NvbmYgUHJvYmxlbSBTdGF0ZW1lbnQgICAgICAgTm92 ZW1iZXIgMjAwNw0NDTQuICBQcm9ibGVtIFN0YXRlbWVudA0NICAgVGhpcyBzZWN0aW9uIGRldGFp bHMgdGhlIGdvYWxzIG9mIE1BTkVUIGF1dG9jb25maWd1cmF0aW9uLiAgQQ0gICB0YXhvbm9teSBv ZiBhdXRvY29uZmlndXJhdGlvbiBpc3N1ZXMgc3BlY2lmaWMgdG8gTUFORVRzIGlzIHRoZW4NICAg ZWxhYm9yYXRlZC4NDTQuMS4gIE1BTkVUIEF1dG9jb25maWd1cmF0aW9uIEdvYWxzDQ0gICBBIE1B TkVUIHJvdXRlciBuZWVkcyB0byBjb25maWd1cmUgSVAgYWRkcmVzc2VzIGFuZCBwcmVmaXhlcyBh cyB1c3VhbCwNICAgb24gaXRzIG5vbi1NQU5FVCBpbnRlcmZhY2VzIGFzIHdlbGwgYXMgaXRzIGF0 dGFjaGVkIGhvc3RzIGFuZA0gICByb3V0ZXJzLCBpZiBhbnkuICBJbiBhZGRpdGlvbiwgYSBNQU5F VCByb3V0ZXIgbmVlZHMgdG8gY29uZmlndXJlIGF0DSAgIGxlYXN0IG9uZSBJUCBhZGRyZXNzIG9u IGl0cyBNQU5FVCBpbnRlcmZhY2UsIHRoaXMgYmVpbmcgYSBsaW5rIGxvY2FsDSAgIGFkZHJlc3Ms IGFuIE1MQSBvciBhIGdsb2JhbCBhZGRyZXNzLiAgQSBNQU5FVCByb3V0ZXIgbWF5IGFsc28gcmVx dWlyZQ0gICBhIGRlbGVnYXRlZCBNTFAsIHByb3ZpZGVkIHByZWZpeCB1bmlxdWVuZXNzIGlzIGd1 YXJhbnRlZWQgBVsyXS4NDSAgIFRoZSBwcmltYXJ5IGdvYWwgb2YgTUFORVQgYXV0b2NvbmZpZ3Vy YXRpb24gaXMgdGh1cyB0byBwcm92aWRlDSAgIG1lY2hhbmlzbXMgZm9yIElQdjYFIHByZWZpeCBk ZWxlZ2F0aW9uIGFuZCBhZGRyZXNzIGFzc2lnbm1lbnQgZm9yDSAgIG9wZXJhdGlvbiBvbiBtb2Jp bGUgYWQgaG9jIG5ldHdvcmtzLiAgTm90ZSB0aGF0IHRoaXMgdGFzayBpcyBkaXN0aW5jdA0gICBm cm9tIHRoYXQgb2YgcHJvcGFnYXRpbmcga25vd2xlZGdlIGFib3V0IGFkZHJlc3Mgb3IgcHJlZml4 IGxvY2F0aW9uLA0gICBhcyBhIHJvdXRpbmcgcHJvdG9jb2wgZG9lcyAoc2VlIGZvciBleGFtcGxl IFs4XSwgWzldKSwgb3IgYXMNICAgZGVzY3JpYmVkIGluIFs3XS4NDSAgIFRoZSBtZWNoYW5pc21z IGVtcGxveWVkIGJ5IHNvbHV0aW9ucyB0byBiZSBkZXNpZ25lZCBtdXN0IGFkZHJlc3MgdGhlDSAg IGRpc3RyaWJ1dGVkLCBtdWx0aS1ob3AgbmF0dXJlIG9mIE1BTkVUcyBbMl0sIGFuZCBiZSBhYmxl IHRvIGZvbGxvdw0gICB0b3BvbG9neSBhbmQgY29ubmVjdGl2aXR5IGNoYW5nZXMgYnkgKHJlKWNv bmZpZ3VyaW5nIGFkZHJlc3NlcyBhbmQvb3INICAgcHJlZml4ZXMgYWNjb3JkaW5nbHkuDQ0gICBU cmFkaXRpb25hbCBkeW5hbWljIElQIGFkZHJlc3MgYXNzaWdubWVudCBwcm90b2NvbHMsIHN1Y2gg YXMgWzVdLCBbM10FDSAgIG9yIFs0XSwgZG8gbm90IHdvcmsgZWZmaWNpZW50bHkgKGlmIGF0IGFs bCkgb24gTUFORVRzLCBkdWUgdG8gdGhlc2UNICAgbmV0d29ya3MnIHVuaXF1ZSBwcm9wZXJ0aWVz BS4gIFRoZSBmb2xsb3dpbmcgdGh1cyBvdmVydmlld3Mgd2hhdCBtdXN0DSAgIGJlIHNwZWNpZmlj YWxseSBzdXBwb3J0ZWQgZm9yIGVmZmljaWVudCBvcGVyYXRpb24gb24gbW9iaWxlIGFkIGhvYw0g ICBuZXR3b3Jrcy4NDTQuMS4xLiAgTXVsdGktaG9wIFN1cHBvcnQNDSAgIFRyYWRpdGlvbmFsIHNv bHV0aW9ucyBhc3N1bWUgdGhhdCBhIGJyb2FkY2FzdCBkaXJlY3RseSByZWFjaGVzIGV2ZXJ5DSAg IHJvdXRlciBvciBob3N0IG9uIHRoZSBzdWJuZXR3b3JrLCB3aGVyZWFzIHRoaXMgZ2VuZXJhbGx5 IGlzIG5vdCB0aGUNICAgY2FzZSBpbiBNQU5FVHMgKHNlZSBbMl0pLiAgBVNvbWUgcm91dGVycyBp biB0aGUgTUFORVQgd2lsbCB0eXBpY2FsbHkNICAgYXNzdW1lIG11bHRpaG9wIGJyb2FkY2FzdCwg YW5kIGV4cGVjdCB0byByZWNlaXZlIHRocm91Z2ggc2V2ZXJhbA0gICBpbnRlcm1lZGlhdGUgcmVs YXlpbmdzIGJ5IHBlZXIgTUFORVQgcm91dGVycy4gIEZvciBleGFtcGxlLCBpbiBGaWcuDSAgIDEs IHRoZSBNQU5FVCByb3V0ZXIgTVIzIGNhbm5vdCBjb21tdW5pY2F0ZSBkaXJlY3RseSB3aXRoIGEg REhDUA0gICBzZXJ2ZXIgWzRdIHRoYXQgd291bGQgYmUgYXZhaWxhYmxlIHRocm91Z2ggYSBNQU5F VCBib3JkZXIgcm91dGVyBSwNICAgc2luY2UgdGhlIHNlcnZlciBhbmQgdGhlIE1BTkVUIHJvdXRl ciBhcmUgbm90IGxvY2F0ZWQgb24gdGhlIHNhbWUNICAgbG9naWNhbCBsaW5rLiAgV2hpbGUgREhD UCBjYW4gdG8gc29tZSBleHRlbnQgb3ZlcmNvbWUgdGhpcyBpc3N1ZSBpbiBhDSAgIHN0YXRpYyBu ZXR3b3JrLCBpdCBpcyBub3QgdGhlIGNhc2UgaW4gYSBkeW5hbWljIHRvcG9sb2d5LCBhcw0gICBl eHBsYWluZWQgYmVsb3cuDQ0NDQ0NQmFjY2VsbGkgKEVkLiksIGV0IGFsLiAgICBFeHBpcmVzIE1h eSAyMiwgMjAwOCAgICAgICAgICAgICAgICAgIFtQYWdlIDddDQwNSW50ZXJuZXQtRHJhZnQgICAg ICBNQU5FVCBBdXRvY29uZiBQcm9ibGVtIFN0YXRlbWVudCAgICAgICBOb3ZlbWJlciAyMDA3DQ0N ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0t LS0tIE1SMS4uLk1SMw0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAvICAgICAgLg0gICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tKyAgICAgICAg ICstLS0tLS0tLS0tLS0rIC8gICAgICAgLg0gICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAg IHAycCAgIHwgIE1BTkVUICAgICB8LyAgICAgICAgLg0gICAgICAgICAgICAgIHwgIElTUCBFZGdl ICAgfCAgIExpbmsgIHwgIEJvcmRlciAgICB8ICAgICAgICAgLg0gICAgICAgICAgICAgIHwgICBS b3V0ZXIgICAgKy0tLS0tLS0tLSsgIFJvdXRlciAgICB8XCAgICAgICAgLg0gICAgICAgICAgICAg IHwgICAgICAgICAgICAgfCAgICAgICAgIHwgICAgICAgICAgICB8IFwgICAgICAgLg0gICAgICAg ICAgICAgICstLS0tLS0tLS0tLS0tKyAgICAgICAgICstLS0tLS0tLS0tLS0rICBcLS0tLS0gTVIy DQ0gICAgICAgICAgICAgICAgICAgICAgIEZpZy4gMS4gQ29ubmVjdGVkIE1BTkVUIHJvdXRlciB0 b3BvbG9neS4NDQ0NNC4xLjIuICBEeW5hbWljIFRvcG9sb2d5IFN1cHBvcnQNDSAgIEEgc2lnbmlm aWNhbnQgcHJvcG9ydGlvbiBvZiB0aGUgcm91dGVycyBpbiB0aGUgTUFORVQgbWF5IGJlIG1vYmls ZQ0gICB3aXRoIHdpcmVsZXNzIGludGVyZmFjZShzKSwgbGVhZGluZyB0byBldmVyIGNoYW5naW5n IG5laWdoYm9yIHNldHMNICAgZm9yIG1vc3QgTUFORVQgcm91dGVycyAoc2VlIFsxXSkuICBUaGVy ZWZvcmUsIG5ldHdvcmsgdG9wb2xvZ3kgbWF5DSAgIGNoYW5nZSByYXRoZXIgZHluYW1pY2FsbHkg Y29tcGFyZWQgdG8gdHJhZGl0aW9uYWwgbmV0d29ya3MsIHdoaWNoDSAgIGludmFsaWRhdGVzIHRy YWRpdGlvbmFsIGRlbGVnYXRpb24gc29sdXRpb25zIHRoYXQgd2VyZSBkZXZlbG9wZWQgZm9yDSAg IGluZnJhc3RydWN0dXJlLWJhc2VkIG5ldHdvcmtzBSwgc3VjaCBhcyBbMTFdLCB3aGljaCBkbyBu b3QgYXNzdW1lDSAgIGludGVybWl0dGVudCByZWFjaGFiaWxpdHkgb2YgY29uZmlndXJhdGlvbiBz ZXJ2ZXIocyksIGFuZCBhDSAgIHBvdGVudGlhbGx5IGV2ZXIgY2hhbmdpbmcgaGllcmFyY2h5IGFt b25nIGRldmljZXMuICBGb3IgaW5zdGFuY2UsIGluDSAgIEZpZy4gMSwgZXZlbiBpZiBNUjEgd291 bGQgYmUgYWJsZSB0byBkZWxlZ2F0ZSBwcmVmaXhlcyB0byBNUjMgd2l0aA0gICBESENQIFs0XQUs IGl0IGNhbm5vdCBiZSBhc3N1bWVkIHRoYXQgTVIxIGFuZCBNUjMgd2lsbCBub3QgbW92ZSBhbmQN ICAgYmVjb21lIHVuYWJsZSB0byBjb21tdW5pY2F0ZSBkaXJlY3RseS4gIE1vcmVvdmVyLCBwb3Nz aWJsZSBmcmVxdWVudA0gICByZWNvbmZpZ3VyYXRpb24gZHVlIHRvIGludGVybWl0dGVudCByZWFj aGFiaWxpdHkgY2F1c2UgWzVdBSB0byBiZSBsZXNzDSAgIGVmZmljaWVudCB0aGFuIGV4cGVjdGVk LCBkdWUgdG8gbGFyZ2UgYW1vdW50cyBvZiBjb250cm9sIHNpZ25hbGxpbmcuDQ0gICBJbiBwYXJ0 aWN1bGFyLCBzdXBwb3J0aW5nIG11bHRpaG9wIGR5bmFtaWMgdG9wb2xvZ2llcyBtZWFucyB0aGF0 IGV2ZW4NICAgaWYgc29tZSBhZGRyZXNzIGNvbmZpZ3VyYXRpb24gc2VydmVycyBhcmUgcHJlc2Vu dCBzb21ld2hlcmUsIGl0DSAgIGNhbm5vdCBiZSBhc3N1bWVkIHRoYXQgdGhleSBhcmUgcmVhY2hh YmxlIG1vc3Qgb2YgdGhlIHRpbWUFLCBjb250cmFyeQ0gICB0byB1c3VhbCBzY2VuYXJpb3MuICBU aGVyZWZvcmUsIHJldXNpbmcgImFzLWlzIiBleGlzdGluZyBzb2x1dGlvbnMNICAgKGZvciBpbnN0 YW5jZSBbNF0pIHVzaW5nIHNlcnZlcnMgb24gYSBNQU5FVCB3b3VsZCBiYXNpY2FsbHkgaW1wbHkN ICAgdGhhdCAiZXZlcnlvbmUgaXMgYSBzZXJ2ZXIiIGluIG9yZGVyIHRvIGVuc3VyZSBzZXJ2ZXIg cmVhY2hhYmlsaXR5BS4NICAgVGhpcyBpbXBsaWNhdGlvbiBpcyB0aGUgc3BlY2lmaWNpdHkgb2Yg TUFORVRzIHRoYXQgYnJpbmdzIHRoZQ0gICByZXF1aXJlbWVudCBmb3IgbmV3IGxldmVscyBvZiBz ZXJ2aWNlIGRpc3RyaWJ1dGlvbiwgc2luY2UgdGhlDSAgICJldmVyeW9uZSBpcyBhIHNlcnZlciIg YXBwcm9hY2ggBWlzIGVzc2VudGlhbGx5IG5vdCBmdW5jdGlvbmFsLg0NNC4xLjMuICBOZXR3b3Jr IE1lcmdpbmcgU3VwcG9ydA0NICAgTmV0d29yayBtZXJnaW5nIGlzIGEgcG90ZW50aWFsIGV2ZW50 IHRoYXQgd2FzIG5vdCBjb25zaWRlcmVkIGluIHRoZQ0gICBkZXNpZ24gb2YgdHJhZGl0aW9uYWwg c29sdXRpb25zLCBhbmQgdGhhdCBtYXkgZ3JlYXRseSBkaXNydXB0IHRoZQ0gICBhdXRvY29uZmln dXJhdGlvbiBtZWNoYW5pc21zIGluIHVzZSAoc2VlIFsyXSkFLiAgRXhhbXBsZXMgb2YgbmV0d29y aw0gICBtZXJnaW5nIHJlbGF0ZWQgaXNzdWVzIGluY2x1ZGUgY2FzZXMgd2hlcmUgYSBNQU5FVCBB IG1heSBmZWF0dXJlDSAgIHJvdXRlcnMgYW5kIGhvc3RzIHRoYXQgdXNlIElQIGFkZHJlc3NlcyB0 aGF0IGFyZSBsb2NhbGx5IHVuaXF1ZQ0gICB3aXRoaW4gTUFORVQgQSwgYnV0IHRoaXMgdW5pcXVl bmVzcyBpcyBub3QgZ3VhcmFudGVlZCBhbnkgbW9yZSBpZg0gICBNQU5FVCBBIG1lcmdlcyB3aXRo IGFub3RoZXIgTUFORVQgQi4gSWYgYWRkcmVzcyB1bmlxdWVuZXNzIGlzDQ0NDUJhY2NlbGxpIChF ZC4pLCBldCBhbC4gICAgRXhwaXJlcyBNYXkgMjIsIDIwMDggICAgICAgICAgICAgICAgICBbUGFn ZSA4XQ0MDUludGVybmV0LURyYWZ0ICAgICAgTUFORVQgQXV0b2NvbmYgUHJvYmxlbSBTdGF0ZW1l bnQgICAgICAgTm92ZW1iZXIgMjAwNw0NDSAgIHJlcXVpcmVkIHdpdGhpbiB0aGUgTUFORVQgKHNl ZSBTZWN0aW9uIDQuMi4yKSwgaXNzdWVzIGFyaXNlIHRoYXQgd2VyZQ0gICBub3QgYWNjb3VudGVk IGZvciBpbiB0cmFkaXRpb25hbCBuZXR3b3JrcyBhbmQgc29sdXRpb25zBS4gIEZvcg0gICBpbnN0 YW5jZSwgWzVdIGFuZCBbM10gdGVzdCBhZGRyZXNzIHVuaXF1ZW5lc3MgdmlhIG1lc3NhZ2VzIHRo YXQgYXJlDSAgIHNlbnQgdG8gbmVpZ2hib3JzIG9ubHkFLCBhbmQgYXMgc3VjaCBjYW5ub3QgZGV0 ZWN0IHRoZSBwcmVzZW5jZSBvZg0gICBkdXBsaWNhdGUgYWRkcmVzc2VzIGNvbmZpZ3VyZWQgd2l0 aGluIHRoZSBuZXR3b3JrIGJ1dCBsb2NhdGVkIHNldmVyYWwNICAgaG9wcyBhd2F5LiAgSG93ZXZl ciwgc2luY2UgTUFORVRzIGFyZSBnZW5lcmFsbHkgbXVsdGktaG9wLCBkZXRlY3Rpb24NICAgb2Yg ZHVwbGljYXRlIGFkZHJlc3NlcyBvdmVyIHNldmVyYWwgaG9wcyBpcyBhIGZlYXR1cmUgdGhhdCBt YXkgYmUNICAgcmVxdWlyZWQgZm9yIE1BTkVUIGludGVyZmFjZSBhZGRyZXNzIGFzc2lnbm1lbnQg KHNlZSBTZWN0aW9uIDQuMi4yKS4NDTQuMS40LiAgTmV0d29yayBQYXJ0aXRpb25pbmcgU3VwcG9y dA0NICAgTmV0d29yayBwYXJ0aXRpb25pbmcgaXMgYSBwb3RlbnRpYWwgZXZlbnQgdGhhdCB3YXMg bm90IGNvbnNpZGVyZWQgaW4NICAgdGhlIGRlc2lnbiBvZiB0cmFkaXRpb25hbCBzb2x1dGlvbnMs IGFuZCB0aGF0IG1heSBpbnZhbGlkYXRlIHVzdWFsDSAgIGF1dG9jb25maWd1cmF0aW9uIG1lY2hh bmlzbXMgKHNlZSBbMl0pBS4gIEV4YW1wbGVzIG9mIHJlbGF0ZWQgaXNzdWVzDSAgIGluY2x1ZGUg Y2FzZXMgc3VjaCBhcyBhIHN0YW5kYWxvbmUgTUFORVQsIHdoZXJlYnkgY29ubmVjdGlvbiB0byB0 aGUNICAgaW5mcmFzdHJ1Y3R1cmUgaXMgbm90IGF2YWlsYWJsZSwgcG9zc2libHkgZHVlIHRvIG5l dHdvcmsgcGFydGl0aW9uaW5nDSAgIGFuZCBsb3NzIG9mIGNvbm5lY3Rpdml0eSB0byBhIE1BTkVU IGJvcmRlciByb3V0ZXIuICBUaGUgTUFORVQgbXVzdA0gICB0aHVzIGZ1bmN0aW9uIAV3aXRob3V0 IHRyYWRpdGlvbmFsIGFkZHJlc3MgYWxsb2NhdGlvbiBzZXJ2ZXINICAgYXZhaWxhYmlsaXR5LiAg V2hpbGUgc3RhdGVsZXNzIHByb3RvY29scyBzdWNoIGFzIFs1XSBhbmQgWzNdIGNvdWxkDSAgIHBy b3ZpZGUgSVAgYWRkcmVzcyBjb25maWd1cmF0aW9uIChmb3IgTUFORVQgaW50ZXJmYWNlcywgbG9v cGJhY2sNICAgaW50ZXJmYWNlcyksIHRoZXNlIHNvbHV0aW9ucyBkbyBub3QgcHJvdmlkZSBhbnkg bWVjaGFuaXNtIGZvcg0gICBhbGxvY2F0aW5nICJ1bmlxdWUgcHJlZml4KGVzKSIgdG8gcm91dGVy cyBpbiBvcmRlciB0byBlbmFibGUgdGhlDSAgIGNvbmZpZ3VyYXRpb24gb2YgaG9zdCBpbnRlcmZh Y2VzLg0NDQ0gICAgICAgICAgICAgICAgICAgICAgICAgIC0tLS0tIE1SMS4uLk1SMy4uLk1SNQ0g ICAgICAgICAgICAgICAgICAgICAgICAgLyAgICAgIC4NICAgICAgICAgICAgICAgICAgICAgICAg LyAgICAgICAuDSAgICAgICAgICAgICAgICAgICAgICAgLyAgICAgICAgLg0gICAgICAgICAgICAg ICAgICAgIE1SNCAgICAgICAgIC4NICAgICAgICAgICAgICAgICAgICAgICBcICAgICAgICAuDSAg ICAgICAgICAgICAgICAgICAgICAgIFwgICAgICAgLg0gICAgICAgICAgICAgICAgICAgICAgICAg XC0tLS0tIE1SMg0NICAgICAgICAgICAgICAgICAgICAgICBGaWcuIDIuIFN0YW5kYWxvbmUgTUFO RVQgcm91dGVyIHRvcG9sb2d5Lg0NDQ0NNC4yLiAgTUFORVQgQXV0b2NvbmZpZ3VyYXRpb24gSXNz dWVzDQ0gICBUYWtpbmcgaW50byBhY2NvdW50IHRoZSBzaG9ydGNvbWluZ3Mgb2YgdHJhZGl0aW9u YWwgc29sdXRpb25zIAVpbiB0aGUNICAgbW9iaWxlIGFkIGhvYyBjb250ZXh0LCB0aGlzIHNlY3Rp b24gY2F0ZWdvcml6ZXMgZ2VuZXJhbCBpc3N1ZXMgd2l0aA0gICByZWdhcmRzIHRvIE1BTkVUIGF1 dG9jb25maWd1cmF0aW9uLg0NDQ0NDQ1CYWNjZWxsaSAoRWQuKSwgZXQgYWwuICAgIEV4cGlyZXMg TWF5IDIyLCAyMDA4ICAgICAgICAgICAgICAgICAgW1BhZ2UgOV0NDA1JbnRlcm5ldC1EcmFmdCAg ICAgIE1BTkVUIEF1dG9jb25mIFByb2JsZW0gU3RhdGVtZW50ICAgICAgIE5vdmVtYmVyIDIwMDcN DQ00LjIuMS4gIEFkZHJlc3MgYW5kIFByZWZpeCBHZW5lcmF0aW9uDQ0gICBUaGUgZGlzdHJpYnV0 ZWQgbmF0dXJlIG9mIE1BTkVUcyBicmluZ3MgdGhlIG5lZWQgZm9yIGFkZHJlc3MNICAgZ2VuZXJh dGlvbiBhbGdvcml0aG1zIHRoYXQgY2FuIGNvbXBsZW1lbnQgZXhpc3Rpbmcgc29sdXRpb25zIGJ5 DSAgIHN1cHBvcnRpbmcgb3BlcmF0aW9uIG91dHNpZGUgImNsaWVudC1zZXJ2ZXIiIHNjaGVtZXMg BWFuZCB3aXRob3V0DSAgIGZpeGVkIGhpZXJhcmNoaWVzIHRvIHByb3ZpZGUgcm91dGVycyB3aXRo IGFwcHJvcHJpYXRlIGFkZHJlc3NlcyBhbmQNICAgcHJlZml4ZXMuICBJbiBhZGRpdGlvbiwgdGhl IG11bHRpLWhvcCBhc3BlY3Qgb2YgTUFORVRzIGJyaW5ncw0gICBzcGVjaWZpYyBuZWVkcyBhcyBm YXIgYXMgYWRkcmVzcyBhbmQgcHJlZml4IHVuaXF1ZW5lc3MgaXMgY29uY2VybmVkLA0gICBhcyBk ZXRhaWxlZCBiZWxvdy4NDTQuMi4yLiAgUHJlZml4IGFuZCBBZGRyZXNzIFVuaXF1ZW5lc3MgUmVx dWlyZW1lbnRzDQ0gICBJZiBwcmVmaXggb3IgYWRkcmVzcyB1bmlxdWVuZXNzIGlzIHJlcXVpcmVk IAV3aXRoaW4gYSBzcGVjaWZpYyBzY29wZSwNICAgYW5kIGlmIHRoZSBhZGRyZXNzL3ByZWZpeCBn ZW5lcmF0aW9uIG1lY2hhbmlzbSBpbiB1c2UgZG9lcyBub3QgZW5zdXJlDSAgIGFkZHJlc3MvcHJl Zml4IHVuaXF1ZW5lc3MsIHRoZW4gYWRkaXRpb25hbCBpc3N1ZXMgYXJpc2UuICBUaGlzDSAgIHNl Y3Rpb24gb3ZlcnZpZXdzIHRoZXNlIHByb2JsZW1zLg0NICAgUHJlLXNlcnZpY2UgSXNzdWVzIC0t IEFkZHJlc3Mgb3IgcHJlZml4IHVuaXF1ZW5lc3MgcHJvYmxlbXMgaW4gdGhpcw0gICBjYXRlZ29y eSBhcmUgY2FsbGVkIHByZS1zZXJ2aWNlIGlzc3Vlcy4gIENvbmNlcHR1YWxseSwgdGhleSByZWxh dGUgdG8NICAgdGhlIGZhY3QgdGhhdCBiZWZvcmUgYSBnZW5lcmF0ZWQgYWRkcmVzcyBvciBwcmVm aXggaXMgYXNzaWduZWQgYW5kDSAgIHVzZWQsIGl0IHNob3VsZCBiZSB2ZXJpZmllZCB0aGF0IGl0 IHdpbGwgbm90IGNyZWF0ZSBhbiBhZGRyZXNzDSAgIGNvbmZsaWN0IHdpdGhpbiB0aGUgc3BlY2lm aWVkIHNjb3BlLiAgVGhpcyBpcyBlc3NlbnRpYWwgaW4gdGhlDSAgIGNvbnRleHQgb2Ygcm91dGlu Zywgd2hlcmUgaXQgaXMgZGVzaXJlYWJsZSB0byByZWR1Y2UgdGhlIHJpc2tzIG9mDSAgIGxvb3Bz BSBkdWUgdG8gcm91dGluZyB0YWJsZSBwb2xsdXRpb24gd2l0aCBkdXBsaWNhdGUgYWRkcmVzc2Vz Lg0NICAgSW4tU2VydmljZSBJc3N1ZXMgLS0gQWRkcmVzcyBvciBwcmVmaXggdW5pcXVlbmVzcyBw cm9ibGVtcyBpbiB0aGlzDSAgIGNhdGVnb3J5IGFyZSBjYWxsZWQgaW4tc2VydmljZSBpc3N1ZXMu ICBUaGV5IGNvbWUgZnJvbSB0aGUgZmFjdCB0aGF0DSAgIGV2ZW4gaWYgYW4gYXNzaWduZWQgYWRk cmVzcyBvciBwcmVmaXggaXMgY3VycmVudGx5IHVuaXF1ZSB3aXRoaW4gdGhlDSAgIHNwZWNpZmll ZCBzY29wZSwgaXQgY2Fubm90IGJlIGVuc3VyZWQgdGhhdCBpdCB3aWxsIGluZGVlZCByZW1haW4N ICAgdW5pcXVlIG92ZXIgdGltZS4NDSAgIFBoZW5vbWVuYSBzdWNoIGFzIE1BTkVUIG5ldHdvcmsg bWVyZ2luZyBhbmQgTUFORVQgbmV0d29yayBwYXJ0aXRpb25pbmcgBW1heSAFYnJpbmcgdGhlDSAg IG5lZWQgZm9yIGNoZWNraW5nIHRoZSB1bmlxdWVuZXNzICh3aXRoaW4gdGhlIHNwZWNpZmllZCBz Y29wZSkgb2YNICAgYWRkcmVzc2VzIG9yIHByZWZpeGVzIHRoYXQgYXJlIGFscmVhZHkgYXNzaWdu ZWQgYW5kIHVzZWQuICBUaGlzIG5lZWQNICAgbWF5IGRlcGVuZCBvbiAoaSkgdGhlIHByb2JhYmls aXR5IG9mIGFkZHJlc3MgY29uZmxpY3RzLCAoaWkpIHRoZQ0gICBhbW91bnQgb2YgdGhlIG92ZXJo ZWFkIGZvciBjaGVja2luZyB1bmlxdWVuZXNzIG9mIGFkZHJlc3NlcywgYW5kDSAgIChpaWkpIGFk ZHJlc3MvcHJlZml4IHVuaXF1ZW5lc3MgcmVxdWlyZW1lbnRzIGZyb20gYXBwbGljYXRpb25zLg0N ICAgRm9yIGluc3RhbmNlLCBpZiAoaSkgaXMgZXh0cmVtZWx5IGxvdyBhbmQgKGlpKSBzaWduaWZp Y2FudCwgdGhlbg0gICBjaGVja2luZyBwcmUtc2VydmljZSB1bmlxdWVuZXNzIG9mIGFkZHJlc3Nl cyBhbmQgcHJlZml4ZXMgbWF5IG5vdCBiZQ0gICB1c2VkLiAgSWYgb24gdGhlIG90aGVyIGhhbmQg KGkpIGlzIG5vdCBleHRyZW1lbHkgbG93LCB0aGVuIGNoZWNraW5nDSAgIHByZS1zZXJ2aWNlIGFu ZCBpbi1zZXJ2aWNlIHVuaXF1ZW5lc3Mgb2YgYWRkcmVzc2VzIG9yIHByZWZpeGVzIG1heSBiZQ0g ICByZXF1aXJlZC4gIEluIGFueSBjYXNlLCBpZiB0aGUgYXBwbGljYXRpb24gBWhhcyBhIGhhcmQg cmVxdWlyZW1lbnQgZm9yDSAgIGFkZHJlc3MgdW5pcXVlbmVzcyBhc3N1cmFuY2UsIGluLXNlcnZp Y2UgdW5pcXVlbmVzcyBjaGVja3Mgb2YNICAgYWRkcmVzc2VzIGFuZCBwcmVmaXhlcyBzaG91bGQg YWx3YXlzIGJlIHVzZWQsIG5vIG1hdHRlciBob3cgdW5saWtlbHkNICAgaXMgdGhlIGV2ZW50IG9m IGFkZHJlc3MgY29uZmxpY3QuDQ0NDQ0NQmFjY2VsbGkgKEVkLiksIGV0IGFsLiAgICBFeHBpcmVz IE1heSAyMiwgMjAwOCAgICAgICAgICAgICAgICAgW1BhZ2UgMTBdDQwNSW50ZXJuZXQtRHJhZnQg ICAgICBNQU5FVCBBdXRvY29uZiBQcm9ibGVtIFN0YXRlbWVudCAgICAgICBOb3ZlbWJlciAyMDA3 DQ0NNC4yLjMuICBJbnRlcm5ldCBDb25maWd1cmF0aW9uIFByb3ZpZGVyIFJlbGF0ZWQgSXNzdWVz DQ0gICBBbm90aGVyIGNhdGVnb3J5IG9mIHByb2JsZW1zIGNvbmNlcm4gdGhlIG1hbmFnZW1lbnQg b2YgSW50ZXJuZXQNICAgY29uZmlndXJhdGlvbiBwcm92aWRlcnMgKElDUHMpLg0NICAgSW4gdGhl IGNhc2Ugd2hlcmUgbXVsdGlwbGUgSUNQcyBhcmUgYXZhaWxhYmxlIGluIHRoZSBNQU5FVCwgcHJv dmlkaW5nDSAgIGFjY2VzcyB0byBtdWx0aXBsZSBhZGRyZXNzIGNvbmZpZ3VyYXRpb24gc2VydmVy cywgc3BlY2lmaWMgcHJvYmxlbXMNICAgYXJpc2UFLiAgT25lIHByb2JsZW0gaXMgdGhlIHdheSBp biB3aGljaCBnbG9iYWwgcHJlZml4ZXMgYXJlIG1hbmFnZWQNICAgd2l0aGluIHRoZSBNQU5FVC4g IElmIG9uZSBwcmVmaXggaXMgdXNlZCBmb3IgdGhlIHdob2xlIE1BTkVULA0gICBwYXJ0aXRpb25p bmcgb2YgdGhlIE1BTkVUIG1heSByZXN1bHQgaW4gaW52YWxpZCByb3V0ZXMgdG93YXJkcyBNQU5F VA0gICByb3V0ZXJzLCBvdmVyIHRoZSBJbnRlcm5ldC4gIE9uIHRoZSBvdGhlciBoYW5kLCB0aGUg dXNlIG9mIG11bHRpcGxlDSAgIG5ldHdvcmsgcHJlZml4ZXMgZ3VhcmFudGVlcyB0cmFmZmljIGlz IHVuYW1iaWd1b3VzbHkgcm91dGVkIGZyb20gdGhlDSAgIGhvc3RzL3JvdXRlcnMgaW4gdGhlIElu dGVybmV0IHRvd2FyZHMgdGhlIGJvcmRlciByb3V0ZXIgcmVzcG9uc2libGUNICAgZm9yIG9uZSBw YXJ0aWN1bGFyIHByZWZpeC4gIEhvd2V2ZXIsIGFzeW1tZXRyeSBpbiB0aGUgcm91dGVycycgY2hv aWNlDSAgIG9mIGluZ3Jlc3MvZWdyZXNzIGJvcmRlciByb3V0ZXIgY2FuIGxlYWQgdG8gbm9uLW9w dGltYWwgcGF0aHMNICAgZm9sbG93ZWQgYnkgaW5ib3VuZC9vdXRib3VuZCBkYXRhIHRyYWZmaWMs IG9yIHRvIGJyb2tlbiBjb25uZWN0aXZpdHksDSAgIGlmIGVncmVzcyBmaWx0ZXJpbmcgaXMgYmVp bmcgZG9uZS4NDSAgIFdoZW4gYSByb3V0ZXIgY2hhbmdlcyBpdHMgSUNQIGFmZmlsaWF0aW9uBSwg c29tZSByb3V0ZXMgbWF5IGJlIGJyb2tlbiwNICAgYWZmZWN0aW5nIE1BTkVUIHBhY2tldCBmb3J3 YXJkaW5nIHBlcmZvcm1hbmNlIGFuZCBhcHBsaWNhdGlvbnMuICBJbiBhDSAgIG11bHRpcGxlIGJv cmRlciByb3V0ZXIgLyBtdWx0aXBsZS1wcmVmaXhlcyBNQU5FVCwgZnJlcXVlbnQNICAgcmVjb25m aWd1cmF0aW9uBSBjb3VsZCBjYXVzZSBhIGxhcmdlIGFtb3VudCBvZiBjb250cm9sIHNpZ25hbGxp bmcgKGZvcg0gICBpbnN0YW5jZSBpZiBbNV0gaXMgdXNlZCkuDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0N DQ0NDQ0NDQ1CYWNjZWxsaSAoRWQuKSwgZXQgYWwuICAgIEV4cGlyZXMgTWF5IDIyLCAyMDA4ICAg ICAgICAgICAgICAgICBbUGFnZSAxMV0NDA1JbnRlcm5ldC1EcmFmdCAgICAgIE1BTkVUIEF1dG9j b25mIFByb2JsZW0gU3RhdGVtZW50ICAgICAgIE5vdmVtYmVyIDIwMDcNDQ01LiAgU29sdXRpb25z IENvbnNpZGVyYXRpb25zDQ0gICBTb2x1dGlvbnMgbXVzdCBhY2hpZXZlIHRoZWlyIHRhc2sgd2l0 aCAoaSkgbG93IG92ZXJoZWFkLCBkdWUgdG8NICAgc2NhcmNzZSBiYW5kd2lkdGgsIGFuZCAoaWkp IGxvdyBkZWxheS9jb252ZXJnZW5jZSB0aW1lLCBkdWUgdG8gdGhlDSAgIGR5bmFtaWNpdHkgb2Yg dGhlIHRvcG9sb2d5LiAgVGhlIGV2YWx1YXRpb24gb2Ygc3VjaCBjcml0ZXJpYSBtYXkNICAgZGVw ZW5kIG9uIHRoZSB0YXJnZXRlZCBuZXR3b3JrIHByb3BlcnRpZXMsIHdoaWNoIGluY2x1ZGUgKGJ1 dCBhcmUgbm90DSAgIGxpbWl0ZWQgdG8pIG5vZGUgY2FyZGluYWxpdHksIG5vZGUgbW9iaWxpdHkg Y2hhcmFjdGVyaXN0aWNzLCBldGMuDQ0gICBTb2x1dGlvbnMgYXJlIHRvIGJlIGRlc2lnbmVkIHRv bXVzdCB3b3JrIGF0IHRoZSBuZXR3b3JrIGxheWVyIGFuZCB0aHVzdG8gdG8NICAgYXBwbHkgdG8g YWxsIGxpbmsgdHlwZXMuICBIb3dldmVyLCBpbiBzaXR1YXRpb25zIHdoZXJlIGxpbmstbGF5ZXIN ICAgbXVsdGljYXN0IGlzIG5lZWRlZCBpdCBpcyBwb3NzaWJsZSB0aGF0IG9uIHNvbWUgbGluayB0 eXBlcyAoZS5nLiwNICAgTkJNQSBsaW5rcyksIGFsdGVybmF0aXZlIG1lY2hhbmlzbXMgb3IgcHJv dG9jb2xzIHNwZWNpZnlpbmcgb3BlcmF0aW9uDSAgIG92ZXIgYSBwYXJ0aWN1bGFyIGxpbmsgdHlw ZSB3b3VsZCBiZSByZXF1aXJlZC4NDSAgIFNvbHV0aW9ucyBtdXN0IGludGVyYWN0IHdpdGggZXhp c3RpbmcgcHJvdG9jb2xzIGluIGEgd2F5IHRoYXQNICAgbGV2ZXJhZ2VzIGFzIG11Y2ggYXMgcG9z c2libGUgYXBwcm9wcmlhdGUgbWVjaGFuaXNtcyB0aGF0IGFyZQ0gICBkZXBsb3llZC4gIEZvciBp bnN0YW5jZSwgYmVzaWRlcyB0aGUgcG9zc2libGUgdXNlIG9mIHRoZSB3ZWxsLWtub3duDSAgIElQ djYgbXVsdGljYXN0IGFkZHJlc3NlcyBkZWZpbmVkIGZvciBuZWlnaGJvciBkaXNjb3ZlcnkgaW4g WzNdIChlLmcuLA0gICBmb3IgRHVwbGljYXRlIEFkZHJlc3MgRGV0ZWN0aW9uKSwgc29sdXRpb25z IG1heSBhcyB3ZWxsIHVzZSBzb21lDSAgIGFkZHJlc3NlcyBkZWZpbmVkIGluIFsxMF0gZm9yIGF1 dG8tY29uZmlndXJhdGlvbiBwdXJwb3Nlcy4gIEhvd2V2ZXIsDSAgIGl0IG11c3QgYmUgZW5zdXJl ZCB0aGF0IG5vIG1vZGlmaWNhdGlvbiBvZiBleGlzdGluZyBwcm90b2NvbHMgaXMgdG8NICAgYmUg cmVxdWlyZWQgb3V0c2lkZSBvZiBNQU5FVCBzY29wZQUuDQ0gICBTb2x1dGlvbnMgbXVzdCBhbHNv IHRha2UgaW50byBhY2NvdW50IHRoZSBzZWN1cml0eSBhbmQgdHJ1c3QgaXNzdWVzDSAgIHRoYXQg YXJlIHNwZWNpZmljIHRvIGFkIGhvYyBuZXR3b3JraW5nIAUoc2VlIFNlY3Rpb24gNikuDQ0NDQ0N DQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NQmFjY2VsbGkgKEVkLiksIGV0IGFsLiAgICBFeHBpcmVzIE1h eSAyMiwgMjAwOCAgICAgICAgICAgICAgICAgW1BhZ2UgMTJdDQwNSW50ZXJuZXQtRHJhZnQgICAg ICBNQU5FVCBBdXRvY29uZiBQcm9ibGVtIFN0YXRlbWVudCAgICAgICBOb3ZlbWJlciAyMDA3DQ0N Ni4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQ0gICBBZGRyZXNzIGNvbmZpZ3VyYXRpb24gaW4g TUFORVRzIGNvdWxkIGJlIHByb25lIHRvIHNlY3VyaXR5IGF0dGFja3MsIGFzDSAgIGluIG90aGVy IHR5cGVzIG9mIElQdjYgbmV0d29ya3MuICBTZWN1cml0eSB0aHJlYXRzIHRvIElQdjYgbmVpZ2hi b3INICAgZGlzY292ZXJ5IHdlcmUgZGlzY3Vzc2VkIGluIHRoZSBTRU5EIFdHIGFuZCBkZXNjcmli ZWQgaW4gWzZdOiB0aHJlZQ0gICBkaWZmZXJlbnQgdHJ1c3QgbW9kZWxzIGFyZSBzcGVjaWZpZWQs IHdpdGggdmFyeWluZyBsZXZlbHMgb2YgdHJ1c3QNICAgYW1vbmcgbmV0d29yayBub2RlcyBhbmQg cm91dGVycy4gIEFtb25nIHRoZW0sIHRoZSBtb2RlbCBieSB3aGljaCBubw0gICB0cnVzdCBleGlz dHMgYW1vbmcgbm9kZXMgbWF5IGJlIHN1aXRhYmxlIGEgcHJpb3JpIGZvciBtb3N0IGFkIGhvYw0g ICBuZXR3b3JrcwUuICBIb3dldmVyLCB0aGUgb3RoZXIgdHdvIG1vZGVscyBtYXkgYmUgYXBwbGlj YWJsZSBpbiBzb21lDSAgIGNhc2VzLCBmb3IgZXhhbXBsZSB3aGVuIGEgdHJ1c3QgcmVsYXRpb25z aGlwIGV4aXN0cyBiZXR3ZWVuIGFuDSAgIG9wZXJhdG9yIGFuZCBzb21lIE1BTkVUIHJvdXRlcnMs IG9yIGJldHdlZW4gbWlsaXRhcnkgZGV2aWNlcyB0aGF0IGFyZQ0gICBpbiB0aGUgc2FtZSB1bml0 LiAgQWx0aG91Z2ggWzZdIGRvZXMgbm90IGV4cGxpY2l0bHkgYWRkcmVzcyBNQU5FVHMsDSAgIHRo ZSB0cnVzdCBtb2RlbHMgaXQgcHJvdmlkZXMgZm9yIGFkIGhvYyBuZXR3b3JrcyBjYW4gYmUgdmFs aWQgYWxzbyBpbg0gICB0aGUgY29udGV4dCBvZiBNQU5FVCBhdXRvY29uZmlndXJhdGlvbi4NDSAg IEl0IGlzIHdvcnRoIG5vdGluZyB0aGF0IGFuYWx5c2lzIG9mIFs2XSBpcyBzdHJpY3RseSByZWxh dGVkIHRvDSAgIE5laWdoYm9yIERpc2NvdmVyeSwgTmVpZ2hib3IgVW5yZWFjaGFiaWxpdHkgRGV0 ZWN0aW9uIGFuZCBEdXBsaWNhdGUNICAgQWRkcmVzcyBEZXRlY3Rpb24gcHJvY2VkdXJlcywgYXMg ZGVmaW5lZCBpbiBbM10gYW5kIFs1XS4gIEFzDSAgIGV4cGxhaW5lZCBpbiB0aGUgcHJlc2VudCBk b2N1bWVudCwgY3VycmVudCBzdGFuZGFyZCBwcm9jZWR1cmVzIGNhbm5vdA0gICBiZSB1c2VkIGFz LWlzIGluIE1BTkVUIGNvbnRleHQgdG8gYWNoaWV2ZSBhdXRvY29uZmlndXJhdGlvbiBvZiBNQU5F VA0gICByb3V0ZXJzBSBhbmQsIHRoZXJlZm9yZSwgZGVzaWduIG9mIG5ldyBtZWNoYW5pc21zIGNh biBiZSBmb3Jlc2Vlbi4NDSAgIEluIHRoaXMgY2FzZSwgYWx0aG91Z2ggc2VjdXJpdHkgdGhyZWF0 cyBhbmQgYXR0YWNrcyBkZWZpbmVkIGluIFs2XQ0gICBjb3VsZCBhbHNvIGFwcGx5IGluIHByZXNl bmNlIG9mIG5ldyBzb2x1dGlvbnMsIGFkZGl0aW9uYWwgdGhyZWF0cyBhbmQNICAgYXR0YWNrcyBj b3VsZCBiZSBwb3NzaWJsZSAoZS5nLiwgbm9uLWNvb3BlcmF0aW9uIGluIG1lc3NhZ2UNICAgZm9y d2FyZGluZyBpbiBtdWx0aS1ob3AgY29tbXVuaWNhdGlvbnMpLiAgVGhlcmVmb3JlLCB0aGUgc2Vj dXJpdHkNICAgYW5hbHlzaXMgaGFzIHRvIGJlIGZ1cnRoZXIgZXh0ZW5kZWQgdG8gaW5jbHVkZSB0 aHJlYXRzLCBzcGVjaWZpYyB0bw0gICBtdWx0aS1ob3AgbmV0d29ya3MgYW5kIHJlbGF0ZWQgdG8g dGhlIHBhcnRpY3VsYXIgYWRkcmVzcw0gICBjb25maWd1cmF0aW9uIHNvbHV0aW9uLg0NICAgR2Vu ZXJhbCBzZWN1cml0eSBpc3N1ZXMgb2YgYWQgaG9jIHJvdXRpbmcgcHJvdG9jb2xzJyBvcGVyYXRp b25zIGFyZQ0gICBub3QgaW4gdGhlIHNjb3BlIG9mIE1BTkVUIGF1dG9jb25maWd1cmF0aW9uLg0N DQ0NDQ0NDQ0NDQ0NDQ0NDQ0NQmFjY2VsbGkgKEVkLiksIGV0IGFsLiAgICBFeHBpcmVzIE1heSAy MiwgMjAwOCAgICAgICAgICAgICAgICAgW1BhZ2UgMTNdDQwNSW50ZXJuZXQtRHJhZnQgICAgICBN QU5FVCBBdXRvY29uZiBQcm9ibGVtIFN0YXRlbWVudCAgICAgICBOb3ZlbWJlciAyMDA3DQ0NNy4g IElBTkEgQ29uc2lkZXJhdGlvbnMNDSAgIFRoaXMgZG9jdW1lbnQgZG9lcyBjdXJyZW50bHkgbm90 IHNwZWNpZnkgSUFOQSBjb25zaWRlcmF0aW9ucy4NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0N DQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NQmFjY2VsbGkgKEVkLiksIGV0IGFsLiAgICBFeHBpcmVzIE1h eSAyMiwgMjAwOCAgICAgICAgICAgICAgICAgW1BhZ2UgMTRdDQwNSW50ZXJuZXQtRHJhZnQgICAg ICBNQU5FVCBBdXRvY29uZiBQcm9ibGVtIFN0YXRlbWVudCAgICAgICBOb3ZlbWJlciAyMDA3DQ0N OC4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMNDSAgIFsxXSAgIE1hY2tlciwgSi4gYW5kIFMuIENv cnNvbiwgIk1BTkVUIFJvdXRpbmcgUHJvdG9jb2wgUGVyZm9ybWFuY2UNICAgICAgICAgSXNzdWVz IGFuZCBFdmFsdWF0aW9uIENvbnNpZGVyYXRpb25zIiwgUkZDIDI1MDEsIEphbnVhcnkgMTk5OS4N DSAgIFsyXSAgIE1hY2tlciwgSi4sIENoYWtlcmVzLCBJLiwgYW5kIFQuIENsYXVzZW4sICJNb2Jp bGUgQWQgaG9jDSAgICAgICAgIE5ldHdvcmsgQXJjaGl0ZWN0dXJlIiwgSUQgZHJhZnQtaWV0Zi1h dXRvY29uZi1tYW5ldGFyY2gsDSAgICAgICAgIEZlYnJ1YXJ5IDIwMDcuDQ0gICBbM10gICBOYXJ0 ZW4sIFQuLCBOb3JkbWFyaywgRS4sIFNpbXBzb24sIFcuLCBhbmQgSC4gU29saW1hbiwNICAgICAg ICAgIk5laWdoYm9yIERpc2NvdmVyeSBmb3IgSVB2NiIsIFJGQyA0ODYxLCBTZXB0ZW1iZXIgMjAw Ny4NDSAgIFs0XSAgIERyb21zLCBSLiwgQm91bmQsIEouLCBWb2x6LCBCLiwgTGVtb24sIFQuLCBQ ZXJraW5zLCBDLiwgYW5kIE0uDSAgICAgICAgIENhcm5leSwgIkR5bmFtaWMgSG9zdCBDb25maWd1 cmF0aW9uIFByb3RvY29sIGZvciBJUHY2IiwNICAgICAgICAgUkZDIDMzMTUsIEp1bHkgMjAwMy4N DSAgIFs1XSAgIE5hcnRlbiwgVC4sIFRob21zb24sIFMuLCBhbmQgVC4gSmlubWVpLCAiSVB2NiBT dGF0ZWxlc3MgQWRkcmVzcw0gICAgICAgICBBdXRvY29uZmlndXJhdGlvbiIsIFJGQyA0ODYyLCBT ZXB0ZW1iZXIgMjAwNy4NDSAgIFs2XSAgIE5pa2FuZGVyLCBQLiwgS2VtcGYsIEouLCBhbmQgRS4g Tm9yZG1hcmssICJJUHY2IE5laWdoYm9yDSAgICAgICAgIERpc2NvdmVyeSAoTkQpIFRydXN0IE1v ZGVscyBhbmQgVGhyZWF0cyIsIFJGQyAzNzU2LCBNYXkgMjAwNC4NDSAgIFs3XSAgIERyYXZlcywg Ui4gYW5kIEQuIFRoYWxlciwgIkRlZmF1bHQgUm91dGVyIFByZWZlcmVuY2VzIGFuZCBNb3JlLQ0g ICAgICAgICBTcGVjaWZpYyBSb3V0ZXMiLCBSRkMgNDE5MSwgMjAwNS4NDSAgIFs4XSAgIE1veSwg Si4sICJPU1BGIHZlcnNpb24gMiIsIFJGQyAyMzI4LCAxOTk4Lg0NICAgWzldICAgTW95LCBKLiwg Q29sdHVuLCBSLiwgYW5kIEQuIEZlcmd1c29uLCAiT1NQRiBmb3IgSVB2NiIsDSAgICAgICAgIFJG QyAyNzQwLCAxOTk5Lg0NICAgWzEwXSAgQ2hha2VyZXMsIEkuLCAiSW50ZXJuZXQgQXNzaWduZWQg TnVtYmVycyBBdXRob3JpdHkgKElBTkEpDSAgICAgICAgIEFsbG9jYXRpb25zIGZvciB0aGUgIE1v YmlsZSBBZCBob2MgTmV0d29ya3MgKE1BTkVUKSBXb3JraW5nDSAgICAgICAgIEdyb3VwIiwgSUQg ZHJhZnQtaWV0Zi1tYW5ldC1pYW5hLCBNYXkgMjAwNy4NDSAgIFsxMV0gIFBhdHJpY2ssIE0uLCAi REhDUCBSZWxheSBBZ2VudCBJbmZvcm1hdGlvbiBPcHRpb24iLCBSRkMgMzA0NiwNICAgICAgICAg MjAwMS4NDSAgIFsxMl0gIE5hcnRlbiwgVC4gYW5kIFIuIERyYXZlcywgIlByaXZhY3kgRXh0ZW5z aW9ucyBmb3IgU3RhdGVsZXNzDSAgICAgICAgIEFkZHJlc3MgQXV0b2NvbmZpZ3VyYXRpb24gaW4g SVB2NiIsIFJGQyAzMDQxLCAyMDAxLg0NICAgWzEzXSAgQXJra28sIEouLCBLZW1wZiwgSi4sIFpp bGwsIEIuLCBhbmQgUC4gTmlrYW5kZXIsICJTRWN1cmUNICAgICAgICAgTmVpZ2hib3IgRGlzY292 ZXJ5IChTRU5EKSIsIFJGQyAzOTcxLCAyMDA1Lg0NICAgWzE0XSAgQXVyYSwgVC4sICJDcnlwdG9n cmFwaGljYWxseSBHZW5lcmF0ZWQgQWRkcmVzc2VzIChDR0EpIiwNICAgICAgICAgUkZDIDM5NzIs IDIwMDUuDQ0gICBbMTVdICBNb29yZSwgTi4sICJPcHRpbWlzdGljIER1cGxpY2F0ZSBBZGRyZXNz IERldGVjdGlvbiAoREFEKSBmb3INICAgICAgICAgSVB2NiIsIFJGQyA0NDI5LCAyMDA2Lg0NDQ1C YWNjZWxsaSAoRWQuKSwgZXQgYWwuICAgIEV4cGlyZXMgTWF5IDIyLCAyMDA4ICAgICAgICAgICAg ICAgICBbUGFnZSAxNV0NDA1JbnRlcm5ldC1EcmFmdCAgICAgIE1BTkVUIEF1dG9jb25mIFByb2Js ZW0gU3RhdGVtZW50ICAgICAgIE5vdmVtYmVyIDIwMDcNDQ0gICBbMTZdICBIaW5kZW4sIFIuIGFu ZCBCLiBIYWJlcm1hbiwgIlVuaXF1ZSBMb2NhbCBJUHY2IFVuaWNhc3QNICAgICAgICAgQWRkcmVz c2VzIiwgUkZDIDQxOTMsIDIwMDUuDQ0gICBbMTddICBUaHViZXJ0LCBQLiBhbmQgVEouIEtuaXZl dG9uLCAiTW9iaWxlIE5ldHdvcmsgUHJlZml4DSAgICAgICAgIERlbGVnYXRpb24iLCBJRCBkcmFm dC1pZXRmLW5lbW8tcHJlZml4LWRlbGVnYXRpb24sIEF1Z3VzdCAyMDA3Lg0NICAgWzE4XSAgVHJv YW4sIE8uIGFuZCBSLiBEcm9tcywgIklQdjYgUHJlZml4IE9wdGlvbnMgZm9yIERIQ1B2NiIsDSAg ICAgICAgIFJGQyAzNjMzLCAyMDAzLg0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0N DQ0NDQ0NDQ0NQmFjY2VsbGkgKEVkLiksIGV0IGFsLiAgICBFeHBpcmVzIE1heSAyMiwgMjAwOCAg ICAgICAgICAgICAgICAgW1BhZ2UgMTZdDQwNSW50ZXJuZXQtRHJhZnQgICAgICBNQU5FVCBBdXRv Y29uZiBQcm9ibGVtIFN0YXRlbWVudCAgICAgICBOb3ZlbWJlciAyMDA3DQ0NQ29udHJpYnV0b3Jz DQ0gICBUaGlzIGRvY3VtZW50IGlzIHRoZSByZXN1bHQgb2Ygam9pbnQgZWZmb3J0cywgaW5jbHVk aW5nIHRob3NlIG9mIHRoZQ0gICBmb2xsb3dpbmcgY29udHJpYnV0ZXJzLCBsaXN0ZWQgaW4gYWxw aGFiZXRpY2FsIG9yZGVyOiBDLiBBZGppaCwgQy4NICAgQmVybmFyZG9zLCBULiBCb290LCBULiBD bGF1c2VuLCBDLiBEZWFybG92ZSwgSC4gTW91c3RhZmEsIEMuIFBlcmtpbnMsDSAgIEEuIFBldHJl c2N1LCBQLiBSdWl6LCBQLiBTdHVwYXIsIEYuIFRlbXBsaW4sIEQuIFRoYWxlciwgSy4gV2VuaWdl ci4NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NQmFjY2VsbGkg KEVkLiksIGV0IGFsLiAgICBFeHBpcmVzIE1heSAyMiwgMjAwOCAgICAgICAgICAgICAgICAgW1Bh Z2UgMTddDQwNSW50ZXJuZXQtRHJhZnQgICAgICBNQU5FVCBBdXRvY29uZiBQcm9ibGVtIFN0YXRl bWVudCAgICAgICBOb3ZlbWJlciAyMDA3DQ0NQXV0aG9ycycgQWRkcmVzc2VzDQ0gICBFbW1hbnVl bCBCYWNjZWxsaQ0gICBJTlJJQQ0NICAgUGhvbmU6ICszMyAxIDY5IDMzIDU1IDExDSAgIEVtYWls OiBFbW1hbnVlbC5CYWNjZWxsaUBpbnJpYS5mcg0NDSAgIEtlbmljaGkgTWFzZQ0gICBOaWlnYXRh IFVuaXZlcnNpdHkNDSAgIFBob25lOiArODEgMjUgMjYyIDc0NDYNICAgRW1haWw6IE1hc2VAaWUu bmlpZ2F0YS11LmFjLmpwDQ0NICAgU2ltb25lIFJ1ZmZpbm8NICAgVGVsZWNvbSBJdGFsaWENDSAg IFBob25lOiArMzkgMDExIDIyOCA3NTY2DSAgIEVtYWlsOiBTaW1vbmUuUnVmZmlub0B0ZWxlY29t aXRhbGlhLml0DQ0NICAgU2h1YmhyYW5zaHUgU2luZ2gNICAgU2Ftc3VuZw0NICAgUGhvbmU6ICs4 MiAzMSAyODAgOTU2OQ0gICBFbWFpbDogU2h1YnJhbnNodUBnbWFpbC5jb20NDQ0NDQ0NDQ0NDQ0N DQ0NDQ0NDQ0NDQ1CYWNjZWxsaSAoRWQuKSwgZXQgYWwuICAgIEV4cGlyZXMgTWF5IDIyLCAyMDA4 ICAgICAgICAgICAgICAgICBbUGFnZSAxOF0NDA1JbnRlcm5ldC1EcmFmdCAgICAgIE1BTkVUIEF1 dG9jb25mIFByb2JsZW0gU3RhdGVtZW50ICAgICAgIE5vdmVtYmVyIDIwMDcNDQ1GdWxsIENvcHly aWdodCBTdGF0ZW1lbnQNDSAgIENvcHlyaWdodCAoQykgVGhlIElFVEYgVHJ1c3QgKDIwMDcpLg0N ICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIHRoZSByaWdodHMsIGxpY2Vuc2VzIGFuZCBy ZXN0cmljdGlvbnMNICAgY29udGFpbmVkIGluIEJDUCA3OCwgYW5kIGV4Y2VwdCBhcyBzZXQgZm9y dGggdGhlcmVpbiwgdGhlIGF1dGhvcnMNICAgcmV0YWluIGFsbCB0aGVpciByaWdodHMuDQ0gICBU aGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBhcmUgcHJv dmlkZWQgb24gYW4NICAgIkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLCBUSEUgT1JH QU5JWkFUSU9OIEhFL1NIRSBSRVBSRVNFTlRTDSAgIE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5Z KSwgVEhFIElOVEVSTkVUIFNPQ0lFVFksIFRIRSBJRVRGIFRSVVNUIEFORA0gICBUSEUgSU5URVJO RVQgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJTSBBTEwgV0FSUkFOVElFUywgRVhQUkVT Uw0gICBPUiBJTVBMSUVELCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5U WSBUSEFUIFRIRSBVU0UgT0YNICAgVEhFIElORk9STUFUSU9OIEhFUkVJTiBXSUxMIE5PVCBJTkZS SU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVEDSAgIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRB QklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLg0NDUludGVsbGVjdHVh bCBQcm9wZXJ0eQ0NICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2 YWxpZGl0eSBvciBzY29wZSBvZiBhbnkNICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBv ciBvdGhlciByaWdodHMgdGhhdCBtaWdodCBiZSBjbGFpbWVkIHRvDSAgIHBlcnRhaW4gdG8gdGhl IGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4NICAg dGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNlbnNlIHVuZGVyIHN1 Y2ggcmlnaHRzDSAgIG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7IG5vciBkb2VzIGl0 IHJlcHJlc2VudCB0aGF0IGl0IGhhcw0gICBtYWRlIGFueSBpbmRlcGVuZGVudCBlZmZvcnQgdG8g aWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiAgSW5mb3JtYXRpb24NICAgb24gdGhlIHByb2NlZHVy ZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBSRkMgZG9jdW1lbnRzIGNhbiBiZQ0gICBmb3Vu ZCBpbiBCQ1AgNzggYW5kIEJDUCA3OS4NDSAgIENvcGllcyBvZiBJUFIgZGlzY2xvc3VyZXMgbWFk ZSB0byB0aGUgSUVURiBTZWNyZXRhcmlhdCBhbmQgYW55DSAgIGFzc3VyYW5jZXMgb2YgbGljZW5z ZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2YgYW4NICAgYXR0ZW1wdCBt YWRlIHRvIG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNl IG9mDSAgIHN1Y2ggcHJvcHJpZXRhcnkgcmlnaHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBv ZiB0aGlzDSAgIHNwZWNpZmljYXRpb24gY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24t bGluZSBJUFIgcmVwb3NpdG9yeSBhdA0gICBodHRwOi8vd3d3LmlldGYub3JnL2lwci4NDSAgIFRo ZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVu dGlvbiBhbnkNICAgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBv ciBvdGhlciBwcm9wcmlldGFyeQ0gICByaWdodHMgdGhhdCBtYXkgY292ZXIgdGVjaG5vbG9neSB0 aGF0IG1heSBiZSByZXF1aXJlZCB0byBpbXBsZW1lbnQNICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFz ZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBhdA0gICBpZXRmLWlwckBpZXRm Lm9yZy4NDQ1BY2tub3dsZWRnbWVudA0NICAgRnVuZGluZyBmb3IgdGhlIFJGQyBFZGl0b3IgZnVu Y3Rpb24gaXMgcHJvdmlkZWQgYnkgdGhlIElFVEYNICAgQWRtaW5pc3RyYXRpdmUgU3VwcG9ydCBB Y3Rpdml0eSAoSUFTQSkuDQ0NDQ0NQmFjY2VsbGkgKEVkLiksIGV0IGFsLiAgICBFeHBpcmVzIE1h eSAyMiwgMjAwOCAgICAgICAgICAgICAgICAgW1BhZ2UgMTldDQwNBVRoaXMgc3RhdGVtZW50IGlz bpJ0IHN1cHBvcnRlZCBieSB0aGUgdGV4dCBpbiB0aGUgZG9jdW1lbnQuDQVXaGF0IGFib3V0IElQ djQ/DQVbM10gaXMgbm90IGFuIGFkZHJlc3MgYXNzaWdubWVudCBvciBwcmVmaXggZGVsZWdhdGlv biBzb2x1dGlvbi4NBVRoaXMgY29uY2x1c2lvbiBpcyBub3Qgc3VmZmljaWVudGx5IG1vdGl2YXRl ZC4gIFRoaXMgZG9jdW1lbnQgaXMgdGhlIJNQcm9ibGVtIFN0YXRlbWVudJQgZG9jdW1lbnQsIGFu ZCBzaG91bGQgcHJvdmlkZSBhIGNvbXBlbGxpbmcgY2FzZSBmb3IgdGhpcyBzdGF0ZW1lbnQsIG5v dCB0YWtlIGl0IGFzIGEgZ2l2ZW4uICBQZXJzb25hbGx5LCBJIGRvbpJ0IGJlbGlldmUgdGhpcyBj b25jbHVzaW9uLg0FSXQgaXMgYSBiaXQgdW5jbGVhciBoZXJlIHdoYXQgdGhlIHJlbGF0aW9uc2hp cCBiZXR3ZWVuIHRoaXMgZG9jdW1lbnQgYW5kIFsyXSBpcy4gIElzIHRoaXMgZG9jdW1lbnQgYSBz dGF0ZW1lbnQgb2YgdGhlIHByb2JsZW0gd2l0aCBbMl0sIG9yIGlzIFsyXSBhbiBhcmNoaXRlY3R1 cmUgdG8gc29sdmUgdGhlIHByb2JsZW0gc3RhdGVkIGluIHRoaXMgZG9jdW1lbnQ/ICBJIHRoaW5r IGl0knMgdGhlIGZvcm1lci4NBUFnYWluLCB0aGlzIGNvbmNsdXNpb24gaXMgbm90IHN1cHBvcnRl ZCBieSB0aGUgZXZpZGVuY2UgcHJlc2VudGVkLiAgV2hlcmUgaXMgdGhlIGFuYWx5c2lzPyAgU3Vj aCBhbiBhbmFseXNpcyBzaG91bGQgYmUgYSBzaWduaWZpY2FudCBwb3J0aW9uIG9mIHRoaXMgZG9j dW1lbnQsIGFzIGl0knMgdGhlIG1vc3QgaW1wb3J0YW50IHBvaW50IHRvIGdldCBjb25zZW5zdXMg b24uDQVJIGRvbpJ0IHVuZGVyc3RhbmQgdGhpcyBkZWZpbml0aW9uLiAgSWYgaXSScyBfZGVsZWdh dGVkXyB0byB0aGUgcm91dGVyLCB0aGVuIGl0knMgdmFsaWQgZm9yIHVzZSBvdXRzaWRlIHRoZSBN QU5FVCAoaS5lLiBvbiBhbiBleHRlcm5hbCBsZWFmIG5ldHdvcmspLCBub3QgaW5zaWRlIChleGNl cHQgdGhhdCB0aGUgTUFORVQgbWF5IHRyYW5zaXQgdHJhZmZpYyB0aHJvdWdoIGl0KS4NBVdoeSBk b2VzIGl0IGhhdmUgdG8gYmUgYSByb3V0ZXI/ICAgVGhpcyBzZWVtcyBvdmVybHkgcmVzdHJpY3Rp dmUgaW4gYSBkZWZpbml0aW9uLiAgU2VjdGlvbiA0LjIuMyBjYWxscyB0aGVtIHNlcnZlcnMuDQVJ dCBjYW6SdCBiZSBhbiBhcmJpdHJhcnkgc2V0IG9mIGNvbnRpZ3VvdXMgYWRkcmVzc2VzLCBpdCBo YXMgdG8gYmUgYSBwcmVmaXggZm9yIGl0IHRvIGJlIGNhbGxlZCCTcHJlZml4lCBkZWxlZ2F0aW9u Lg0FV2h5IGRvZXMgaXQgaGF2ZSB0byBiZSBhIHJvdXRlcj8gIFNlY3Rpb24gNC4yLjMgY2FsbHMg dGhlbSBzZXJ2ZXJzLg0FSSBkb26SdCB0aGluayBpdJJzIGV2ZXIgk2d1YXJhbnRlZWSULCBqdXN0 IGxpa2VseSBlbm91Z2ggdG8gYmUgdXNlZC4NBVdoYXQgYWJvdXQgSVB2ND8NBVRoaXMgaXMgbm90 IGFuIGFkZHJlc3MgYXNzaWdubWVudCBwcm90b2NvbCBhbmQgZG9lc26SdCBiZWxvbmcgaGVyZS4N BU5lZWQgbW9yZSBkZXRhaWxzIHRvIGp1c3RpZnkgdGhpcy4NBU5laXRoZXIgWzVdIG5vciBbNF0g YXNzdW1lIHRoaXMuICBPbmx5IERBRCBhc3N1bWVzIHRoaXMsIGJ1dCBwcmUtc2VydmljZSBEQUQg Y2FuIG5ldmVyIGJlIHBlcmZlY3QgKG9uY2UgaW4tc2VydmljZSkgYW55d2F5IGR1ZSB0byBtZXJn aW5nLiAgSGVuY2UgdGhpcyBkb2VzIG5vdCBqdXN0aWZ5IHdoeSBTTEFBQyBhbmQgREhDUHY2IHdv dWxkIG5vdCB3b3JrLg0FVGhpcyBzaW1wbHkgYXJndWVzIHRoYXQgdGhlIE1BTkVUIEJSIHNob3Vs ZCBiZSBhIERIQ1AgU2VydmVyIG9yIGEgREhDUCBSZWxheS4gIE5vdGhpbmcgbmV3IHRoZXJlLg0F Tm8gaXQgZG9lc26SdC4gIFlvdSBzdGlsbCBnZXQgYSB1bmlxdWUgcHJlZml4LCBhbmQgeW91IHVz ZSBhIHJvdXRpbmcgcHJvdG9jb2wgdG8gYWxsb3cgdGhlIG5ldHdvcmsgdG8ga25vdyB0aGUgbG9j YXRpb24uICBUaGF0IGRvZXNuknQgaW52YWxpZGF0ZSBhbnl0aGluZy4NBVRoZSBNQU5FVCBCUiBp cyB0aGUgbmF0dXJhbCBlbnRpdHkgdGhhdCBkZWxlZ2F0ZXMgdGhlIHByZWZpeCAob3IgdGhlIElT UCBFZGdlIFJvdXRlciwgaWYgdGhlIEJSIGlzIGEgcmVsYXkpLiAgTVIxIGp1c3QgaGFzIHRvIGZv cndhcmQgcmVxdWVzdHMgYXQgdGhlIHRpbWUgb2YgdGhlIHJlcXVlc3QsIG5vdGhpbmcgbW9yZS4N BUkgZG9uknQga25vdyB3aGF0IHRoaXMgaXMgdGFsa2luZyBhYm91dC4gIEludGVybWl0dGVudCBy ZWFjaGFiaWxpdHkgdG8gdGhlIG91dHNpZGUgd29ybGQ/ICBPciB3aGF0PyAgTW92ZW1lbnQgYXJv dW5kIGEgTUFORVQgc2hvdWxkbpJ0IHJlc3VsdCBpbiBhIHJlY29uZmlndXJhdGlvbiAob2YgYWRk cmVzcy9wcmVmaXggaW5mbyksIG9ubHkgcm91dGluZyBwcm90b2NvbCB1cGRhdGVzLg0FV2h5PyAg VGhlcmWScyBubyBleHBsYW5hdGlvbiBmb3IgdGhpcyBzdGF0ZW1lbnQuDQVObyBpdCBkb2VzbpJ0 LiAgSSBkb26SdCBzZWUgaG93IHlvdSBnZXQgdGhhdCBjb25jbHVzaW9uLg0FRXhpc3Rpbmcgc29s dXRpb25zICE9IGV2ZXJ5b25lIGlzIGEgc2VydmVyIGFwcHJvYWNoLg0FV2hlcmUgZG9lcyB0aGlz IGNvbWUgZnJvbT8gIEkgY2FuknQgZmluZCB0aGlzIHN0YXRlbWVudCBpbiBbMl0uDQVIb3dldmVy LCB0aGV5IGNhbiBhcmlzZSBpbiB0cmFkaXRpb25hbCBuZXR3b3JrcywgYW5kIGhlbmNlIHRoZSBz b2x1dGlvbiBzaG91bGQgbm90IGJlIE1BTkVUIHNwZWNpZmljLCBpZiBhIHNvbHV0aW9uIGlzIHJl cXVpcmVkLg0FTm8sIHRoZXmScmUgc2VudCB0byBhIGxpbmstbG9jYWwgbXVsdGljYXN0IGFkZHJl c3MgKHRoZXkgaGF2ZSBubyBrbm93bGVkZ2Ugb2YgbmVpZ2hib3JzKS4gIElmIHRoZSBNQU5FVCBh cmNoaXRlY3R1cmUgZG9lcyBub3QgZm9yd2FyZCBsaW5rLWxvY2FsIGFkZHJlc3NlcywgdGhhdJJz IGEgcHJvcGVydHkgb2YgYSBzcGVjaWZpYyBNQU5FVCBhcmNoaXRlY3R1cmUsIG5vdCBbNV0gYW5k IFszXSBwZXIgc2UuDQVBZ2FpbiwgSSBkb26SdCBmb2xsb3cgdGhpcyBjb25jbHVzaW9uIGF0IGFs bC4gIFBhcnRpdGlvbnMgaGFwcGVuIGluIHRyYWRpdGlvbmFsIG5ldHdvcmtzIHRvbywgZS5nLiBz d2l0Y2hlZCBFdGhlcm5ldC4NBUFsdGhvdWdoIGl0IG1heSBub3QgYmUgYWJsZSB0byBnaXZlIG5l dyBhZGRyZXNzZXMsIGFueW9uZSB3aG8gaGFzIG9uZSBhbHJlYWR5IGNhbiBjb250aW51ZSB0byB1 c2UgaXQuDQVXaGljaCBoYXZlbpJ0IGJlZW4gc3VmZmljaWVudGx5IHNob3duIHRvIGNvbmNsdWRl IGFueXRoaW5nIHlldIUNBURvbpJ0IGtub3cgd2hhdCB0aGlzIG1lYW5zLg0FU28gdGhlcmWScyBu byBzdGF0ZW1lbnQgaW4gaGVyZSB0aGF0IGl0IGFjdHVhbGx5IGlzIHJlcXVpcmVkLiAgSWYgaXSS cyBub3QgcmVxdWlyZWQgKGkuZS4sIHByb2JhYmlsaXN0aWMgaXMgZ29vZCBlbm91Z2gpLCB0aGVu IGlzIHRoZXJlIGFueSBwcm9ibGVtPw0FSSBkb26SdCBzZWUgaG93IGl0IGNhbiBldmVyIGdlbmVy YXRlIGEgbG9vcC4gIEl0IGlzIGluZGlzdGluZ3Vpc2hhYmxlIGZyb20gYSBtdWx0aS1ob21lZCBy b3V0ZXIuICBUaGVyZSBhcmUgdHdvIHNpbmtzLCBubyBsb29wcy4gIFNvIEkgZG9uknQgdGhpbmsg dGhpcyBtYWtlcyBzZW5zZS4NBVN0aWNrIHRvIHRoZSB0ZXJtcyBkZWZpbmVkIGluIHNlY3Rpb24g Mi4NBUFnYWluIHRoaXMgc291bmRzIHZlcnkgdW5jZXJ0YWluIHRoYXQgdGhlcmUgaXMgYWN0dWFs bHkgYW55IHByb2JsZW0uICBUaGlzIGRvZXNuknQgc2VlbSB0byBiZSBhIHByb2JsZW0gc3RhdGVt ZW50IGRvY3VtZW50LCBzbyBtdWNoIGFzIGRvY3VtZW50ZWQgZmVhciB0aGF0IHRoZXJlIG1pZ2h0 IGluIGZhY3QgYmUgYSBwcm9ibGVtLCBvciBtaWdodCBub3QuDQVBcmUgeW91IHN1Z2dlc3Rpbmcg dGhhdCBlYWNoIGFwcGxpY2F0aW9uIGJlIGFibGUgdG8gZ2VuZXJhdGUgaXRzIG93biByZXF1aXJl bWVudHMgYWJvdXQgYWRkcmVzcyB1bmlxdWVuZXNzPyAgV2h5PyAgVGhpcyBkb2VzbpJ0IHNlZW0g bGlrZSBhbiBhcHBsaWNhdGlvbi1sYXllciBkZWNpc2lvbiB0byBtZS4gIE5vciBkb2VzIGl0IHNl ZW0gbGlrZSBpdCBoYXMgYW55dGhpbmcgdG8gZG8gd2l0aCBNQU5FVHMsIGlmIGl0IGhhcyB0byBk byB3aXRoIGFwcGxpY2F0aW9uLWxheWVyIHN0dWZmLg0FVGhlc2UgZG9uknQgc2VlbSBzcGVjaWZp YyB0byBNQU5FVCBpbiBhbnkgd2F5LiAgSXSScyBub3QgYSBNQU5FVC1zcGVjaWZpYyBwcm9ibGVt IGFuZCBoZW5jZSBzaG91bGRuknQgaGF2ZSBhIE1BTkVULXNwZWNpZmljIHNvbHV0aW9uLCBpZiBv bmUgaXMgcmVxdWlyZWQuDQVXaHkgdGhlIHVzZSBvZiB0aGUgc2luZ3VsYXI/ICBUaGVyZZJzIG5v IG5vdGlvbiBvZiBiZWluZyCTYWZmaWxpYXRlZJQgd2l0aCBvbmx5IG9uZSBJQ1AsIHJpZ2h0PyAg VGhlcmWScyBhbiBpbmRpcmVjdCCTYWZmaWxpYXRpb26UIHdpdGggZWFjaCBJQ1AgZnJvbSB3aGlj aCB5b3UgZ2V0IGFuIGFkZHJlc3MvcHJlZml4LCBhbmQgd2hldGhlciB0aGVyZZJzIG9uZSBvciBt YW55IGRlcGVuZHMgb24gdGhlIGRlcGxveW1lbnQsIHJpZ2h0Pw0FVW5jbGVhciB3aGF0IHNvcnQg b2YgcmVjb25maWd1cmF0aW9uIGlzIG1lYW50Lg0FSSBkb26SdCBrbm93IHdoYXQgdGhhdCBtZWFu cy4gIElmIHRoYXQgbWVhbnMgdGhhdCBhbGwgcHJvYmxlbXMgKHdoaWNoIG1heSBub3QgYmUgdW5p cXVlIHRvIE1BTkVUcykgbXVzdCBiZSBhZGRyZXNzZWQgaW4gYSBNQU5FVC1zcGVjaWZpYyB3YXks IHRoZW4gSSBkaXNhZ3JlZS4NBT8gIFNlY3Rpb24gNiBkb2VzbpJ0IG1lbnRpb24gYW55IHNlY3Vy aXR5IG9yIHRydXN0IGlzc3VlcyBzcGVjaWZpYyB0byBhZCBob2MgbmV0d29ya2luZy4NBVdoeT8g IFdoeSBkbyB5b3UgdGhpbmsgk21vc3SUIHdpbGwgZml0IGludG8gdGhpcyBjYXRlZ29yeT8gIEkg ZG9uknQgc2VlIGFueSBqdXN0aWZpY2F0aW9uIGZvciB0aGlzLg0FQWN0dWFsbHksIHRoYXQgd2Fz bpJ0IGV4cGxhaW5lZCBhdCBhbGwuDQ0NAAAAAAAAAAAAAAAAAAAGAAACCAAASwgAABMJAAD4CQAA exAAAHwQAADJGwAAzBsAANAbAABUHAAAVRwAAJUcAACWHAAA6hwAAOscAADtHAAA7hwAAEUdAABG HQAAmB0AANUdAAAXHwAAGh8AAB0fAABaHwAAWx8AAJ0hAACkIQAAqiEAAKshAACsIQAAwyEAAMkh AABXIgAAWCIAAFkiAABfIgAAZCIAALQiAAC1IgAAtiIAALwiAADBIgAA8SIAAPQiAAD2IgAA7iQA AA8lAAAA+wD7AO4A4doA7gDuAO4A7gDuAPsA4doA7gDNxr/uALIApQClngClAKWeAJeKAH0AAAAA AAAZAAiBY0gBAGRoAAAAAGRoAAAAAGRoxqq7ZhkACIFjSAEAZGgAAAAAZGgAAAAAZGhGq7tmDQEI gQRIAQAFaEaru2YNAQiBBEgBAAVoy6q7ZhkACIFjSAEAZGgAAAAAZGgAAAAAZGjLqrtmGQAIgWNI AQBkaAAAAABkaAAAAABkaCSru2YNAQiBBEgBAAVozaq7Zg0BCIEESAEABWhLq7tmGQAIgWNIAQBk aAAAAABkaAAAAABkaM2qu2YNAQiBBEgBAAVowqq7ZhkACIFjSAEAZGgAAAAAZGgAAAAAZGjCqrtm GQNqAAAAADBKEABPSgAAUUoAAFUIAV5KAAAIbUgQBHNIEAQwAAYAAAEIAAACCAAASwgAAJQIAADd CAAAJgkAAG8JAAC4CQAAAQoAAEoKAACTCgAAlAoAAJUKAADdCgAAEgsAABMLAAAnCwAAKAsAAG4L AACzCwAA+QsAAD0MAAA+DAAAgwwAAMcMAAAKDQAAFQ0AABYNAABfDQAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8AAB0ABgAAaoQAAPKXAAD9/QAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQEAAEBAl8NAACnDQAA6Q0AACcOAAAoDgAAYg4A AJEOAACSDgAA1g4AAPoOAAD7DgAALw8AADAPAABBDwAAQg8AAGoPAABrDwAAbA8AAG0PAABuDwAA bw8AAHAPAABxDwAAcg8AAHMPAAC8DwAAvg8AAAcQAAAIEAAACRAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAAAdCRAAABIQAAATEAAAXBAAAKYQAADmEAAA 9BAAAPUQAAD2EAAACBEAAAkRAABSEQAAmxEAAOQRAAAtEgAAdhIAAL8SAAAIEwAAURMAAJoTAADj EwAALBQAAHUUAAC+FAAABxUAAFAVAACZFQAA4hUAACsWAAB0FgAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8AAB10FgAAvRYAAAYXAABPFwAAmBcAAJkXAACa FwAAmxcAAJwXAACdFwAAnhcAAJ8XAACgFwAAoRcAAKIXAACjFwAApBcAAKUXAACmFwAApxcAAKgX AACpFwAAqhcAAPMXAAD1FwAAPhgAAD8YAABAGAAAURgAAFIYAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDwAAHVIYAACXGAAA3hgAACMZAABmGQAAqhkAAOEZ AADiGQAAJxoAAHAaAAC2GgAAwxoAAMQaAAAHGwAATRsAAJUbAADgGwAAKRwAADkcAAA6HAAAfxwA AMYcAAAMHQAAUR0AAJUdAACjHQAApB0AAKUdAACmHQAApx0AAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAAAdpx0AAKgdAACpHQAAqh0AAKsdAACsHQAArR0A AK4dAACvHQAAsB0AALEdAACyHQAAsx0AALQdAAC1HQAAth0AALcdAAC4HQAAuR0AALodAAC7HQAA BB4AAAYeAABPHgAAUB4AAFEeAABhHgAAYh4AAKceAAC8HgAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8AAB28HgAAvR4AAAYfAABNHwAAZh8AAGcfAACrHwAA 6x8AAOwfAAA1IAAAdyAAAL0gAAC+IAAABiEAAEYhAABuIQAAbyEAAL0hAAAFIgAAKSIAACoiAAB2 IgAAhSIAAIYiAADSIgAA4SIAAOIiAAAmIwAAVCMAAFUjAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDwAAHVUjAACeIwAA0yMAANQjAAAaJAAATiQAAE8kAACX JAAArCQAAK0kAAD1JAAARCUAAGclAABoJQAAaSUAAGolAABrJQAAbCUAAG0lAAC2JQAAuCUAAAEm AAACJgAAAyYAAFEmAACYJgAA6SYAAOomAAA4JwAAfCcAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAAAdDyUAABUlAAAWJQAAFyUAAEMmAABJJgAATiYAALUm AADnJgAAKScAAC8nAAA0JwAA1SkAANspAADgKQAAASoAAAIqAAAFKgAADCoAABIqAAATKgAAFCoA ACUqAAArKgAAySsAAM4rAADVKwAAJi0AACwtAAAxLQAAai0AAHEtAAB3LQAAeC0AAIgtAACNLQAA sS8AALIvAADyMAAA9TAAABExAAASMQAAJDQAAPgA6wDe1wDQAN7XAMPQALwAr6ih6wCUAK+hAIeA AId5gACHALwAvABsAAAAGQAIgWNIAQBkaAAAAABkaAAAAABkaCaru2YNAQiBBEgBAAVoTKu7Zg0B CIEESAEABWgjq7tmGQAIgWNIAQBkaAAAAABkaAAAAABkaCOru2YZAAiBY0gBAGRoAAAAAGRoAAAA AGRoJKu7Zg0BCIEESAEABWjNqrtmDQEIgQRIAQAFaEuru2YZAAiBY0gBAGRoAAAAAGRoAAAAAGRo zaq7Zg0BCIEESAEABWglq7tmGQAIgWNIAQBkaAAAAABkaAAAAABkaMiqu2YNAQiBBEgBAAVoyKq7 Zg0BCIEESAEABWjHqrtmGQAIgWNIAQBkaAAAAABkaAAAAABkaMequ2YZA2oAAAAAMEoQAE9KAABR SgAAVQgBXkoAAA0BCIEESAEABWjGqrtmACp8JwAAvicAAL8nAADAJwAAwScAAMInAADDJwAAxCcA AMUnAADGJwAAxycAAMgnAADJJwAAyicAAMsnAADMJwAAzScAAM4nAADPJwAA0CcAANEnAADSJwAA 0ycAANQnAADVJwAA1icAANcnAADYJwAA2ScAANonAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAAAAAAAAAAAAAAABDwAAHdonAADbJwAA3CcAAN0nAADeJwAA3ycAAOAnAADhJwAA 4icAAOMnAADkJwAA5ScAAOYnAADnJwAA6CcAAOknAADqJwAAMygAADUoAAB+KAAAfygAAIAoAACZ KAAAmigAAN0oAAAgKQAAaSkAAI4pAACPKQAApSkAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAEPAAAdpSkAAKYpAADxKQAAPioAAIAqAADFKgAADCsAADIrAAAz KwAAeisAAL8rAAAPLAAAViwAAJ4sAADdLAAA3iwAAPUsAAD2LAAARC0AAI4tAADVLQAAHS4AAGIu AACrLgAA8y4AAAcvAAAILwAASy8AAJQvAADdLwAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAQ8AAB3dLwAA/i8AAP8vAAAkMAAAJTAAAGowAACsMAAA9zAAABkx AAAaMQAAGzEAABwxAAAdMQAAHjEAAB8xAABoMQAAajEAALMxAAC0MQAAtTEAAMsxAADMMQAADTIA AFAyAABfMgAAYDIAAIQyAACFMgAAzjIAAA8zAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAAAAAAAAAAAAAAABDwAAHQ8zAABWMwAAnjMAAOczAAAqNAAAKzQAAG00AACyNAAA+zQA AEM1AACDNQAAmDUAAJk1AADhNQAAJzYAAHA2AACJNgAAijYAANQ2AAAbNwAAZDcAAKo3AAC3NwAA uDcAANI3AADTNwAAGzgAAGI4AACqOAAA7jgAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAEPAAAdJDQAACU0AACDNAAAhDQAANI2AADTNgAAOTcAADo3AACAOAAA gTgAALs5AAC8OQAAIj8AACM/AAAfQAAAIEAAAN5AAADfQAAA/UEAAP5BAADZQgAA2kIAAIFDAACC QwAAf0QAAIBEAABaRQAAW0UAAMBGAADBRgAAKEcAAClHAABRSQAAUkkAAFdKAABYSgAAvkoAAMZK AACKTQAAi00AAH5PAAB/TwAA1VAAANZQAAAiUwAAI1MAAEdTAABIUwAAyFQAAM5UAADWVAAA4lQA AOhUAADwVAAA/VQAAP5UAAACVQAAA1UAAK9XAACwVwAAS1oAAExaAAAQXQAAEV0AAMddAADIXQAA Nl8AADdfAADyAPIA8gDyAPIA8gDyAPIA8gDyAPIA8gDyAOsA8gDyAPIA8gDeAPIA8gDyANEA8gDE vQDEvQDyAPIA8gDyAPIA8gC2AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0BCIEESAEABWhRq7tm DQEIgQRIAQAFaEaru2YZAAiBY0gBAGRoAAAAAGRoAAAAAGRoRqu7ZhkACIFjSAEAZGgAAAAAZGgA AAAAZGhEq7tmGQAIgWNIAQBkaAAAAABkaAAAAABkaEGru2YNAQiBBEgBAAVoN6u7ZhkDagAAAAAw ShAAT0oAAFFKAABVCAFeSgAAAEPuOAAANTkAAHg5AAC+OQAAAzoAAEw6AACMOgAAoDoAAKE6AACi OgAAozoAAKQ6AAClOgAA7joAAPA6AAA5OwAAOjsAADs7AACCOwAAwTsAAAA8AAA/PAAAfjwAAL08 AAD8PAAAPT0AAD49AAB+PQAAfz0AAIA9AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAAAAAAAAAAAAAAABDwAAHYA9AACBPQAAoj0AAKM9AADpPQAALz4AAHU+AAC6PgAAAj8AAEc/ AACGPwAAzj8AABRAAABaQAAAoUAAAOtAAAAzQQAANEEAAH1BAADAQQAACUIAAE9CAACUQgAA3EIA AB1DAABeQwAAoUMAAKJDAADCQwAAw0MAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAEPAAAdw0MAAApEAABPRAAAl0QAANtEAAAeRQAAY0UAAKRFAAClRQAApkUA AKdFAADwRQAA8kUAADtGAAA8RgAAPUYAAIZGAADIRgAAD0cAAFVHAACeRwAA5kcAACtIAABzSAAA dEgAAJlIAACaSAAA4kgAAChJAABwSQAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAQ8AAB1wSQAAt0kAAABKAABGSgAAhkoAAMxKAAAQSwAAUUsAAJVLAAC6SwAA u0sAALxLAAC9SwAA7UsAAA9MAAAxTAAAU0wAAHVMAACXTAAAuUwAAN1MAADeTAAAH00AACBNAAAh TQAAIk0AACNNAABITQAASU0AAJJNAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AAAAAAAAAAAAAAABDwAAHZJNAADZTQAAAE4AAAFOAAACTgAAA04AAAROAAAFTgAABk4AAE9OAABR TgAAmk4AAJtOAACcTgAAwk4AAMNOAAADTwAARk8AAItPAADSTwAAE1AAAFtQAABxUAAAclAAAKVQ AACmUAAA71AAADhRAAB6UQAAn1EAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAEPAAAdn1EAAKBRAADnUQAAMFIAAHZSAAC4UgAA+lIAAD9TAACCUwAAg1MAAMlT AAARVAAAWVQAAJ1UAACyVAAAs1QAAA1VAABRVQAAmVUAAN1VAAAhVgAAZFYAAGVWAACpVgAA8VYA ADhXAACBVwAAy1cAAAxYAABUWAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAQ8AAB1UWAAAeVgAAHpYAAB7WAAAfFgAAH1YAAB+WAAAx1gAAMlYAAASWQAAE1kA ABRZAABLWQAATFkAAI9ZAACyWQAAs1kAAPxZAABDWgAAi1oAAMxaAAAUWwAAW1sAAKNbAADqWwAA M1wAAHRcAAC9XAAA41wAAORcAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAA AAAAAAAAAAABDwAAHeRcAAAuXQAAd10AALVdAAD/XQAAHF4AAB1eAAAeXgAAH14AACBeAAAhXgAA Il4AACNeAAAkXgAAJV4AACZeAAAnXgAAKF4AACleAAAqXgAAK14AACxeAAAtXgAALl4AAC9eAAAw XgAAMV4AADJeAAAzXgAANF4AAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAEPAAAdNF4AADVeAAA2XgAAN14AADheAACBXgAAg14AAMxeAADNXgAAzl4AAOteAADs XgAAL18AAHVfAAC5XwAAAmAAAEdgAABIYAAAl2AAANxgAAAhYQAAamEAAJxhAACdYQAA3mEAAB9i AABmYgAAr2IAAPNiAAA7YwAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAQ8AAB03XwAAOF8AAFVgAABqYAAAbmAAAIlgAACRYAAAk2AAAJRgAACWYAAAH2EAACBh AACtYgAArmIAAKdjAACoYwAAHGQAAB1kAAAcZQAAHWUAAKtlAACvZQAAsGYAALFmAACXaQAAmGkA AAR1AAA4dQAA7nYAAEN3AACMegAAzHoAAGqEAABrhAAAp4QAAKiEAAC5hAAAuoQAAPqEAAD7hAAA 3YUAAN6FAADIhgAAyYYAAJ6HAACfhwAAeIgAAHmIAADuiAAA74gAAGSJAABliQAAqYkAAKqJAADv iQAA8IkAAAGKAAACigAARooAAEeKAABqigAAa4oAADiLAAA5iwAAm4sAAJyLAAA4jAAAOYwAAPKM AADzjAAAz40AANCNAAABjgAAAo4AADuOAAA8jgAAcY4AAHKOAADyAPLrAPLrAPIA5ADkANcA1wDQ ANAA1wDXAMsAywDLAMQAxADEAMQAxADEAMQAxADEAMQAxADEAMQAxADEAMQAxADEAMQAxADEAMQA xAAAAA0DagAAAAAwShAAVQgBCG1IEARzSBAEAA0BCIEESAEABWhUq7tmGQNqAAAAADBKEABPSgAA UUoAAFUIAV5KAAANAQiBBEgBAAVoUqu7Zg0BCIEESAEABWhRq7tmGQAIgWNIAQBkaAAAAABkaAAA AABkaFGru2YATTtjAACCYwAAqmMAAKtjAADyYwAALmQAAC9kAAAwZAAAMWQAADJkAAAzZAAANGQA ADVkAAA2ZAAAN2QAADhkAAA5ZAAAOmQAADtkAAA8ZAAAPWQAAD5kAAA/ZAAAQGQAAEFkAABCZAAA Q2QAAERkAABFZAAARmQAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAEPAAAdRmQAAEdkAABIZAAAkWQAAJNkAADcZAAA3WQAAN5kAAD6ZAAA+2QAAEVlAACMZQAA 02UAABlmAABgZgAApWYAAOxmAAAuZwAAd2cAAL5nAAAHaAAAMmgAADNoAAB1aAAAvGgAAPxoAABF aQAAjWkAANNpAADUaQAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAQ8AAB3UaQAAGmoAAGNqAACiagAA52oAAC5rAABqawAAhWsAAIZrAADNawAA/WsAAP5rAAD/ awAAAGwAAAFsAAACbAAAA2wAAARsAAAFbAAABmwAAAdsAAAIbAAACWwAAApsAAALbAAADGwAAA1s AAAObAAAD2wAABBsAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAA AAABDwAAHRBsAABZbAAAW2wAAKRsAAClbAAApmwAAL5sAAC/bAAAAG0AAAFtAAACbQAAA20AAARt AAAFbQAABm0AAAdtAAAIbQAACW0AAAptAAALbQAADG0AAA1tAAAObQAAD20AABBtAAARbQAAEm0A ABNtAAAUbQAAFW0AAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAEPAAAdFW0AABZtAAAXbQAAGG0AABltAAAabQAAG20AABxtAAAdbQAAHm0AAB9tAAAgbQAAIW0A ACJtAAAjbQAAJG0AACVtAAAmbQAAJ20AAChtAAApbQAAKm0AACttAAAsbQAALW0AAC5tAAAvbQAA MG0AAHltAAB7bQAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AQ8AAB17bQAAxG0AAMVtAADGbQAA4W0AAOJtAAApbgAAcW4AAHJuAAC0bgAA9m4AAA5vAAAPbwAA T28AAJFvAACSbwAA2m8AABtwAAA5cAAAOnAAAINwAAC6cAAAu3AAAP1wAABEcQAARXEAAI5xAAC5 cQAAunEAAO5xAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB DwAAHe5xAADvcQAAL3IAAEhyAABJcgAAjHIAANFyAAAGcwAAB3MAAE5zAABdcwAAXnMAAKNzAADg cwAA4XMAACN0AABYdAAAWXQAAJt0AAC0dAAAtXQAAPt0AAAbdQAAHHUAAB11AAAedQAAZ3UAAGl1 AACydQAAs3UAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEP AAAds3UAALR1AAD0dQAAGXYAABp2AABYdgAAoXYAAKJ2AADldgAA/nYAAP92AAAAdwAAAXcAAAJ3 AAADdwAABHcAAAV3AAAGdwAAB3cAAAh3AAAJdwAACncAAAt3AAAMdwAADXcAAA53AAAPdwAAEHcA ABF3AAASdwAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8A AB0SdwAAE3cAABR3AAAVdwAAFncAABd3AAAYdwAAGXcAABp3AAAbdwAAHHcAAB13AAAedwAAH3cA ACB3AAAhdwAAIncAACN3AAAkdwAAJXcAACZ3AAAndwAAKHcAACl3AABydwAAdHcAAL13AAC+dwAA v3cAAMx3AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDwAA Hcx3AADNdwAAFXgAAFt4AACkeAAA63gAAOx4AADteAAA7ngAAO94AADweAAA8XgAAPJ4AADzeAAA 9HgAAPV4AAD2eAAA93gAAPh4AAD5eAAA+ngAAPt4AAD8eAAA/XgAAP54AAD/eAAAAHkAAAF5AAAC eQAAA3kAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAAAd A3kAAAR5AAAFeQAABnkAAAd5AAAIeQAACXkAAAp5AAALeQAADHkAAA15AAAOeQAAD3kAABB5AAAR eQAAEnkAABN5AAAUeQAAFXkAABZ5AAAXeQAAGHkAAGF5AABjeQAArHkAAK15AACueQAAwXkAAMJ5 AADXeQAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8AAB3X eQAA4HkAAOF5AAD9eQAAInoAACN6AAAkegAANHoAAEp6AABLegAAZXoAAId6AACIegAAiXoAAJt6 AACtegAArnoAAMl6AADzegAA9HoAAPV6AAAKewAAFXsAABZ7AAAwewAAT3sAAFB7AABRewAAUnsA AFN7AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDwAAHVN7 AABUewAAVXsAAFZ7AABXewAAWHsAAFl7AABaewAAW3sAAFx7AABdewAAXnsAAF97AABgewAAYXsA AGJ7AABjewAAZHsAAGV7AABmewAAr3sAALF7AAD6ewAA+3sAAPx7AAAVfAAAFnwAAD58AAA/fAAA hHwAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAAAdhHwA AMl8AADlfAAA5nwAAC99AAB4fQAAwX0AAAl+AABSfgAAmH4AAN5+AADffgAA4H4AAPZ+AAD3fgAA PH8AAIV/AADMfwAAEoAAAFiAAAChgAAA5YAAAASBAAAFgQAAR4EAAIuBAADUgQAAEIIAAFmCAAB1 ggAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8AAB11ggAA doIAAL2CAAABgwAAR4MAAIiDAACegwAAn4MAAKCDAACvgwAAsIMAAO+DAAAahAAAG4QAAByEAAAd hAAAHoQAAB+EAABohAAAaoQAAKeEAAC5hAAA+oQAAN2FAADIhgAAnocAAHiIAADuiAAAZIkAAKmJ AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAA AAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsA AAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAAAAAAAAAAERAAABDwAAHamJAADv iQAAAYoAAEaKAABqigAAOIsAAJuLAAA4jAAA8owAAM+NAAABjgAAO44AAHGOAACyjgAANI8AAB2Q AACUkAAA+5AAADyRAABZkQAA75EAAJWSAAC/kgAAjJMAAKSUAAA/lQAAOZYAAGmWAAAJlwAAY5cA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAERAAAdco4AALKO AACzjgAANI8AADWPAAAdkAAAHpAAAJSQAACVkAAA+5AAAPyQAAA8kQAAPZEAAFmRAABakQAA75EA APCRAACVkgAAlpIAAL+SAADAkgAAjJMAAI2TAACklAAApZQAAD+VAABAlQAAOZYAADqWAABplgAA apYAAAmXAAAKlwAAY5cAAGSXAADIlwAAyZcAAPOXAAAA+AD4APgA+AD4APgA+AD4APgA+AD4APgA +AD4APgA+AD4APgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0DagAAAAAwShAAVQgBACVjlwAAyJcA APGXAADylwAA85cAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8AAAEAAAABEQAABCwAMZBoAR+w 0C8gsOA9IbAnBSKwJwUjkKAFJJCgBSWwAAAXsNACGLDQAgyQ0AIAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIYCFAASAAEAnAAPAAQAAAAD AAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAEQAAEDx/wIARAAMBAAAAAAAAAAABgBOAG8AcgBtAGEAbAAAAAIAAAAcAENKGABfSAEEYUoY AG1ICQRuSBIEc0gJBHRIEgQAAAAAAAAAAAAAAAAAAAAAAABEAEFA8v+hAEQADAUAAAAAAAAAABYA RABlAGYAYQB1AGwAdAAgAFAAYQByAGEAZwByAGEAcABoACAARgBvAG4AdAAAAAAAUgBpQPP/swBS AAwFAAAAAAAAAAAMAFQAYQBiAGwAZQAgAE4AbwByAG0AYQBsAAAAHAAX9gMAADTWBgABCgNsADTW BgABBQMAAGH2AwAAAgALAAAAKABrQPT/wQAoAAAFAAAAAAAAAAAHAE4AbwAgAEwAaQBzAHQAAAAC AAAAAAAAAEQAWkABAPIARAAMBAAAAAAAAAAACgBQAGwAYQBpAG4AIABUAGUAeAB0AAAAAgAPABQA Q0oUAE9KBABRSgQAXkoEAGFKFABCACdAogABAUIADAUAAAAAAAAAABEAQwBvAG0AbQBlAG4AdAAg AFIAZQBmAGUAcgBlAG4AYwBlAAAACABDShAAYUoQADwAHkABABIBPAAMBQAAAAAAAAAADABDAG8A bQBtAGUAbgB0ACAAVABlAHgAdAAAAAIAEQAIAENKFABhShQAQABqQBEBEgFAAAwFAAAAAAAAAAAP AEMAbwBtAG0AZQBuAHQAIABTAHUAYgBqAGUAYwB0AAAAAgASAAYANQiBXAiBSACZQAEAMgFIAAwF AAAAAAAAAAAMAEIAYQBsAGwAbwBvAG4AIABUAGUAeAB0AAAAAgATABQAQ0oQAE9KBQBRSgUAXkoF AGFKEAALAEQAYQB2AGUAIABUAGgAYQBsAGUAcgB7CAAAVBQAAJUUAADqFAAA7RQAAEUVAABaFwAA qxkAABYdAAATIgAAJCwAAIMsAADSLgAAOS8AAIAwAAC7MQAAIjcAAB84AADeOAAA/TkAANk6AACB OwAAfzwAAMA+AAAoPwAAUUEAAFdCAACKRQAAfkcAANVIAABHSwAA/UwAAAJNAACvTwAAS1IAABBV AADHVQAAp1sAABxcAACwXgAAl2EAAPOPAAACAEQAVAAAAAAAAAAAAAAAAAAAAAAAAAAAAC6s7goC AEQAVAAAAAAAAAAAAAAAAAAAAAAAAAAAAEWs7goCAEQAVAAAAAAAAAAAAAAAAAAAAAAAAAAAABWO 7goCAEQAVAAAAAAAAAAAAAAAAAAAAAAAAAAAADqO7goCAEQAVAAAAAAAAAAAAAAAAAAAAAAAAAAA ADKk7goCAEQAVAAAAAAAAAAAAAAAAAAAAAAAAAAAAHuO7goCAEQAVAAAAAAAAAAAAAAAAAAAAAAA AAAAAPGO7goCAEQAVAAAAAAAAAAAAAAAAAAAAAAAAAAAAE6Q7goCAEQAVAAAAAAAAAAAAAAAAAAA AAAAAAAAAMCP7goCAEQAVAAAAAAAAAAAAAAAAAAAAAAAAAAAAOiQ7goCAEQAVAAAAAAAAAAAAAAA AAAAAAAAAAAAAAim7goCAEQAVAAAAAAAAAAAAAAAAAAAAAAAAAAAAFKs7goCAEQAVAAAAAAAAAAA AAAAAAAAAAAAAAAAAJKm7goCAEQAVAAAAAAAAAAAAAAAAAAAAAAAAAAAAGmm7goCAEQAVAAAAAAA AAAAAAAAAAAAAAAAAAAAAMim7goCAEQAVAAAAAAAAAAAAAAAAAAAAAAAAAAAAFKn7goCAEQAVAAA AAAAAAAAAAAAAAAAAAAAAAAAAL2n7goCAEQAVAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqo7goCAEQA VAAAAAAAAAAAAAAAAAAAAAAAAAAAAGCo7goCAEQAVAAAAAAAAAAAAAAAAAAAAAAAAAAAAJio7goC AEQAVAAAAAAAAAAAAAAAAAAAAAAAAAAAAK6o7goCAEQAVAAAAAAAAAAAAAAAAAAAAAAAAAAAAMSo 7goCAEQAVAAAAAAAAAAAAAAAAAAAAAAAAAAAABWp7goCAEQAVAAAAAAAAAAAAAAAAAAAAAAAAAAA AIGp7goCAEQAVAAAAAAAAAAAAAAAAAAAAAAAAAAAANWp7goCAEQAVAAAAAAAAAAAAAAAAAAAAAAA AAAAAD2q7goCAEQAVAAAAAAAAAAAAAAAAAAAAAAAAAAAAHmq7goCAEQAVAAAAAAAAAAAAAAAAAAA AAAAAAAAANiq7goCAEQAVAAAAAAAAAAAAAAAAAAAAAAAAAAAAAyr7goCAEQAVAAAAAAAAAAAAAAA AAAAAAAAAAAAADKr7goCAEQAVAAAAAAAAAAAAAAAAAAAAAAAAAAAAIWr7goCAEQAVAAAAAAAAAAA AAAAAAAAAAAAAAAAANWr7goCAEQAVAAAAAAAAAAAAAAAAAAAAAAAAAAAAOir7goCAEQAVAAAAAAA AAAAAAAAAAAAAAAAAAAAALCs7goCAEQAVAAAAAAAAAAAAAAAAAAAAAAAAAAAAFSt7goCAEQAVAAA AAAAAAAAAAAAAAAAAAAAAAAAAO+t7goCAEQAVAAAAAAAAAAAAAAAAAAAAAAAAAAAAEiu7goCAEQA VAAAAAAAAAAAAAAAAAAAAAAAAAAAAMuu7goCAEQAVAAAAAAAAAAAAAAAAAAAAAAAAAAAACGv7goC AEQAVAAAAAAAAAAAAAAAAAAAAAAAAAAAADiv7goCAEQAVAAAAAAAAAAAAAAAAAAAAAAAAAAAAIWv 7gpIq7tmAAAAAAAAAAAAAAAAAABIq7tmAAAAAAAAAAAAAAAAAAC7qrtmAAAAAAAAAAAAAAAAAADB qrtmAAAAAAAAAAAAAAAAAAAmq7tmAAAAAAAAAAAAAAAAAADCqrtmAAAAAAAAAAAAAAAAAADFqrtm AAAAAAAAAAAAAAAAAABLq7tmAAAAAAAAAAAAAAAAAADHqrtmAAAAAAAAAAAAAAAAAABMq7tmAAAA AAAAAAAAAAAAAAAqq7tmAAAAAAAAAAAAAAAAAABIq7tmAAAAAAAAAAAAAAAAAAAsq7tmAAAAAAAA AAAAAAAAAAArq7tmAAAAAAAAAAAAAAAAAAAuq7tmAAAAAAAAAAAAAAAAAAAwq7tmAAAAAAAAAAAA AAAAAAAxq7tmAAAAAAAAAAAAAAAAAAAzq7tmAAAAAAAAAAAAAAAAAAA0q7tmAAAAAAAAAAAAAAAA AAA0q7tmAAAAAAAAAAAAAAAAAAA1q7tmAAAAAAAAAAAAAAAAAAA1q7tmAAAAAAAAAAAAAAAAAAA3 q7tmAAAAAAAAAAAAAAAAAAA4q7tmAAAAAAAAAAAAAAAAAAA6q7tmAAAAAAAAAAAAAAAAAABAq7tm AAAAAAAAAAAAAAAAAABBq7tmAAAAAAAAAAAAAAAAAABDq7tmAAAAAAAAAAAAAAAAAABDq7tmAAAA AAAAAAAAAAAAAABEq7tmAAAAAAAAAAAAAAAAAABFq7tmAAAAAAAAAAAAAAAAAABGq7tmAAAAAAAA AAAAAAAAAABJq7tmAAAAAAAAAAAAAAAAAABLq7tmAAAAAAAAAAAAAAAAAABPq7tmAAAAAAAAAAAA AAAAAABQq7tmAAAAAAAAAAAAAAAAAABRq7tmAAAAAAAAAAAAAAAAAABTq7tmAAAAAAAAAAAAAAAA AABWq7tmAAAAAAAAAAAAAAAAAABVq7tmAAAAAAAAAAAAAAAAAABWq7tmAAAAAAAAAAAAAAAAAAAA AAAAPQAAAE8AAACQAAAAcwEAAF4CAAA0AwAADgQAAIQEAAD6BAAAPwUAAIUFAACXBQAA3AUAAAAG AADOBgAAMQcAAM4HAACICAAAZQkAAJcJAADRCQAABwoAAEgKAADKCgAAswsAACoMAACRDAAA0gwA AO8MAACFDQAAKw4AAFUOAAAiDwAAOhAAANUQAADPEQAA/xEAAJ8SAAD5EgAAXhMAAIcTAACKEwAA AAAAAPOPAAAEAADyAAAFAP////8AAAAAAQAAAAIAAABLAAAAlAAAAN0AAAAmAQAAbwEAALgBAAAB AgAASgIAAJMCAACUAgAAlQIAAN0CAAASAwAAEwMAACcDAAAoAwAAbgMAALMDAAD5AwAAPQQAAD4E AACDBAAAxwQAAAoFAAAVBQAAFgUAAF8FAACnBQAA6QUAACcGAAAoBgAAYgYAAJEGAACSBgAA1gYA APoGAAD7BgAALwcAADAHAABBBwAAQgcAAGoHAABrBwAAbAcAAG0HAABuBwAAbwcAAHAHAABxBwAA cgcAAHMHAAC8BwAAvgcAAAcIAAAICAAACQgAABIIAAATCAAAXAgAAKYIAADmCAAA9AgAAPUIAAD2 CAAACAkAAAkJAABSCQAAmwkAAOQJAAAtCgAAdgoAAL8KAAAICwAAUQsAAJoLAADjCwAALAwAAHUM AAC+DAAABw0AAFANAACZDQAA4g0AACsOAAB0DgAAvQ4AAAYPAABPDwAAmA8AAJkPAACaDwAAmw8A AJwPAACdDwAAng8AAJ8PAACgDwAAoQ8AAKIPAACjDwAApA8AAKUPAACmDwAApw8AAKgPAACpDwAA qg8AAPMPAAD1DwAAPhAAAD8QAABAEAAAURAAAFIQAACXEAAA3hAAACMRAABmEQAAqhEAAOERAADi EQAAJxIAAHASAAC2EgAAwxIAAMQSAAAHEwAATRMAAJUTAADgEwAAKRQAADkUAAA6FAAAfxQAAMYU AAAMFQAAURUAAJUVAACjFQAApBUAAKUVAACmFQAApxUAAKgVAACpFQAAqhUAAKsVAACsFQAArRUA AK4VAACvFQAAsBUAALEVAACyFQAAsxUAALQVAAC1FQAAthUAALcVAAC4FQAAuRUAALoVAAC7FQAA BBYAAAYWAABPFgAAUBYAAFEWAABhFgAAYhYAAKcWAAC8FgAAvRYAAAYXAABNFwAAZhcAAGcXAACr FwAA6xcAAOwXAAA1GAAAdxgAAL0YAAC+GAAABhkAAEYZAABuGQAAbxkAAL0ZAAAFGgAAKRoAACoa AAB2GgAAhRoAAIYaAADSGgAA4RoAAOIaAAAmGwAAVBsAAFUbAACeGwAA0xsAANQbAAAaHAAAThwA AE8cAACXHAAArBwAAK0cAAD1HAAARB0AAGcdAABoHQAAaR0AAGodAABrHQAAbB0AAG0dAAC2HQAA uB0AAAEeAAACHgAAAx4AAFEeAACYHgAA6R4AAOoeAAA4HwAAfB8AAL4fAAC/HwAAwB8AAMEfAADC HwAAwx8AAMQfAADFHwAAxh8AAMcfAADIHwAAyR8AAMofAADLHwAAzB8AAM0fAADOHwAAzx8AANAf AADRHwAA0h8AANMfAADUHwAA1R8AANYfAADXHwAA2B8AANkfAADaHwAA2x8AANwfAADdHwAA3h8A AN8fAADgHwAA4R8AAOIfAADjHwAA5B8AAOUfAADmHwAA5x8AAOgfAADpHwAA6h8AADMgAAA1IAAA fiAAAH8gAACAIAAAmSAAAJogAADdIAAAICEAAGkhAACOIQAAjyEAAKUhAACmIQAA8SEAAD4iAACA IgAAxSIAAAwjAAAyIwAAMyMAAHojAAC/IwAADyQAAFYkAACeJAAA3SQAAN4kAAD1JAAA9iQAAEQl AACOJQAA1SUAAB0mAABiJgAAqyYAAPMmAAAHJwAACCcAAEsnAACUJwAA3ScAAP4nAAD/JwAAJCgA ACUoAABqKAAArCgAAPcoAAAZKQAAGikAABspAAAcKQAAHSkAAB4pAAAfKQAAaCkAAGopAACzKQAA tCkAALUpAADLKQAAzCkAAA0qAABQKgAAXyoAAGAqAACEKgAAhSoAAM4qAAAPKwAAVisAAJ4rAADn KwAAKiwAACssAABtLAAAsiwAAPssAABDLQAAgy0AAJgtAACZLQAA4S0AACcuAABwLgAAiS4AAIou AADULgAAGy8AAGQvAACqLwAAty8AALgvAADSLwAA0y8AABswAABiMAAAqjAAAO4wAAA1MQAAeDEA AL4xAAADMgAATDIAAIwyAACgMgAAoTIAAKIyAACjMgAApDIAAKUyAADuMgAA8DIAADkzAAA6MwAA OzMAAIIzAADBMwAAADQAAD80AAB+NAAAvTQAAPw0AAA9NQAAPjUAAH41AAB/NQAAgDUAAIE1AACi NQAAozUAAOk1AAAvNgAAdTYAALo2AAACNwAARzcAAIY3AADONwAAFDgAAFo4AAChOAAA6zgAADM5 AAA0OQAAfTkAAMA5AAAJOgAATzoAAJQ6AADcOgAAHTsAAF47AAChOwAAojsAAMI7AADDOwAACjwA AE88AACXPAAA2zwAAB49AABjPQAApD0AAKU9AACmPQAApz0AAPA9AADyPQAAOz4AADw+AAA9PgAA hj4AAMg+AAAPPwAAVT8AAJ4/AADmPwAAK0AAAHNAAAB0QAAAmUAAAJpAAADiQAAAKEEAAHBBAAC3 QQAAAEIAAEZCAACGQgAAzEIAABBDAABRQwAAlUMAALpDAAC7QwAAvEMAAL1DAADtQwAAD0QAADFE AABTRAAAdUQAAJdEAAC5RAAA3UQAAN5EAAAfRQAAIEUAACFFAAAiRQAAI0UAAEhFAABJRQAAkkUA ANlFAAAARgAAAUYAAAJGAAADRgAABEYAAAVGAAAGRgAAT0YAAFFGAACaRgAAm0YAAJxGAADCRgAA w0YAAANHAABGRwAAi0cAANJHAAATSAAAW0gAAHFIAABySAAApUgAAKZIAADvSAAAOEkAAHpJAACf SQAAoEkAAOdJAAAwSgAAdkoAALhKAAD6SgAAP0sAAIJLAACDSwAAyUsAABFMAABZTAAAnUwAALJM AACzTAAADU0AAFFNAACZTQAA3U0AACFOAABkTgAAZU4AAKlOAADxTgAAOE8AAIFPAADLTwAADFAA AFRQAAB5UAAAelAAAHtQAAB8UAAAfVAAAH5QAADHUAAAyVAAABJRAAATUQAAFFEAAEtRAABMUQAA j1EAALJRAACzUQAA/FEAAENSAACLUgAAzFIAABRTAABbUwAAo1MAAOpTAAAzVAAAdFQAAL1UAADj VAAA5FQAAC5VAAB3VQAAtVUAAP9VAAAcVgAAHVYAAB5WAAAfVgAAIFYAACFWAAAiVgAAI1YAACRW AAAlVgAAJlYAACdWAAAoVgAAKVYAACpWAAArVgAALFYAAC1WAAAuVgAAL1YAADBWAAAxVgAAMlYA ADNWAAA0VgAANVYAADZWAAA3VgAAOFYAAIFWAACDVgAAzFYAAM1WAADOVgAA61YAAOxWAAAvVwAA dVcAALlXAAACWAAAR1gAAEhYAACXWAAA3FgAACFZAABqWQAAnFkAAJ1ZAADeWQAAH1oAAGZaAACv WgAA81oAADtbAACCWwAAqlsAAKtbAADyWwAALlwAAC9cAAAwXAAAMVwAADJcAAAzXAAANFwAADVc AAA2XAAAN1wAADhcAAA5XAAAOlwAADtcAAA8XAAAPVwAAD5cAAA/XAAAQFwAAEFcAABCXAAAQ1wA AERcAABFXAAARlwAAEdcAABIXAAAkVwAAJNcAADcXAAA3VwAAN5cAAD6XAAA+1wAAEVdAACMXQAA 010AABleAABgXgAApV4AAOxeAAAuXwAAd18AAL5fAAAHYAAAMmAAADNgAAB1YAAAvGAAAPxgAABF YQAAjWEAANNhAADUYQAAGmIAAGNiAACiYgAA52IAAC5jAABqYwAAhWMAAIZjAADNYwAA/WMAAP5j AAD/YwAAAGQAAAFkAAACZAAAA2QAAARkAAAFZAAABmQAAAdkAAAIZAAACWQAAApkAAALZAAADGQA AA1kAAAOZAAAD2QAABBkAABZZAAAW2QAAKRkAAClZAAApmQAAL5kAAC/ZAAAAGUAAAFlAAACZQAA A2UAAARlAAAFZQAABmUAAAdlAAAIZQAACWUAAAplAAALZQAADGUAAA1lAAAOZQAAD2UAABBlAAAR ZQAAEmUAABNlAAAUZQAAFWUAABZlAAAXZQAAGGUAABllAAAaZQAAG2UAABxlAAAdZQAAHmUAAB9l AAAgZQAAIWUAACJlAAAjZQAAJGUAACVlAAAmZQAAJ2UAAChlAAApZQAAKmUAACtlAAAsZQAALWUA AC5lAAAvZQAAMGUAAHllAAB7ZQAAxGUAAMVlAADGZQAA4WUAAOJlAAApZgAAcWYAAHJmAAC0ZgAA 9mYAAA5nAAAPZwAAT2cAAJFnAACSZwAA2mcAABtoAAA5aAAAOmgAAINoAAC6aAAAu2gAAP1oAABE aQAARWkAAI5pAAC5aQAAumkAAO5pAADvaQAAL2oAAEhqAABJagAAjGoAANFqAAAGawAAB2sAAE5r AABdawAAXmsAAKNrAADgawAA4WsAACNsAABYbAAAWWwAAJtsAAC0bAAAtWwAAPtsAAAbbQAAHG0A AB1tAAAebQAAZ20AAGltAACybQAAs20AALRtAAD0bQAAGW4AABpuAABYbgAAoW4AAKJuAADlbgAA /m4AAP9uAAAAbwAAAW8AAAJvAAADbwAABG8AAAVvAAAGbwAAB28AAAhvAAAJbwAACm8AAAtvAAAM bwAADW8AAA5vAAAPbwAAEG8AABFvAAASbwAAE28AABRvAAAVbwAAFm8AABdvAAAYbwAAGW8AABpv AAAbbwAAHG8AAB1vAAAebwAAH28AACBvAAAhbwAAIm8AACNvAAAkbwAAJW8AACZvAAAnbwAAKG8A AClvAABybwAAdG8AAL1vAAC+bwAAv28AAMxvAADNbwAAFXAAAFtwAACkcAAA63AAAOxwAADtcAAA 7nAAAO9wAADwcAAA8XAAAPJwAADzcAAA9HAAAPVwAAD2cAAA93AAAPhwAAD5cAAA+nAAAPtwAAD8 cAAA/XAAAP5wAAD/cAAAAHEAAAFxAAACcQAAA3EAAARxAAAFcQAABnEAAAdxAAAIcQAACXEAAApx AAALcQAADHEAAA1xAAAOcQAAD3EAABBxAAARcQAAEnEAABNxAAAUcQAAFXEAABZxAAAXcQAAGHEA AGFxAABjcQAArHEAAK1xAACucQAAwXEAAMJxAADXcQAA4HEAAOFxAAD9cQAAInIAACNyAAAkcgAA NHIAAEpyAABLcgAAZXIAAIdyAACIcgAAiXIAAJtyAACtcgAArnIAAMlyAADzcgAA9HIAAPVyAAAK cwAAFXMAABZzAAAwcwAAT3MAAFBzAABRcwAAUnMAAFNzAABUcwAAVXMAAFZzAABXcwAAWHMAAFlz AABacwAAW3MAAFxzAABdcwAAXnMAAF9zAABgcwAAYXMAAGJzAABjcwAAZHMAAGVzAABmcwAAr3MA ALFzAAD6cwAA+3MAAPxzAAAVdAAAFnQAAD50AAA/dAAAhHQAAMl0AADldAAA5nQAAC91AAB4dQAA wXUAAAl2AABSdgAAmHYAAN52AADfdgAA4HYAAPZ2AAD3dgAAPHcAAIV3AADMdwAAEngAAFh4AACh eAAA5XgAAAR5AAAFeQAAR3kAAIt5AADUeQAAEHoAAFl6AAB1egAAdnoAAL16AAABewAAR3sAAIh7 AACeewAAn3sAAKB7AACvewAAsHsAAO97AAAafAAAG3wAABx8AAAdfAAAHnwAAB98AABofAAAanwA AKd8AAC5fAAA+nwAAN19AADIfgAAnn8AAHiAAADugAAAZIEAAKmBAADvgQAAAYIAAEaCAABqggAA OIMAAJuDAAA4hAAA8oQAAM+FAAABhgAAO4YAAHGGAACyhgAANIcAAB2IAACUiAAA+4gAADyJAABZ iQAA74kAAJWKAAC/igAAjIsAAKSMAAA/jQAAOY4AAGmOAAAJjwAAY48AAMiPAADxjwAA9I8AAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA gACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAIAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAAGYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACaQAAAETAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAABEwAAAAAAAAAIAAAACAAAAA AAAAAAAAAJhAAAARMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAAETAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmEAAABEwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAARMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYQAAAETAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAABEwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJhAAAARMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAAETAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmEAAABEwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAARMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYQAAAETAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAABEwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJhAAAARMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAAETAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mEAAABEwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAARMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY QAAAETAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAABEwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhA AAARMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAAETAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAA ABEwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAARMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAA ETAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAABEwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAR MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAAETAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAABEw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAARMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAAETAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAABEwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAARMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYQAAAETAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAABEwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJhAAAARMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAAETAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmEAAABEwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAARMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYQAAAETAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAABEwAAAAAAAA AIAAAACAAAAAAAAAAAAAAAoAAAAAAAAAAAAAAAAAAAAAAB0wMBMAAAAAAAcAAAAAxBIAAAcTAABN EwAAlRMAAOATAAA5FAAAOhQAAH8UAADGFAAADBUAAKcWAAC8FgAAvRYAAAYXAABNFwAAZhcAAGcX AACrFwAAvhgAAAYZAABGGQAAbhkAAG8ZAAC9GQAABRoAACkaAAAqGgAAdhoAAIUaAACGGgAA0hoA AOEaAADiGgAAJhsAAJccAACsHAAArRwAAPUcAABEHQAAbR0AALYdAAC4HQAAAR4AAAIeAAADHgAA UR4AAJgeAADpHgAA6h4AADgfAABpIQAAjiEAAI8hAAClIQAApiEAAPEhAAA+IgAAMiMAADMjAAB6 IwAAvyMAAA8kAACeJAAA3SQAAN4kAAD1JAAA9iQAAEQlAACOJQAABycAAAgnAABLJwAAlCcAAN0n AAAkKAAAJSgAAGooAACsKAAA9ygAABkpAACFKgAAzioAAA8rAABWKwAAnisAAHAuAACJLgAAii4A ANQuAAC4LwAA0i8AANMvAAAbMAAAujYAAAI3AABHNwAAhjcAAM43AAAUOAAAWjgAAKE4AAAzOQAA NDkAAH05AADAOQAACToAAE86AABPPAAAlzwAANs8AAAePQAAYz0AAABCAABGQgAAhkIAAMxCAACm SAAA70gAADhJAAB6SQAAn0kAAHZKAAC4SgAA+koAAD9LAAARTAAAWUwAAJ1MAACyTAAAs0wAAA1N AADOVgAA61YAAOxWAAAvVwAAdVcAALlXAAACWAAAR1gAAEhYAACXWAAA3FgAACFZAACdWQAA3lkA AB9aAABmWgAAr1oAANxcAADdXAAA3lwAAPpcAAD7XAAARV0AAIxdAADTXQAAanwAAKd8AAC5fAAA +nwAAN19AADIfgAAnn8AAHiAAADugAAAZIEAAKmBAADvgQAAAYIAAEaCAABqggAAOIMAAJuDAAA4 hAAA8oQAAM+FAAABhgAAO4YAAHGGAACyhgAANIcAAB2IAACUiAAA+4gAADyJAABZiQAA74kAAJWK AAC/igAAjIsAAKSMAAA/jQAAOY4AAGmOAAAJjwAAY48AAMiPAADxjwAA9I8AAOiQADAAAAAAAAAA AAEAAAAOAAAAAQAAAFBonAfokAAwAAAAAAAAAAABAAAADQAAAAAAAAAAAIAB6JAAMAAAAAAAAAAA AgAAAAsAAAAAAAAAAACAAeiQADAAAAAAAAAAAAEAAAADAAAAAAAAAAAAgAHokAAwAAAAAAAAAAAB AAAABAAAAAAAAAAAAIAH6JAAMAAAAAAAAAAAAQAAAAQAAAABAAAAjB2SB+iQADAAAAAAAAAAAAEA AAADAAAAAAAAAAAAgAHokAAwAAAAAAAAAAACAAAAAQAAAAAAAAAAAIAHAQAAAAAAAAAAAAAAAAAA AAAAAAAAWAAAAACAAeiQADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAgAfokAAwBQAAAAAAAAABAAAA BAAAAAYAAAAYHpIH6JAAMAUAAAAAAAAAAQAAAAMAAAAAAAAAAACAAeiQADAFAAAAAAAAAAIAAAAB AAAAAAAAAAAAgAEAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAH6JAAMAAAAAAAAAAAAQAAAAAA AAAAAAAAAACAB+iQADAPAAAAAAAAAAEAAAADAAAAAAAAAAAAgAHokAAwDwAAAAAAAAACAAAAAQAA AAAAAAAAAIABEAAAAAAAAAAAAAAAIAAAABAAAAAAAAAAAACAAeiQADASAAAAAAAAAAEAAAApAAAA EwAAABCWiwfokAAwEgAAAAAAAAABAAAAKAAAAAAAAAAAAIAB6JAAMBIAAAAAAAAAAgAAACYAAAAA AAAAAACAAeiQADASAAAAAAAAAAEAAAAZAAAAAAAAAAAAgAHokAAwEgAAAAAAAAABAAAAGgAAAAAA AAAAAIAB6JAAMBIAAAAAAAAAAQAAABkAAAAAAAAAAACAB+iQADASAAAAAAAAAAIAAAAXAAAAAAAA AAAAgAfokAAwEgAAAAAAAAABAAAAAwAAAAAAAAAAAIAB6JAAMBIAAAAAAAAAAQAAAAQAAAAAAAAA AACAAeiQADASAAAAAAAAAAEAAAAEAAAAAAAAAAAAgAHokAAwEgAAAAAAAAABAAAABAAAAAAAAAAA AIAB6JAAMBIAAAAAAAAAAQAAAAQAAAAAAAAAAACAAeiQADASAAAAAAAAAAEAAAAEAAAAAAAAAAAA gAHokAAwHwAAAAAAAAABAAAAXwAAAAAAAAAAAIAB6JAAMB8AAAAAAAAAAgAAAF0AAAAAAAAAAACA AeiQADASAAAAAAAAAAEAAAADAAAAAAAAAAAAgAfokAAwEgAAAAAAAAABAAAABAAAABMAAABcdZIH 6JAAMBIAAAAAAAAAAQAAAAMAAAAAAAAAAACAAeiQADASAAAAAAAAAAIAAAABAAAAAAAAAAAAgAE0 FAAAehQAAMEUAAAGFQAAoRYAAAAAAAAAAIgB6JAAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAACAAeiQ ADAXAAAAAAAAAAEAAAAEAAAAGAAAABiakgfokAAwFwAAAAAAAAABAAAAAwAAAAAAAAAAAIAB6JAA MBcAAAAAAAAAAgAAAAEAAAAAAAAAAACAAQQTAABMEwAAAAAAAAAAAAAAAAAAAAAAAAAAgAHokAAw AAAAAAAAAAABAAAAAAAAAAAAAAAAAIAB6JAAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAACAAeiQADAA AAAAAAAAAAEAAAAAAAAAAAAAAAAAgAHokAAwHgAAAAAAAAACAAAAAQAAAAAAAAAAAIABAAAAAAAA AAAAAAAAAAAzHwQAAAAAAAAAAACAB+iQADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAgAHokAAwAAAA AAAAAAABAAAAAAAAAAAAAAAAAIAH6JAAMCIAAAAAAAAAAQAAAAQAAAAjAAAAtD6SB+iQADAiAAAA AAAAAAEAAAADAAAAAAAAAAAAgAHokAAwIgAAAAAAAAACAAAAAQAAAAAAAAAAAIABAP8AAAD/AAAA AAAAAAAAADg2AAAAAAAAAACAAeiQADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAgAHokAAwAAAAAAAA AAABAAAAAAAAAAAAAAAAAIAB6JAAMDEAAAAAAAAAAQAAAAQAAAAAAAAAAACAB+iQADAxAAAAAAAA AAEAAAAEAAAAMgAAALR+iwfokAAwMQAAAAAAAAABAAAAAwAAAAAAAAAAAIAB6JAAMDEAAAAAAAAA AgAAAAEAAAAAAAAAAACAAQAAAAABAAAA+HsAAAAAAAAAAAAAAAAAAAAAgAHokAAwAAAAAAAAAAAB AAAAAAAAAAAAAAAAAIAH6JAAMDsAAAAAAAAAAQAAAAUAAAA8AAAAjJqLB+iQADA7AAAAAAAAAAEA AAAEAAAAAAAAAAAAgAHokAAwOwAAAAAAAAACAAAAAgAAAAAAAAAAAIABmAAAAAAAAAAAAAAAAIAA AACAAAAAAAAAAACAAeiQADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAgAHokAAwAAAAAAAAAAABAAAA AAAAAAAAAAAAAIAB6JAAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAACAB+iQADBCAAAAAAAAAAEAAAAF AAAAQwAAAFCbiwfokAAwQgAAAAAAAAABAAAABAAAAAAAAAAAAIAB6JAAMEIAAAAAAAAAAgAAAAIA AAAAAAAAAACAAZgAAAAAAAAAAAAAAACAAAAAgAAAAAAAAAAAgAHokAAwAAAAAAAAAAABAAAAAAAA AAAAAAAAAIAH6JAAMEcAAAAAAAAAAQAAAAUAAABIAAAAQEaLB+iQADBHAAAAAAAAAAEAAAAEAAAA AAAAAAAAgAHokAAwRwAAAAAAAAACAAAAAgAAAAAAAAAAAIABmAAAAAAAAAAAAAAAAIAAAACAAAAA AAAAAACAAeiQADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAgAHokAAwAAAAAAAAAAABAAAAAAAAAAAA AAAAAIAH6JAAME0AAAAAAAAAAQAAAAUAAABOAAAA6EaLB+iQADBNAAAAAAAAAAEAAAAEAAAAAAAA AAAAgAHokAAwTQAAAAAAAAACAAAAAgAAAAAAAAAAAIABmAAAAAAAAAAAAAAAAIAAAACAAAAAAAAA AACAAeiQADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAgAfokAAwUgAAAAAAAAABAAAABQAAAFMAAAB0 R4sH6JAAMFIAAAAAAAAAAQAAAAQAAAAAAAAAAACAAeiQADBSAAAAAAAAAAIAAAACAAAAAAAAAAAA gAGYAAAAAAAAAAAAAAAAgAAAAIAAAAAAAAAAAIAH6JAAMFYAAAAAAAAAAQAAAAUAAABXAAAAvFR9 B+iQADBWAAAAAAAAAAEAAAAEAAAAAAAAAAAAAAHokAAwVgAAAAAAAAACAAAAAgAAAAAAAAAAAIAB mAAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAACAAeiQADBaAAAAAAAAAAEAAAAFAAAAWwAAACxVfQfo kAAwWgAAAAAAAAABAAAABAAAAAAAAAAAAAAB6JAAMFoAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAZgA AAAAAAAAAAAAAACAAAAAgAAAAAAAAAAAgAfokAAwXgAAAAAAAAABAAAABQAAAF8AAACcVX0H6JAA MF4AAAAAAAAAAQAAAAQAAAAAAAAAAAAAAeiQADBeAAAAAAAAAAIAAAACAAAAAAAAAAAAAAGYAAAA AAAAAAAAAAAAgAAAAIAAAAAAAAAAAIAB6JAAMGIAAAAAAAAAAQAAAAUAAABjAAAADFZ9B+iQADBi AAAAAAAAAAEAAAAEAAAAAAAAAAAAAAHokAAwYgAAAAAAAAACAAAAAgAAAAAAAAAAAAABmAAAAAAA AAAAAAAAAIAAAACAAAAAAAAAAACAAeiQADBmAAAAAAAAAAIAAAACAAAAAAAAAAAAAAGYQAAAAAAA AAAAAAAAgAAAAIAAAAAAAAAAAIAH6JAAMGgAAAAAAAAAAQAAAAUAAABpAAAAtFZ9B+iQADBoAAAA AAAAAAEAAAAEAAAAAAAAAAAAAAHokAAwaAAAAAAAAAACAAAAAgAAAAAAAAAAAAABmAAAAAAAAAAA AAAAAIAAAACAAAAAAAAAAACAAeiQADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAgAfokAAwbQAAAAAA AAABAAAABQAAAG4AAABoUJEH6JAAMG0AAAAAAAAAAQAAAAQAAAAAAAAAAACAAeiQADBtAAAAAAAA AAIAAAACAAAAAAAAAAAAAAGYAAAAAAAAAAAAAAAAgAAAAIAAAAAAAAAAAIAH6JAAMHEAAAAAAAAA AQAAAAUAAAByAAAA2FCRB+iQADBxAAAAAAAAAAEAAAAEAAAAAAAAAAAAgAHokAAwcQAAAAAAAAAC AAAAAgAAAAAAAAAAAIABmAAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAACAAeiQADAAAAAAAAAAAAEA AAAAAAAAAAAAAAAAgAfokAAwdgAAAAAAAAABAAAABQAAAHcAAABkUZEH6JAAMHYAAAAAAAAAAQAA AAQAAAAAAAAAAACAAeiQADB2AAAAAAAAAAIAAAACAAAAAAAAAAAAgAGYAAAAAAAAAAAAAAAAgAAA AIAAAAAAAAAAAIAH6JAAMH0AAAAAAAAAAQAAAAUAAAB+AAAAKFKRB+iQADB9AAAAAAAAAAEAAAAE AAAAAAAAAAAAgAHokAAwfQAAAAAAAAACAAAAAgAAAAAAAAAAAIABmAAAAAAAAAAAAAAAAIAAAACA AAAAAAAAAACAAeiQADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAgAHokAAwAAAAAAAAAAABAAAAAAAA AAAAAAAAAIAH6JAAMIMAAAAAAAAAAQAAAAYAAACEAAAA0FKRB+iQADCDAAAAAAAAAAEAAAAFAAAA AAAAAAAAgAHokAAwgwAAAAAAAAABAAAABAAAAAAAAAAAAIAB6JAAMIMAAAAAAAAAAgAAAAIAAAAA AAAAAACAAZgAAAAAAAAAAAAAAACAAAAAgAAAAAAAAAAAAAfokAAwiAAAAAAAAAABAAAABAAAAAAA AAAAAIAB6JAAMIgAAAAAAAAAAgAAAAIAAAAAAAAAAACAAZgAAAAAAAAAAAAAAACAAAAAgAAAAAAA AAAAAAGYAAAAAAAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAAAAAAAAAAAIAAAACAAAAAAAAA AAAAAZgAAAAAAAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAAAAAAAAAAAAAgAAAAIAAAAAAAAAA AAAH6JAAMI8AAAAAAAAAAQAAAAUAAACQAAAAwJCRB+iQADCPAAAAAAAAAAEAAAAEAAAAAAAAAAAA gAHokAAwjwAAAAAAAAACAAAAAgAAAAAAAAAAAIABmAAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAAA AZgAAAAAAAAAAAAAAACAAAAAgAAAAAAAAAAAAAfokAAwlAAAAAAAAAABAAAABQAAAJUAAABMkZEH 6JAAMJQAAAAAAAAAAQAAAAQAAAAAAAAAAACAAeiQADCUAAAAAAAAAAIAAAACAAAAAAAAAAAAgAGY AAAAAAAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgA AAAAAAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAAAAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAA AAAAAAAAAAAAAIAAAACAAAAAAAAAAAAAB5gAAAAAAAAAAAAAAACAAAAAgAAAAAAAAAAAAAfo0AAw AAAAAAAAAAABAAAAAwAAAAAAAAAAAIAH6NAAMAAAAAAAAAAAAQAAAAMAAAAAAAAAAACAB+jQADAA AAAAAAAAAAEAAAADAAAAAAAAAAAAgAfo0AAwAAAAAAAAAAACAAAAAQAAAAAAAAAAAIAB0EIAAIIl AAD/////AAAAAAAAAAAAAAAAAAAAAdBCAACCJQAA/////wAAAAAAAAAAAAAAAAAAAAHo0AAwAAAA AAAAAAABAAAAAAAAAAAAAAAAAIAB6NAAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAACAAejQADAAAAAA AAAAAAEAAAAAAAAAAAAAAAAAgAHo0AAwAAAAAAAAAAABAAAAAAAAAAAAAAAAAIAH6NAAMAAAAAAA AAAAAQAAAAAAAAAAAAAAAACAAejQADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAgAfo0AAwAAAAAAAA AAABAAAAAAAAAAAAAAAAAIAH6NAAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAACAAejQADAAAAAAAAAA AAEAAAAAAAAAAAAAAAAAgAHo0AAwAAAAAAAAAAABAAAAAAAAAAAAAAAAAIAB6NAAMAAAAAAAAAAA AQAAAAAAAAAAAAAAAACAAejQADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAgAHo0AAwAAAAAAAAAAAB AAAAAAAAAAAAAAAAAIAB6NAAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAACAAejQADAAAAAAAAAAAAEA AAAAAAAAAAAAAAAAgAHo0AAwAAAAAAAAAAABAAAAAAAAAAAAAAAAAIAB6NAAMAAAAAAAAAAAAQAA AAAAAAAAAAAAAACAAejQADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAgAHo0AAwAAAAAAAAAAABAAAA AAAAAAAAAAAAAIAB6NAAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAACAAejQADAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAgAHo0AAwAAAAAAAAAAABAAAAAAAAAAAAAAAAAIAB6NAAMAAAAAAAAAAAAQAAAAAA AAAAAAAAAACAAejQADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAgAHo0AAwAAAAAAAAAAABAAAAAAAA AAAAAAAAAIAB6NAAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAACAAejQADAAAAAAAAAAAAEAAAAAAAAA AAAAAAAAgAHo0AAwAAAAAAAAAAABAAAAAAAAAAAAAAAAAIAB6NAAMAAAAAAAAAAAAQAAAAAAAAAA AAAAAACAAejQADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAgAHo0AAwAAAAAAAAAAABAAAAAAAAAAAA AAAAAIAB6NAAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAACAAejQADAAAAAAAAAAAAEAAAAAAAAAAAAA AAAAgAfo0AAwAAAAAAAAAAABAAAAAAAAAAAAAAAAAIAB6NAAMAAAAAAAAAAAAQAAAAAAAAAAAAAA AACABwgAAAAAAAAAAAAAAAAAAAAAAB0wMBMAAAAAAAcABgAADyUAACQ0AAA3XwAAco4AAPOXAABM AAAAVgAAAFwAAABmAAAAdwAAAAAGAABfDQAACRAAAHQWAABSGAAApx0AALweAABVIwAAfCcAANon AAClKQAA3S8AAA8zAADuOAAAgD0AAMNDAABwSQAAkk0AAJ9RAABUWAAA5FwAADReAAA7YwAARmQA ANRpAAAQbAAAFW0AAHttAADucQAAs3UAABJ3AADMdwAAA3kAANd5AABTewAAhHwAAHWCAACpiQAA Y5cAAPOXAABNAAAATwAAAFAAAABRAAAAUgAAAFMAAABUAAAAVQAAAFcAAABYAAAAWQAAAFoAAABb AAAAXQAAAF4AAABfAAAAYAAAAGEAAABiAAAAYwAAAGQAAABlAAAAZwAAAGgAAABpAAAAagAAAGsA AABsAAAAbQAAAG4AAABvAAAAcAAAAHEAAAByAAAAcwAAAHQAAAB1AAAAdgAAAHgAAAAABgAA8pcA AE4AAAD//wsAAAAGAAZaUwAQAAEAbNr8CQYAB1pTABAAAQCsr/wJBgAIWlMAEAABAOy0/AkGAAla UwARAAEArMX8CQYAClpTABAAAQBsqPwJBgALWlMAEAABACzY/AkGAAxaUwAQAAEALLX8CQYADVpT ABEAAQAs0/wJBgAOWlMAEQABAOzc/AkGAA9aUwAIAAIArLj8CQYAEFpTAAgAAgBsxPwJ+mUAAJFm AAAUagAAFGoAAFxqAABCbgAAN3IAADdyAAA/cgAA+HIAAMN7AAD0jwAAAAAAAAEAAQAAAAEAAgAA AAIAAwAAAAIABAAAAAEABQAAAAEABwAAAAIABgAAAAIACAAAAAIACQAAAAEACgAAAAEAA2YAAJNm AAAcagAAHGoAAF5qAABIbgAAPnIAAElyAABJcgAAA3MAAM17AAD0jwAAAAAAAAEAAAACAAAAAwAA AAQAAAAFAAAABwABAAYAAAAIAAAACQAAAAoAAAAFAAAAPQAAAAMAAAAqgHVybjpzY2hlbWFzLW1p Y3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncwmAUGxhY2VUeXBlAIA9AAAABAAAACqAdXJuOnNj aGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzCYBQbGFjZU5hbWUAgDgAAAAIAAAA KoB1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MEgENpdHkAgDkAAAAL AAAAKoB1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MFgHBsYWNlAIA+ AAAAAgAAACqAdXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzCoBQZXJz b25OYW1lAIAMAAABdOAfEgAAAAALAAAAAAALAAAAAAALAAAAAAAIAAAAAAALAAAAAAALAAAAAAAL AAAAAAAEAAAAAAADAAAAAAACAAAAAAACAAAAAAD//ykACgAAAAABLqzuCv////8AAAABRazuCv// //8AAAABFY7uCv////8AAAABOo7uCv////8AAAABMqTuCv////8AAAABe47uCv////8AAAAB8Y7u Cv////8AAAABTpDuCv////8AAAABwI/uCv////8AAAAB6JDuCv////8AAAABCKbuCv////8AAAAB UqzuCv////8AAAABkqbuCv////8AAAABaabuCv////8AAAAByKbuCv////8AAAABUqfuCv////8A AAABvafuCv////8AAAABCqjuCv////8AAAABYKjuCv////8AAAABmKjuCv////8AAAABrqjuCv// //8AAAABxKjuCv////8AAAABFanuCv////8AAAABganuCv////8AAAAB1anuCv////8AAAABParu Cv////8AAAABearuCv////8AAAAB2KruCv////8AAAABDKvuCv////8AAAABMqvuCv////8AAAAB havuCv////8AAAAB1avuCv////8AAAAB6KvuCv////8AAAABsKzuCv////8AAAABVK3uCv////8A AAAB763uCv////8AAAABSK7uCv////8AAAABy67uCv////8AAAABIa/uCv////8AAAABOK/uCv// //8AAAABha/uCv////8WCAAAUBQAAJEUAACaFAAA7BQAAPIUAABTFwAAnRkAAO4cAAAFIgAAGSwA AH8sAADPLgAA3y4AAOwvAABQMQAAvTYAAOE3AACYOAAAvTkAAIQ6AABhOwAAOzwAAG8+AAAXPwAA E0EAAE5CAABgRQAAXkcAAKlIAAAySwAAyEwAAP5MAACfTwAAMVIAAP1UAACsVQAAPlsAAPVbAACZ XgAA+WAAAGx8AAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsA AAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAA ABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAA KAAAAHsIAABUFAAAlRQAAOoUAADtFAAARRUAAFoXAACkGQAAFh0AAAwiAAAkLAAAgywAANIuAAA5 LwAAgDAAALsxAAAiNwAAHzgAAN44AAD9OQAA2ToAAIE7AAB/PAAAwD4AACg/AABRQQAAV0IAAIpF AAB+RwAA1UgAAEdLAAD9TAAAAk0AAK9PAABLUgAAEFUAAMdVAACnWwAAHFwAALBeAACXYQAAbHwA AAAAAAACAAAASwAAANgAAADcAAAAEwEAACYBAABkAQAAbwEAAKkBAAC4AQAAngIAAK8CAACDBQAA jAUAAHMHAAB7BwAA2AcAAOAHAAAZCwAAKgsAAIYMAACXDAAAqg8AALIPAAAPEAAAFxAAAGUQAABs EAAAKhIAADQSAACxFAAAtxQAAJgVAACjFQAAuxUAANUVAAAgFgAAKBYAAG0dAAB1HQAA0h0AANod AADqHwAA8h8AAE8gAABXIAAAsyEAALkhAAC6IgAAuyIAANYkAADbJAAABCUAAAolAAAtJgAALiYA ANEmAADXJgAAjigAAJ8oAAAfKQAAJykAAIQpAACMKQAA9ykAAAgqAAAcKgAALSoAAEEqAABHKgAA bCoAAH0qAABILAAAWSwAAAUuAAALLgAABi8AAAwvAAA0MAAAPjAAAG0wAABzMAAAtDAAALwwAAD+ MAAABzEAAKUyAACtMgAACjMAABIzAABXNwAAYzcAAMg4AADUOAAAJzkAADE5AABROQAAWTkAAM06 AADZOgAABjsAAAw7AABSPAAAYzwAAKc9AACvPQAADD4AABQ+AAC8PwAAwj8AACtBAAA8QQAAbkMA AHBDAAAvRQAAQEUAAO1FAAD+RQAABkYAAA5GAABrRgAAc0YAAOBGAADmRgAABUgAAAtIAACrTQAA rE0AAHpOAAB7TgAAEU8AABJPAAB+UAAAhlAAAONQAADrUAAAq1EAAK9RAADRUQAA1VEAAO9VAAD5 VQAAOFYAAEBWAACdVgAApVYAABdXAAAYVwAASFwAAFBcAACtXAAAtVwAABddAAAdXQAAtl8AALxf AAAfYAAAMGAAAJVgAACjYAAAcmEAAINhAADqYwAA+2MAABBkAAAYZAAAdWQAAH1kAAAwZQAAOGUA AJVlAACdZQAA3WYAAPRmAABjaAAAaWgAAIxoAACdaAAAAWoAAAdqAADragAA+moAALRrAADFawAA HGwAACJsAAAEbQAAG20AAB5tAAA4bQAAg20AAIttAADsbQAA820AAHduAACSbgAA7m4AAP5uAAAp bwAAQ28AAI5vAACWbwAAInAAAC5wAABRcAAAVnAAAF5wAABncAAAgXAAAIlwAACOcAAAlnAAAMBw AADGcAAA4nAAAOlwAAAYcQAAIHEAAH1xAACFcQAAznEAANZxAAAvcgAAM3IAAIxyAACbcgAAnnIA AK1yAACxcgAAyXIAANNyAADycgAAZnMAAG5zAADLcwAA03MAAB98AAAnfAAAanwAACqFAAA2hQAA bowAAHSMAADFjgAAy44AAPSPAAAHAAUABwAcAAcABQAHAAUABwAFAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAFAAcABQAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAUABwAF AAcAHAAHABwABwAcAAcABQAHAAUABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAFAAcABQAHAAUABwAcAAcAHAAHABwABwAcAAcABwAcAAcAHAAHABwABwAA AAAAAgAAAEoAAAATAQAAJQEAAGQBAABuAQAAqQEAALcBAADxAgAAEQMAAHEDAAB7AwAAtgMAALoD AAD8AwAAAQQAAIYEAAC7BAAAygQAAM8EAAANBQAAFAUAAGIFAABlBQAAqgUAAK4FAADsBQAA9AUA AFMHAABWBwAAXwgAAGEIAACpCAAArwgAAOkIAADyCAAA7AkAAPgJAAA1CgAAQgoAAH4KAACLCgAA EAsAABgLAABdCwAAZQsAAKYLAACwCwAA7wsAAPkLAAA4DAAAQgwAAH0MAACFDAAAygwAANQMAAAT DQAAHA0AAFwNAABnDQAAmhAAAKEQAAAJEQAADBEAACYRAAAzEQAAaREAAHERAACtEQAAuREAACoS AAA0EgAAcxIAAHYSAAC5EgAAwRIAAAoTAAAQEwAAUBMAAFUTAACYEwAAnBMAAOMTAADlEwAALBQA ADcUAACCFAAAixQAAMkUAADRFAAADxUAABkVAABUFQAAXBUAAJgVAACiFQAAuxUAANUVAACqFgAA sxYAANcWAADbFgAADBcAABYXAABTFwAAWRcAAIIXAACGFwAAsRcAALoXAAD2FwAA/xcAADsYAAA9 GAAAfRgAAIQYAADIGAAA0hgAAAwZAAAPGQAATBkAAFoZAACWGQAAmhkAAMkZAADQGQAACxoAABIa AAA3GgAAPxoAAHwaAAB/GgAAlBoAAJwaAADYGgAA2xoAACwbAAA0GwAAYBsAAG8bAACkGwAAqBsA AN8bAADsGwAAIBwAACQcAABaHAAAZxwAAJ0cAACiHAAAtxwAAMQcAAAPHQAAFR0AAEodAABUHQAA Gh4AACceAABXHgAAXx4AAJ4eAACkHgAAAB8AAA0fAAA+HwAARh8AAIIfAACIHwAA4CAAAOYgAAAj IQAALSEAAGwhAABuIQAAkiEAAJ4hAAD0IQAA9yEAAEEiAABOIgAAgyIAAIkiAADIIgAA0CIAAA8j AAAVIwAAfSMAAH8jAADCIwAAyCMAABIkAAAWJAAAWSQAAGAkAAChJAAAoyQAAOEkAADuJAAAkSUA AJglAADYJQAA3CUAACAmAAAmJgAAZSYAAGomAACuJgAAuCYAAPYmAAD4JgAATicAAFYnAACXJwAA pScAAOAnAADiJwAAAigAAA8oAABtKAAAdigAAK8oAAC4KAAA+igAAP4oAAAQKgAAGCoAAFMqAABd KgAAYyoAAGsqAADRKgAA0yoAABIrAAAZKwAAWSsAAF4rAAChKwAAqCsAAOorAADrKwAAcCwAAHos AAC1LAAAviwAAP4sAAACLQAARi0AAEgtAACGLQAAjy0AAOQtAADvLQAAKi4AADIuAABzLgAAey4A ANcuAADZLgAAHi8AACYvAABnLwAAaS8AAK0vAAC1LwAAvS8AAMUvAAAeMAAAJDAAAGUwAABpMAAA rTAAALMwAADxMAAA/TAAACAxAAA0MQAAezEAAIExAADBMQAAxjEAAAYyAAANMgAATzIAAFUyAACP MgAAmDIAACY0AAAuNAAATTQAAFM0AACkNAAArTQAAC81AAAzNQAAVTUAAFw1AABdNQAAfTUAAIY1 AACQNQAA7DUAAPA1AAAyNgAANTYAAHg2AAB+NgAAvTYAAMg2AAAFNwAAGTcAAEo3AABWNwAAiTcA AJQ3AABdOAAAYzgAAKQ4AACzOAAA7jgAAPc4AACAOQAAgjkAAMM5AADJOQAADDoAAA46AABTOgAA VjoAAJc6AACbOgAAIDsAACs7AABiOwAAajsAAKc7AACxOwAADTwAABM8AABSPAAAYzwAAJo8AACh PAAA3jwAAOU8AAAhPQAAJz0AAEA+AABIPgAAiT4AAIw+AADLPgAA0z4AABI/AAAWPwAAWD8AAGE/ AAChPwAApT8AAOk/AADrPwAALkAAADZAAAB5QAAAg0AAAOVAAADoQAAAK0EAADxBAABzQQAAekEA ALpBAADIQQAAA0IAAAZCAABJQgAATUIAAIlCAACVQgAAz0IAANZCAAATQwAAHUMAAFRDAABeQwAA mEMAAKVDAAD1RAAA/EQAAP1EAAAeRQAAJkUAAC5FAACVRQAAm0UAANxFAADjRQAAoUYAAKtGAAAG RwAAEEcAAElHAABTRwAAjkcAAJNHAADVRwAA3UcAABZIAAAeSAAAXkgAAGBIAAB3SAAAgEgAAPJI AAD1SAAAO0kAAElJAAB9SQAAhEkAAOpJAADySQAAM0oAADZKAAB5SgAAfUoAALtKAADDSgAA/UoA AARLAABCSwAAR0sAAMxLAADUSwAAFEwAABhMAABcTAAAZUwAAKBMAACmTAAAEE0AABRNAABUTQAA XU0AAJxNAACfTQAA4E0AAOZNAACsTgAAtE4AAPROAAD4TgAAO08AAEZPAACETwAAjE8AAM5PAADV TwAAD1AAABhQAABXUAAAWVAAABlRAAAkUQAAklEAAJ9RAAD/UQAABVIAAEZSAABLUgAAjlIAAJRS AADPUgAA21IAABdTAAAeUwAAXlMAAGVTAACmUwAAs1MAAO1TAADwUwAANlQAADhUAAB3VAAAf1QA AMBUAADCVAAAMVUAADpVAAB6VQAAglUAALhVAADHVQAAAlYAAApWAAAyVwAAN1cAAHhXAACCVwAA vFcAAMJXAAAFWAAADFgAAJpYAACfWAAA31gAAOhYAABtWQAAcVkAAOFZAADqWQAAIloAACpaAACs WgAArloAALJaAAC1WgAA9loAAP9aAAA+WwAAQFsAAIVbAACHWwAA9VsAAPlbAABIXQAASl0AAI9d AACYXQAA1l0AAN9dAAAcXgAAIV4AAGNeAABoXgAAqF4AALBeAADvXgAA9F4AADFfAAA5XwAAel8A AHxfAADBXwAAxF8AAApgAAANYAAA/2AAAAhhAABIYQAASmEAAJBhAACXYQAAHWIAACJiAABmYgAA bWIAAKViAACvYgAA6mIAAPJiAAAxYwAAOmMAAG1jAAB6YwAA0GMAANNjAACXaQAAuGkAADhqAABH agAAT2oAAFpqAAClagAAsGoAANpqAAAFawAADWsAABdrAABkawAAbWsAAKxrAADfawAA52sAAO9r AABfbAAAZmwAAKRsAACzbAAAu2wAAMNsAAAEbQAAGm0AAB5tAAA4bQAAum0AAMNtAAD9bQAAGG4A ACBuAAAqbgAAYW4AAKBuAACobgAAsG4AAO5uAAD9bgAAKW8AAENvAAAYcAAAIXAAAIxyAACacgAA nnIAAKxyAACxcgAAyHIAACd0AAAqdAAAh3QAAJB0AADMdAAA0nQAAJt2AADddgAAiHcAAI93AADP dwAA03cAABV4AAAaeAAAW3gAAF94AACkeAAApngAAOh4AADteAAASnkAAFR5AACOeQAAlXkAANd5 AADbeQAAE3oAACB6AADAegAAynoAAAR7AAAKewAASnsAAE57AADyewAAGXwAAGp8AAC+fAAAwHwA AEWGAABQhgAA9I8AAAcABQAHAAUABwAFAAcABQAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAFAAcABQAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHAAUA BwAFAAcAMwAHADMABwAzAAcAMwAHADMABwAFAAcABQAHADMABwAFAAcABQAHAAUABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAHADMABwAzAAcAAAAAAMYUAADyFAAATRcAAGoXAAAbLwAAPS8AAChBAABVQQAAekkA AJ5JAACgSQAAo0kAAENSAABPUgAApV4AALReAADyewAAaXwAAGp8AACnfAAAuXwAALB9AADcfQAA zIAAAO6AAACHgQAAqYEAAO+BAAABggAAFoQAADeEAAD0jwAABwAFAAcABQAHAAUABwAFAAcABQAH AAUABwAFAAcABQAHAAUABwAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAAAAABqfAAA9I8AAAcA BwAAAAAAlFgAAO97AAD0jwAAAAAAAHEOJgAAAAAA/0ABgAEAaXwAAGl8AABAKR8SAQABAGl8AAAA AAAAaXwAAAAAAAACEAAAAAAAAADzjwAAQAAAEABAAAD//wIAAAAHAFUAbgBrAG4AbwB3AG4ACwBE AGEAdgBlACAAVABoAGEAbABlAHIA//8CAAgAAAAAAAAAAAAAAAAAAAAAAAAAAQD//wIAAAAAAAAA //8AAAIA//8AAAAA//8AAAIA//8AAAAABgAAAFMWkAEAEAICBgMFBAUCAwTvOgDgQXgAwAkAAAAA AAAA/wEAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAAFQAaQBtAGUAcwAAAFsW kAECBwUFAQIBBwYCBQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAAEIAbwBv AGsAcwBoAGUAbABmACAAUwB5AG0AYgBvAGwAIAAzAAAARyaQAQAGAgsGBAICAgICBP86AOBDeADA CQAAAAAAAAD/AQAAAAAAAEEAcgBpAGEAbAAAAEgAZQBsAHYAZQB0AGkAYwBhAAAAPxaQAYEHAgMG AAABAQEBAa8CALD7fNdpMAAAAAAAAACfAAgAAAAAAEIAYQB0AGEAbgBnAAAAuQDZAMUAwQAAAE81 kAEADAIHAwkCAgUCBAT/OgDgQ3gAwAkAAAAAAAAA/wEAAAAAAABDAG8AdQByAGkAZQByACAATgBl AHcAAABDAG8AdQByAGkAZQByAAAATSaQAQAHAgsGBAMFBAQCBP86AOFbYADAKQAAAAAAAAD/AQEA AAAAAFQAYQBoAG8AbQBhAAAAQQByAGkAYQBsACAAQgBsAGEAYwBrAAAAIgAEAHGIiBgA8NACAABo AQAAAAC4qrtmV6u7ZgAAAAAFAIoAAACREgAA2WkAAAEAPwAAAAQAAxDhAAAAkRIAANlpAAABAD8A AADhAAAAAAAAACEDAPAQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACcFoAW0ALQAgYEyNAAA EAAZAGQAAAAZAAAAK3wAACt8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAATKDEQDwEAAIAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABLWAAAAAAo8P8PAQABPwAAAAAAAMkTAAD///9/////fwAAAAD///9///// f////38AAAAAAAAAADIAAAAAAAAAAAAAAAAAAQAAAP//EgAAAAAAAAAAAAAAAAAAAAsARABhAHYA ZQAgAFQAaABhAGwAZQByAAsARABhAHYAZQAgAFQAaABhAGwAZQByAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABgACAAAA AAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAABwAQAAEQAAAAEAAACQAAAAAgAA AJgAAAADAAAApAAAAAQAAACwAAAABQAAAMQAAAAGAAAA0AAAAAcAAADcAAAACAAAAOwAAAAJAAAA AAEAABIAAAAMAQAACgAAACwBAAAMAAAAOAEAAA0AAABEAQAADgAAAFABAAAPAAAAWAEAABAAAABg AQAAEwAAAGgBAAACAAAA5AQAAB4AAAAEAAAAAAAAAB4AAAAEAAAAAAAAAB4AAAAMAAAARGF2ZSBU aGFsZXIAHgAAAAQAAAAAAAAAHgAAAAQAAAAAAAAAHgAAAAgAAABOb3JtYWwAAB4AAAAMAAAARGF2 ZSBUaGFsZXIAHgAAAAQAAAA1AAAAHgAAABgAAABNaWNyb3NvZnQgT2ZmaWNlIFdvcmQAAABAAAAA ALxDRxMAAABAAAAAAKANKHAsyAFAAAAAANIusYQsyAEDAAAAAQAAAAMAAACREgAAAwAAANlpAAAD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAYAAgAAAAAAAAAAAAAA AAAAAAAAAQAAAALVzdWcLhsQk5cIACss+a4wAAAA/AAAAAwAAAABAAAAaAAAAA8AAABwAAAABQAA AJAAAAAGAAAAmAAAABEAAACgAAAAFwAAAKgAAAALAAAAsAAAABAAAAC4AAAAEwAAAMAAAAAWAAAA yAAAAA0AAADQAAAADAAAAN0AAAACAAAA5AQAAB4AAAAYAAAATWljcm9zb2Z0IENvcnBvcmF0aW9u AAAAAwAAAOEAAAADAAAAPwAAAAMAAAArfAAAAwAAAA8nCwALAAAAAAAAAAsAAAAAAAAACwAAAAAA AAALAAAAAAAAAB4QAAABAAAAAQAAAAAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcA AAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAA ABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAA JAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAAADEAAAAy AAAAMwAAADQAAAA1AAAANgAAADcAAAA4AAAAOQAAADoAAAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAA AABBAAAAQgAAAEMAAABEAAAARQAAAEYAAABHAAAASAAAAEkAAABKAAAASwAAAEwAAABNAAAATgAA AE8AAABQAAAAUQAAAFIAAABTAAAAVAAAAFUAAABWAAAAVwAAAFgAAABZAAAAWgAAAFsAAABcAAAA XQAAAF4AAABfAAAAYAAAAGEAAABiAAAAYwAAAGQAAABlAAAAZgAAAGcAAABoAAAAaQAAAGoAAABr AAAAbAAAAG0AAABuAAAAbwAAAHAAAABxAAAAcgAAAHMAAAB0AAAAdQAAAHYAAAB3AAAAeAAAAHkA AAD+////ewAAAHwAAAB9AAAAfgAAAH8AAACAAAAAgQAAAP7///+DAAAAhAAAAIUAAACGAAAAhwAA AIgAAACJAAAAigAAAIsAAACMAAAAjQAAAI4AAACPAAAAkAAAAJEAAACSAAAAkwAAAJQAAACVAAAA lgAAAJcAAACYAAAAmQAAAJoAAACbAAAAnAAAAJ0AAACeAAAAnwAAAKAAAAChAAAAogAAAKMAAACk AAAApQAAAKYAAACnAAAAqAAAAKkAAACqAAAAqwAAAKwAAACtAAAArgAAAK8AAACwAAAAsQAAALIA AACzAAAAtAAAALUAAAC2AAAAtwAAALgAAAC5AAAAugAAALsAAAC8AAAAvQAAAL4AAAC/AAAAwAAA AMEAAADCAAAAwwAAAMQAAADFAAAAxgAAAMcAAADIAAAAyQAAAMoAAADLAAAAzAAAAM0AAADOAAAA zwAAANAAAADRAAAA0gAAANMAAADUAAAA1QAAANYAAADXAAAA2AAAANkAAADaAAAA2wAAANwAAADd AAAA3gAAAN8AAADgAAAA4QAAAOIAAADjAAAA5AAAAOUAAADmAAAA5wAAAOgAAADpAAAA6gAAAOsA AADsAAAA/v///+4AAADvAAAA8AAAAPEAAADyAAAA8wAAAPQAAAD+////9gAAAPcAAAD4AAAA+QAA APoAAAD7AAAA/AAAAP7////9/////f////3///8BAQAA/v////7////+//////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAA AADAAAAAAAAARgAAAAAAAAAAAAAAAMClA7yELMgBAwEAAIAAAAAAAAAARABhAHQAYQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAgH///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB6AAAAABAAAAAAAAAx AFQAYQBiAGwAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAADgACAQEAAAAGAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AIIAAADw1AAAAAAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIBAgAAAAUAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAC7yAAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEA dABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgH///////////////8AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADtAAAAABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4A dABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAQQAAAD/ /////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPUAAAAAEAAAAAAAAAEA QwBvAG0AcABPAGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAASAAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAHEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAA/v////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////wEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYfAAAA TWljcm9zb2Z0IE9mZmljZSBXb3JkIERvY3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9j dW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA --Apple-Mail-5-519609794 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed -- Thomas Clausen thomas@thomasclausen.org http://www.ThomasClausen.org/ http://hipercom.thomasclausen.org/ --Apple-Mail-5-519609794 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 --Apple-Mail-5-519609794-- From autoconf-bounces@ietf.org Thu Nov 22 05:37:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv9RG-00066e-UE; Thu, 22 Nov 2007 05:37:42 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Iv9RF-00066T-Vn for autoconf-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 05:37:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv9RF-00066L-JT for autoconf@ietf.org; Thu, 22 Nov 2007 05:37:41 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iv9RF-0000AY-0x for autoconf@ietf.org; Thu, 22 Nov 2007 05:37:41 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-153.messagelabs.com!1195727859!10517167!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 7242 invoked from network); 22 Nov 2007 10:37:39 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-14.tower-153.messagelabs.com with SMTP; 22 Nov 2007 10:37:39 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id lAMAbdM0001904; Thu, 22 Nov 2007 03:37:39 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id lAMAbcDq011795; Thu, 22 Nov 2007 04:37:38 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id lAMAbYwk011751; Thu, 22 Nov 2007 04:37:36 -0600 (CST) Message-ID: <47455BEC.2060800@gmail.com> Date: Thu, 22 Nov 2007 11:37:32 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Shubhranshu Subject: Re: [Autoconf] Request to publish draft-ietf-autoconf-manetarch-07.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071121-0, 21/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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: > Alex, > > ----- Original Message ----- From: "Alexandru Petrescu" > To: "Shubhranshu" > >> Shubhranshu wrote: [...] >>> 4. Do you have any specific concerns/issues with this document >>> that you believe the ADs and/or IESG should be aware of? For >>> example, perhaps you are uncomfortable with certain parts of the >>> document, or have concerns whether there really is a need for it. >>> In any event, if your issues have been discussed in the WG and >>> the WG has indicated it that it still wishes to advance the >>> document, detail those concerns in the write-up. >>> >>> NO. >> No? >> >> I've just raised yesterday an issue about multicast interpretation >> confusion between manetarch and problem statement documents. HAs >> that been solved already? A decision made? The issue is here, and >> the following thread keeps the subject: >> http://www1.ietf.org/mail-archive/web/autoconf/current/msg00771.html >> >> >> >> Was there a decision made with respect to this issue? It seems >> like the confusing issue around multicast that I've raised is >> completely ignored?? >> > > If the community thinks there are issues that really needs to be > addressed before moving this document forward then I'd be willing to > ask for postponement. > > Why do you think there is a WGLC in the process ? I remember you > saying at the WG mailing list, about a couple of weeks after WGLC for > this ID ended, that you have some comments on section 5.1 but > "Otherwise - yes, I'm fine with the document." !! Shubhranshu: yes, until I stumbled across this inconsistency with respect to multicast in the problem-statement document. > According to the ID authors those comments were minor in nature and > is addressed in the later version. I am not sure if you or anyone > would not have any confusion or new thoughts even after, say, one > year of further discussions. I will not stir this any further. 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 Nov 22 06:20:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvA6Z-0004OS-R4; Thu, 22 Nov 2007 06:20:23 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IvA6X-0004Cp-Tx for autoconf-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 06:20:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvA6W-0003xr-IK for autoconf@ietf.org; Thu, 22 Nov 2007 06:20:20 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvA6T-00025T-Vq for autoconf@ietf.org; Thu, 22 Nov 2007 06:20:18 -0500 Received: from epmmp2 (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 <0JRW00K6WNFH5W@mailout3.samsung.com> for autoconf@ietf.org; Thu, 22 Nov 2007 20:18:54 +0900 (KST) Received: from Shubhranshu ([107.108.209.125]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0JRW007B4NFGRF@mmp2.samsung.com> for autoconf@ietf.org; Thu, 22 Nov 2007 20:18:53 +0900 (KST) Date: Thu, 22 Nov 2007 16:50:29 +0530 From: Shubhranshu Subject: Re: [Autoconf] Request to publish draft-ietf-autoconf-manetarch-07.txt To: Alexandru Petrescu Message-id: <01b401c82cf9$b13c7f70$7dd16c6b@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=iso-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <47455BEC.2060800@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Alex, ----- Original Message ----- From: "Alexandru Petrescu" To: "Shubhranshu" >> If the community thinks there are issues that really needs to be >> addressed before moving this document forward then I'd be willing to >> ask for postponement. >> >> Why do you think there is a WGLC in the process ? I remember you >> saying at the WG mailing list, about a couple of weeks after WGLC for >> this ID ended, that you have some comments on section 5.1 but >> "Otherwise - yes, I'm fine with the document." !! > > Shubhranshu: yes, until I stumbled across this inconsistency > with respect to multicast in the problem-statement document. > >> According to the ID authors those comments were minor in nature and >> is addressed in the later version. I am not sure if you or anyone >> would not have any confusion or new thoughts even after, say, one >> year of further discussions. > > I will not stir this any further. Your constructive comments are always welcomed and appreciated. - Shubhranshu > > Alex _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 22 08:37:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCFM-0002C2-8a; Thu, 22 Nov 2007 08:37:36 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IvCFK-0002Bk-TX for autoconf-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 08:37:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCFJ-0002Ba-Vs for autoconf@ietf.org; Thu, 22 Nov 2007 08:37:34 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IvCFI-0006ui-Qy for autoconf@ietf.org; Thu, 22 Nov 2007 08:37:33 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-153.messagelabs.com!1195738651!6377445!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 7310 invoked from network); 22 Nov 2007 13:37:31 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-153.messagelabs.com with SMTP; 22 Nov 2007 13:37:31 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lAMDbVYv025342; Thu, 22 Nov 2007 06:37:31 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id lAMDbUbv002792; Thu, 22 Nov 2007 07:37:30 -0600 (CST) 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 lAMDbS92002773; Thu, 22 Nov 2007 07:37:29 -0600 (CST) Message-ID: <47458618.4000704@gmail.com> Date: Thu, 22 Nov 2007 14:37:28 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Shubhranshu Subject: Re: [Autoconf] tentative draft-ietf-autoconf-problem-statement-03.txt and the manetarch document References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071121-0, 21/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: autoconf@ietf.org, Emmanuel.Baccelli@inria.fr 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: [...] > I can see the problem being described here but yes I agree that it > needs to be expanded, to further calrify things. See below. Shubhranshu, thank you for reading my proposal text. I'm taking the comments. I think I will make modifications as you suggest (see below) but I don't think I will do them right away. I think I will do that for the next next IETF (after Vancouver), to let time for things to settle. Besides, there may be some impact in how the manetarch document is written: should the manetarch document picture a non-hierarchical addressing architecture (in addition to the pictured _hierarchical_ addressing architecture Figure 6). I think yes because that (manetarch) draft says that "MANETs of those sizes can perform reasonably well in many cases w/o hierarchy" - what does "hierachy" mean? > >>> For example, in Figure 1, we assume that the "p2p Link" >>> (point-to-point link) and the links BR-MR1, MR1-MR2 and MR2-MR3 all >>> have distinctive IP subnets assigned. The MR3 needs to be assigned >>> an IPv6 prefix. The MANET router MR3 does not yet know the IP >>> address of the DHCPv6 Server, so it needs to discover it by using >>> link-layer multicast mechanisms and IP-layer multicast. It is >>> possible for MR2 to run DHCP Relay software. In this case the MR3 >>> would send a DHCP Solicit message (IP dst address is a IP multicast >>> address), message preceded by a header containing a link-layer >>> multicast address as destination. The Solicit message would be >>> further sent by MR2 (DHCP Relay) to the the ISP Edge Router (DHCP >>> Server). After this initial step the next DHCPv6 exchanges would >>> be performed such that the MR3 obtains a prefix. > > > Looks like you are proposing that the problem statement assume or > suggest this way of solving the problems. Are you proposing text for > the problem ID or for the solution ID? For the problem ID. The DHCP behaviour described above is standard behaviour, not anything new. My use of "would be sent" is to mean that I really think that that happens, but to check whether anyone else thinks that doesn't happen that way. >>> ----- MR1-MR2-MR3 >>> / . >>> +-------------+ +------------+ / . >>> | | p2p | |/ . (MANET) >>> | ISP Edge | Link | Border | . >>> | Router +---------+ Router |\ . >>> | | | | \ . >>> +-------------+ +------------+ \----- MRn >>> >>> Fig. 1. Connected MANET router topology. >>> >>> This is a DHCP behaviour that would work in this MANET topology. >>> However, there may be at least the following two issues: >>> >>> -in the group of MANET Routers described above there should be a >>> dynamic decision of roles about who is a Relay and at what moment. >>> If MR2 disappears from its place and another MR takes its place >>> then that router should receive the DHCPv6 Solicit sent by MR3 and >>> relay it to the DHCPv6 Server. > > Agree, this is one of the issue. And one possible solution of this may > be, as for an example "Each MANET router should act as a dynamic DHCP > relay". I think this is solution indeed. I think we can discuss this solution at further length in solution draft. But I think an issue should be described in the problemstatement as well. >>> -some implementations of DHCPv6 Prefix Delegation will not update >>> routes on the DHCP Server with respect to the allocated prefix. >>> Or, when assigning prefixes that don't respect a hierarchical >>> structure it is necessary when using a Relay to add a new routing >>> table entry at the DHCP Server whenever a new prefix is assigned >>> to a new MANET Router. This route should point to the Relay >>> address. > > Hmmm.... again I see lots of text which I think would make a good > content of a proposed solution document. Shubhranshu, I can try to re-formulate that text to express better that that is a problem not a solution. If one tries to run DHCPv6 Server and a DHCPv6 Relay, and then a Router behind the Relay requests for a prefix (with DHCPv6 PRefix Delegation) then one realizes that (1) the allocated prefix must be hierarchically[*] fit within the prefix administratively assigned on the Relay's interface towards Router and (2) once the prefix is allocated it will unfortunately _not_ be inserted in DHCP Server's routing table (because it is already covered by the routing entry pointing to Relay's prefix). This is a problem from implementation. It could help if we had a requirement (within a bulleted list of Req items) on architecture of unicast prefixes assigned on MANET subnets to be able to be both hierarchical and non-hierarchical - i.e. there should be no strict hierarchical relationship between IPv6 prefixes assigned to the MANET subnets (even when the pictured topology seems hierarchical tree-like). To better explain that need to support non-hierarchical addressing architectures one would first have to explain hierarchical address architecture and then, keeping the same topology, one would do a non-hierarchical addressing architecture. I describe this below. (Remark that the manetarch draft only pictures a _hierarchical_ addressing architecture in Figure 6.) An example of a non-hierarchical address architecture followed by a hierarchical address architecture is illustrated below. Assume three prefixes: 8000::/length (also represented as "100..." meaning first 3 bits are "100" and then followed by 125 0s), 4000::/length (010...) and c000::/length (110...) and three MANET Routers. Hierarchical IPv6 address architecture on a topology illustrated as a tree: ------ |MANET | |Router| ------ / \ 8000::/1 / \ 4000::/1 (100...) / \(010...) ------ ------ |MANET | |MANET | |Router| |Router| ------ ------ | | c000::/2 (110...) Same topology illustrated linearly, and with a IPv6 non-hierarchical addressing architecture: ------ ------ ------ -------|MANET |----------|MANET |----------|MANET | 8000::/1|Router| 4000::/1 |Router| c000::/1 |Router| (100...) ------ (010...) ------ (110...) ------ Both types of IPv6 addressing architecture should be supported by an address auto-configuration protocol for MANETs. This is a requirement, within a buletted list. (if/when this description of hierarchy is agreed then I can suggest another useful addressing architecture from MANEMO). For solution, for example, one could write spec to say that a MANET Router acting as a DHCP Server and requesting PD requests from a MANET Router acting as a Relay will always update its forwarding information base with respect to that Relay and the allocated prefix. This is indeed part of solution. >>> These are two issues that appear in the topology pictured in Figure >>> 1. In this figure the DHCP Server, Border Router, MR1 and MR3 are >>> assumed to be stable non-moving (only MR2 moves). If we consider >>> that any entities will also move then there may be more DHCP issues >>> that could be identified. > > Yes. Ok. I think some more could be identified. Emmanuel asked the same thing. I think it will take some time to identify them, that's why I postpone it to next next IETF. Please accept my excuses if this looks too pedagogical... it's just my means to communicate... 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 Nov 22 08:57:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCYH-0007Mg-6r; Thu, 22 Nov 2007 08:57:09 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IvCYG-0007JU-I4 for autoconf-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 08:57:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCYG-0007IH-6C; Thu, 22 Nov 2007 08:57:08 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IvCYF-0007au-FX; Thu, 22 Nov 2007 08:57:08 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-153.messagelabs.com!1195739826!10688844!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 16348 invoked from network); 22 Nov 2007 13:57:06 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-153.messagelabs.com with SMTP; 22 Nov 2007 13:57:06 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lAMDv5oN029702; Thu, 22 Nov 2007 06:57:05 -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 lAMDv5Ut012250; Thu, 22 Nov 2007 07:57:05 -0600 (CST) 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 lAMDv45m012138; Thu, 22 Nov 2007 07:57:04 -0600 (CST) Message-ID: <47458AA5.2070009@gmail.com> Date: Thu, 22 Nov 2007 14:56:53 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 Subject: Re: [Autoconf] RE: [MEXT] Prefix Delegation documents References: <483735.10786.qm@web84112.mail.mud.yahoo.com><470167CD.8020601@gmail.com><8E035F3A-301D-446B-BA63-7A977C20E117@clarinet.u-strasbg.fr><473DC6F2.9060509@gmail.com><664C7601-4EBC-4283-AD51-38D1164DA992@clarinet.u-strasbg.fr><47417205.7070805@gmail.com> <7892795E1A87F04CADFCCF41FADD00FC04CEAFC6@xmb-ams-337.emea.cisco.com> <006a01c82b48$de794bb0$9b6be310$@nl> <47432B43.5020100@azairenet.com> <7892795E1A87F04CADFCCF41FADD00FC04CEB847@xmb-ams-337.emea.cisco.com> <47447F8F.3050103@azairenet.com> <005f01c82cd8$062d2880$12877980$@nl> In-Reply-To: <005f01c82cd8$062d2880$12877980$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071121-0, 21/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 1.6 (+) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: autoconf@ietf.org, mext@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 Teco Boot wrote: > Thanks for the clarifications. > > I wanted to know, as Prefix Delegation is being worked on in Autoconf > also. If Autoconf comes up with a third solution, it could be > difficult to manage in environments with equipment is both Mobile > Router (NEMO) and MANET Router (Autoconf). Are others also studying > this overlap in functionality? > > Maybe there are some issues with PD and DSMIPv6. Has anyone looked at > this? DS-MIPv6... I don't think it allocates prefixes in any way. I think DS-MIPv6 assumes that the underlying MIP6 implementation could allocate prefixes. Ie I take a MIP6 implementation, I enhance it with NEMOv6-MIP6-PD messages and then I enhance it further with DS-MIPv6 extensions. IPv6-IPv4... "Prefix Delegation" is somehow called "Subnet Allocation" for IPv4 in the DHCP WG. Status-wise the IPv4 "DHCP Subnet Allocation" has less impact, it's Informational, than DHCPv6-PD StdsTrack. However, technically on paper it seems to have more advanced features than DHCPv6-PD (I haven't checked "DHCP Subnet Allocation" implementation). > I suggest to keep the PD discussion in MEXT. What is "Prefix Delegation"? Is it DHCPv6-PD? Is it MIP6-based Prefix Delegation? Is it PMIPv6-based prefix allocation? I'd suggest for "Prefix Delegation" to mean "DHCPv6-PD" and only that, but can't enforce it I know. As such I think it can be discussed anywhere where people need a mechanism to autoconfigure prefixes (instead of just addresses). Alex > > Teco. > >> -----Oorspronkelijk bericht----- Van: Vijay Devarapalli >> [mailto:vijay.devarapalli@azairenet.com] Verzonden: woensdag 21 >> november 2007 19:57 Aan: Pascal Thubert (pthubert) CC: Teco Boot; >> mext@ietf.org Onderwerp: Re: [MEXT] Prefix Delegation documents >> >> Pascal Thubert (pthubert) wrote: >>> Hi Vijay >>> >>> My proposal to break the tie is this: >>> >>> - move draft-ietf-nemo-dhcpv6-pd-02.txt to informational track as >>> it documents a way to use DHCP-PD but does not need new >>> exchanges. Last >> I >>> checked, some components were still missing but Ralph knows >>> better. >>> >>> - focus on draft-ietf-nemo-prefix-delegation-02.txt for standard >> track. >>> The draft is agnostic to the delegation mechanism in the backend >>> and does not have dependencies. It proposes an integrated >>> mechanism that fits the general MIP6 / NEMO approach and formats. >>> >>> >>> What do you think? >> I am fine with this approach. >> >> For draft-ietf-nemo-prefix-delegation-02.txt, I would like to simplify the mechanism a bit, by removing the Mobile Network Prefix >> Confirm option. Just use the Mobile Network Prefix option for the >> home agent to send the prefix to the mobile router. I actually >> don't understand the need for the Mobile Network Prefix Confirm >> option. >> >> Vijay >> >>> Pascal >>> >>>> -----Original Message----- From: Vijay Devarapalli >>>> [mailto:vijay.devarapalli@AzaireNet.com] Sent: Tuesday, >>>> November 20, 2007 7:45 PM To: Teco Boot Cc: Pascal Thubert >>>> (pthubert); mext@ietf.org Subject: Re: [MEXT] Re: [nemo] Prefix >>>> Delegation documents >>>> >>>> Teco Boot wrote: >>>>> Hi Pascal, Question on WG documents for prefix delegation. >>>>> There are two of >>> them: >>>>> 1: draft-ietf-nemo-prefix-delegation-02.txt (August 21, 2007) >>>>> 2: draft-ietf-nemo-dhcpv6-pd-02.txt (September 28, 2006) Are >>>>> we still working on both solutions? >>>> We have a sort of stalemate on this. I believe Jari (AD) would >> prefer >>>> one solution in this space. I think the earlier decision by the >>>> NEMO WG was to standardize both solutions. Not sure what the >>>> consensus is right now. >>>> >>>> IMO, we should standardize one ASAP. Without a prefix >>>> delegation mechanism the only possible solution now is to >>>> pre-configure the mobile network prefix on the mobile router. >>>> This is not sufficient. >>>> >>>> Vijay > > > > _______________________________________________ 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 Nov 22 09:41: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 1IvDFM-0006vE-0i; Thu, 22 Nov 2007 09:41:40 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IvDFL-0006v7-1T for autoconf-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 09:41:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvDFK-0006ux-NZ for autoconf@ietf.org; Thu, 22 Nov 2007 09:41:38 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IvDFK-0000bL-Ai for autoconf@ietf.org; Thu, 22 Nov 2007 09:41:38 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-153.messagelabs.com!1195742496!13827048!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 15183 invoked from network); 22 Nov 2007 14:41:36 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-15.tower-153.messagelabs.com with SMTP; 22 Nov 2007 14:41:36 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id lAMEfVMg012577; Thu, 22 Nov 2007 07:41:32 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id lAMEfVx2012216; Thu, 22 Nov 2007 08:41:31 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id lAMEfSX7012100; Thu, 22 Nov 2007 08:41:29 -0600 (CST) Message-ID: <47459508.7070204@gmail.com> Date: Thu, 22 Nov 2007 15:41:12 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Autoconf] tentative draft-ietf-autoconf-problem-statement-03.txt and the manetarch document References: <47458618.4000704@gmail.com> In-Reply-To: <47458618.4000704@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071121-0, 21/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: autoconf@ietf.org, Emmanuel.Baccelli@inria.fr, Shubhranshu 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 Correction... [...] > Same topology illustrated linearly, and with a IPv6 non-hierarchical > addressing architecture: > > ------ ------ ------ > -------|MANET |----------|MANET |----------|MANET | > 8000::/1|Router| 4000::/1 |Router| c000::/1 |Router| ---------------------------------------------------^ I meant '2' not '1' > (100...) ------ (010...) ------ (110...) ------ 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 Nov 22 13:15:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvGaB-0004PH-HS; Thu, 22 Nov 2007 13:15:23 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IvGaA-0004Ka-N0 for autoconf-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 13:15:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvGaA-0004J4-Cn for autoconf@ietf.org; Thu, 22 Nov 2007 13:15:22 -0500 Received: from mail176.messagelabs.com ([85.158.138.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IvGa5-0001Bm-Mr for autoconf@ietf.org; Thu, 22 Nov 2007 13:15:22 -0500 X-VirusChecked: Checked X-Env-Sender: Ronald.intVelt@tno.nl X-Msg-Ref: server-14.tower-176.messagelabs.com!1195755316!6524887!1 X-StarScan-Version: 5.5.12.14.2; banners=tno.nl,-,- X-Originating-IP: [134.221.2.2] Received: (qmail 14948 invoked from network); 22 Nov 2007 18:15:16 -0000 Received: from zeus.tno.nl (HELO zeus.tno.nl) (134.221.2.2) by server-14.tower-176.messagelabs.com with SMTP; 22 Nov 2007 18:15:16 -0000 Received: from ms-dt01thalia.tsn.tno.nl (ms-dt01thalia.tno.nl [134.221.225.157]) by zeus.tno.nl (8.11.7p1+Sun/8.11.7) with ESMTP id lAMIFG001067 for ; Thu, 22 Nov 2007 19:15:16 +0100 (MET) 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] tentative draft-ietf-autoconf-problem-statement-03.txt Date: Thu, 22 Nov 2007 19:15:15 +0100 Message-ID: <7877C5C0B5CC894AB26113CF06CF88631EA66B@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <47443AAB.4070009@inria.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] tentative draft-ietf-autoconf-problem-statement-03.txt thread-index: AcgsR1Fj1rYba91kSCCbI8hr4dc4VAA7BtnA References: <47443152.5070807@inria.fr> <474435BA.5020208@motorola.com> <47443AAB.4070009@inria.fr> From: "Velt, R. (Ronald) in 't" To: X-Spam-Score: -2.2 (--) X-Scan-Signature: 2b3349545af520ba354ccdc9e1a03fc1 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,=20all,=20=20 >=20-----Original=20Message----- >=20From:=20Emmanuel=20Baccelli=20[mailto:Emmanuel.Baccelli@inria.fr]=20 >=20Sent:=20woensdag=2021=20november=202007=2015:03 >=20To:=20autoconf@ietf.org >=20Subject:=20[Autoconf]=20tentative=20 >=20draft-ietf-autoconf-problem-statement-03.txt >=20 >=20All, >=20 >=20after=20the=20feedback=20received=20from=20Alex,=20Teco,=20Carlos,=20R= onald,=20 >=20Thomas=20(thanks=20to=20all=20of=20you),=20a=20tentative=20-03=20is=20= available=20 >=20on=20a=20server=20reachable=20at=20 >=20http://djincoda.free.fr/autoconf-PS/draft-ietf-autoconf-proble >=20m-statement-03.txt >=20 >=20Highlights=20about=20the=20updates=20include: >=20 >=20-=20the=20definition=20of=20the=20term=20ICP=20is=20more=20precise >=20-=20even=20more=20explicit=20mention=20that=20DHCP=20etc.=20may=20be=20= part=20of=20a=20solution >=20-=20typos=20corrected=20here=20and=20there >=20-=20global=20address=20terminology=20updated >=20-=20more=20precision=20regarding=20issues=20developped=20in=204.1.x >=20 >=20Alex,=20you=20were=20suggesting=20to=20write=20up=20a=20paragraph=20ab= out=20even=20 >=20more=20details=20on=20DHCP=20shortcomings.=20Can=20you=20propose=20som= e=20text=20 >=20and=20a=20place=20to=20put=20it=20in=20-03=20? >=20 >=20Otherwise,=20please=20take=20-03=20as=20the=20base=20for=20further=20 >=20discussions=20as=20of=20now. >=20 For=20what=20it's=20worth=20after=20the,=20er,=20thorough=20review=20by=20= Dave=20Thaler,=20I=20too have=20some=20comments.=20(Reminds=20me=20of=20that=20old=20joke=20about=20= the=20mouse=20and=20the elephant=20walking=20side=20by=20side=20over=20a=20wooden=20bridge,=20with= =20the=20mouse saying:=20"Aren't=20we=20making=20a=20lot=20of=20noise?").=20Mine=20are=20= against=20the tentative=20-03=20and=20are=20mainly=20terminology=20related.=20I=20need=20= to=20look=20more into=20the=20perceived=20(by=20some)=20disparity=20between=20this=20draft=20= and=20the=20WG charter.=20Perhaps=20the=20more=20logical=20order=20would=20be=20to=20rais= e=20fundamental issues=20first=20and=20deal=20with=20terminoloy=20/=20editorials=20later.=20= However,=20I chose=20to=20do=20easy=20stuff=20first,=20hard=20stuff=20later=20to=20give= =20you=20some=20early feedback. Here=20goes: 1.=20Introduction,=202nd=20para.=20typo:=20"assymetric"=20-->=20asymmetric= 2.=20Terminology (Section=20copied=20verbatim,=20with=20comments=20inserted) This=20document=20uses=20the=20terminology=20defined=20in=20[2],=20as=20we= ll=20as=20the =20=20=20following=20terms=20: =20=20=20MANET=20Local=20Prefix=20(MLP)=20=20-=20An=20IP=20prefix=20delega= ted=20to=20a=20MANET=20router, =20=20=20=20=20=20consisting=20in=20chunks=20of=20IP=20addresses=20valid=20= for=20communications =20=20=20=20=20=20inside=20the=20MANET. RitV:=20"chunks"???=20Does=201=20"chunk"=20correspond=20to=201=20prefix?=20= Note=20that=20the definition=20of=20"Prefix=20provision"=20later=20in=20the=20section=20talk= s=20about=20a=20set of=20contiguous=20addresses.=20And=20even=20that=20is=20not=20completely=20= accurate,=20as pointed=20out=20by=20Dave=20T. =20=20=20MANET=20Local=20Address=20(MLA)=20=20-=20An=20IP=20address=20conf= igured=20on=20a=20MANET =20=20=20=20=20=20interface,=20and=20valid=20for=20communications=20inside= =20the=20MANET. =20=20=20Internet=20Configuration=20Provider=20(ICP)=20=20-=20An=20entity=20= that=20can=20provide =20=20=20=20=20=20routers=20requesting=20configuration=20with=20routable=20= addresses=20or =20=20=20=20=20=20prefixes.=20=20A=20typical=20example=20of=20ICP=20is=20a= =20DHCP=20server. RitV:=20Alternative=20terms=20have=20been=20suggested,=20such=20as=20Inter= net=20Address and=20Prefix=20Provider.=20Conceptually,=20we=20could=20even=20distinguish= =20between Internet=20Address=20Provider=20and=20Internet=20Address=20Prefix=20Provid= er,=20which may=20or=20may=20not=20be=20co-located.=20=20 =20=20=20Global=20prefix=20=20-=20An=20IP=20prefix=20managed=20by=20a=20ro= uter,=20consisting=20in =20=20=20=20=20=20chunks=20of=20IP=20addresses=20valid=20for=20communicati= ons=20reaching=20outside =20=20=20=20=20=20the=20MANET=20(as=20well=20as=20communications=20within=20= the=20MANET). =20=20=20Global=20address=20=20-=20An=20IP=20address=20configured=20on=20a= n=20interface,=20and=20valid =20=20=20=20=20=20for=20communications=20inside=20the=20MANET=20as=20well=20= as=20for=20communications =20=20=20=20=20=20with=20corresponding=20hosts=20on=20the=20Internet,=20vi= a=20a=20border=20router.=20=20A =20=20=20=20=20=20global=20address=20may=20be=20associated=20with=20a=20pa= rticular=20ICP=20in=20order=20to =20=20=20=20=20=20be=20routable. RitV:=20Works=20for=20me.=20Teco=20seems=20to=20be=20saying=20that=20not=20= all=20global addresses=20are=20suitable=20for=20the=20purpose=20intended=20here=20and=20= proposes=20MGA. (Not=20sure=20if=20I've=20understood=20him=20correctly).=20To=20me,=20the=20= adjective=20put=20in front=20of=20"address"=20is=20an=20indication=20of=20scope.=20Thus,=20"MAN= ET=20Local"=20makes sense=20to=20me,=20but=20"MANET=20Global"=20does=20not.=20Teco=20further=20= stated=20that=20these addresses=20should=20be=20unique=20and=20globally=20routable.=20To=20me,=20= that=20is=20implied by=20"valid=20for=20communications=20..."=20in=20the=20definition=20above.= =20=20=20Connected=20MANET=20=20-=20A=20mobile=20ad=20hoc=20network,=20whi= ch=20has=20reachability=20to =20=20=20=20=20=20at=20least=20one=20ICP. RitV:=20I=20have=20a=20problem=20with=20"connected".=20Using=20the=20defin= ition=20of=20a Mobile=20Ad=20Hoc=20Network=20that=20you=20give=20in=20the=20first=20sente= nce=20of=20the Introduction,=20"Connected=20MANET"=20expands=20into=20"Connected=20loosel= y connected=20set=20of=20MANET=20routers"=20What,=20then,=20is=20a=20Disconn= ected=20MANET?=20I'm trying=20to=20think=20of=20something=20better,=20without=20success=20so=20= far.=20Attached MANET?=20Internet-attached=20MANET?=20Suggestions,=20anyone?=20(Note=20tha= t=20in=20the MANEMO=20/=20Tree=20Discovery=20vernacular,=20terms=20"grounded"=20and=20"= floating"=20are used=20for=20concepts=20not=20entirely=20unlike=20"connected"=20and=20"sta= nd=20alone".=20But I=20would=20not=20want=20to=20propose=20those=20here). =20=20=20Standalone=20MANET=20=20-=20A=20mobile=20ad=20hoc=20network,=20wh= ich=20does=20not=20have =20=20=20=20=20=20reachability=20to=20any=20ICP. =20=20=20Network=20merger=20=20-=20The=20process=20by=20which=20two=20or=20= more=20previously =20=20=20=20=20=20disjoint=20ad=20hoc=20networks=20get=20connected. RitV:=20See?=20"Connected"=20gets=20you=20in=20trouble=20here=20already.=20= I=20don't=20think you=20mean=20"connected"=20in=20the=20sense=20of=20"connected=20MANET". =20=20=20Network=20partitioning=20=20-=20The=20process=20by=20which=20an=20= ad=20hoc=20network=20splits =20=20=20=20=20=20into=20two=20or=20more=20disconnected=20ad=20hoc=20netwo= rks. RitV:=20Same=20thing:=20Disconnected=20MANETs? =20=20=20Address=20generation=20=20-=20The=20process=20of=20selecting=20a=20= tentative=20address =20=20=20=20=20=20with=20the=20purpose=20of=20configuring=20an=20interface= . =20=20=20Address=20assignment=20=20-=20The=20process=20of=20configuring=20= an=20interface=20with=20a =20=20=20=20=20=20given=20address. =20=20=20Prefix=20provision=20=20-=20The=20process=20of=20providing=20a=20= router=20with=20a=20set=20of =20=20=20=20=20=20contiguous=20addresses=20it=20may=20manage=20for=20the=20= purpose=20of=20configuring =20=20=20=20=20=20interfaces=20or=20other=20routers. RitV:=20"Prefix=20provision"=20-->=20Prefix=20provisioning? =20=20=20Pre-service=20address=20uniqueness=20=20-=20The=20property=20of=20= an=20address=20which=20is =20=20=20=20=20=20assigned=20at=20most=20once=20within=20a=20given=20scope= ,=20and=20which=20is=20unique, =20=20=20=20=20=20before=20it=20is=20being=20used. =20=20=20In-service=20address=20uniqueness=20=20-=20The=20property=20of=20= an=20address=20which=20was =20=20=20=20=20=20assigned=20at=20most=20once=20within=20a=20given=20scope= ,=20and=20which=20remains =20=20=20=20=20=20unique=20over=20time,=20after=20the=20address=20has=20st= arted=20being=20used. (end=20of=20copy) 3.=20Deployment=20Sceanarios 3.2=20Standalone=20MANET 1st=20sentence,=20typo:=20"does"=20-->=20do "Due=20to=20potential=20network=20partitions=20and=20mergers,=20standalone= =20MANETs=20may be=20composed=20of=20routers=20of=20either=20types."=20-->=20Isn't=20this=20= also=20true=20for "Connected=20MANETs"? 3.3=20Deployment=20Scenarios=20Selection last=20sentence,=20typo:=20"an=20other"=20-->=20another 4.=20Problem=20Statement 4.1.=20=20MANET=20Autoconfiguration=20Goals "A=20MANET=20router=20needs=20to=20configure=20IP=20addresses=20and=20pref= ixes=20as=20usual, on=20its=20non-MANET=20interfaces=20as=20well=20as=20its=20attached=20host= s=20and=20routers, if=20any." -->=20suggest=20to=20change=20this=20to: =20"A=20MANET=20router=20needs=20to=20configure=20IP=20addresses=20and=20p= refixes=20as=20usual on=20its=20non-MANET=20interfaces=20as=20well=20as=20facilitate=20IP=20add= ress=20and=20prefix configuration=20for=20its=20attached=20hosts=20and=20routers,=20if=20any."= =20 4.1.1.=20=20Multi-hop=20Support "Existing=20protocols=20assume=20that=20a=20broadcast=20directly=20reaches= =20every router=20or=20host=20on=20the=20subnetwork,=20whereas=20this=20generally=20= is=20not=20the=20case in=20MANETs=20(see=20[2])." -->=20As=20pointed=20out=20in=20my=20mail=20of=20last=20Tuesday:=20Section= =205.2=20of=20the manetarch=20I-D=20says=20that=20"MANET=20interfaces=20(...)=20must=20be=20= configured=20with unique=20prefixes."=20If=20I=20am=20interpreting=20this=20correctly,=20it=20= means=20that=20a MANET=20interface=20is=20always=20the=20only=20interface=20in=20the=20subn= etwork=20formed from=20its=20prefix=20and=20therefore=20it=20is=20still=20true=20that=20a=20= broadcast=20reaches "every=20router=20or=20host=20on=20the=20subnetwork".=20Can=20we=20safely=20= replace "subnetwork"=20by=20"link"=20here=20to=20make=20the=20point=20that=20was=20= intended?=20(Note: I=20think=20Carlos=20was=20saying=20that=20in=20some=20cases=20all=20MANET= =20interfaces=20from=20a MANET=20could=20be=20configured=20from=20a=20single=20prefix.=20Haven't=20= found=20time=20yet to=20read=20his=20I-Ds.=20Would=20that=20still=20be=20in=20line=20with=20t= he=20manetarch draft?).=20 "Due=20to=20the=20nature=20of=20the=20links=20over=20which=20a=20MANET=20i= s=20formed,=20ad=20hoc nodes=20within=20a=20MANET=20do=20not=20share=20access=20to=20a=20single=20= multicast-capable link=20for=20signaling." -->=20Sometimes=20they=20do,=20sometimes=20they=20don't.=20That's=20depend= ent=20on=20the time-varying=20topology=20of=20the=20MANET. 4.1.2.=20=20Dynamic=20Topology=20Support 1st=20para.=20"On=20the=20other=20hand,=20frequent=20reconfiguration=20may= =20cause=20IPv6 Stateless=20Address=20Autoconfiguration=20[5]=20to=20be=20much=20less=20ef= ficient=20than expected,=20due=20to=20large=20amounts=20of=20control=20signalling."=20 -->=20What=20is=20meant=20here:=20sending=20Router=20Advertisements=20at=20= a=20higher=20rate?=20 2nd=20para.=20This=20implication=20is=20the=20specificity=20of=20MANETs=20= that=20brings=20the requirement=20for=20new=20levels=20of=20service=20distribution,=20since=20= the=20"everyone is=20a=20server"=20approach=20is=20essentially=20not=20functional. -->=20This=20claim=20needs=20to=20be=20substantiated. 4.1.4.=20=20Network=20Partitioning=20Support typo:=20provisionning=20-->=20provisioning 4.2.=20=20MANET=20Autoconfiguration=20Issues 4.2.2.=20=20Prefix=20and=20Address=20Uniqueness=20Requirements "Pre-service=20Issues=20--=20Address=20or=20prefix=20uniqueness=20problems= =20in=20this category=20are=20called=20pre-service=20issues."=20-->=20Which=20category=20= is=20meant? 5.=20=20Solutions=20Considerations 1st=20sentence,=20typo:=20"scarse"=20-->=20scarce=20(already=20found=20by=20= Dave=20Thaler). That's=20all=20for=20now, Regards, Ronald This=20e-mail=20and=20its=20contents=20are=20subject=20to=20the=20DISCLAIM= ER=20at=20http://www.tno.nl/disclaimer/email.html _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 22 21:18:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvO7g-0002WP-Da; Thu, 22 Nov 2007 21:18:28 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IvO7d-0002Tq-N0 for autoconf-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 21:18:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvO7d-0002Os-5b for autoconf@ietf.org; Thu, 22 Nov 2007 21:18:25 -0500 Received: from ccmail.cc.niigata-u.ac.jp ([133.35.23.1] helo=mxav01.cc.niigata-u.ac.jp) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvO7c-0007VL-Fc for autoconf@ietf.org; Thu, 22 Nov 2007 21:18:24 -0500 Received: from mxav01.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 750384F48A9 for ; Fri, 23 Nov 2007 11:18:22 +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 62A044F413B for ; Fri, 23 Nov 2007 11:18:22 +0900 (JST) Received: (qmail 11731 invoked from network); 23 Nov 2007 11:18:22 +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 Nov 2007 11:18:22 +0900 Received: (qmail 12744 invoked from network); 23 Nov 2007 11:18:21 +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 Nov 2007 11:18:21 +0900 Message-Id: <7.0.0.16.2.20071123111049.0452e0d0@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Fri, 23 Nov 2007 11:18:24 +0900 To: "Velt, R. (Ronald) in 't" , From: mase Subject: RE: [Autoconf] tentative draft-ietf-autoconf-problem-statement-03.txt In-Reply-To: <7877C5C0B5CC894AB26113CF06CF88631EA66B@ms-dt01thalia.tsn.t no.nl> References: <47443152.5070807@inria.fr> <474435BA.5020208@motorola.com> <47443AAB.4070009@inria.fr> <7877C5C0B5CC894AB26113CF06CF88631EA66B@ms-dt01thalia.tsn.tno.nl> 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: 93238566e09e6e262849b4f805833007 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 Dear Ronald, all, Thank you for your comments. I agree "Connected MANET" may be confusing. Among your suggestions. I like Internet-attached MANET (or Infrastructure-attached MANET). Regards, Kenichi At 03:15 07/11/23, Velt, R. (Ronald) in 't wrote: > Connected MANET - A mobile ad hoc network, which has reachability to > at least one ICP. > >RitV: I have a problem with "connected". Using the definition of a >Mobile Ad Hoc Network that you give in the first sentence of the >Introduction, "Connected MANET" expands into "Connected loosely >connected set of MANET routers" What, then, is a Disconnected MANET? I'm >trying to think of something better, without success so far. Attached >MANET? Internet-attached MANET? Suggestions, anyone? (Note that in the >MANEMO / Tree Discovery vernacular, terms "grounded" and "floating" are >used for concepts not entirely unlike "connected" and "stand alone". But >I would not want to propose those here). _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 23 02:51: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 1IvTJn-0006Ds-3t; Fri, 23 Nov 2007 02:51:19 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IvTJl-00062D-OQ for autoconf-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 02:51:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvTJf-0005xQ-MW for autoconf@ietf.org; Fri, 23 Nov 2007 02:51:11 -0500 Received: from hpsmtp-eml12.kpnxchange.com ([213.75.38.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvTJb-0006u5-D5 for autoconf@ietf.org; Fri, 23 Nov 2007 02:51:11 -0500 Received: from hpsmtp-eml05.kpnxchange.com ([213.75.38.105]) by hpsmtp-eml12.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Nov 2007 08:51:04 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml05.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Nov 2007 08:51:03 +0100 From: "Teco Boot" To: "'Velt, R. \(Ronald\) in 't'" , References: <47443152.5070807@inria.fr> <474435BA.5020208@motorola.com> <47443AAB.4070009@inria.fr> <7877C5C0B5CC894AB26113CF06CF88631EA66B@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <7877C5C0B5CC894AB26113CF06CF88631EA66B@ms-dt01thalia.tsn.tno.nl> Subject: RE: [Autoconf] tentative draft-ietf-autoconf-problem-statement-03.txt Date: Fri, 23 Nov 2007 08:50:55 +0100 Message-ID: <000c01c82da5$9405c900$bc115b00$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgsR1Fj1rYba91kSCCbI8hr4dc4VAA7BtnAABwNiuA= Content-Language: nl X-OriginalArrivalTime: 23 Nov 2007 07:51:03.0738 (UTC) FILETIME=[98DAA9A0:01C82DA5] X-Spam-Score: -1.0 (-) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 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 Clarifications on usage if Global Address > Global address - An IP address configured on an interface, and > valid > for communications inside the MANET as well as for communications > with corresponding hosts on the Internet, via a border router. A > global address may be associated with a particular ICP in order > to > be routable. > > RitV: Works for me. Teco seems to be saying that not all global > addresses are suitable for the purpose intended here and proposes MGA. > (Not sure if I've understood him correctly). To me, the adjective put > in > front of "address" is an indication of scope. Thus, "MANET Local" makes > sense to me, but "MANET Global" does not. Teco further stated that > these > addresses should be unique and globally routable. To me, that is > implied > by "valid for communications ..." in the definition above. IMHO Global Addresses may have very different contexts, especially outside Autoconf and also related to Autoconf. GA can be "valid", but not by definition "valid for communication" in a MANET environment. This is an important aspect and I think this is the main reason having an Autoconf WG. I don't care which name we pick, as long as we all know what we mean when we use the name. Using MGA, it is clear that the GA is inside the MANET, and that is exactly what it is. MGA shall not be used outside the MANET, ingress filtering shall block such a usage (multiple of BCP on this!!). MLA are also inside the MANET, but cannot be used for Internet connectivity. MGA can and shall be used for this, with respecting the topologically correctness requirement. Sometimes MIP/NEMO can be used, sometimes this is not needed, e.g. when there is only one BR. There could be other methods enforcing routing via the associated BR. I am interested in all options ensuring topologically correctness. Teco. > Connected MANET - A mobile ad hoc network, which has reachability > to > at least one ICP. > > RitV: I have a problem with "connected". Using the definition of a > Mobile Ad Hoc Network that you give in the first sentence of the > Introduction, "Connected MANET" expands into "Connected loosely > connected set of MANET routers" What, then, is a Disconnected MANET? > I'm > trying to think of something better, without success so far. Attached > MANET? Internet-attached MANET? Suggestions, anyone? (Note that in the > MANEMO / Tree Discovery vernacular, terms "grounded" and "floating" are > used for concepts not entirely unlike "connected" and "stand alone". > But > I would not want to propose those here). > > Standalone MANET - A mobile ad hoc network, which does not have > reachability to any ICP. > > Network merger - The process by which two or more previously > disjoint ad hoc networks get connected. > > RitV: See? "Connected" gets you in trouble here already. I don't think > you mean "connected" in the sense of "connected MANET". > > Network partitioning - The process by which an ad hoc network > splits > into two or more disconnected ad hoc networks. > > RitV: Same thing: Disconnected MANETs? > > Address generation - The process of selecting a tentative address > with the purpose of configuring an interface. > > Address assignment - The process of configuring an interface with a > given address. > > Prefix provision - The process of providing a router with a set of > contiguous addresses it may manage for the purpose of configuring > interfaces or other routers. > > RitV: "Prefix provision" --> Prefix provisioning? > > Pre-service address uniqueness - The property of an address which > is > assigned at most once within a given scope, and which is unique, > before it is being used. > > In-service address uniqueness - The property of an address which > was > assigned at most once within a given scope, and which remains > unique over time, after the address has started being used. > > (end of copy) > > 3. Deployment Sceanarios > > 3.2 Standalone MANET > > 1st sentence, typo: "does" --> do > > "Due to potential network partitions and mergers, standalone MANETs may > be composed of routers of either types." --> Isn't this also true for > "Connected MANETs"? > > 3.3 Deployment Scenarios Selection > > last sentence, typo: "an other" --> another > > 4. Problem Statement > > 4.1. MANET Autoconfiguration Goals > > "A MANET router needs to configure IP addresses and prefixes as usual, > on its non-MANET interfaces as well as its attached hosts and routers, > if any." > --> suggest to change this to: > "A MANET router needs to configure IP addresses and prefixes as usual > on its non-MANET interfaces as well as facilitate IP address and prefix > configuration for its attached hosts and routers, if any." > > 4.1.1. Multi-hop Support > > "Existing protocols assume that a broadcast directly reaches every > router or host on the subnetwork, whereas this generally is not the > case > in MANETs (see [2])." > > --> As pointed out in my mail of last Tuesday: Section 5.2 of the > manetarch I-D says that "MANET interfaces (...) must be configured with > unique prefixes." If I am interpreting this correctly, it means that a > MANET interface is always the only interface in the subnetwork formed > from its prefix and therefore it is still true that a broadcast reaches > "every router or host on the subnetwork". Can we safely replace > "subnetwork" by "link" here to make the point that was intended? (Note: > I think Carlos was saying that in some cases all MANET interfaces from > a > MANET could be configured from a single prefix. Haven't found time yet > to read his I-Ds. Would that still be in line with the manetarch > draft?). > > "Due to the nature of the links over which a MANET is formed, ad hoc > nodes within a MANET do not share access to a single multicast-capable > link for signaling." > > --> Sometimes they do, sometimes they don't. That's dependent on the > time-varying topology of the MANET. > > 4.1.2. Dynamic Topology Support > > 1st para. "On the other hand, frequent reconfiguration may cause IPv6 > Stateless Address Autoconfiguration [5] to be much less efficient than > expected, due to large amounts of control signalling." > > --> What is meant here: sending Router Advertisements at a higher rate? > > 2nd para. This implication is the specificity of MANETs that brings the > requirement for new levels of service distribution, since the "everyone > is a server" approach is essentially not functional. > > --> This claim needs to be substantiated. > > 4.1.4. Network Partitioning Support > > typo: provisionning --> provisioning > > 4.2. MANET Autoconfiguration Issues > > 4.2.2. Prefix and Address Uniqueness Requirements > > "Pre-service Issues -- Address or prefix uniqueness problems in this > category are called pre-service issues." --> Which category is meant? > > 5. Solutions Considerations > > 1st sentence, typo: "scarse" --> scarce (already found by Dave Thaler). > > > That's all for now, > > Regards, > Ronald > > This e-mail and its contents are subject to the DISCLAIMER at > http://www.tno.nl/disclaimer/email.html > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://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 Nov 23 03:41:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvU61-00032t-PL; Fri, 23 Nov 2007 03:41:09 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IvU60-00032j-UJ for autoconf-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 03:41:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvU60-00032b-IG for autoconf@ietf.org; Fri, 23 Nov 2007 03:41:08 -0500 Received: from ccmail.cc.niigata-u.ac.jp ([133.35.23.1] helo=mxav02.cc.niigata-u.ac.jp) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvU5y-0008HE-Pt for autoconf@ietf.org; Fri, 23 Nov 2007 03:41:08 -0500 Received: from mxav02.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6B46045489C for ; Fri, 23 Nov 2007 17:41:05 +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 5862E4546D8 for ; Fri, 23 Nov 2007 17:41:05 +0900 (JST) Received: (qmail 22762 invoked from network); 23 Nov 2007 17:41:05 +0900 Received: from unknown (HELO chamame.ie.niigata-u.ac.jp) (133.35.169.34) by mxav02.cc.niigata-u.ac.jp with SMTP; 23 Nov 2007 17:41:05 +0900 Received: (qmail 28505 invoked from network); 23 Nov 2007 17:41:04 +0900 Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 23 Nov 2007 17:41:04 +0900 Message-Id: <7.0.0.16.2.20071123171754.049c0398@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Fri, 23 Nov 2007 17:41:07 +0900 To: "Teco Boot" , "'Velt, R. (Ronald) in 't'" , From: mase Subject: RE: [Autoconf] tentative draft-ietf-autoconf-problem-statement-03.txt In-Reply-To: <000c01c82da5$9405c900$bc115b00$@nl> References: <47443152.5070807@inria.fr> <474435BA.5020208@motorola.com> <47443AAB.4070009@inria.fr> <7877C5C0B5CC894AB26113CF06CF88631EA66B@ms-dt01thalia.tsn.tno.nl> <000c01c82da5$9405c900$bc115b00$@nl> 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: 1e467ff145ef391eb7b594ef62b8301f 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 Dear all, See in line. At 16:50 07/11/23, Teco Boot wrote: >Clarifications on usage if Global Address > > > Global address - An IP address configured on an interface, and > > valid > > for communications inside the MANET as well as for communications > > with corresponding hosts on the Internet, via a border router. A > > global address may be associated with a particular ICP in order > > to > > be routable. > > > > RitV: Works for me. Teco seems to be saying that not all global > > addresses are suitable for the purpose intended here and proposes MGA. > > (Not sure if I've understood him correctly). To me, the adjective put > > in > > front of "address" is an indication of scope. Thus, "MANET Local" makes > > sense to me, but "MANET Global" does not. I strongly agree. >Teco further stated that > > these > > addresses should be unique and globally routable. To me, that is > > implied > > by "valid for communications ..." in the definition above. > >IMHO Global Addresses may have very different contexts, especially outside >Autoconf and also related to Autoconf. >GA can be "valid", but not by definition "valid for communication" in a >MANET environment. This is an important aspect and I think this is the main >reason having an Autoconf WG. One of the goals of Autoconf WG is to establish a method to provide "global addresses" to MANET routers for communication with the Internet. Not to provide MGA to MANET routers. The same global address may be given some time to MANET routers and some time to non-MANET mobile routers or hosts. After, a MANET router obtains the global address, it may lose Internet connectivity and its global address may become useless for communication with the Internet, but it is still one of the global address. IMHO I don't think the definition of the global address is necessary in the PS document, because I think this terminology should and can be used in the same meaning outside Autoconf. I agree Teco in the sense that the current special definition of teh global address in PS document is confusing and should be deleted. Regards, Kenichi >I don't care which name we pick, as long as we all know what we mean when we >use the name. >Using MGA, it is clear that the GA is inside the MANET, and that is exactly >what it is. MGA shall not be used outside the MANET, ingress filtering shall >block such a usage (multiple of BCP on this!!). > >MLA are also inside the MANET, but cannot be used for Internet connectivity. > >MGA can and shall be used for this, with respecting the topologically >correctness requirement. Sometimes MIP/NEMO can be used, sometimes this is >not needed, e.g. when there is only one BR. There could be other methods >enforcing routing via the associated BR. I am interested in all options >ensuring topologically correctness. > >Teco. > > > > > > > > > > > > > > Connected MANET - A mobile ad hoc network, which has reachability > > to > > at least one ICP. > > > > RitV: I have a problem with "connected". Using the definition of a > > Mobile Ad Hoc Network that you give in the first sentence of the > > Introduction, "Connected MANET" expands into "Connected loosely > > connected set of MANET routers" What, then, is a Disconnected MANET? > > I'm > > trying to think of something better, without success so far. Attached > > MANET? Internet-attached MANET? Suggestions, anyone? (Note that in the > > MANEMO / Tree Discovery vernacular, terms "grounded" and "floating" are > > used for concepts not entirely unlike "connected" and "stand alone". > > But > > I would not want to propose those here). > > > > Standalone MANET - A mobile ad hoc network, which does not have > > reachability to any ICP. > > > > Network merger - The process by which two or more previously > > disjoint ad hoc networks get connected. > > > > RitV: See? "Connected" gets you in trouble here already. I don't think > > you mean "connected" in the sense of "connected MANET". > > > > Network partitioning - The process by which an ad hoc network > > splits > > into two or more disconnected ad hoc networks. > > > > RitV: Same thing: Disconnected MANETs? > > > > Address generation - The process of selecting a tentative address > > with the purpose of configuring an interface. > > > > Address assignment - The process of configuring an interface with a > > given address. > > > > Prefix provision - The process of providing a router with a set of > > contiguous addresses it may manage for the purpose of configuring > > interfaces or other routers. > > > > RitV: "Prefix provision" --> Prefix provisioning? > > > > Pre-service address uniqueness - The property of an address which > > is > > assigned at most once within a given scope, and which is unique, > > before it is being used. > > > > In-service address uniqueness - The property of an address which > > was > > assigned at most once within a given scope, and which remains > > unique over time, after the address has started being used. > > > > (end of copy) > > > > 3. Deployment Sceanarios > > > > 3.2 Standalone MANET > > > > 1st sentence, typo: "does" --> do > > > > "Due to potential network partitions and mergers, standalone MANETs may > > be composed of routers of either types." --> Isn't this also true for > > "Connected MANETs"? > > > > 3.3 Deployment Scenarios Selection > > > > last sentence, typo: "an other" --> another > > > > 4. Problem Statement > > > > 4.1. MANET Autoconfiguration Goals > > > > "A MANET router needs to configure IP addresses and prefixes as usual, > > on its non-MANET interfaces as well as its attached hosts and routers, > > if any." > > --> suggest to change this to: > > "A MANET router needs to configure IP addresses and prefixes as usual > > on its non-MANET interfaces as well as facilitate IP address and prefix > > configuration for its attached hosts and routers, if any." > > > > 4.1.1. Multi-hop Support > > > > "Existing protocols assume that a broadcast directly reaches every > > router or host on the subnetwork, whereas this generally is not the > > case > > in MANETs (see [2])." > > > > --> As pointed out in my mail of last Tuesday: Section 5.2 of the > > manetarch I-D says that "MANET interfaces (...) must be configured with > > unique prefixes." If I am interpreting this correctly, it means that a > > MANET interface is always the only interface in the subnetwork formed > > from its prefix and therefore it is still true that a broadcast reaches > > "every router or host on the subnetwork". Can we safely replace > > "subnetwork" by "link" here to make the point that was intended? (Note: > > I think Carlos was saying that in some cases all MANET interfaces from > > a > > MANET could be configured from a single prefix. Haven't found time yet > > to read his I-Ds. Would that still be in line with the manetarch > > draft?). > > > > "Due to the nature of the links over which a MANET is formed, ad hoc > > nodes within a MANET do not share access to a single multicast-capable > > link for signaling." > > > > --> Sometimes they do, sometimes they don't. That's dependent on the > > time-varying topology of the MANET. > > > > 4.1.2. Dynamic Topology Support > > > > 1st para. "On the other hand, frequent reconfiguration may cause IPv6 > > Stateless Address Autoconfiguration [5] to be much less efficient than > > expected, due to large amounts of control signalling." > > > > --> What is meant here: sending Router Advertisements at a higher rate? > > > > 2nd para. This implication is the specificity of MANETs that brings the > > requirement for new levels of service distribution, since the "everyone > > is a server" approach is essentially not functional. > > > > --> This claim needs to be substantiated. > > > > 4.1.4. Network Partitioning Support > > > > typo: provisionning --> provisioning > > > > 4.2. MANET Autoconfiguration Issues > > > > 4.2.2. Prefix and Address Uniqueness Requirements > > > > "Pre-service Issues -- Address or prefix uniqueness problems in this > > category are called pre-service issues." --> Which category is meant? > > > > 5. Solutions Considerations > > > > 1st sentence, typo: "scarse" --> scarce (already found by Dave Thaler). > > > > > > That's all for now, > > > > Regards, > > Ronald > > > > This e-mail and its contents are subject to the DISCLAIMER at > > http://www.tno.nl/disclaimer/email.html > > > > > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://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 Fri Nov 23 08:37:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvYiy-0002B0-2W; Fri, 23 Nov 2007 08:37:40 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IvYiw-0002Ah-84 for autoconf-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 08:37:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvYit-0002AY-Rb for autoconf@ietf.org; Fri, 23 Nov 2007 08:37:37 -0500 Received: from p130.piuha.net ([2001:14b8:400::130] helo=smtp.piuha.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvYit-00006O-56 for autoconf@ietf.org; Fri, 23 Nov 2007 08:37:35 -0500 Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 1C518198682; Fri, 23 Nov 2007 15:37:34 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id A2F6E198670; Fri, 23 Nov 2007 15:37:33 +0200 (EET) Message-ID: <4746D79D.3090005@piuha.net> Date: Fri, 23 Nov 2007 15:37:33 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: Alexandru Petrescu References: <47205BF8.6070409@gmail.com> In-Reply-To: <47205BF8.6070409@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -1.4 (-) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: autoconf@ietf.org Subject: [Autoconf] Alex's issues 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 Alex, > But then, looking at section 5.1 General Address Architecture: > -I can't parse the figure: where are the interfaces precisely? Is the > loopback assigned P:1::/64? As I just read the document, this was clear to me at least. > -"MANET interfaces are specifically *NOT* configured with this prefix.": > which prefix? The previous paragraph mentions at least two prefixes. I agree that this is a bug, and will suggest text in my later AD review e-mail. > -what's the difference between "assigned" and "delegated" prefix? The > picture seems to make a distinction, but I don't understand. General terminology. You may be delegated a prefix, but only after you assign a prefix to an interface it becomes actually usable. Before that it is simply something that the requesting router has, not something that packets can be delivered to. > Also, the paragraph should also let the MANET Router have completely > different prefixes on their interfaces. Currently, the paragraph says > that there should be (eg) a common P::/62 out of which (eg) P:1::/64 > and P:2::/64 are assigned on two different interfaces. This is an > example ok. But there should also be a possibility of eg Q::/64 and > R::/64 on two different interfaces, Q and R having only the first > three bits common (001), and without needing to have 001::/64 > "delegated" to the MANET router. Yes, there should be a possibility. The current text allows that: A MANET router can be delegated zero or more prefixes. For example, if a MANET router is delegated a prefix p::, then subnet prefixes derived from this prefix (e.g, p:1::/64, p:2::/64, ...) > I've just raised yesterday an issue about multicast interpretation > confusion between manetarch and problem statement documents. HAs that > been solved already? A decision made? The issue is here, and the > following thread keeps the subject: > http://www1.ietf.org/mail-archive/web/autoconf/current/msg00771.html > > Was there a decision made with respect to this issue? It seems like > the confusing issue around multicast that I've raised is completely > ignored?? I tend to agree with Ronald and Emmanuel on this. For me it was clear that the manetarch definition only talks about *neighbors* not *subnet*. I do not see a need to change the manetarch document, though certainly -statement needs work. >> Semi-Broadcast Interface (SBI) >> A broadcast capable interface that may exhibit asymmetric >> reachability. Multiple access wireless radio interfaces are often >> SBI. Note that since a SBI *may* exhibit asymmetric reachability, >> it also may not. > > Please explain more what a SBI interface is. If this SBI comes from a > wifi experience please explain in wifi terms. The 802.11/wifi > standards and implementation don't use this term, so I'm really > confused by this term altogether. > > Please explain how asymmetric reachability matches UDLR concepts. > > Please explain what "Multiple access wireless radio interfaces" mean: > a interface connected to multiple radios? Or several types of > interfaces? > > Please explain what asymmetric means in terms of asymmetric bandwidth, > asymmetric MTU, asymmetric fragmentation; like when we talk ADSL or PMTU. Some of the terms that you are asking for are well known, e.g., multiple access. Asymmetric reachability has been defined earlier in the document. I don't think specific link layer definitions are useful here. The definition needs to be based on fundamental concepts. That being said, I have some suggestions on improving this definition. More on this later. >> 4.2.1. Semi-Broadcast Interface >> >> Given a wireless SBI that exhibits time-varying asymmetric >> reachability and spatially distributed MANET routers, each MANET >> router may have a different unique partial view of the MANET. > > Please explain what "time-varying asymmetric reachability and > spatially distributed MANET routers mean". Seemed clear to me... The set of other nodes reached by a broadcast message is different for different senders and may also vary with time. Jari _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 23 09:35: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 1IvZcz-0006OV-I6; Fri, 23 Nov 2007 09:35:33 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IvZcy-0006OD-8i for autoconf-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 09:35:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvZcx-0006O5-Q7 for autoconf@ietf.org; Fri, 23 Nov 2007 09:35:31 -0500 Received: from mail1-relais-roc.national.inria.fr ([192.134.164.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvZcu-00020D-Hz for autoconf@ietf.org; Fri, 23 Nov 2007 09:35:31 -0500 X-IronPort-AV: E=Sophos;i="4.21,457,1188770400"; d="scan'208";a="4831793" Received: from sphinx.lix.polytechnique.fr (HELO BoolfightMaN-Laptop.local) ([129.104.11.1]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Nov 2007 15:35:15 +0100 Message-ID: <4746E524.4050800@inria.fr> Date: Fri, 23 Nov 2007 15:35:16 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org References: <4746E44D.3060102@inria.fr> In-Reply-To: <4746E44D.3060102@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Autoconf] Goals of MANET autoconf 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 All, over the last 3 IETF meetings, there seemed to be a large consensus that the goals of MANET autoconfiguration are (verbatim from the presentation in Prague): 1. provide MANET-wide unique prefixes (up to /128) to each MANET router 2. if one or more Internet Gateway is reachable, provide unique global prefixes to each MANET router 3. detect and resolve if non-unique prefixes are assigned to MANET routers (e.g. as a result of a network partitioning/merger) Is there still a consensus? Is there some disagreement on these items? Emmanuel _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 23 11:26:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvbMR-00044S-5t; Fri, 23 Nov 2007 11:26:35 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IvbMP-00042a-8Q for autoconf-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 11:26:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvbMO-00042O-Uu for autoconf@ietf.org; Fri, 23 Nov 2007 11:26:32 -0500 Received: from an-out-0708.google.com ([209.85.132.243]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvbML-0005PQ-71 for autoconf@ietf.org; Fri, 23 Nov 2007 11:26:32 -0500 Received: by an-out-0708.google.com with SMTP id d11so723786and for ; Fri, 23 Nov 2007 08:26:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=ZsbXA5aU9Urhfjmxa6gUwunbr9J666etPiOS3ME1KFE=; b=STla98mNDkGl1ajRToopqf/DPLkwKJ71Dun/A4RIuIu5gp4olIBypzTpUOAvKMeytHNarskzBG75Yt9aJ6pLbiG6ARRKDtrkJedwxTOKJlcVjQ8adsUwxuBxBtCXQuKp/TX7TADw/hPsfqareH3095v4V/otUWZqVJv9K40pG3M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=GI6KfI5u1E/jkzzkAcbUpnDm78UKMsNUqvpKn3acyCS7YIwomwO4SjVT03SlvVOK0wr5T+hN6PbPf5yUghzMQ3D7xdiWAaYG+0PPpnzWGKEHY9vrHCtCZpArPgQcfn6RfpQJRiUNszbY40voVY/z3sD44P2kwCnADtviVUgNlRg= Received: by 10.100.94.14 with SMTP id r14mr14327773anb.1195835188820; Fri, 23 Nov 2007 08:26:28 -0800 (PST) Received: by 10.100.229.8 with HTTP; Fri, 23 Nov 2007 08:26:28 -0800 (PST) Message-ID: Date: Sat, 24 Nov 2007 01:26:28 +0900 From: Shubhranshu To: autoconf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Subject: [Autoconf] Some Thoughts on Problem Statement. 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 All, Below are some thoughts that might help us a more focused discussion and clarify some of the issues. Please send your comments such that we can further refine / clarify them. A MANET router needs to configure an IPv6 prefix(es) on its host interface and/or an IPv6 address on its loopback interface. Besides, it needs to configure a /128 (or /32 in case of IPv4) and/or a link local address on its MANET interface. A MANET router may also configure a prefix shorter than /128 (or /32) on its MANET interface provided prefix uniqueness is guaranteed [MANET-Arch I-D]. MANET node needs to configure "MANET scope" address to communicate among themselves. "MANET Scope" addresses are currently not specified / standardized within / outside the IETF. As mentioned above, there are three interfaces under consideration for address auto-configuration. Further detail related to these address auto-configuration is provided below: 1) Configuration of loopback interface: It is possible that a MANET Router does not have any host attached to its network interface or it has only MANET interface which can be used for intra-manet communication. In the absence of any "external" host, MANET router may configure an IPv6 global address on its loopback interface. The traditional auto configuration procedure such as RFC 2462, can be used for this purpose provided the MANET router has been assigned a suitable prefix. As usual, this interface is expected to send multicast RA/RS messages. However, in this case, these messages would be limited to the Router's loopback interface only. 2) Configuration of MANET interface: MANET Router uses this interface to communicate with other MANET Routers. MANET routing and other MANET specific protocols are expected to run on this interface. This interface SHOULD be configured with a link local address and/or a /128 (in case of IPv6) or with /32 (in case of IPv4) address. MANET interface may also use smaller prefix provided the prefix uniqueness is guaranteed. Configuration of MANET interface with a link local address and/or a /128 address is straightforward, as it can use existing mechanisms, except the issue of address uniqueness test over "multi-hop network". The probability of address duplication is quite low if most of the /128 bits are randomly generated and so a node may skip address uniqueness test. However, address uniqueness detection / resolution is a requirement when smaller prefixes are used and also in military & other critical MANET application scenarios. The address uniqueness detection / resolution should be done across the entire network thus requiring that the specific broadcast/multicast messages used for this purpose be propagated "even to MANET Routers that are multi-hop away". Currently there is no standard specification that addresses this requirement. 3) Configuration of Host interface: MANET router needs an unique prefix(es) such that it can configure the prefix on its host interface. This prefix may further be subnetted and used for address configuration of the hosts attached to the MANET router. In this scenario a MANET Router should receive one or more unique prefix(es). This is further explained below for the scenario where DHCP server is available (i.e connected MANET) and for the scenario where there is no server available (i.e. Standalone MANET): - Scenario where DHCP server is available. In this case the DHCP server could be either co-located or directly reachable to the MANET Boarder Router. If the server is directly reachable, as shown in the figure 1 below, then MANET Boarder Router can use existing DHCP request-reply messages (RFC 3315) between itself and the DHCP server in order to receive prefix(es). The MANET Boarder Router can then delegate those prefixes to the MANET routers connected to it either directly or over multi-hop routes. It should be noted that the link between the MANET router and its attached host follows the classic link model and SHOULD use the relevant traditional protocols for address configuration. The above mentioned DHCP request-reply mechanism normally assumes direct or stable i.e. not a dynamic multi-hop route connectivity expected between the requesting node and the DHCP server. MANET routers dynamically update routes & frequently change neighborhood and are multi-hop away from the DHCP server e.g. MR3 in Fig 1. These, however, does not require a complete protocol design but rather puts some requirements on the existing protocols [e.g. RFC 3633]. Currently there is no standard to address these requirements or that allows that MANET nodes should act as a dynamic DHCP relay. ----- MR1...MR3 / . +-------------+ +------------+ | / . | | p2p | MANET |/ . | ISP Edge| Link | Border | . | Router +---------+ Router |\ . | | | | \ . +-------------+ +------------+ \----- MR2 Fig 1 (same as fig 1 in draft-ietf-autoconf-statement-02) - Scenario where no DHCP server is available. By its very nature, MANET environment does not always assume availability of any pre-configured server. Even in such scenarios a MANET router needs to configure an unique prefix. Traditionally, protocols such as RFC 2462 are used for address configuration of nodes in stateless manner. However, RFC 2462 defines address auto configuration mechanisms for nodes (host and router) and as such it does not provide any mechanism for allocating "unique prefix(es)" to the routers. For example, in Figure 2 below, a MANET Router, say MR3, may need to receive prefix(es) (which can be further subnetted and used for address configuration of its attached host nodes) from the MANET Boarder Router /Access Router. Currently no specification exists that addresses this requirement. -- MR1...MR3 ....MR5 / / . / . MR4 . \ \ \ -- MR2 ... Fig 2. (same as Fig 2 in draft-ietf-autoconf-statement-02) Mobile and wireless nature of MANET routers result in dynamic network topology [MANET-Arch ID, RFC 2501] which has the property of changing neighbor nodes. These MANET properties result in network partitioning and merger of initially isolated networks. Normally, once an address is allocated to a node, it continues using it and collaborating to detect and resolve duplicates in case its address is allocated to any other node. Since initially isolated MANETs had allocated addresses independent with each other, there remains probability of more than one node using same address. Currently there is no specification that solves problem of MANET "network merger detection" and duplicate address detection/ resolution resulting due to two / more MANETs merger. It is desirable that network partitioning is also detected such that resources / prefixes that were allocated to the outgoing nodes could be re-used. Currently there is no specification to solve the problem of MANET "network merger detection". _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 23 11:42:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvbbO-0007p2-2X; Fri, 23 Nov 2007 11:42:02 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IvbbM-0007om-TN for autoconf-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 11:42:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvbbL-0007oY-JS for autoconf@ietf.org; Fri, 23 Nov 2007 11:41:59 -0500 Received: from an-out-0708.google.com ([209.85.132.248]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvbbI-0005vf-0G for autoconf@ietf.org; Fri, 23 Nov 2007 11:41:59 -0500 Received: by an-out-0708.google.com with SMTP id d11so724599and for ; Fri, 23 Nov 2007 08:41:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=z1z8PiKofeffFgPNN1GFUWq/PewYjiGLCGdzRGuNG9Q=; b=VwYEA41+5PdQ+thqule/b0Dh6SU3hjFT5a0HL9TpeR3tKLPzxu7Oc9aQ1/vdQHKc0Evuk9N6itCK6m7+6aiYKiIlUhTAvuE4eXuBbfT2luzXjchSI8tghRqI7+AdW15yU56Rqg+vb6M8u6HodIK2WMre30nkS1B9tqG8BuqgH/E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=ddgWTpEjoagtiM+zSG1T0WJSbi3XIr/1hjEBHBV1mg0FC2riWLAEr7amYcnJf4gWYXjk/n4FUWwMYg86Kpvqk5q3CI6pS58wv7GRpl64DcvbRqZrcdP9JmIWlpTUvpp8TWMdEIbRgGb9aFig47eJ2ao4i02QRBW2U/cBxRbUdEI= Received: by 10.100.242.20 with SMTP id p20mr14359333anh.1195836115716; Fri, 23 Nov 2007 08:41:55 -0800 (PST) Received: by 10.100.229.8 with HTTP; Fri, 23 Nov 2007 08:41:55 -0800 (PST) Message-ID: Date: Sat, 24 Nov 2007 01:41:55 +0900 From: Shubhranshu To: alexandru.petrescu@gmail.com Subject: Re: [Autoconf] tentative draft-ietf-autoconf-problem-statement-03.txt and the manetarch document MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 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 Alex, Please see below. ----- Original Message ----- From: "Alexandru Petrescu" > Shubhranshu wrote: > [...] >> I can see the problem being described here but yes I agree that it >> needs to be expanded, to further calrify things. See below. > > Shubhranshu, thank you for reading my proposal text. I'm taking the > comments. I think I will make modifications as you suggest (see below) > but I don't think I will do them right away. I think I will do that for > the next next IETF (after Vancouver), to let time for things to settle. Thanks. I sent some of my thoughts a while before hoping that it would help continue our discussion and make some progress even before the Vancouver meeting. I look forward to hear your comments as well....:-) > > Besides, there may be some impact in how the manetarch document is > written: should the manetarch document picture a non-hierarchical > addressing architecture (in addition to the pictured _hierarchical_ > addressing architecture Figure 6). I think yes because that (manetarch) > draft says that "MANETs of those sizes can perform reasonably well in > many cases w/o hierarchy" - what does "hierachy" mean? I think you are talking about section 8.2. Its Routing hierarchy. > Shubhranshu, I can try to re-formulate that text to express better that > that is a problem not a solution. If one tries to run DHCPv6 Server and > a DHCPv6 Relay, and then a Router behind the Relay requests for a prefix > (with DHCPv6 PRefix Delegation) then one realizes that (1) the allocated > prefix must be hierarchically[*] fit within the prefix administratively > assigned on the Relay's interface towards Router and (2) once the prefix > is allocated it will unfortunately _not_ be inserted in DHCP Server's > routing table (because it is already covered by the routing entry > pointing to Relay's prefix). > > This is a problem from implementation. > > It could help if we had a requirement (within a bulleted list of Req > items) on architecture of unicast prefixes assigned on MANET subnets to > be able to be both hierarchical and non-hierarchical - i.e. there should > be no strict hierarchical relationship between IPv6 prefixes assigned to > the MANET subnets (even when the pictured topology seems hierarchical > tree-like). Above you said "the allocated prefix must be hierarchically[*] fit.." but your requirement in the immediately above paragraph is "there should be no strict hierarchical relationship between IPv6 prefixes assigned". I guess I am missing something since these two sounds contradicting to me. > > To better explain that need to support non-hierarchical addressing > architectures one would first have to explain hierarchical address > architecture and then, keeping the same topology, one would do a > non-hierarchical addressing architecture. I describe this below. > (Remark that the manetarch draft only pictures a _hierarchical_ > addressing architecture in Figure 6.) > > An example of a non-hierarchical address architecture followed by a > hierarchical address architecture is illustrated below. Assume three > prefixes: 8000::/length (also represented as "100..." meaning first 3 > bits are "100" and then followed by 125 0s), 4000::/length (010...) and > c000::/length (110...) and three MANET Routers. > > Hierarchical IPv6 address architecture on a topology illustrated as a tree: > ------ > |MANET | > |Router| > ------ > / \ > 8000::/1 / \ 4000::/1 > (100...) / \(010...) > ------ ------ > |MANET | |MANET | > |Router| |Router| > ------ ------ > | > | c000::/2 > (110...) > > Same topology illustrated linearly, and with a IPv6 non-hierarchical > addressing architecture: > > ------ ------ ------ > -------|MANET |----------|MANET |----------|MANET | > 8000::/1|Router| 4000::/1 |Router| c000::/1 |Router| > (100...) ------ (010...) ------ (110...) ------ > > Both types of IPv6 addressing architecture should be supported by an > address auto-configuration protocol for MANETs. This is a requirement, > within a buletted list. Thanks. You explained very well but I am not yet decided on this. Perhaps I need to further analyse both of them. I'll do that. - Shubhranshu > > (if/when this description of hierarchy is agreed then I can suggest > another useful addressing architecture from MANEMO). > > For solution, for example, one could write spec to say that a MANET > Router acting as a DHCP Server and requesting PD requests from a MANET > Router acting as a Relay will always update its forwarding information > base with respect to that Relay and the allocated prefix. This is > indeed part of solution. > >>>> These are two issues that appear in the topology pictured in Figure >>>> 1. In this figure the DHCP Server, Border Router, MR1 and MR3 are >>>> assumed to be stable non-moving (only MR2 moves). If we consider >>>> that any entities will also move then there may be more DHCP issues >>>> that could be identified. >> >> Yes. > > Ok. I think some more could be identified. Emmanuel asked the same > thing. I think it will take some time to identify them, that's why I > postpone it to next next IETF. > Please accept my excuses if this looks too pedagogical... it's just my > means to communicate... > > Alex _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 23 12:01: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 1Ivbtj-0006iI-ON; Fri, 23 Nov 2007 12:00:59 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Ivbth-0006bI-Tn for autoconf-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 12:00:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivbtg-0006a4-V3 for autoconf@ietf.org; Fri, 23 Nov 2007 12:00:57 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ivbtg-0007VI-F6 for autoconf@ietf.org; Fri, 23 Nov 2007 12:00:56 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-128.messagelabs.com!1195837255!564725!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 14810 invoked from network); 23 Nov 2007 17:00:55 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-11.tower-128.messagelabs.com with SMTP; 23 Nov 2007 17:00:55 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id lANH0tRg019393; Fri, 23 Nov 2007 10:00:55 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id lANH0sLl016458; Fri, 23 Nov 2007 11:00:54 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id lANH0q49016129; Fri, 23 Nov 2007 11:00:53 -0600 (CST) Message-ID: <4747072E.2080304@gmail.com> Date: Fri, 23 Nov 2007 18:00:30 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Shubhranshu Subject: Re: [Autoconf] tentative draft-ietf-autoconf-problem-statement-03.txt and the manetarch document References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071122-0, 22/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected 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 Shubhranshu wrote: >> Shubhranshu, I can try to re-formulate that text to express better that >> that is a problem not a solution. If one tries to run DHCPv6 Server and >> a DHCPv6 Relay, and then a Router behind the Relay requests for a prefix >> (with DHCPv6 PRefix Delegation) then one realizes that (1) the allocated >> prefix must be hierarchically[*] fit within the prefix administratively >> assigned on the Relay's interface towards Router and (2) once the prefix >> is allocated it will unfortunately _not_ be inserted in DHCP Server's >> routing table (because it is already covered by the routing entry >> pointing to Relay's prefix). >> >> This is a problem from implementation. >> >> It could help if we had a requirement (within a bulleted list of Req >> items) on architecture of unicast prefixes assigned on MANET subnets to >> be able to be both hierarchical and non-hierarchical - i.e. there should >> be no strict hierarchical relationship between IPv6 prefixes assigned to >> the MANET subnets (even when the pictured topology seems hierarchical >> tree-like). > > Above you said "the allocated prefix must be hierarchically[*] fit.." [*]: that's what some DHCPv6 implementation requires. It may be a DHCP problem that could be corrected. > but your requirement in the immediately above paragraph is "there > should be no strict hierarchical relationship between IPv6 prefixes > assigned". I guess I am missing something since these two sounds > contradicting to me. I agree with you and others that in a MANET Network the IPv6 Addressing Architecture should not rely on prefixes being aggregated hierarchically. The AUTOCONF protocol and MANET protocol should work regardless of the IPv6 addressing architecture being hierarchical or not hierarchical. I've probably been not clear enough. This is a good requirement I agree on. 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 Nov 23 12:17:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivc9j-0003G0-6l; Fri, 23 Nov 2007 12:17:31 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Ivc9g-0003Fq-Dq for autoconf-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 12:17:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivc9g-0003Fd-4E for autoconf@ietf.org; Fri, 23 Nov 2007 12:17:28 -0500 Received: from an-out-0708.google.com ([209.85.132.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ivc9d-0007Oy-KG for autoconf@ietf.org; Fri, 23 Nov 2007 12:17:28 -0500 Received: by an-out-0708.google.com with SMTP id d11so726461and for ; Fri, 23 Nov 2007 09:17:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=r5mwDnB/8GJsncE6nTZExycXX4c94P2nVwbvie4f51s=; b=XoYQf/40iIs8so9s+9QPFebCsxGMM/K8qgZVNbPtQuadXoZ3vZN6Q7cvOhb/hBu4a7v9mPF0Z/w2YHaO/xSbL/oVaSjVZ+ium2EfOJE5736b2KBw/ox7E7NNqhISY7ICDH4SSSYxD8YK71eVUtd/0T3lJVtFGIDefM4dQvfhGUk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lbyvZIqHMgDIbzGiXE5IldVqPjCPt6rQZLsLn2Z/L+kv9+VFqeUTL+UlCYJxmRxVw7JoIqdLhFppWFyFVm8W42cN75dj4Wl9kT+o6+HFbWyQ3cwNF1qRk0tpX584YkoWUtIMduvALp2lZwclTj4FmjMexocpHBrV2OYGPZycLvA= Received: by 10.100.208.11 with SMTP id f11mr14404243ang.1195838245343; Fri, 23 Nov 2007 09:17:25 -0800 (PST) Received: by 10.100.229.8 with HTTP; Fri, 23 Nov 2007 09:17:25 -0800 (PST) Message-ID: Date: Sat, 24 Nov 2007 02:17:25 +0900 From: Shubhranshu To: autoconf@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [Autoconf] Fwd: Some Thoughts on Problem Statement. 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 A correction, please see below ---------- Forwarded message ---------- From: Shubhranshu Date: Nov 24, 2007 1:26 AM Subject: Some Thoughts on Problem Statement. To: autoconf@ietf.org - Scenario where no DHCP server is available. By its very nature, MANET environment does not always assume availability of any pre-configured server. Even in such scenarios a MANET router needs to configure an unique prefix. Traditionally, protocols such as RFC 2462 are used for address configuration of nodes in stateless manner. However, RFC 2462 defines address auto configuration mechanisms for nodes (host and router) and as such it >> "2462 defines address auto configuration mechanisms for nodes (hosts and not routers)". - Shubhranshu does not provide any mechanism for allocating "unique prefix(es)" to the routers. For example, in Figure 2 below, a MANET Router, say MR3, may need to receive prefix(es) (which can be further subnetted and used for address configuration of its attached host nodes) from the MANET Boarder Router /Access Router. Currently no specification exists that addresses this requirement. -- MR1...MR3 ....MR5 / / . / . MR4 . \ \ \ -- MR2 ... Fig 2. (same as Fig 2 in draft-ietf-autoconf-statement-02) Mobile and wireless nature of MANET routers result in dynamic network topology [MANET-Arch ID, RFC 2501] which has the property of changing neighbor nodes. These MANET properties result in network partitioning and merger of initially isolated networks. Normally, once an address is allocated to a node, it continues using it and collaborating to detect and resolve duplicates in case its address is allocated to any other node. Since initially isolated MANETs had allocated addresses independent with each other, there remains probability of more than one node using same address. Currently there is no specification that solves problem of MANET "network merger detection" and duplicate address detection/ resolution resulting due to two / more MANETs merger. It is desirable that network partitioning is also detected such that resources / prefixes that were allocated to the outgoing nodes could be re-used. Currently there is no specification to solve the problem of MANET "network merger detection". _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 23 16:03:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivffx-0007MQ-JP; Fri, 23 Nov 2007 16:03:01 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Ivffv-0007ML-Ig for autoconf-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 16:02:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivffv-0007MD-8v for autoconf@ietf.org; Fri, 23 Nov 2007 16:02:59 -0500 Received: from p130.piuha.net ([2001:14b8:400::130] helo=smtp.piuha.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ivffu-0007JE-QT for autoconf@ietf.org; Fri, 23 Nov 2007 16:02:59 -0500 Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 12C8419867C; Fri, 23 Nov 2007 23:02:58 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id AFA03198670; Fri, 23 Nov 2007 23:02:57 +0200 (EET) Message-ID: <47474001.3080901@piuha.net> Date: Fri, 23 Nov 2007 23:02:57 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: autoconf@ietf.org, draft-ietf-autoconf-manetarch@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -1.4 (-) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Subject: [Autoconf] AD review of draft-ietf-autoconf-manetarch 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 have done a part of my AD review on this document. I found a few issues, noted below. I am currently looking at the issues raised by Thomas Narten in his review from September and thinking about what additional modifications are needed. I felt that the SBI definition needs to be clearer about what the exact condition is when an interface is an SBI. Suggested alternative formulation below. In Section 2.1, change: OLD: Semi-Broadcast Interface (SBI) A broadcast capable interface that may exhibit asymmetric reachability. Multiple access wireless radio interfaces are often SBI. Note that since a SBI *may* exhibit asymmetric reachability, it also may not. NEW: Semi-Broadcast Interface (SBI) A broadcast capable interface that may exhibit asymmetric reachability. Multiple access wireless radio interfaces are often SBI. Note that an interface is SBI when a possibility exists that asymmetric reachability may occur. But asymmetric reachability may not actually be present all the time, e.g., when the nodes are close enough to all hear each other. The reference "this prefix" needs to be made explicit in Section 5.1. In Section 5.1, change: OLD: MANET interfaces are specifically *NOT* configured with this prefix. NEW: MANET interfaces are specifically *NOT* configured with the prefix(es) delegated to the MANET router. The vulnerabilities related to nodes inside the MANET need to be taken into account, as was noted during WGLC. Suggested text: add a new paragraph before the last paragraph of the Security Consideration section: Some MANET deployments may also have to deal with malicious behavior from the routers involved in the MANET itself. Defenses against such attacks are a research topic. Jari _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 23 21:27: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 1Ivkjo-0001VT-7i; Fri, 23 Nov 2007 21:27:20 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Ivkjn-0001Ry-A6 for autoconf-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 21:27:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivkjn-0001Rq-0B for autoconf@ietf.org; Fri, 23 Nov 2007 21:27:19 -0500 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 1Ivkji-0008TX-LC for autoconf@ietf.org; Fri, 23 Nov 2007 21:27:18 -0500 Received: from mxav02.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9C3694543FC for ; Sat, 24 Nov 2007 11:27:12 +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 89739454341 for ; Sat, 24 Nov 2007 11:27:12 +0900 (JST) Received: (qmail 22544 invoked from network); 24 Nov 2007 11:27:12 +0900 Received: from unknown (HELO chamame.ie.niigata-u.ac.jp) (133.35.169.34) by mxav02.cc.niigata-u.ac.jp with SMTP; 24 Nov 2007 11:27:12 +0900 Received: (qmail 14944 invoked from network); 24 Nov 2007 11:27:12 +0900 Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 24 Nov 2007 11:27:12 +0900 Message-Id: <7.0.0.16.2.20071124105741.04ce7008@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Sat, 24 Nov 2007 11:27:15 +0900 To: Shubhranshu , autoconf@ietf.org From: mase In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: Subject: [Autoconf] Re: Some Thoughts on Problem Statement. 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 Dear Shubranshu, I think that your text cleary describes the issues. My comments and questions are in line. Thanks, Kenichi At 01:26 07/11/24, Shubhranshu wrote: >All, > >Below are some thoughts that might help us a more focused discussion >and clarify some of the issues. Please send your comments such that >we can further refine / clarify them. > > > >A MANET router needs to configure an IPv6 prefix(es) on its host >interface and/or an IPv6 address on its loopback interface. Besides, >it needs to configure a /128 (or /32 in case of IPv4) and/or a link >local address on its MANET interface. A MANET router may also >configure a prefix shorter than /128 (or /32) on its MANET interface >provided prefix uniqueness is guaranteed [MANET-Arch I-D]. MANET node >needs to configure "MANET scope" address to communicate among >themselves. "MANET Scope" addresses are currently not specified / >standardized within / outside the IETF. > >As mentioned above, there are three interfaces under consideration for >address auto-configuration. Further detail related to these address >auto-configuration is provided below: > >1) Configuration of loopback interface: > >It is possible that a MANET Router does not have any host attached to >its network interface or it has only MANET interface which can be used >for intra-manet communication. In the absence of any "external" host, >MANET router may configure an IPv6 global address on its loopback >interface. The traditional auto configuration procedure such as RFC >2462, can be used for this purpose provided the MANET router has been >assigned a suitable prefix. As usual, this interface is expected to >send multicast RA/RS messages. However, in this case, these messages >would be limited to the Router's loopback interface only. > >2) Configuration of MANET interface: > >MANET Router uses this interface to communicate with other MANET >Routers. MANET routing and other MANET specific protocols are expected >to run on this interface. This interface SHOULD be configured with a >link local address and/or a /128 (in case of IPv6) or with /32 (in >case of IPv4) address. MANET interface may also use smaller prefix >provided the prefix uniqueness is guaranteed. Configuration of MANET >interface with a link local address and/or a /128 address is >straightforward, as it can use existing mechanisms, except the issue >of address uniqueness test over "multi-hop network". > >The probability of address duplication is quite low if most of the >/128 bits are randomly generated and so a node may skip address >uniqueness test. However, address uniqueness detection / resolution is >a requirement when smaller prefixes are used and also in military & >other critical MANET application scenarios. The address uniqueness >detection / resolution should be done across the entire network thus >requiring that the specific broadcast/multicast messages used for this >purpose be propagated "even to MANET Routers that are multi-hop away". >Currently there is no standard specification that addresses this >requirement. The above description only covers pre-service DAD issue. I think that we should also describe in-service issue here. Thai is merger of two isolated MANETs may bring address conflict and the method of detecting and resolving the address conflict is required. >3) Configuration of Host interface: > >MANET router needs an unique prefix(es) such that it can configure the >prefix on its host interface. This prefix may further be subnetted and >used for address configuration of the hosts attached to the MANET >router. In this scenario a MANET Router should receive one or more >unique prefix(es). This is further explained below for the scenario >where DHCP server is available (i.e connected MANET) and for the >scenario where there is no server available (i.e. Standalone MANET): > >- Scenario where DHCP server is available. > >In this case the DHCP server could be either co-located or directly >reachable to the MANET Boarder Router. If the server is directly >reachable, as shown in the figure 1 below, then MANET Boarder Router >can use existing DHCP request-reply messages (RFC 3315) between >itself and the DHCP server in order to receive prefix(es). The MANET >Boarder Router can then delegate those prefixes to the MANET routers >connected to it either directly or over multi-hop routes. It should be >noted that the link between the MANET router and its attached host >follows the classic link model and SHOULD use the relevant traditional >protocols for address configuration. > >The above mentioned DHCP request-reply mechanism normally assumes >direct or stable i.e. not a dynamic multi-hop route connectivity >expected between the requesting node and the DHCP server. MANET >routers dynamically update routes & frequently change neighborhood and >are multi-hop away from the DHCP server e.g. MR3 in Fig 1. These, >however, does not require a complete protocol design but rather puts >some requirements on the existing protocols [e.g. RFC 3633]. Currently >there is no standard to address these requirements or that allows that >MANET nodes should act as a dynamic DHCP relay. > > ----- MR1...MR3 > / . > +-------------+ +------------+ | / . > | | p2p | MANET |/ . > | ISP Edge| Link | Border | . > | Router +---------+ Router |\ . > | | | | \ . > +-------------+ +------------+ \----- MR2 > > >Fig 1 (same as fig 1 in draft-ietf-autoconf-statement-02) > >- Scenario where no DHCP server is available. > >By its very nature, MANET environment does not always assume >availability of any pre-configured server. Even in such scenarios a >MANET router needs to configure an unique prefix. Traditionally, >protocols such as RFC 2462 are used for address configuration of nodes >in stateless manner. However, RFC 2462 defines address auto >configuration mechanisms for nodes (host and router) and as such it >does not provide any mechanism for allocating "unique prefix(es)" to >the routers. For example, in Figure 2 below, a MANET Router, say MR3, >may need to receive prefix(es) (which can be further subnetted and >used for address configuration of its attached host nodes) from the >MANET Boarder Router /Access Router. Currently no specification exists >that addresses this requirement. I think that MANET Border Router/Access Router is not available or meaningful in this scenario where no DHCP server is available (stand-alone MANET). > -- MR1...MR3 ....MR5 > / > / . > / . > MR4 . > \ > \ > \ -- MR2 ... > >Fig 2. (same as Fig 2 in draft-ietf-autoconf-statement-02) > > >Mobile and wireless nature of MANET routers result in dynamic network >topology [MANET-Arch ID, RFC 2501] which has the property of changing >neighbor nodes. These MANET properties result in network partitioning >and merger of initially isolated networks. Normally, once an address In this paragraph, you use address. Is this ok? You discuss unique prefix issues above. Should "address" here be replaced with prefix? >is allocated to a node, it continues using it and collaborating to >detect and resolve duplicates in case its address is allocated to any >other node. Since initially isolated MANETs had allocated addresses >independent with each other, there remains probability of more than >one node using same address. Currently there is no specification that >solves problem of MANET "network merger detection" and duplicate >address detection/ resolution resulting due to two / more MANETs >merger. > >It is desirable that network partitioning is also detected such that >resources / prefixes that were allocated to the outgoing nodes could >be re-used. Currently there is no specification to solve the problem >of MANET "network merger detection". This should be "network partitioning detection" _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sat Nov 24 06:18:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivt1d-00057S-60; Sat, 24 Nov 2007 06:18:17 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Ivt1c-00057J-4o for autoconf-confirm+ok@megatron.ietf.org; Sat, 24 Nov 2007 06:18:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivt1b-000576-NP; Sat, 24 Nov 2007 06:18:15 -0500 Received: from [202.99.23.227] (helo=people.com.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ivt1a-0000Vv-Oz; Sat, 24 Nov 2007 06:18:15 -0500 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmba47481395; Sat, 24 Nov 2007 19:31:12 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm1447418b37; Mon, 19 Nov 2007 19:55:21 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Mon, 19 Nov 2007 19:55:21 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu4Vy-0001iO-MK; Mon, 19 Nov 2007 06:10:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu4Vu-0001ht-Sh; Mon, 19 Nov 2007 06:10:02 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu4Vu-0008OB-HH; Mon, 19 Nov 2007 06:10:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 67C982AC50; Mon, 19 Nov 2007 11:10:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu4Vu-00070j-6M; Mon, 19 Nov 2007 06:10:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Nov 2007 06:10:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: autoconf@ietf.org Subject: [Autoconf] I-D Action:draft-ietf-autoconf-statement-02.txt X-BeenThere: autoconf@ietf.org Reply-To: internet-drafts@ietf.org 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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Ad-Hoc Network Autoconfiguration Working Group of the IETF. Title : Address Autoconfiguration for MANET: Terminology and Problem Statement Author(s) : E. Baccelli, et al. Filename : draft-ietf-autoconf-statement-02.txt Pages : 19 Date : 2007-11-19 Traditional dynamic IPv6 address assignment solutions are not adapted to mobile ad hoc networks. This document elaborates on this problem, states the need for new solutions, and requirements to these solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-autoconf-statement-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-autoconf-statement-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-autoconf-statement-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-19060156.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-autoconf-statement-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-autoconf-statement-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19060156.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart 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 --NextPart-- From autoconf-bounces@ietf.org Sun Nov 25 07:45:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwGr5-0000cf-5b; Sun, 25 Nov 2007 07:44:59 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IwGr3-0000X3-Iu for autoconf-confirm+ok@megatron.ietf.org; Sun, 25 Nov 2007 07:44:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwGr3-0000Wo-98 for autoconf@ietf.org; Sun, 25 Nov 2007 07:44:57 -0500 Received: from an-out-0708.google.com ([209.85.132.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwGr0-0001u2-Pa for autoconf@ietf.org; Sun, 25 Nov 2007 07:44:57 -0500 Received: by an-out-0708.google.com with SMTP id d11so46828and for ; Sun, 25 Nov 2007 04:44:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=n/A4juCPWwryUaavJ/2MO7wKBvUKTD8uWKSFZrZ9KTI=; b=n74E9jI+jgnzlYhmTLMY1TGVaHYB2NzwrHun5QB9vEmyESHFFym+VGE38dRa6ip3yvPP5yeDXJWMk/xcP8l7mQKqy7gq3OYhR3Lh636bQQ2QDgqwwjoTnZK6KybBH5y6XIuWB75cq9AP9mfFp3eJ1s9H6TstV5A8DAEhWVaT5O4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=n+2n1boe+AB24U/9jYzfxwgKA5EdNarHWgZCYRAER1UTV5siYrmrRf/2A8vFyxFmPiXRNmJIyNvofuZZtNnAjFkD7WdJGUNDNqB9MlE32IVg1EqNFr3XKcBosuBPOzBxcFxEFG2BXL/f0f8B5kg6OFIVI5Z6gms1aTBNTpcsbSU= Received: by 10.100.211.8 with SMTP id j8mr1730671ang.1195994694522; Sun, 25 Nov 2007 04:44:54 -0800 (PST) Received: by 10.100.229.8 with HTTP; Sun, 25 Nov 2007 04:44:54 -0800 (PST) Message-ID: Date: Sun, 25 Nov 2007 21:44:54 +0900 From: Shubhranshu To: mase In-Reply-To: <7.0.0.16.2.20071124105741.04ce7008@ie.niigata-u.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7.0.0.16.2.20071124105741.04ce7008@ie.niigata-u.ac.jp> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: autoconf@ietf.org Subject: [Autoconf] Re: Some Thoughts on Problem Statement. 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 Prof. Mase, Please see below: On 11/24/07, mase wrote: > Dear Shubranshu, > > I think that your text cleary describes the issues. Thank you. (also I received some private e-mail expressing this ....:-) ) >My comments and > questions are in line. > > Thanks, > Kenichi > > At 01:26 07/11/24, Shubhranshu wrote: > >All, > >The probability of address duplication is quite low if most of the > >/128 bits are randomly generated and so a node may skip address > >uniqueness test. However, address uniqueness detection / resolution is > >a requirement when smaller prefixes are used and also in military & > >other critical MANET application scenarios. The address uniqueness > >detection / resolution should be done across the entire network thus > >requiring that the specific broadcast/multicast messages used for this > >purpose be propagated "even to MANET Routers that are multi-hop away". > >Currently there is no standard specification that addresses this > >requirement. > > The above description only covers pre-service DAD issue. I think that > we should also describe in-service issue here. Thai is merger of two > isolated MANETs may bring address conflict and the method of > detecting and resolving the address conflict is required. > Agree, we need to include them. Later paragraph describes network merger and related issues. > > >3) Configuration of Host interface: > > > >- Scenario where no DHCP server is available. > > > >By its very nature, MANET environment does not always assume > >availability of any pre-configured server. Even in such scenarios a > >MANET router needs to configure an unique prefix. Traditionally, > >protocols such as RFC 2462 are used for address configuration of nodes > >in stateless manner. However, RFC 2462 defines address auto > >configuration mechanisms for nodes (host and router) and as such it > >does not provide any mechanism for allocating "unique prefix(es)" to > >the routers. For example, in Figure 2 below, a MANET Router, say MR3, > >may need to receive prefix(es) (which can be further subnetted and > >used for address configuration of its attached host nodes) from the > >MANET Boarder Router /Access Router. Currently no specification exists > >that addresses this requirement. > > I think that MANET Border Router/Access Router is not available or > meaningful in this scenario where no DHCP server is available > (stand-alone MANET). Right, need to replace with MR4. > > > > -- MR1...MR3 ....MR5 > > / > > / . > > / . > > MR4 . > > \ > > \ > > \ -- MR2 ... > > > >Fig 2. (same as Fig 2 in draft-ietf-autoconf-statement-02) > > > > > >Mobile and wireless nature of MANET routers result in dynamic network > >topology [MANET-Arch ID, RFC 2501] which has the property of changing > >neighbor nodes. These MANET properties result in network partitioning > >and merger of initially isolated networks. Normally, once an address > > In this paragraph, you use address. Is this ok? You discuss unique > prefix issues above. > Should "address" here be replaced with prefix? Prefixes. > > >is allocated to a node, it continues using it and collaborating to > >detect and resolve duplicates in case its address is allocated to any > >other node. Since initially isolated MANETs had allocated addresses > >independent with each other, there remains probability of more than > >one node using same address. Currently there is no specification that > >solves problem of MANET "network merger detection" and duplicate > >address detection/ resolution resulting due to two / more MANETs > >merger. > > > >It is desirable that network partitioning is also detected such that > >resources / prefixes that were allocated to the outgoing nodes could > >be re-used. Currently there is no specification to solve the problem > >of MANET "network merger detection". > > This should be "network partitioning detection" > Typo. Thanks for catching them. - Shubhranshu > > > > > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 26 09:05: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 1IweaR-0006xY-34; Mon, 26 Nov 2007 09:05:23 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IweaP-0006xR-ML for autoconf-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 09:05:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IweaP-0006xJ-Ce for autoconf@ietf.org; Mon, 26 Nov 2007 09:05:21 -0500 Received: from nf-out-0910.google.com ([64.233.182.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IweaK-0006gY-KG for autoconf@ietf.org; Mon, 26 Nov 2007 09:05:21 -0500 Received: by nf-out-0910.google.com with SMTP id d21so622863nfb for ; Mon, 26 Nov 2007 06:05:11 -0800 (PST) Received: by 10.78.107.8 with SMTP id f8mr2862421huc.1196085911032; Mon, 26 Nov 2007 06:05:11 -0800 (PST) Received: by 10.78.170.19 with HTTP; Mon, 26 Nov 2007 06:05:11 -0800 (PST) Message-ID: <25c114b90711260605n22e6f879ve8e4f8fd77d1a8ed@mail.gmail.com> Date: Mon, 26 Nov 2007 15:05:11 +0100 From: "Ulrich Herberg" To: autoconf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 32bb3c91530e9b79 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Subject: [Autoconf] Review of tentative draft-ietf-autoconf-statement-03.txt 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 Dear all, I have some comments on the autoconf statement (03). In some way I agree with Dave Thaler (comments inline): > > From: Dave Thaler > > Date: November 21, 2007 10:34:11 PM CEST > > Subject: Review of draft-ietf-autoconf-statement-02.txt > > > > 1) The document is supposed to be a problem statement, and it does > > not really state what the problem is. It concludes that existing > > solutions can't work, but provides no discussion of this to > > motivate that conclusion. That is what, in my view, is the point > > of a problem statement document and as such should be a significant > > contribution. This is the main reason why I feel it needs > > significant work before WGLC. In my opinion, the problem statement should state more prominently the problems of autoconfiguration and existing solutions (e.g. IPv6 stateless autoconfiguration, DHCPv6). In section 4.1.1, part of these problems are mentioned, but under the section "goals". I would rather change the order of section 4.1 and 4.2 and first speak of issues THEN of goals how to solve these issues. To my understanding, a discussion of problems of existing solutions would rather belong to the section "issues" than to "goals". Maybe one could also underline that the main problem of existing solutions like IPv6 stateless autoconfiguration is not only that it "do[es] not account for potential address duplication beyond a single [...] link" (from section 4.1.1), but that it has a completely other intention: namely to configure HOSTS, while we are talking about assigning prefixes to ROUTERs. In section 4.1., "the primary goal of MANET autoconfiguration is [...] to provide mechanisms for IPv6 prefix provision and address assignment for operation on MANETs". This formulation -- though probably correct -- sounds a bit vague for me. I have another idea in my mind which would be: "The primary goal of MANET autoconfiguration is to allocate globally unique and topologically correct prefixes, and IP addresses to MANET interfaces. " This primary goal is probably not always desirable or necessary; that's why I would add some "subgoals" in a hierarchical sense: 1. configuration of unique link-local addresses / prefixes 2. configuration of unique MLA addresses / prefixes 3. configuration of global addresses / prefixes One or more of these subgoals can be achieved by autoconfiguration. Looking at the table of contents of the draft, I see the following subsections of 4.1 MANET Autoconfiguration Goals 4.1.1 Multi-hop Support 4.1.2 Dynamic Topology Support 4.1.3 Network Merging Support 4.1.4 Network Partitioning Support Are these really the the main goals of autoconfiguration? If I think of goals of autoconfiguration, I would have something different in mind. Some of these would be (feel free to comment...) - MANET nodes need to have unique prefixes within the desired scope - The prefixes of MANET routers should be easily aggregatable using Classless Inter-Domain Routing (CIDR). - Hosts should be automatically configured using the prefix of the router they are connected to (e.g. using IPv6 Stateless Autoconf.) - All subgoals mentioned above should be accomplishable: autoconfiguration of unique link-local addresses/prefixes, autoconfiguration of MANET-local unique addresses/prefixes, and configuration of global prefixes. - The achievement of one subgoal should not depend on the accomplishment of another (e.g. allocation of MANET-local prefixes should not depend on link-local addresses). - The solution should be independent of any particular routing protocol. Another idea would be to think about the following question: "what do we actually want to autoconfigure? hosts? routers?". I would propose add some sentence like: "FIRST we need to autoconfigure the MANET interface of the ROUTERS (i.e. assigning a unique IP address to the MANET interface, and a prefix to the router); THEN we can configure HOSTS attached to this router e.g. by using existing protocols like IPv6 SA". Even if the difference is stated in section 5.1 of the manetarch draft, it could be useful to remind the difference of autoconfiguration of the ingress interface (thus the MANET interface) and the egress interface (thus the attached network to the router -- which may be any kind of network). Regards, Ulrich _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 26 09:46:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwfEV-0006xo-Pu; Mon, 26 Nov 2007 09:46:47 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IwfEV-0006xY-IF for autoconf-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 09:46:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwfEV-0006xJ-80 for autoconf@ietf.org; Mon, 26 Nov 2007 09:46:47 -0500 Received: from server9.hosting2go.nl ([83.137.192.232]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwfEU-00022B-4W for autoconf@ietf.org; Mon, 26 Nov 2007 09:46:46 -0500 Received: (qmail 8301 invoked from network); 26 Nov 2007 15:46:43 +0100 Received: from unknown (HELO M90Teco) (217.169.232.211) by server9.hosting2go.nl with SMTP; 26 Nov 2007 15:46:43 +0100 From: "Teco Boot" To: "'Emmanuel Baccelli'" References: <4746E44D.3060102@inria.fr> <4746E524.4050800@inria.fr> In-Reply-To: <4746E524.4050800@inria.fr> Subject: RE: [Autoconf] Goals of MANET autoconf Date: Mon, 26 Nov 2007 15:46:07 +0100 Message-ID: <008a01c8303b$26611740$732345c0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acgt3jSwxKpSQcv9QXKeLo68bFfc/wCWX6Vg Content-Language: nl X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 Emmanuel, I agree on all 3 items. Reading back the items, I have some thoughts: What is the scope? IPv6 only? Is ND to be replaced with something new? Has item 3 anything to do with item 2? Or is it a sub-goal on item 1? Shouldn't we try to prevent non-unique prefixes instead of detecting / resolving? On item 2, do we care on "routable"? Teco. > -----Oorspronkelijk bericht----- > Van: Emmanuel Baccelli [mailto:Emmanuel.Baccelli@inria.fr] > Verzonden: vrijdag 23 november 2007 15:35 > Aan: autoconf@ietf.org > Onderwerp: [Autoconf] Goals of MANET autoconf > > All, > > over the last 3 IETF meetings, there seemed to be a large consensus > that > the goals of MANET autoconfiguration are (verbatim from the > presentation > in Prague): > > > 1. provide MANET-wide unique prefixes (up to /128) to each MANET router > > 2. if one or more Internet Gateway is reachable, provide unique global > prefixes to each MANET router > > 3. detect and resolve if non-unique prefixes are assigned to MANET > routers (e.g. as a result of a network partitioning/merger) > > > Is there still a consensus? Is there some disagreement on these items? > > Emmanuel > > > _______________________________________________ > 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 Nov 26 09:50:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwfIP-00088W-LC; Mon, 26 Nov 2007 09:50:49 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IwfIO-00088H-9a for autoconf-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 09:50:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwfIN-000889-UV for autoconf@ietf.org; Mon, 26 Nov 2007 09:50:48 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IwfIM-000294-WB for autoconf@ietf.org; Mon, 26 Nov 2007 09:50:47 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-153.messagelabs.com!1196088644!10655058!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 21007 invoked from network); 26 Nov 2007 14:50:44 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-4.tower-153.messagelabs.com with SMTP; 26 Nov 2007 14:50:44 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id lAQEohLM013508; Mon, 26 Nov 2007 07:50:43 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id lAQEogHF002098; Mon, 26 Nov 2007 08:50:42 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id lAQEoeRg002009; Mon, 26 Nov 2007 08:50:41 -0600 (CST) Message-ID: <474ADD38.5090403@gmail.com> Date: Mon, 26 Nov 2007 15:50:32 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ulrich Herberg Subject: Re: [Autoconf] Review of tentative draft-ietf-autoconf-statement-03.txt References: <25c114b90711260605n22e6f879ve8e4f8fd77d1a8ed@mail.gmail.com> In-Reply-To: <25c114b90711260605n22e6f879ve8e4f8fd77d1a8ed@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071124-0, 24/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 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 mainly agree with the tendency of this message. One little comment with respect to formulating a problem stressing SLAAC (stateless autoconf) does not work for routers. Ulrich Herberg wrote: > Dear all, > > I have some comments on the autoconf statement (03). In some way I > agree with Dave Thaler (comments inline): > >>> From: Dave Thaler >>> Date: November 21, 2007 10:34:11 PM CEST >>> Subject: Review of draft-ietf-autoconf-statement-02.txt >>> >>> 1) The document is supposed to be a problem statement, and it does >>> not really state what the problem is. It concludes that existing >>> solutions can't work, but provides no discussion of this to >>> motivate that conclusion. That is what, in my view, is the point >>> of a problem statement document and as such should be a significant >>> contribution. This is the main reason why I feel it needs >>> significant work before WGLC. > > In my opinion, the problem statement should state more prominently the > problems of autoconfiguration and existing solutions (e.g. IPv6 > stateless autoconfiguration, DHCPv6). In section 4.1.1, part of these > problems are mentioned, but under the section "goals". I would rather > change the order of section 4.1 and 4.2 and first speak of issues THEN > of goals how to solve these issues. To my understanding, a discussion > of problems of existing solutions would rather belong to the section > "issues" than to "goals". > Maybe one could also underline that the main problem of existing > solutions like IPv6 stateless autoconfiguration is not only that it > "do[es] not account for potential address duplication beyond a single > [...] link" (from section 4.1.1), but that it has a completely other > intention: namely to configure HOSTS, while we are talking about > assigning prefixes to ROUTERs. I agree with the suggestion after having noticed myself and other colleagues assuming SLAAC autoconfiguration would work with MANET Routers and then correcting selves on second thought. I'd push it further. I'd add that maybe that tendency of assuming SLAAC working for Routers is from the simplicity on implementation to make SLAAC work for routers (on linux simply switch a sysctl flag) and on the spec to simply decide (for example) that a certain "MANET Interface" is acting as a "Host" instead of a "Router". For example, a NEMO Mobile Router decides its "Egress Interface" is acting as a Host instead of a Router thus _can_ be autoconfigured with SLAAC. This doesn't mean your remark is incorrect - I agree with it. I'd rather try to identify _why_ SLAAC on a Router's interface would have limitations and what protocol would it break. If we have two routers both sending RAs to each other with two different prefixes - which Router should configure its address from which Router? Should Router1 auto-configure an address from the prefix in Router2's RA? Or the other way? Or both? Is this a problem? Just some thoughts. I mainly agree with the direction of your message. Alex > > In section 4.1., "the primary goal of MANET autoconfiguration is [...] > to provide mechanisms for IPv6 prefix provision and address assignment > for operation on MANETs". This formulation -- though probably correct > -- sounds a bit vague for me. I have another idea in my mind which > would be: > "The primary goal of MANET autoconfiguration is to allocate globally > unique and topologically correct prefixes, and IP addresses to MANET > interfaces. " > > This primary goal is probably not always desirable or necessary; > that's why I would add some "subgoals" in a hierarchical sense: > 1. configuration of unique link-local addresses / prefixes > 2. configuration of unique MLA addresses / prefixes > 3. configuration of global addresses / prefixes > One or more of these subgoals can be achieved by autoconfiguration. > > Looking at the table of contents of the draft, I see the following > subsections of > 4.1 MANET Autoconfiguration Goals > 4.1.1 Multi-hop Support > 4.1.2 Dynamic Topology Support > 4.1.3 Network Merging Support > 4.1.4 Network Partitioning Support > > Are these really the the main goals of autoconfiguration? If I think > of goals of autoconfiguration, I would have something different in > mind. Some of these would be (feel free to comment...) > - MANET nodes need to have unique prefixes within the desired scope > - The prefixes of MANET routers should be easily aggregatable > using Classless > Inter-Domain Routing (CIDR). > - Hosts should be automatically configured using the prefix of the > router they are > connected to (e.g. using IPv6 Stateless Autoconf.) > - All subgoals mentioned above should be accomplishable: > autoconfiguration of unique link-local addresses/prefixes, > autoconfiguration of > MANET-local unique addresses/prefixes, and configuration of > global prefixes. > - The achievement of one subgoal should not depend on the accomplishment of > another (e.g. allocation of MANET-local prefixes should not depend on link-local > addresses). > - The solution should be independent of any particular routing protocol. > > > Another idea would be to think about the following question: "what do > we actually want to autoconfigure? hosts? routers?". I would propose > add some sentence like: > "FIRST we need to autoconfigure the MANET interface of the ROUTERS > (i.e. assigning a unique IP address to the MANET interface, and a > prefix to the router); THEN we can configure HOSTS attached to this > router e.g. by using existing protocols like IPv6 SA". Even if the > difference is stated in section 5.1 of the manetarch draft, it could > be useful to remind the difference of autoconfiguration of the ingress > interface (thus the MANET interface) and the egress interface (thus > the attached network to the router -- which may be any kind of > network). > > Regards, > Ulrich > > > _______________________________________________ > 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 Mon Nov 26 10:16: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 1IwfhF-00054P-TD; Mon, 26 Nov 2007 10:16:29 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IwfhE-00054B-Pt for autoconf-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 10:16:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwfhE-000542-GJ for autoconf@ietf.org; Mon, 26 Nov 2007 10:16:28 -0500 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwfh9-0008VO-1O for autoconf@ietf.org; Mon, 26 Nov 2007 10:16:28 -0500 Received: by ug-out-1314.google.com with SMTP id u2so2454124uge for ; Mon, 26 Nov 2007 07:16:22 -0800 (PST) Received: by 10.78.136.9 with SMTP id j9mr2977131hud.1196090181887; Mon, 26 Nov 2007 07:16:21 -0800 (PST) Received: by 10.78.170.19 with HTTP; Mon, 26 Nov 2007 07:16:21 -0800 (PST) Message-ID: <25c114b90711260716j7129c650x3af081bbab5ec97e@mail.gmail.com> Date: Mon, 26 Nov 2007 16:16:21 +0100 From: "Ulrich Herberg" To: autoconf@ietf.org, draft-ietf-autoconf-manetarch@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 746c41a248c153c2 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Subject: [Autoconf] Review of draft-ietf-autoconf-manetarch-07 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, some minor comments on the MANET architecture draft: ---------------------- typos: ---------------------- -- page 10 (section 4.2.2), paragraph 4: "In MANETs` with SBI..."; remove the genitive apostrophe -- page 12 (section 5.1), paragraph 3: "...may be assigned to the MANET routers' non-MANET interfaces(s)" ; remove first s of interfaces -- same paragraph: the prefix p should be either upper-case or lower-case but not mixed -- page 13 (section 5.2), paragraph "unique prefixes": "this requirements" -- wrong plural; should be "these requirements" or "this requirement" -- same paragraph, "One way to achieve this is /128 ..."; I would rather say "One way to achieve this is _using_ /128 [...] prefixes"... as I am not a native English speaker, I am not sure about that :-) -- same paragraph, last line: MANETs instead of MANET -- page 15 (section 7), paragraph 2: "or two network can share..."; network should be in plural -- page 16 (section 8.2), paragraph 2: "to discuss the number of MANET router to.."; router should be in plural ------------------ other issues ------------------ -- maybe I would combine section 6 and 7. They seem to belong together in a certain way -- figure 5: maybe I just didn't see it, but I cannot find a reference to this figure -- figure 6: I would definitely add some more explanations to this figure (which itself is very good) in the paragraph above of it: it could be explained why a /62 prefix is used in the delegated prefix, otherwise one could think it's a typo. Also the loopback interface is not explained in the text. One could maybe also add in the text that the address of the MANET interface of is not part of a subnet, or formulated in another way: the MANET is not a subnet. In the second paragraph of section 5.1, one could relate these nodes with the figure (to help the reader understand which nodes in the figure are exposed to the MANET characteristics and which not) -- section 8.1. "one or more IP hops - MANET, _site_,...". Is the site scope defined? Hasn't it been declared deprecated in RFC3879? -- same section, last sentence. I do not understand this sentence; why do you suddenly talk about AS, when you did never before or after this sentence? Regards, Ulrich _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 26 10:24: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 1IwfpR-0005Bq-W0; Mon, 26 Nov 2007 10:24:57 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IwfpQ-0005B9-PV for autoconf-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 10:24:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwfpQ-0005At-Dn for autoconf@ietf.org; Mon, 26 Nov 2007 10:24:56 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IwfpI-0000It-EG for autoconf@ietf.org; Mon, 26 Nov 2007 10:24:56 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-3.tower-119.messagelabs.com!1196090687!36552375!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 22768 invoked from network); 26 Nov 2007 15:24:47 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-3.tower-119.messagelabs.com with SMTP; 26 Nov 2007 15:24:47 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id lAQFOlS7024751; Mon, 26 Nov 2007 08:24:47 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id lAQFOkav008039; Mon, 26 Nov 2007 09:24:46 -0600 (CST) 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 lAQFOid9007920; Mon, 26 Nov 2007 09:24:45 -0600 (CST) Message-ID: <474AE536.8070400@gmail.com> Date: Mon, 26 Nov 2007 16:24:38 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Shubhranshu References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071124-0, 24/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Cc: autoconf@ietf.org Subject: [Autoconf] Re: Some Thoughts on Problem Statement. 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, thanks for your message. To my reading, your message has structure in it; e.g. it says which are the cases to be followed. It also seems to take into account most major ideas having already been exposed (since the little while I follow it). I agree with it. I have some comments. Overall, I'm trying to identify where and how do protocols break. Shubhranshu wrote: > All, > > Below are some thoughts that might help us a more focused discussion > and clarify some of the issues. Please send your comments such that > we can further refine / clarify them. > > > > A MANET router needs to configure an IPv6 prefix(es) on its host > interface and/or an IPv6 address on its loopback interface. Besides, > it needs to configure a /128 (or /32 in case of IPv4) and/or a link > local address on its MANET interface. I yet have to understand why MANET router has to configure a prefix on its loopback interface. It's probably by proper definition of MANET - in that case, sorry, froget it. On another hand, if a Router has a prefix in its config file and looks for a way to configure a address from that prefix on one of its real interfaces, then one possibility is to derive itself an address from its Ethernet MAC address, attach it to that prefix and then 'ifconfig' and 'route add'. Another alternative is to send RAs on its loopback interface with that prefix, and let the IPv6 stack autoconfigure address, prefix and route as usual. These are two choices. > A MANET router may also configure a prefix shorter than /128 (or /32) > on its MANET interface provided prefix uniqueness is guaranteed > [MANET-Arch I-D]. MANET node needs to configure "MANET scope" address > to communicate among themselves. "MANET Scope" addresses are > currently not specified / standardized within / outside the IETF. Ok, I think "prefix uniqueness" is something not simple to define. I think comparing addresses /128 is simple because they're fixed length. Comparing a /128 address to a set of prefixes is also simple because we have the "longest prefix match". But comparing two prefixes has many other undefined possibilities. I think though a human administrator can easily plan an addressing architecture and static routing where prefixes are unique, store those in a set of files. Also, MANET Scope is somehting I need to understand better. Is MANET Scope in any relationship with the existing scopes: link-local scope, global scope? Is MANET Scope in some relationship with the scope of the all-manet-routers IP multicast group requested by manet-iana document? Is MANET scope in some relationship with the scopes of the following Ethernet MAC multicast addresses: 33::1 (all Ethernet hosts), 33::2 (all Ethernet routers), or other Ethernet MAC multicast group scopes? _some_ relationship? _No_ relationship whatsoever? > As mentioned above, there are three interfaces under consideration > for address auto-configuration. Further detail related to these > address auto-configuration is provided below: > > 1) Configuration of loopback interface: > > It is possible that a MANET Router does not have any host attached to > its network interface or it has only MANET interface which can be > used for intra-manet communication. In the absence of any "external" > host, MANET router may configure an IPv6 global address on its > loopback interface. The traditional auto configuration procedure such > as RFC 2462, can be used for this purpose provided the MANET router > has been assigned a suitable prefix. As usual, this interface is > expected to send multicast RA/RS messages. However, in this case, > these messages would be limited to the Router's loopback interface > only. This makes me think the MANET Router doesn't communicate to anybody else than self. Its (real) network interface has no hosts attached to it (has Routers attached to it?), MANET interface is virtual and loopback interface leads to self. I may misunderstand you. Also, I will have to read other documents to understand why the loopback interface needs to have address/prefix. If I understand that then maybe I can understand the above as well. > 2) Configuration of MANET interface: > > MANET Router uses this interface to communicate with other MANET > Routers. MANET routing and other MANET specific protocols are > expected to run on this interface. This interface SHOULD be > configured with a link local address and/or a /128 (in case of IPv6) > or with /32 (in case of IPv4) address. MANET interface may also use > smaller prefix provided the prefix uniqueness is guaranteed. > Configuration of MANET interface with a link local address and/or a > /128 address is straightforward, as it can use existing mechanisms, > except the issue of address uniqueness test over "multi-hop network". I agree. If the MANET interface is virtual then I think there's no standard for defining link-local address on a virtual interface. People do different things for these, sometimes random. I think a good virtual interface (MANET interface or other) would need: -a link-local address (/128 length). -a link-local prefix (the fe80 /10 length). -maybe a global subnet prefix with global address. -maybe another global subnet prefix with a global address. I think you mean that "MANET Interface" means a sort of a label we put on a real network interface. Something that in some contexts some people call "egress interface", or "ingress interface". So, if you mean MANET Interface is a real interface, then we may already have a means to form a link-local address for it. > The probability of address duplication is quite low if most of the > /128 bits are randomly generated and so a node may skip address > uniqueness test. However, address uniqueness detection / resolution > is a requirement when smaller prefixes are used and also in military > & other critical MANET application scenarios. The address uniqueness > detection / resolution should be done across the entire network thus > requiring that the specific broadcast/multicast messages used for > this purpose be propagated "even to MANET Routers that are multi-hop > away". Currently there is no standard specification that addresses > this requirement. I think I'd suggest that when the MANET network uses subnets with well-defined link-layer multicast behaviour then the duplication should be ensured by DAD. If the MANET network doesn't use such subnets, or uses SBI (semi-broadcast interface) then the address uniqueness detection should be indeed done across the semi-subnets (maybe define semi-subnet). Or maybe that address uniqueness should be _ensured_ across the entire MANET network, probably with a detection mechanism that acts on a scope lesser than the entire MANET network. This is related to that MANET scope... I will read the tail of this message later. Thanks, Alex > 3) Configuration of Host interface: > > MANET router needs an unique prefix(es) such that it can configure > the prefix on its host interface. This prefix may further be > subnetted and used for address configuration of the hosts attached to > the MANET router. In this scenario a MANET Router should receive one > or more unique prefix(es). This is further explained below for the > scenario where DHCP server is available (i.e connected MANET) and for > the scenario where there is no server available (i.e. Standalone > MANET): > > - Scenario where DHCP server is available. > > In this case the DHCP server could be either co-located or directly > reachable to the MANET Boarder Router. If the server is directly > reachable, as shown in the figure 1 below, then MANET Boarder Router > can use existing DHCP request-reply messages (RFC 3315) between > itself and the DHCP server in order to receive prefix(es). The MANET > Boarder Router can then delegate those prefixes to the MANET routers > connected to it either directly or over multi-hop routes. It should > be noted that the link between the MANET router and its attached host > follows the classic link model and SHOULD use the relevant > traditional protocols for address configuration. > > The above mentioned DHCP request-reply mechanism normally assumes > direct or stable i.e. not a dynamic multi-hop route connectivity > expected between the requesting node and the DHCP server. MANET > routers dynamically update routes & frequently change neighborhood > and are multi-hop away from the DHCP server e.g. MR3 in Fig 1. These, > however, does not require a complete protocol design but rather puts > some requirements on the existing protocols [e.g. RFC 3633]. > Currently there is no standard to address these requirements or that > allows that MANET nodes should act as a dynamic DHCP relay. > > ----- MR1...MR3 / . +-------------+ +------------+ | / > . | | p2p | MANET |/ . | ISP Edge| > Link | Border | . | Router +---------+ Router |\ > . | | | | \ . > +-------------+ +------------+ \----- MR2 > > > Fig 1 (same as fig 1 in draft-ietf-autoconf-statement-02) > > - Scenario where no DHCP server is available. > > By its very nature, MANET environment does not always assume > availability of any pre-configured server. Even in such scenarios a > MANET router needs to configure an unique prefix. Traditionally, > protocols such as RFC 2462 are used for address configuration of > nodes in stateless manner. However, RFC 2462 defines address auto > configuration mechanisms for nodes (host and router) and as such it > does not provide any mechanism for allocating "unique prefix(es)" to > the routers. For example, in Figure 2 below, a MANET Router, say MR3, > may need to receive prefix(es) (which can be further subnetted and > used for address configuration of its attached host nodes) from the > MANET Boarder Router /Access Router. Currently no specification > exists that addresses this requirement. > > -- MR1...MR3 ....MR5 / / . / . MR4 > . \ \ \ -- MR2 ... > > Fig 2. (same as Fig 2 in draft-ietf-autoconf-statement-02) > > > Mobile and wireless nature of MANET routers result in dynamic network > topology [MANET-Arch ID, RFC 2501] which has the property of > changing neighbor nodes. These MANET properties result in network > partitioning and merger of initially isolated networks. Normally, > once an address is allocated to a node, it continues using it and > collaborating to detect and resolve duplicates in case its address is > allocated to any other node. Since initially isolated MANETs had > allocated addresses independent with each other, there remains > probability of more than one node using same address. Currently there > is no specification that solves problem of MANET "network merger > detection" and duplicate address detection/ resolution resulting due > to two / more MANETs merger. > > It is desirable that network partitioning is also detected such that > resources / prefixes that were allocated to the outgoing nodes could > be re-used. Currently there is no specification to solve the problem > of MANET "network merger detection". > ______________________________________________________________________ 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 Nov 26 13:19: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 1IwiYk-000180-V8; Mon, 26 Nov 2007 13:19:54 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IwiYk-00015r-3U for autoconf-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 13:19:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwiYj-00014Z-PY for autoconf@ietf.org; Mon, 26 Nov 2007 13:19:53 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IwiYf-0007X6-2c for autoconf@ietf.org; Mon, 26 Nov 2007 13:19:53 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-119.messagelabs.com!1196101188!27291390!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 608 invoked from network); 26 Nov 2007 18:19:48 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-119.messagelabs.com with SMTP; 26 Nov 2007 18:19:48 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lAQIJlUZ017031; Mon, 26 Nov 2007 11:19:47 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id lAQIJlMc026615; Mon, 26 Nov 2007 12:19:47 -0600 (CST) Received: from [127.0.0.1] ([10.129.41.160]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id lAQIJjfK026603; Mon, 26 Nov 2007 12:19:46 -0600 (CST) Message-ID: <474B0E40.8020802@gmail.com> Date: Mon, 26 Nov 2007 19:19:44 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ulrich Herberg Subject: Re: AUTOCONF address architecture (was: [Autoconf] Review of draft-ietf-autoconf-manetarch-07) References: <25c114b90711260716j7129c650x3af081bbab5ec97e@mail.gmail.com> In-Reply-To: <25c114b90711260716j7129c650x3af081bbab5ec97e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071124-0, 24/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 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 Ulrich, please allow me make some comments without troubling too much the waters on this topic. This document manetarch is already largely discussed and hard-agreed, and deep in the reviewing state. Ulrich Herberg wrote: [...] > MANET <~~~~~~+~~~~~~> > Interface | Delegated > | Prefix > ''''''''''''''''''''' ========== > ' MANET ' <=== P::/62 = > ' Router ' ========== > ''''''''' : ' Assigned > : ' : ' Prefix > : '++--------+' ============ > : '|Loopback |' <=== P:1::/64 = > ============ : '|P:1::L/64|' ============ > = : = : '+---------+' > = Other = : ''''''''''''' Assigned > =Interfaces= : Prefix > ============ : ============ > +...+...........+ <=== P:2::/64 = > : : ============ > +------+--+ +--+------+ > |P:2::1/64| * * * |P:2::K/64| > +---------+ +---------+ [...] The first thing I'd note is that people have already worked very hard to get agreement between several very different opinions on that figure. It's been long debated at least at public meetings and it's been very difficult for many people to finally agree on it - I respect the work and I don't oppose it. That said. > -- figure 6: I would definitely add some more explanations to this > figure (which itself is very good) in the paragraph above of it: it > could be explained why a /62 prefix is used in the delegated prefix, > otherwise one could think it's a typo. To me, that /62 is clear. It means that a MANET Router is allocated that prefix. That prefix is further divided by that Router's logic into some /64 prefixes which are then assigned on interfaces (presumably for Ethernet EID SLAAC stateless autoconf to work ok to the hosts attached). My personal understanding is that this is hierarchically aggregated prefixes, and it is good and an obvious common denominator - I agree with it. What's not clear to me is the "P" - what does it mean. Is it a 32bit string? Less? It's not common IPv6 notation, but it is conceptually understandable. I wrote to authors and there seems to be suggestion to substitute "2001:db8::/32" (RFC3849 "IPv6 Address Prefix Reserved for Documentation") for "P", for a more precise IPv6 notation. Further, what _could_ be clearer, is _probably_ an IPv6 Addressing Architecture for AUTOCONF, that would show both that hierarchically aggregated prefixes _and_ some completely non-aggregated prefixes for a completely non-hierarchical topology. That's difficult to draw for at least two reasons: (1) how could a MANET Router be at such top routing level such to have two prefixes differing on the first (!) bit on two of its interfaces - these are typically huge Router farms not small MANET Routers and (2) there's only one prefix reserved for documentation (2001:db8::/32) so whatever two prefixes one will derive from it they'll always be shown somehow aggregated. I think it's tough to illustrate a suggestive non-hierarchical non-aggregated example. I am not sure whether this non-hierarchical non-aggregated AUTOCONF IPv6 Addressing Architecture is relevant for MANET, or just one of its particular cases. It's just that people mention very often that MANETs are non-hierarchical, so I think a figure would be more support for it. > Also the loopback interface is not explained in the text. I'm also surprised it's indeed not explained in the manetarch text. But for this also there seems to be already agreement that MANET uses the loopback interface in a special way. It could be very difficult to get it modified in that document. I think it's very hard to modify existing consensus - I wouldn't try. At some point I could live without knowing what the manetarch document use intends to make out of the loopback interface as long as AUTOCONF mechanism would work without any special loopback treatment too in some cases. My two cents worth. > One could maybe also add in the text that the address of the MANET > interface of is not part of a subnet, or formulated in another way: > the MANET is not a subnet. sorry, I'm confused by the "of is not" text above? > In the second paragraph of section 5.1, one could relate these nodes > with the figure (to help the reader understand which nodes in the > figure are exposed to the MANET characteristics and which not) -- > section 8.1. "one or more IP hops - MANET, _site_,...". Is the site > scope defined? Hasn't it been declared deprecated in RFC3879? I agree. > -- same section, last sentence. I do not understand this sentence; > why do you suddenly talk about AS, when you did never before or after > this sentence? I think you mean this manetarch draft sentence: > Different frameworks for autoconfiguration, network management, and > routing within an Autonomous System (AS) can be developed based upon > the expected constraints and operating conditions. I think it meant eg AUTOCONF could develop a new autoconfiguration mechanism (like SLAAC/DHCP), and maybe a new SNMP extension or even a BGP extension; and that three should be different. I read it highly conceptual, I can live ok with it. Of course, that's my humble interpretation. Thanks, 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 Nov 26 13:55:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwj6w-0008Qn-6K; Mon, 26 Nov 2007 13:55:14 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Iwj6u-0008Oc-Sb for autoconf-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 13:55:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwj6u-0008N5-GF for autoconf@ietf.org; Mon, 26 Nov 2007 13:55:12 -0500 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwj6q-0008VU-Tn for autoconf@ietf.org; Mon, 26 Nov 2007 13:55:12 -0500 Received: by nf-out-0910.google.com with SMTP id d21so718653nfb for ; Mon, 26 Nov 2007 10:55:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=FWffcUp3Sdg10NMWkbp7paQmOQxxoGvMo6NB6H4fY00=; b=vDc4MRwFoxdYDkeVt8l+HGuoLAKHv7Ut86AIWNFupqfsHX8k8safqDavrvYgjkW09DjZgrh4tDCQ8F9gjjDN1VGcxUcL5J3bX68oBsg2uxhSKK6+gRQju32Zgwr5yIFViIyJGyljxLb8MV78KaAChZGVrU4ItMHPAuBbB96CW38= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uZFPB+kWprMiQiSqAnQU81ysjv6GnBCPKhBg4MGI7grjA7EQfOig2UkyaSC3WRxs77P0v/9aZAQ0yPDWGIRI2LySIavGgc0Pp+8bdD5iOPsGxMDbmFYU2CaS6IQTiTbzrjdtU7K6ZcTxZ5Drfb21XUjIRzKYFLIvDPwA5i3wGyg= Received: by 10.78.122.16 with SMTP id u16mr3342448huc.1196103307444; Mon, 26 Nov 2007 10:55:07 -0800 (PST) Received: by 10.78.33.7 with HTTP; Mon, 26 Nov 2007 10:55:07 -0800 (PST) Message-ID: <374005f30711261055t75723cc0hcc322bee430d702b@mail.gmail.com> Date: Tue, 27 Nov 2007 00:25:07 +0530 From: "Ian Chakeres" To: "Ulrich Herberg" In-Reply-To: <25c114b90711260716j7129c650x3af081bbab5ec97e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <25c114b90711260716j7129c650x3af081bbab5ec97e@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: autoconf@ietf.org Subject: [Autoconf] Re: Review of draft-ietf-autoconf-manetarch-07 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 Thank you very much for the detailed review. I will work to integrate your comments in my local revision. I plan to submit an update based on the feedback recently received when I-D submission opens again. Thanks. Ian Chakeres On Nov 26, 2007 8:46 PM, Ulrich Herberg wrote: > Hi, > > some minor comments on the MANET architecture draft: > ---------------------- > typos: > ---------------------- > > -- page 10 (section 4.2.2), paragraph 4: "In MANETs` with SBI..."; > remove the genitive apostrophe > -- page 12 (section 5.1), paragraph 3: "...may be assigned to the > MANET routers' non-MANET interfaces(s)" ; remove first s of interfaces > -- same paragraph: the prefix p should be either upper-case or > lower-case but not mixed > -- page 13 (section 5.2), paragraph "unique prefixes": "this > requirements" -- wrong plural; should be "these requirements" or "this > requirement" > -- same paragraph, "One way to achieve this is /128 ..."; I would > rather say "One way to achieve this is _using_ /128 [...] prefixes"... > as I am not a native English speaker, I am not sure about that :-) > -- same paragraph, last line: MANETs instead of MANET > -- page 15 (section 7), paragraph 2: "or two network can share..."; > network should be in plural > -- page 16 (section 8.2), paragraph 2: "to discuss the number of > MANET router to.."; router should be in plural > > > ------------------ > other issues > ------------------ > -- maybe I would combine section 6 and 7. They seem to belong > together in a certain way > -- figure 5: maybe I just didn't see it, but I cannot find a > reference to this figure > -- figure 6: I would definitely add some more explanations to this > figure (which itself is very good) in the paragraph above of it: it > could be explained why a /62 prefix is used in the delegated prefix, > otherwise one could think it's a typo. Also the loopback interface is > not explained in the text. One could maybe also add in the text that > the address of the MANET interface of is not part of a subnet, or > formulated in another way: the MANET is not a subnet. In the second > paragraph of section 5.1, one could relate these nodes with the figure > (to help the reader understand which nodes in the figure are exposed > to the MANET characteristics and which not) > -- section 8.1. "one or more IP hops - MANET, _site_,...". Is the > site scope defined? Hasn't it been declared deprecated in RFC3879? > -- same section, last sentence. I do not understand this sentence; > why do you suddenly talk about AS, when you did never before or after > this sentence? > > Regards, > Ulrich > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 27 03:34: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 1IwvtM-0001Ss-LH; Tue, 27 Nov 2007 03:34:04 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IwvtL-0001Se-1t for autoconf-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 03:34:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwvtH-0001Ro-Qa for autoconf@ietf.org; Tue, 27 Nov 2007 03:33:59 -0500 Received: from wr-out-0506.google.com ([64.233.184.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwvtD-0002Wf-Sr for autoconf@ietf.org; Tue, 27 Nov 2007 03:33:59 -0500 Received: by wr-out-0506.google.com with SMTP id 68so695164wra for ; Tue, 27 Nov 2007 00:33:55 -0800 (PST) Received: by 10.78.204.1 with SMTP id b1mr3812173hug.1196152433918; Tue, 27 Nov 2007 00:33:53 -0800 (PST) Received: by 10.78.170.19 with HTTP; Tue, 27 Nov 2007 00:33:53 -0800 (PST) Message-ID: <25c114b90711270033k1a05e8b5ld3547e20949521ea@mail.gmail.com> Date: Tue, 27 Nov 2007 09:33:53 +0100 From: "Ulrich Herberg" To: "Alexandru Petrescu" Subject: Re: [Autoconf] Re: Some Thoughts on Problem Statement. In-Reply-To: <474AE536.8070400@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <474AE536.8070400@gmail.com> X-Google-Sender-Auth: 6dc408da9390f8cd X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: autoconf@ietf.org, Shubhranshu 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 Alexandru, hello Shubhranshu, I also think that the text by Shubhranshu is very useful; some comments inline... On 11/26/07, Alexandru Petrescu wrote: > > A MANET router needs to configure an IPv6 prefix(es) on its host > > interface and/or an IPv6 address on its loopback interface. Besides, > > it needs to configure a /128 (or /32 in case of IPv4) and/or a link > > local address on its MANET interface. > > I yet have to understand why MANET router has to configure a prefix on > its loopback interface. It's probably by proper definition of MANET - > in that case, sorry, froget it. To my understanding, this loopback interface serves as a "logical" host on the MANET node (correct me if I am wrong). As in real-life scenarios, most of the time a mobile node will not only be a router but some mobile device (PDA, laptop, ...), it will run some applications on it (e.g. web browser). The loopback interface definitely needs to be explained in the manetarch draft as I am also not sure whether my explanation is correct. Another reason of using the loopback interface could be to not attribute an IP address to the MANET interface but using unnumbered interfaces (as specified by Cisco). > On another hand, if a Router has a prefix in its config file and looks > for a way to configure a address from that prefix on one of its real > interfaces, then one possibility is to derive itself an address from its > Ethernet MAC address, attach it to that prefix and then 'ifconfig' and > 'route add'. Another alternative is to send RAs on its loopback > interface with that prefix, and let the IPv6 stack autoconfigure > address, prefix and route as usual. These are two choices. I think that this is correct. While the first case is simpler, it would mean changing the way of how a network interface is configured. By the way, do you know how the loopback interface in for example Linux is configured? That would be an interesting comparison. Sure, it normally has ::1/128 as fixed address, but could one assign prefixes to it using RA messages? > > A MANET router may also configure a prefix shorter than /128 (or /32) > > on its MANET interface provided prefix uniqueness is guaranteed > > [MANET-Arch I-D]. MANET node needs to configure "MANET scope" address > > to communicate among themselves. "MANET Scope" addresses are > > currently not specified / standardized within / outside the IETF. > > Ok, I think "prefix uniqueness" is something not simple to define. > > I think comparing addresses /128 is simple because they're fixed length. > > Comparing a /128 address to a set of prefixes is also simple because we > have the "longest prefix match". > > But comparing two prefixes has many other undefined possibilities. > > I think though a human administrator can easily plan an addressing > architecture and static routing where prefixes are unique, store those > in a set of files. I think your concern is what happens if you compare two prefixes which are shorter than /128. My guess is that you still have to check for uniqueness of all 128 bits, as you we still talk about IP addresses (not prefixes) on the MANET interface. (prefixes are only later assigned on the egress interface of the router). However, the following situation could appear: two MANET interfaces configured with the following addresses: -- node A: a:b:c:d/64 (where each letter means 2 bytes) -- node B: a:b:c:d:e/64 The IP addresses are still unique, however, B would be in the subnet of A. That's probably bad... > Also, MANET Scope is somehting I need to understand better. Is MANET > Scope in any relationship with the existing scopes: link-local scope, > global scope? Is MANET Scope in some relationship with the scope of the > all-manet-routers IP multicast group requested by manet-iana document? > > Is MANET scope in some relationship with the scopes of the following > Ethernet MAC multicast addresses: 33::1 (all Ethernet hosts), 33::2 (all > Ethernet routers), or other Ethernet MAC multicast group scopes? > > _some_ relationship? _No_ relationship whatsoever? I don't know... I do not think that there is a common agreement on this term. The border between a MANET and the Internet using an ICP might be understandable (even though it has also been remarked that when a MANET is connected to the Internet, it is at that moment part of the Internet). However, when two or more MANETs are in the direct neighborhod and do not merge but instead add inter-MANET routes between them using aggregation, the MANET scope is less evident for me. If MANETs could for example use aggregation for different hierarchical levels of prefixes, it might be difficult to say: "The MANET ends _here_". > > As mentioned above, there are three interfaces under consideration > > for address auto-configuration. Further detail related to these > > address auto-configuration is provided below: > > > > 1) Configuration of loopback interface: > > > > It is possible that a MANET Router does not have any host attached to > > its network interface or it has only MANET interface which can be > > used for intra-manet communication. In the absence of any "external" > > host, MANET router may configure an IPv6 global address on its > > loopback interface. The traditional auto configuration procedure such > > as RFC 2462, can be used for this purpose provided the MANET router > > has been assigned a suitable prefix. As usual, this interface is > > expected to send multicast RA/RS messages. However, in this case, > > these messages would be limited to the Router's loopback interface > > only. > > This makes me think the MANET Router doesn't communicate to anybody > else than self. Its (real) network interface has no hosts attached to > it (has Routers attached to it?), MANET interface is virtual and > loopback interface leads to self. I may misunderstand you. > > Also, I will have to read other documents to understand why the loopback > interface needs to have address/prefix. If I understand that then maybe > I can understand the above as well. Same for me :-) That's why a description of the loopback interface would be nice in the manetarch draft. > > > 2) Configuration of MANET interface: > > > > MANET Router uses this interface to communicate with other MANET > > Routers. MANET routing and other MANET specific protocols are > > expected to run on this interface. This interface SHOULD be > > configured with a link local address and/or a /128 (in case of IPv6) > > or with /32 (in case of IPv4) address. MANET interface may also use > > smaller prefix provided the prefix uniqueness is guaranteed. > > Configuration of MANET interface with a link local address and/or a > > /128 address is straightforward, as it can use existing mechanisms, > > except the issue of address uniqueness test over "multi-hop network". > > I agree. > > If the MANET interface is virtual then I think there's no standard for > defining link-local address on a virtual interface. People do different > things for these, sometimes random. I don't understand this. Why do you say it is a virtual interface? I thought that it is a real interface on a mobile node, and that it is the only interface on the node which knows and cares about MANET characteristics (e.g. by running a MANET routing protocol on it). > > I think a good virtual interface (MANET interface or other) would need: > -a link-local address (/128 length). > -a link-local prefix (the fe80 /10 length). > -maybe a global subnet prefix with global address. > -maybe another global subnet prefix with a global address. > > I think you mean that "MANET Interface" means a sort of a label we put > on a real network interface. Something that in some contexts some > people call "egress interface", or "ingress interface". > > So, if you mean MANET Interface is a real interface, then we may already > have a means to form a link-local address for it. Ah, know I think I understood you. So you mean that a MANET interface is virtual in the sense that it only a "caption" somehow for a real (e.g. 802.11) network interface, do you? Well, to my understanding it probably makes thinks more complicate to talk about a virtual interface instead of a "real" MANET interface Regards, Ulrich _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 27 04:52:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwx74-0004IU-GS; Tue, 27 Nov 2007 04:52:18 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Iwx70-0004GC-Ow for autoconf-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 04:52:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwx70-0004Ft-Dx for autoconf@ietf.org; Tue, 27 Nov 2007 04:52:14 -0500 Received: from hpsmtp-eml11.kpnxchange.com ([213.75.38.111]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwx6z-0004Ym-PJ for autoconf@ietf.org; Tue, 27 Nov 2007 04:52:14 -0500 Received: from hpsmtp-eml04.kpnxchange.com ([213.75.38.104]) by hpsmtp-eml11.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 10:52:12 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml04.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 10:52:12 +0100 From: "Teco Boot" To: References: <25c114b90711260605n22e6f879ve8e4f8fd77d1a8ed@mail.gmail.com> <474ADD38.5090403@gmail.com> In-Reply-To: <474ADD38.5090403@gmail.com> Date: Tue, 27 Nov 2007 10:52:12 +0100 Message-ID: <002501c830db$2edd5f50$8c981df0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgwO9CKwE7utxyzTHO2OyyD75v+ZwAnRtGw Content-Language: nl X-OriginalArrivalTime: 27 Nov 2007 09:52:12.0666 (UTC) FILETIME=[2F200DA0:01C830DB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Autoconf] draft-ietf-autoconf-statement and link-locals 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 Some questions on recent discussion on draft-ietf-autoconf-statement-03.txt: Is there a -03 version? Recently, it is posted that a MANET Interface have a unique prefix (e.g. /128) and/or a link local address. I do not understand why there would be no link-local. E.g. for OSPFv3 (and OSPFv3-MANET, I do not expect an update): >>>> RFC2740, page 6: >>>> OSPF for IPv6 assumes that each router has been assigned >>>> link-local unicast addresses on each of the router's attached >>>> physical segments. I think adding a unique prefix is OK, to be used for communication with nodes on other links. But why not using the link local for MANET Routing protocols and other link-local protocols? This seems so obvious to me. I think the impact on using an unique prefix as source address for routing protocols is not well understood. I know I speak for myself;-) Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 27 05:03:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwxHb-00085G-AH; Tue, 27 Nov 2007 05:03:11 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IwxHa-00084y-6x for autoconf-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 05:03:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwxHZ-00084m-SL for autoconf@ietf.org; Tue, 27 Nov 2007 05:03:09 -0500 Received: from mail2-relais-roc.national.inria.fr ([192.134.164.83]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwxHZ-0005am-8C for autoconf@ietf.org; Tue, 27 Nov 2007 05:03:09 -0500 X-IronPort-AV: E=Sophos;i="4.23,218,1194217200"; d="scan'208";a="4650816" Received: from sphinx.lix.polytechnique.fr (HELO BoolfightMaN-Laptop.local) ([129.104.11.1]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Nov 2007 11:03:08 +0100 Message-ID: <474BEB5C.9090001@inria.fr> Date: Tue, 27 Nov 2007 11:03:08 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org Subject: Re: [Autoconf] Goals of MANET autoconf References: <4746E44D.3060102@inria.fr> <4746E524.4050800@inria.fr> <008a01c8303b$26611740$732345c0$@nl> In-Reply-To: <008a01c8303b$26611740$732345c0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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, Teco Boot a écrit : > Hi Emmanuel, > > I agree on all 3 items. OK > > Reading back the items, I have some thoughts: > > What is the scope? IPv6 only? yes, we are chartered for IPv6 only. > Is ND to be replaced with something new? > Maybe? I guess we should make clear in the PS what are the issues with using ND. > Has item 3 anything to do with item 2? Or is it a sub-goal on item 1? > Shouldn't we try to prevent non-unique prefixes instead of detecting / > resolving? > I guess the distinction here is between in-service and pre-service uniqueness. So item 3 is more about in-service, and item 1 is more about pre-service. > On item 2, do we care on "routable"? Yes. I think we should add this precision in the items, so they would read: 1. provide MANET-wide unique prefixes (up to /128) to each MANET router 2. if one or more Internet Gateway is reachable, provide routable unique global prefixes to each MANET router 3. detect and resolve if non-unique prefixes are assigned to MANET routers (e.g. as a result of a network partitioning/merger) Emmanuel > >> -----Oorspronkelijk bericht----- >> Van: Emmanuel Baccelli [mailto:Emmanuel.Baccelli@inria.fr] >> Verzonden: vrijdag 23 november 2007 15:35 >> Aan: autoconf@ietf.org >> Onderwerp: [Autoconf] Goals of MANET autoconf >> >> All, >> >> over the last 3 IETF meetings, there seemed to be a large consensus >> that >> the goals of MANET autoconfiguration are (verbatim from the >> presentation >> in Prague): >> >> >> 1. provide MANET-wide unique prefixes (up to /128) to each MANET router >> >> 2. if one or more Internet Gateway is reachable, provide unique global >> prefixes to each MANET router >> >> 3. detect and resolve if non-unique prefixes are assigned to MANET >> routers (e.g. as a result of a network partitioning/merger) >> >> >> Is there still a consensus? Is there some disagreement on these items? >> >> Emmanuel >> >> >> _______________________________________________ >> 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 Nov 27 05:19:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwxXU-0005JB-MW; Tue, 27 Nov 2007 05:19:36 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IwxXT-0005IN-92 for autoconf-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 05:19:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwxXS-0005Hu-VQ for autoconf@ietf.org; Tue, 27 Nov 2007 05:19:34 -0500 Received: from mail2-relais-roc.national.inria.fr ([192.134.164.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwxXP-0004C5-E9 for autoconf@ietf.org; Tue, 27 Nov 2007 05:19:34 -0500 X-IronPort-AV: E=Sophos;i="4.23,219,1194217200"; d="scan'208";a="4651509" Received: from sphinx.lix.polytechnique.fr (HELO BoolfightMaN-Laptop.local) ([129.104.11.1]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Nov 2007 11:19:30 +0100 Message-ID: <474BEF32.6000808@inria.fr> Date: Tue, 27 Nov 2007 11:19:30 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org Subject: Re: [Autoconf] Goals of MANET autoconf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 All, In order to agree on proposed or existing text, we have to agree on axioms. The following step would be to reshape -03 tightly around such axioms. Previously, there was an agreement on the following axioms. Now does anybody think the following items need to be updated/completed? If so how exactly? Please be vocal if you think they are good enough, or not. 1. provide MANET-wide unique prefixes (up to /128) to each MANET router 2. if one or more Internet Gateway is reachable, provide routable unique global prefixes to each MANET router 3. detect and resolve if non-unique prefixes are assigned to MANET routers (e.g. as a result of a network partitioning/merger) Regards Emmanuel _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 27 06:23: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 1IwyXB-0005jK-PF; Tue, 27 Nov 2007 06:23:21 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IwyXA-0005iu-1j for autoconf-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 06:23:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwyX9-0005iX-DV for autoconf@ietf.org; Tue, 27 Nov 2007 06:23:19 -0500 Received: from hpsmtp-eml11.kpnxchange.com ([213.75.38.111]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwyX8-00059u-Dr for autoconf@ietf.org; Tue, 27 Nov 2007 06:23:18 -0500 Received: from hpsmtp-eml01.kpnxchange.com ([213.75.38.101]) by hpsmtp-eml11.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 12:23:16 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml01.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 12:23:07 +0100 From: "Teco Boot" To: "'Emmanuel Baccelli'" , References: <474BEF32.6000808@inria.fr> In-Reply-To: <474BEF32.6000808@inria.fr> Subject: RE: [Autoconf] Goals of MANET autoconf Date: Tue, 27 Nov 2007 12:23:05 +0100 Message-ID: <002701c830e7$e226a060$a673e120$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acgw3xxCfSyp4Sm8TUORtFlu8ErEkgABqArQ Content-Language: nl X-OriginalArrivalTime: 27 Nov 2007 11:23:07.0910 (UTC) FILETIME=[E2B43A60:01C830E7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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 Hi Emmanual, On item 3, the text: "as a result of a network partitioning/merger", I think it is impossible having non-unique global addresses after a merge; where before the merge addresses were globally unique. Or maybe earth merged with mars;-) And partitioning should be removed, as discussed before. Personally I would use Addresses instead of Prefixes, to be compliant with charter. For a /128 prefix, there is not much difference with an address. I think the Prefix Delegation discussion is interesting, but strictly spoken we are not chartered for this. We are chartered for issues related to "prefix and/or address providing entities". IMHO discuss PD is OK, but we should first describe problems with address assignment before taking steps into PD. Writing the PS this way is OK for me. But be careful, PD is a step into solution space. === More on ND: I prefer keeping ND for link-layer address determination. I don't think we discuss replacing this. I agree on describing problems with ND in PS first. On problems with ND, which WG is describing problems with Redirect Messages? I think on SBI, Redirect Messages should not be sent. As simple as that. But where is this defined? Add something in PS that this is to be worked out? Teco. > -----Oorspronkelijk bericht----- > Van: Emmanuel Baccelli [mailto:Emmanuel.Baccelli@inria.fr] > Verzonden: dinsdag 27 november 2007 11:20 > Aan: autoconf@ietf.org > Onderwerp: Re: [Autoconf] Goals of MANET autoconf > > All, > > > In order to agree on proposed or existing text, we have to agree on > axioms. The following step would be to reshape -03 tightly around such > axioms. > > Previously, there was an agreement on the following axioms. Now does > anybody think the following items need to be updated/completed? If so > how exactly? Please be vocal if you think they are good enough, or not. > > > 1. provide MANET-wide unique prefixes (up to /128) to each MANET router > > 2. if one or more Internet Gateway is reachable, provide routable > unique > global prefixes to each MANET router > > 3. detect and resolve if non-unique prefixes are assigned to MANET > routers (e.g. as a result of a network partitioning/merger) > > > Regards > Emmanuel > > > _______________________________________________ > 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 Nov 27 08:58: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 1Ix0xk-0003Ge-BY; Tue, 27 Nov 2007 08:58:56 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Ix0xj-0003GV-Ic for autoconf-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 08:58:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix0xj-0003GJ-2M for autoconf@ietf.org; Tue, 27 Nov 2007 08:58:55 -0500 Received: from mail2-relais-roc.national.inria.fr ([192.134.164.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix0xh-0005yy-9i for autoconf@ietf.org; Tue, 27 Nov 2007 08:58:55 -0500 X-IronPort-AV: E=Sophos;i="4.23,219,1194217200"; d="scan'208";a="4660588" Received: from ras75-3-82-226-221-97.fbx.proxad.net (HELO BoolfightMaN-Laptop.local) ([82.226.221.97]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Nov 2007 14:58:52 +0100 Message-ID: <474C229C.1060501@inria.fr> Date: Tue, 27 Nov 2007 14:58:52 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org Subject: Re: [Autoconf] Goals of MANET autoconf References: <474BEF32.6000808@inria.fr> <002701c830e7$e226a060$a673e120$@nl> In-Reply-To: <002701c830e7$e226a060$a673e120$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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, Teco Boot a écrit : > Hi Emmanual, > > On item 3, the text: "as a result of a network partitioning/merger", I think > it is impossible having non-unique global addresses after a merge; where > before the merge addresses were globally unique. Or maybe earth merged with > mars;-) > And partitioning should be removed, as discussed before. I agree with removing the mention of partitionning here. But as far as non-unique addresses are concerned, I disagree. There are types of addresses other than global. And in this case they may not be unique after a merger for instance. So maybe we could talk more specifically about non-unicity of addresses of types other than global? > > Personally I would use Addresses instead of Prefixes, to be compliant with > charter. > For a /128 prefix, there is not much difference with an address. > I think the Prefix Delegation discussion is interesting, but strictly spoken > we are not chartered for this. We are chartered for issues related to > "prefix and/or address providing entities". IMHO discuss PD is OK, but we > should first describe problems with address assignment before taking steps > into PD. Writing the PS this way is OK for me. But be careful, PD is a step > into solution space. > I agree. But since we are, as you mention, to talk about "prefixes and/or addresses" then we should not restrain from talking about prefixes too, right? So how about this formulation: 1. provide MANET-scoped unique addresses and/or prefixes to each MANET router 2. if one or more Internet Gateway is reachable, provide routable unique global addresses and/or prefixes to each MANET router 3. detect and resolve if duplicated MANET-scoped addresses and/or prefixes are assigned to MANET routers (e.g. as a result of a network merger) > > More on ND: > I prefer keeping ND for link-layer address determination. I don't think we > discuss replacing this. > I agree on describing problems with ND in PS first. > OK. So let's work on that. > On problems with ND, which WG is describing problems with Redirect Messages? > > I think on SBI, Redirect Messages should not be sent. As simple as that. But > where is this defined? Add something in PS that this is to be worked out? > > Teco. > >> -----Oorspronkelijk bericht----- >> Van: Emmanuel Baccelli [mailto:Emmanuel.Baccelli@inria.fr] >> Verzonden: dinsdag 27 november 2007 11:20 >> Aan: autoconf@ietf.org >> Onderwerp: Re: [Autoconf] Goals of MANET autoconf >> >> All, >> >> >> In order to agree on proposed or existing text, we have to agree on >> axioms. The following step would be to reshape -03 tightly around such >> axioms. >> >> Previously, there was an agreement on the following axioms. Now does >> anybody think the following items need to be updated/completed? If so >> how exactly? Please be vocal if you think they are good enough, or not. >> >> >> 1. provide MANET-wide unique prefixes (up to /128) to each MANET router >> >> 2. if one or more Internet Gateway is reachable, provide routable >> unique >> global prefixes to each MANET router >> >> 3. detect and resolve if non-unique prefixes are assigned to MANET >> routers (e.g. as a result of a network partitioning/merger) >> >> >> Regards >> Emmanuel >> >> >> _______________________________________________ >> 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 Nov 27 09:10: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 1Ix18Y-0006St-Tc; Tue, 27 Nov 2007 09:10:06 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Ix18X-0006SY-D4 for autoconf-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 09:10:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix18X-0006SE-15 for autoconf@ietf.org; Tue, 27 Nov 2007 09:10:05 -0500 Received: from ns1.its.eads.net ([193.56.40.66] helo=mx1.its.eads.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix18W-0001yg-43 for autoconf@ietf.org; Tue, 27 Nov 2007 09:10:04 -0500 Received: from fr-gate1.mailhub.intra.corp ([53.154.16.33]) by mx1.its.eads.net with Microsoft SMTPSVC(6.0.3790.2499); Tue, 27 Nov 2007 15:07:43 +0100 Received: from ZFRMSXIDF01.edsn.com ([10.37.0.36]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.6713); Tue, 27 Nov 2007 15:13:17 +0100 Received: by ZFRMSXIDF01.edsn.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Nov 2007 15:10:02 +0100 Message-ID: <03AB04489317984CAC194CAAC9EDD9420648BD06@ZFRMSXIDF05.edsn.com> From: "Hahusseau, Thomas" To: autoconf@ietf.org Date: Tue, 27 Nov 2007 15:09:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-OriginalArrivalTime: 27 Nov 2007 14:13:17.0474 (UTC) FILETIME=[A8141020:01C830FF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Subject: [Autoconf] Autoconf implementations ? 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="===============1533548447==" Errors-To: autoconf-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1533548447== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C830FF.3041A9A4" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C830FF.3041A9A4 Content-Type: text/plain Hello, This is my first email on that list. I would like to know if there is some implementation of autoconfiguration protocols for standalone MANETs under development ? the only ones I found were a couple years old : - Pacman feb 2005 - Manet:Prophet may 2004 - NOA-OLSR jul 2005 The only one which seems to be still supported is AHCPd : nov 2007 Most of them doesn't work on recent kernel (2.6.x), because they use ipqueue which seems to be deprecated on 2.6.x kernels. Does anyone know where I could find recent implementation of autoconfiguration protocols for MANETs ? All projects about autoconfiguration implementations seems to be dead (except AHCP) or what ? It's hard to believe that nobody works on it, because there few mails on that list about comments on draft and the WG doesn't look to be dead. Your sincerely Thomas Hahusseau ------_=_NextPart_001_01C830FF.3041A9A4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Autoconf implementations ?

Hello,

This is my first = email on that list. I would like = to know if there is some implementation of autoconfiguration = protocols for standalone = MANETs under development = ? the only ones I found were = a couple years old :

- Pacman feb = 2005

- Manet:Prophet may = 2004

- NOA-OLSR jul = 2005

The only one which seems = to be still supported is AHCPd : nov 2007

Most of them = doesn't work on recent kernel (2.6.x), because they use = ipqueue which seems to = be deprecated on 2.6.x kernels. = Does anyone know where I could find = recent implementation of autoconfiguration protocols for MANETs = ? All projects = about autoconfiguration implementations seems to be dead = (except AHCP) or what = ? It's hard to = believe that nobody works on it, because there few mails on that list = about comments on draft and the WG doesn't look to be = dead.

Your sincerely

Thomas = Hahusseau

 

------_=_NextPart_001_01C830FF.3041A9A4-- --===============1533548447== 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 --===============1533548447==-- From autoconf-bounces@ietf.org Tue Nov 27 09:46: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 1Ix1he-0004ZT-R5; Tue, 27 Nov 2007 09:46:22 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Ix1hd-0004ZM-Le for autoconf-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 09:46:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix1hd-0004Z5-5h for autoconf@ietf.org; Tue, 27 Nov 2007 09:46:21 -0500 Received: from hpsmtp-eml12.kpnxchange.com ([213.75.38.112]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix1hb-0000Dv-Rv for autoconf@ietf.org; Tue, 27 Nov 2007 09:46:20 -0500 Received: from hpsmtp-eml02.kpnxchange.com ([213.75.38.102]) by hpsmtp-eml12.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 15:46:18 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml02.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 15:46:12 +0100 From: "Teco Boot" To: "'Emmanuel Baccelli'" References: <474BEF32.6000808@inria.fr> <002701c830e7$e226a060$a673e120$@nl> <474C229C.1060501@inria.fr> In-Reply-To: <474C229C.1060501@inria.fr> Subject: RE: [Autoconf] Goals of MANET autoconf Date: Tue, 27 Nov 2007 15:46:09 +0100 Message-ID: <005901c83104$408be7c0$c1a3b740$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acgw/cWYg7n8q8gbTBqn1T06JelXrwAAJjxQ Content-Language: nl X-OriginalArrivalTime: 27 Nov 2007 14:46:12.0584 (UTC) FILETIME=[4155EE80:01C83104] X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 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, On 3, now the text includes "duplicated MANET-scoped addresses". OK, but reworded, see below. On changing addresses in addresses and/or prefixes, I don't know what = you intent to do with the text. It is a bit tiny for the content of a = section and a bit long for a name for a chapter. If the PS text explains that for configuring an IP address on an = interface (assignment), a prefix length is needed and thus an IP address = assignment is the same as a prefix assignment, I am OK. This assigned prefix is also to be added in the MANET protocol, and = there it is called a prefix. A minor issue: 1 and 2 mentions "to each MANET router". I don't think it is mandatory = to provide addresses / prefixes to all MANET routers. Only when they need = it. Maybe a MANET Router only wants to relay (no local or global address = needed) or only want to use the Internet (only global address needed) or only = want inner-MANET communication (only local address needed). What about changing "to each MANET router" into "to MANET routers" (like item 3). I don't know what MANET-scoped is. I can guess the intention. I will = react when reading PS text on this. For now: I do not like an introduction of some kind of scoping, like site-scope or MANET_ID. I used other wording below, for what I think = what was your intention. Proposal with corrections, also some rewording for being more compliant = with charter: 1. provide unique local addresses and/or prefixes to MANET routers for inner-MANET communication 2. if one or more Internet Gateway(s) is (are) reachable, provide = globally routable unique addresses and/or prefixes to MANET routers 3. detect and resolve if duplicated local addresses and/or prefixes are assigned to MANET routers (e.g. as a result of a network merger) Teco. > -----Oorspronkelijk bericht----- > Van: Emmanuel Baccelli [mailto:Emmanuel.Baccelli@inria.fr] > Verzonden: dinsdag 27 november 2007 14:59 > Aan: autoconf@ietf.org > Onderwerp: Re: [Autoconf] Goals of MANET autoconf >=20 > Hi Teco, >=20 > Teco Boot a =E9crit : > > Hi Emmanual, > > > > On item 3, the text: "as a result of a network partitioning/merger", > I think > > it is impossible having non-unique global addresses after a merge; > where > > before the merge addresses were globally unique. Or maybe earth > merged with > > mars;-) > > And partitioning should be removed, as discussed before. >=20 > I agree with removing the mention of partitionning here. But as far as > non-unique addresses are concerned, I disagree. There are types of > addresses other than global. And in this case they may not be unique > after a merger for instance. So maybe we could talk more specifically > about non-unicity of addresses of types other than global? >=20 >=20 > > > > Personally I would use Addresses instead of Prefixes, to be = compliant > with > > charter. > > For a /128 prefix, there is not much difference with an address. > > I think the Prefix Delegation discussion is interesting, but = strictly > spoken > > we are not chartered for this. We are chartered for issues related = to > > "prefix and/or address providing entities". IMHO discuss PD is OK, > but we > > should first describe problems with address assignment before taking > steps > > into PD. Writing the PS this way is OK for me. But be careful, PD is > a step > > into solution space. > > >=20 > I agree. But since we are, as you mention, to talk about "prefixes > and/or addresses" then we should not restrain from talking about > prefixes too, right? So how about this formulation: >=20 >=20 > 1. provide MANET-scoped unique addresses and/or prefixes to each MANET > router >=20 > 2. if one or more Internet Gateway is reachable, provide routable > unique > global addresses and/or prefixes to each MANET router >=20 > 3. detect and resolve if duplicated MANET-scoped addresses and/or > prefixes are assigned to MANET routers (e.g. as a result of a network > merger) >=20 >=20 > > > > More on ND: > > I prefer keeping ND for link-layer address determination. I don't > think we > > discuss replacing this. > > I agree on describing problems with ND in PS first. > > >=20 > OK. So let's work on that. >=20 > > On problems with ND, which WG is describing problems with Redirect > Messages? > > > > I think on SBI, Redirect Messages should not be sent. As simple as > that. But > > where is this defined? Add something in PS that this is to be worked > out? > > > > Teco. > > > >> -----Oorspronkelijk bericht----- > >> Van: Emmanuel Baccelli [mailto:Emmanuel.Baccelli@inria.fr] > >> Verzonden: dinsdag 27 november 2007 11:20 > >> Aan: autoconf@ietf.org > >> Onderwerp: Re: [Autoconf] Goals of MANET autoconf > >> > >> All, > >> > >> > >> In order to agree on proposed or existing text, we have to agree on > >> axioms. The following step would be to reshape -03 tightly around > such > >> axioms. > >> > >> Previously, there was an agreement on the following axioms. Now = does > >> anybody think the following items need to be updated/completed? If > so > >> how exactly? Please be vocal if you think they are good enough, or > not. > >> > >> > >> 1. provide MANET-wide unique prefixes (up to /128) to each MANET > router > >> > >> 2. if one or more Internet Gateway is reachable, provide routable > >> unique > >> global prefixes to each MANET router > >> > >> 3. detect and resolve if non-unique prefixes are assigned to MANET > >> routers (e.g. as a result of a network partitioning/merger) > >> > >> > >> Regards > >> Emmanuel > >> > >> > >> _______________________________________________ > >> 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 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 27 10:09: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 1Ix247-0007Cw-6t; Tue, 27 Nov 2007 10:09:35 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Ix245-0007Ck-90 for autoconf-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 10:09:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix243-0007CW-WB for autoconf@ietf.org; Tue, 27 Nov 2007 10:09:32 -0500 Received: from balu3.urz.unibas.ch ([131.152.1.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix243-0004Rd-Cs for autoconf@ietf.org; Tue, 27 Nov 2007 10:09:31 -0500 Received: from [131.152.55.200] (baobab.cs.unibas.ch [131.152.55.200]) by balu3.urz.unibas.ch (8.13.1/8.13.1) with ESMTP id lARF9TJA012596; Tue, 27 Nov 2007 16:09:30 +0100 Message-ID: <474C3381.2020908@unibas.ch> Date: Tue, 27 Nov 2007 16:10:57 +0100 From: Christophe Jelger Organization: University of Basel User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070828) MIME-Version: 1.0 To: "Hahusseau, Thomas" Subject: Re: [Autoconf] Autoconf implementations ? References: <03AB04489317984CAC194CAAC9EDD9420648BD06@ZFRMSXIDF05.edsn.com> In-Reply-To: <03AB04489317984CAC194CAAC9EDD9420648BD06@ZFRMSXIDF05.edsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-Vilter-Version: 1.3.2 X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 Thomas, If you want to test a non-conventional implementation that includes reactive routing, DNS-style naming, and NAT-style address autoconfiguration then you can try LUNARng, last maintained in June 2007. It compiles (as Linux kernel module) for 2.6.20+ and used to compile for 2.4.x and older 2.6.x kernels but that was not tested recently. Also the mips cross-compilation is currently broken (I'll fix that one day). http://core.it.uu.se/core/index.php/LUNAR Autoconf here is resolved in a very brute-force way: since reactive discovery is done with DNS names and forwarding is done with label-switching, unique addresses are no longer needed (we still need unique names). Hence the system only ensures that for each remote peer a unique local address is assigned, and NAT is used at reception to make everything works fine. The current limitation is that it uses a home-made NAT code which is not capable of handling NAT-unfriendly applications (e.g. FTP). Note that the code is experimental: the goal was to demonstrate a radical way for doing manet autoconf, not to write production code. have fun! Christophe -------------------------------------------------- Dr. Christophe Jelger, http://cn.cs.unibas.ch University of Basel, Departement Informatik Bernoullistrasse 16, CH-4056 Basel, Switzerland Hahusseau, Thomas wrote: > Hello, > > This is my first email on that list. I would like to know if there is > some implementation of autoconfiguration protocols for standalone MANETs > under development ? the only ones I found were a couple years old : > > - Pacman feb 2005 > > - Manet:Prophet may 2004 > > - NOA-OLSR jul 2005 > > The only one which seems to be still supported is AHCPd : nov 2007 > > Most of them doesn't work on recent kernel (2.6.x), because they use > ipqueue which seems to be deprecated on 2.6.x kernels. Does anyone know > where I could find recent implementation of autoconfiguration protocols > for MANETs ? All projects about autoconfiguration implementations seems > to be dead (except AHCP) or what ? It's hard to believe that nobody > works on it, because there few mails on that list about comments on > draft and the WG doesn't look to be dead. > > Your sincerely > > Thomas Hahusseau > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 27 10:35:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix2Sw-0008WK-8y; Tue, 27 Nov 2007 10:35:14 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Ix2Su-0008W0-Tz for autoconf-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 10:35:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix2Su-0008Vq-KI for autoconf@ietf.org; Tue, 27 Nov 2007 10:35:12 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ix2St-0007IY-SC for autoconf@ietf.org; Tue, 27 Nov 2007 10:35:12 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-119.messagelabs.com!1196177711!37126287!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 27955 invoked from network); 27 Nov 2007 15:35:11 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-119.messagelabs.com with SMTP; 27 Nov 2007 15:35:11 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lARFZAQU002322; Tue, 27 Nov 2007 08:35:10 -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 lARFZA4E006896; Tue, 27 Nov 2007 09:35:10 -0600 (CST) 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 lARFZ8Zc006777; Tue, 27 Nov 2007 09:35:09 -0600 (CST) Message-ID: <474C3927.7060205@gmail.com> Date: Tue, 27 Nov 2007 16:35:03 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Emmanuel Baccelli Subject: Re: [Autoconf] Goals of MANET autoconf References: <474BEF32.6000808@inria.fr> In-Reply-To: <474BEF32.6000808@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071125-0, 25/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.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 Emmanuel, please take it as a simple opinion. Emmanuel Baccelli wrote: > All, > > > In order to agree on proposed or existing text, we have to agree on > axioms. The following step would be to reshape -03 tightly around > such axioms. > > Previously, there was an agreement on the following axioms. Now does > anybody think the following items need to be updated/completed? If > so how exactly? Please be vocal if you think they are good enough, or > not. > > > 1. provide MANET-wide unique prefixes (up to /128) to each MANET > router What does "MANET-wide" mean? Any relationship with the "site" term used by RFC4193 "Unique Local IPv6 Unicast Addresses (ULA)"? Would this "site" used by RFC4193 address my (and Ulrich's) confusion with respect to the manetarch document ("one or more IP hops - MANET, site, global") and deprecated site-local addresses? Then. What does "unique prefix" mean? Computing a unique value involves comparison with other values. Let's say for example I have this fd67::/16 prefix and I wonder whether it's unique. I ask left and right and two people tell me they already use fd67::/8 and fd67:300::/24. Is my prefix unique compared to these? Can I use my prefix? Another example: I have this address and prefix fd67::1/64 and you have this address and prefix fd67::1/63. Can I use my prefix? Can I use my address? Is there a widely agreed prefix match rule for variable-length prefixes? Or maybe I miss something big... > 2. if one or more Internet Gateway is reachable, provide routable > unique global prefixes to each MANET router YEs, makes sense to me because I see a DHCP Server on that Internet Gateway, or maybe a Router sending RAs. But yes, makes sense to me. > 3. detect and resolve if non-unique prefixes are assigned to MANET > routers (e.g. as a result of a network partitioning/merger) I'm not sure what's meant by this. It seems related to the "MANET-wide unique prefixes". 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 Nov 27 10:47:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix2eO-0001Th-KV; Tue, 27 Nov 2007 10:47:04 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Ix2eN-0001TD-AI for autoconf-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 10:47:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix2eN-0001T5-0J for autoconf@ietf.org; Tue, 27 Nov 2007 10:47:03 -0500 Received: from hpsmtp-eml18.kpnxchange.com ([213.75.38.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix2eL-00016o-I2 for autoconf@ietf.org; Tue, 27 Nov 2007 10:47:02 -0500 Received: from hpsmtp-eml08.kpnxchange.com ([213.75.38.108]) by hpsmtp-eml18.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 16:47:00 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml08.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 16:46:58 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <474BEF32.6000808@inria.fr> <474C3927.7060205@gmail.com> In-Reply-To: <474C3927.7060205@gmail.com> Subject: RE: [Autoconf] Goals of MANET autoconf Date: Tue, 27 Nov 2007 16:46:57 +0100 Message-ID: <005d01c8310c$bde94890$39bbd9b0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgxCzOXRUiLTEAzTT6XuNoNu94wMwAAN49g Content-Language: nl X-OriginalArrivalTime: 27 Nov 2007 15:46:58.0851 (UTC) FILETIME=[BEAE1F30:01C8310C] X-Spam-Score: -1.0 (-) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Alex wrote: > What does "unique prefix" mean? Computing a unique value involves > comparison with other values. > > Let's say for example I have this fd67::/16 prefix and I wonder whether > it's unique. I ask left and right and two people tell me they already > use fd67::/8 and fd67:300::/24. Is my prefix unique compared to these? I think so. Prefix is address and prefix length. > Is there a widely agreed prefix match rule for variable-length > prefixes? Longest match rule is defined in RFC1812. This is CIDR (by definition...) Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 27 10:49:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix2gX-0003KM-MM; Tue, 27 Nov 2007 10:49:17 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Ix2gW-0003FL-9n for autoconf-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 10:49:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix2gV-0003F3-NC for autoconf@ietf.org; Tue, 27 Nov 2007 10:49:15 -0500 Received: from mail.um.es ([155.54.212.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix2gR-0001YQ-93 for autoconf@ietf.org; Tue, 27 Nov 2007 10:49:15 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id D55D8400B6 for ; Tue, 27 Nov 2007 16:49:10 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.4.2 (20060627) (Debian) at xenon2.telemat.um.es Received: from mail.um.es ([127.0.0.1]) by localhost (xenon2.telemat.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bAif9tkTHJ91 for ; Tue, 27 Nov 2007 16:49:09 +0100 (CET) Received: from aries.dif.um.es (aries.inf.um.es [155.54.210.253]) by mail.um.es (Postfix) with SMTP id 994834009D for ; Tue, 27 Nov 2007 16:49:09 +0100 (CET) Received: (qmail 6602 invoked from network); 27 Nov 2007 16:09:07 -0000 Received: from inf-205-38.um.es (155.54.205.38) by aries.dif.um.es with SMTP; 27 Nov 2007 16:09:07 -0000 From: "Francisco J. Ros" Organization: University of Murcia To: autoconf@ietf.org Subject: Re: [Autoconf] Goals of MANET autoconf Date: Tue, 27 Nov 2007 16:55:27 +0100 User-Agent: KMail/1.9.5 References: <474BEF32.6000808@inria.fr> <002701c830e7$e226a060$a673e120$@nl> <474C229C.1060501@inria.fr> In-Reply-To: <474C229C.1060501@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200711271655.27469.fjrm@dif.um.es> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: 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 Hi everyone, On Tuesday 27 November 2007 14:58, Emmanuel Baccelli wrote: > Hi Teco, > > Teco Boot a =E9crit : > > Hi Emmanual, > > > > On item 3, the text: "as a result of a network partitioning/merger", I > > think it is impossible having non-unique global addresses after a merge; > > where before the merge addresses were globally unique. Or maybe earth > > merged with mars;-) > > > > And partitioning should be removed, as discussed before. > > I agree with removing the mention of partitionning here. But as far as > non-unique addresses are concerned, I disagree. There are types of > addresses other than global. And in this case they may not be unique > after a merger for instance. So maybe we could talk more specifically > about non-unicity of addresses of types other than global? > That seems to preclude the use of in-service DAD for globally routable=20 addresses. However, duplicates could appear e.g. if some addresses are=20 manually assigned or any node presents some kind of misbehavior. Therefore,= I=20 wouldn't exclude global addresses from the uniqueness check. Regards, fran > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf =2D-=20 =46rancisco J. Ros, Ph.D. Student Dept. of Information and Communications Engineering University of Murcia, Murcia (Spain) http://masimum.inf.um.es/fjrm/ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 27 10:55: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 1Ix2mN-0000vp-7J; Tue, 27 Nov 2007 10:55:19 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Ix2mM-0000va-DP for autoconf-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 10:55:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix2mM-0000vR-2j for autoconf@ietf.org; Tue, 27 Nov 2007 10:55:18 -0500 Received: from smtp02.uc3m.es ([163.117.176.132]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix2mL-0005ML-BV for autoconf@ietf.org; Tue, 27 Nov 2007 10:55:17 -0500 Subject: Re: [Autoconf] Goals of MANET autoconf From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Alexandru Petrescu In-Reply-To: <474C3927.7060205@gmail.com> References: <474BEF32.6000808@inria.fr> <474C3927.7060205@gmail.com> Organization: Universidad Carlos III de Madrid Date: Tue, 27 Nov 2007 16:55:01 +0100 Message-Id: <1196178901.4021.2.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: autoconf@ietf.org, Emmanuel Baccelli X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2114478737==" Errors-To: autoconf-bounces@ietf.org --===============2114478737== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-bZYBsFZclRrfCOmEAbDo" --=-bZYBsFZclRrfCOmEAbDo Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Alex, > What does "unique prefix" mean? Computing a unique value involves > comparison with other values. >=20 > Let's say for example I have this fd67::/16 prefix and I wonder whether > it's unique. I ask left and right and two people tell me they already > use fd67::/8 and fd67:300::/24. Is my prefix unique compared to these? > Can I use my prefix? >=20 > Another example: I have this address and prefix fd67::1/64 and you have > this address and prefix fd67::1/63. Can I use my prefix? Can I use my > address? >=20 > Is there a widely agreed prefix match rule for variable-length prefixes? As I understand that, a prefix is unique if it is not contained within any other prefix used within the MANET. Therefore, referring to your examples, fd67::/16 is not unique if fd67::/8 is already used by another MANET router. Similarly, if I'm using fd67::1/63, then you cannot use fd67::1/64. At least, this is my understanding... how about others? Carlos >=20 > Or maybe I miss something big... >=20 > > 2. if one or more Internet Gateway is reachable, provide routable > > unique global prefixes to each MANET router >=20 > YEs, makes sense to me because I see a DHCP Server on that Internet > Gateway, or maybe a Router sending RAs. But yes, makes sense to me. >=20 > > 3. detect and resolve if non-unique prefixes are assigned to MANET=20 > > routers (e.g. as a result of a network partitioning/merger) >=20 > I'm not sure what's meant by this. It seems related to the "MANET-wide > unique prefixes". >=20 > Alex >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf --=20 =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-bZYBsFZclRrfCOmEAbDo Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHTD3VNdy6TdFwT2cRAsXoAKC6/zysi5axg5R9m9oLw3VjNWy3uwCeO8rf +TaRSgGd/paIG0E09E4HQis= =aTB6 -----END PGP SIGNATURE----- --=-bZYBsFZclRrfCOmEAbDo-- --===============2114478737== 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 --===============2114478737==-- From autoconf-bounces@ietf.org Tue Nov 27 11:03: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 1Ix2uA-0001x8-2h; Tue, 27 Nov 2007 11:03:22 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Ix2u8-0001ul-Sl for autoconf-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 11:03:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix2u8-0001ss-HT for autoconf@ietf.org; Tue, 27 Nov 2007 11:03:20 -0500 Received: from hpsmtp-eml16.kpnxchange.com ([213.75.38.116]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix2u8-00075w-2D for autoconf@ietf.org; Tue, 27 Nov 2007 11:03:20 -0500 Received: from hpsmtp-eml10.kpnxchange.com ([213.75.38.110]) by hpsmtp-eml16.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 17:03:19 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml10.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 17:03:17 +0100 From: "Teco Boot" To: "'Francisco J. Ros'" References: <474BEF32.6000808@inria.fr> <002701c830e7$e226a060$a673e120$@nl> <474C229C.1060501@inria.fr> <200711271655.27469.fjrm@dif.um.es> In-Reply-To: <200711271655.27469.fjrm@dif.um.es> Subject: RE: [Autoconf] Goals of MANET autoconf Date: Tue, 27 Nov 2007 17:03:14 +0100 Message-ID: <006401c8310f$05a614e0$10f23ea0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgxDSVJ+9vQEswsSTyBF8rSkWY/SgAAEO7g Content-Language: nl X-OriginalArrivalTime: 27 Nov 2007 16:03:18.0060 (UTC) FILETIME=[06558EC0:01C8310F] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 > > > On item 3, the text: "as a result of a network > partitioning/merger", I > > > think it is impossible having non-unique global addresses after a > merge; > > > where before the merge addresses were globally unique. Or maybe > earth > > > merged with mars;-) > > > > > > And partitioning should be removed, as discussed before. > > > > I agree with removing the mention of partitionning here. But as far > as > > non-unique addresses are concerned, I disagree. There are types of > > addresses other than global. And in this case they may not be unique > > after a merger for instance. So maybe we could talk more specifically > > about non-unicity of addresses of types other than global? > > > That seems to preclude the use of in-service DAD for globally routable > addresses. However, duplicates could appear e.g. if some addresses are > manually assigned or any node presents some kind of misbehavior. > Therefore, I > wouldn't exclude global addresses from the uniqueness check. I think we agree on removing partitioning, OK? On merges: yes, some types of address generation have a somewhat high probability on collisions. But we are scoped on autoconfiguration, or am I missing something? My personal experience in real world: many years ago I had to deal with a malware attack, utilizing duplicate checks. Still, this is one of my nightmares. Just to place DAD in perspective, it has also a large, large drawback. I am not against DAD, but I want to use it very carefully. By the way, I like using anycast a lot, especially in an ad-hoc environment. Typically addresses are configured manually and must not be blocked by multi-link DAD. Teco. > > Regards, > fran > > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www1.ietf.org/mailman/listinfo/autoconf > > -- > Francisco J. Ros, Ph.D. Student > Dept. of Information and Communications Engineering > University of Murcia, Murcia (Spain) > > http://masimum.inf.um.es/fjrm/ > > > _______________________________________________ > 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 Nov 27 11:11:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix31l-0004ES-DJ; Tue, 27 Nov 2007 11:11:13 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Ix31j-0004E2-E9 for autoconf-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 11:11:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix31j-0004Dt-4O for autoconf@ietf.org; Tue, 27 Nov 2007 11:11:11 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ix31i-0006DK-LY for autoconf@ietf.org; Tue, 27 Nov 2007 11:11:11 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-153.messagelabs.com!1196179868!6237222!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 1509 invoked from network); 27 Nov 2007 16:11:08 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-153.messagelabs.com with SMTP; 27 Nov 2007 16:11:08 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lARGB8h6014188; Tue, 27 Nov 2007 09:11:08 -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 lARGB81i028329; Tue, 27 Nov 2007 10:11:08 -0600 (CST) 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 lARGB61T028171; Tue, 27 Nov 2007 10:11:07 -0600 (CST) Message-ID: <474C4195.8030409@gmail.com> Date: Tue, 27 Nov 2007 17:11:01 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Teco Boot Subject: Re: [Autoconf] Goals of MANET autoconf References: <474BEF32.6000808@inria.fr> <474C3927.7060205@gmail.com> <005d01c8310c$bde94890$39bbd9b0$@nl> In-Reply-To: <005d01c8310c$bde94890$39bbd9b0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071125-0, 25/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 Teco Boot wrote: > Alex wrote: >> What does "unique prefix" mean? Computing a unique value involves >> comparison with other values. >> >> Let's say for example I have this fd67::/16 prefix and I wonder whether >> it's unique. I ask left and right and two people tell me they already >> use fd67::/8 and fd67:300::/24. Is my prefix unique compared to these? > > I think so. > Prefix is address and prefix length. Ok, so for you two prefixes whose first 16bits match (fd67::/16 and fd67:300::/24) are not equal. Are they aggregated? >> Is there a widely agreed prefix match rule for variable-length >> prefixes? > > Longest match rule is defined in RFC1812. This is CIDR (by definition...) Right... "longest prefix match" is what a router does when comparing a dst address in a packet against a set of prefixes in a routing table - ok, algorithm known and implemented widely. It selects a routing table entry, but it doesn't detect duplicates. There may be several entries in the routing table that do match; thus I wouldn't say longest prefix match is good at detecting duplicates. (DAD detects duplicates easily because it compares 128bit apples to 128bit apples). That algorithm would give inconsistent (to my sense) answers when the prefixes to be compared are variable length. It would compare apples to oranges. For example, if I try to match fd67::/16 to fd67:1000::/24 then I have two cases: -I consider the /16 to be the full length, I longest prefix match and I find they really match(!). So they're not unique. -I consider the /128 to be the full address length, then I find fd67::/24 doesn't match at all fd67:1000::/24. So they're unique. That's why I don't know how to say when prefixes of variable lengths are unique or not. Sorry if I miss something big... or maybe I should ask whether there's a widely accepted concept of prefix matching. I may not be aware sorry. 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 Nov 27 11:15: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 1Ix35x-0007xJ-VC; Tue, 27 Nov 2007 11:15:33 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Ix35x-0007xB-GE for autoconf-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 11:15:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix35x-0007ww-6b for autoconf@ietf.org; Tue, 27 Nov 2007 11:15:33 -0500 Received: from hpsmtp-eml18.kpnxchange.com ([213.75.38.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix35w-0007GL-FX for autoconf@ietf.org; Tue, 27 Nov 2007 11:15:33 -0500 Received: from hpsmtp-eml10.kpnxchange.com ([213.75.38.110]) by hpsmtp-eml18.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 17:15:28 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml10.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 17:15:27 +0100 From: "Teco Boot" To: , "'Alexandru Petrescu'" References: <474BEF32.6000808@inria.fr> <474C3927.7060205@gmail.com> <1196178901.4021.2.camel@localhost> In-Reply-To: <1196178901.4021.2.camel@localhost> Subject: RE: [Autoconf] Goals of MANET autoconf Date: Tue, 27 Nov 2007 17:15:26 +0100 Message-ID: <006c01c83110$b8b1b1b0$2a151510$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgxDf4/nKkYfwbXR8KL6moJP9EZhAAAR+aw Content-Language: nl X-OriginalArrivalTime: 27 Nov 2007 16:15:27.0958 (UTC) FILETIME=[B9632760:01C83110] X-Spam-Score: -1.0 (-) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b 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 > -----Oorspronkelijk bericht----- > Van: Carlos Jes=FAs Bernardos Cano [mailto:cjbc@it.uc3m.es] > Verzonden: dinsdag 27 november 2007 16:55 > Aan: Alexandru Petrescu > CC: autoconf@ietf.org; Emmanuel Baccelli > Onderwerp: Re: [Autoconf] Goals of MANET autoconf >=20 > Hi Alex, >=20 > > What does "unique prefix" mean? Computing a unique value involves > > comparison with other values. > > > > Let's say for example I have this fd67::/16 prefix and I wonder > > whether it's unique. I ask left and right and two people tell me > they > > already use fd67::/8 and fd67:300::/24. Is my prefix unique = compared > to these? > > Can I use my prefix? > > > > Another example: I have this address and prefix fd67::1/64 and you > > have this address and prefix fd67::1/63. Can I use my prefix? Can = I > > use my address? > > > > Is there a widely agreed prefix match rule for variable-length > prefixes? >=20 > As I understand that, a prefix is unique if it is not contained within > any other prefix used within the MANET. Therefore, referring to your > examples, fd67::/16 is not unique if fd67::/8 is already used by > another MANET router. Similarly, if I'm using fd67::1/63, then you > cannot use fd67::1/64. >=20 > At least, this is my understanding... how about others? Please do not mess up addresses and prefixes. fd67::/8 and fd67::1/63 are not a valid prefixes. Those are FD::/8 and FD67:0:0:0::/63 (or FD67::/63 in short). FD67:: is an address. fd67::1 also. Addresses should be unique. Prefixes should be unique (forget anycast = for a second). Check RFC1812 for some history on subnets / masks, CIDR and prefixes: The use of networks and subnets is now historical, although the language used to describe them remains in current use. They have been replaced by the more tractable concept of a network prefix. A network prefix is, by definition, a contiguous set of bits at the more significant end of the address that defines a set of systems; host numbers select among those systems. There is no requirement that all the internet use network prefixes uniformly. To collapse routing information, it is useful to divide the internet into addressing domains. Within such a domain, detailed information is available about constituent networks; outside it, only the common network prefix is advertised. Teco. >=20 > Carlos >=20 > > > > Or maybe I miss something big... > > > > > 2. if one or more Internet Gateway is reachable, provide routable > > > unique global prefixes to each MANET router > > > > YEs, makes sense to me because I see a DHCP Server on that Internet > > Gateway, or maybe a Router sending RAs. But yes, makes sense to me. > > > > > 3. detect and resolve if non-unique prefixes are assigned to MANET > > > routers (e.g. as a result of a network partitioning/merger) > > > > I'm not sure what's meant by this. It seems related to the > > "MANET-wide unique prefixes". > > > > 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 > -- > =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 27 11:23: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 1Ix3E7-0007vY-Ca; Tue, 27 Nov 2007 11:23:59 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Ix3E5-0007vA-SI for autoconf-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 11:23:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix3E5-0007v2-In for autoconf@ietf.org; Tue, 27 Nov 2007 11:23:57 -0500 Received: from hpsmtp-eml15.kpnxchange.com ([213.75.38.115]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix3E4-0000km-35 for autoconf@ietf.org; Tue, 27 Nov 2007 11:23:57 -0500 Received: from hpsmtp-eml07.kpnxchange.com ([213.75.38.107]) by hpsmtp-eml15.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 17:23:55 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml07.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 17:23:54 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <474BEF32.6000808@inria.fr> <474C3927.7060205@gmail.com> <005d01c8310c$bde94890$39bbd9b0$@nl> <474C4195.8030409@gmail.com> In-Reply-To: <474C4195.8030409@gmail.com> Subject: RE: [Autoconf] Goals of MANET autoconf Date: Tue, 27 Nov 2007 17:23:51 +0100 Message-ID: <006d01c83111$e6d653b0$b482fb10$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgxECDTJtBTcTZlRA6AhcvfRnYywAAALglg Content-Language: nl X-OriginalArrivalTime: 27 Nov 2007 16:23:54.0980 (UTC) FILETIME=[E7989240:01C83111] X-Spam-Score: -1.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 > -----Oorspronkelijk bericht----- > Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Verzonden: dinsdag 27 november 2007 17:11 > Aan: Teco Boot > CC: autoconf@ietf.org > Onderwerp: Re: [Autoconf] Goals of MANET autoconf > > Teco Boot wrote: > > Alex wrote: > >> What does "unique prefix" mean? Computing a unique value involves > >> comparison with other values. > >> > >> Let's say for example I have this fd67::/16 prefix and I wonder > whether > >> it's unique. I ask left and right and two people tell me they > already > >> use fd67::/8 and fd67:300::/24. Is my prefix unique compared to > these? > > > > I think so. > > Prefix is address and prefix length. > > Ok, so for you two prefixes whose first 16bits match (fd67::/16 and > fd67:300::/24) are not equal. Are they aggregated? Highly depends on routing protocol. Don't forget we do not have natural masks anymore, we have CIDR. > > >> Is there a widely agreed prefix match rule for variable-length > >> prefixes? > > > > Longest match rule is defined in RFC1812. This is CIDR (by > definition...) > > Right... "longest prefix match" is what a router does when comparing a > dst address in a packet against a set of prefixes in a routing table - > ok, algorithm known and implemented widely. It selects a routing table > entry, but it doesn't detect duplicates. There may be several entries > in the routing table that do match; thus I wouldn't say longest prefix > match is good at detecting duplicates. (DAD detects duplicates easily > because it compares 128bit apples to 128bit apples). Current DAD is on link. I did not check all these DAD proposals. I think checking a routing table or any other table on /128 prefixes makes sense. Maybe checking on other prefixes also, e.g. when generating a unique ULA prefix, why not checking some tables? Mostly it is just burning CPU cycles, but once in a trillion years, who knows. Or when verifying PD, maybe there is a false node using a prefix when it should have released this. Or a false DHCP server. (I know the manual config stuff, false MAC addresses etc.) Teco. > > That algorithm would give inconsistent (to my sense) answers when the > prefixes to be compared are variable length. It would compare apples > to > oranges. > > For example, if I try to match fd67::/16 to fd67:1000::/24 then I have > two cases: > -I consider the /16 to be the full length, I longest prefix > match and I find they really match(!). So they're not unique. > -I consider the /128 to be the full address length, then I find > fd67::/24 doesn't match at all fd67:1000::/24. So they're unique. > > That's why I don't know how to say when prefixes of variable lengths > are > unique or not. Sorry if I miss something big... or maybe I should ask > whether there's a widely accepted concept of prefix matching. I may > not > be aware sorry. > > 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 Nov 27 11:35:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix3PO-00034B-03; Tue, 27 Nov 2007 11:35:38 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Ix3PM-00033s-QF for autoconf-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 11:35:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix3PM-00033f-FJ for autoconf@ietf.org; Tue, 27 Nov 2007 11:35:36 -0500 Received: from smtp03.uc3m.es ([163.117.176.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix3PL-0005x4-GA for autoconf@ietf.org; Tue, 27 Nov 2007 11:35:36 -0500 Subject: RE: [Autoconf] Goals of MANET autoconf From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Teco Boot In-Reply-To: <006c01c83110$b8b1b1b0$2a151510$@nl> References: <474BEF32.6000808@inria.fr> <474C3927.7060205@gmail.com> <1196178901.4021.2.camel@localhost> <006c01c83110$b8b1b1b0$2a151510$@nl> Organization: Universidad Carlos III de Madrid Date: Tue, 27 Nov 2007 17:35:37 +0100 Message-Id: <1196181337.4021.18.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: autoconf@ietf.org, 'Emmanuel Baccelli' X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0231118101==" Errors-To: autoconf-bounces@ietf.org --===============0231118101== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-grox6W86HfsYCAWVQLiE" --=-grox6W86HfsYCAWVQLiE Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Teco, > Please do not mess up addresses and prefixes. > fd67::/8 and fd67::1/63 are not a valid prefixes. Those are FD::/8 and > FD67:0:0:0::/63 (or FD67::/63 in short). > FD67:: is an address. fd67::1 also. Although conceptually I agree that FD::/8 is more correct when referring to a prefix, FD67::/8 can also be used (it is actually the same prefix: FD::/8, nothing more). FD67::1/63 is also a valid prefix (it's just FD67::/63). I agree FD67:: and FD67::1 are addresses (I didn't say otherwise), but, on the other hand, we can use FD67::1/64 both to refer to a prefix or an address combined with the prefix (RFC4291), it depends on the context (I was talking about prefixes in my previous mail, I just copied and pasted, I agree I could have been more correct...). Then, coming back to the uniqueness of addresses and prefixes, if we are thinking about delegation of prefixes to a MANET router, which is going to use it to configure its/their interface/s (and maybe those of attached nodes), then prefixes should be unique in the sense that the IPv6 addresses that can be formed out of these prefixes are unique, compared to the addresses that can be formed out of other prefixes delegated within the MANET. This is different from prefix aggregation in routing, we are talking about prefix delegation within a MANET (delegated prefixes used by MANET routers should not overlap). Maybe I'm missing something... Regards, Carlos >=20 > Addresses should be unique. Prefixes should be unique (forget anycast for= a > second). >=20 > Check RFC1812 for some history on subnets / masks, CIDR and prefixes: > The use of networks and subnets is now historical, although the > language used to describe them remains in current use. They have > been replaced by the more tractable concept of a network prefix. A > network prefix is, by definition, a contiguous set of bits at the > more significant end of the address that defines a set of systems; > host numbers select among those systems. There is no requirement > that all the internet use network prefixes uniformly. To collapse > routing information, it is useful to divide the internet into > addressing domains. Within such a domain, detailed information is > available about constituent networks; outside it, only the common > network prefix is advertised. >=20 > Teco. >=20 >=20 > >=20 > > Carlos > >=20 > > > > > > Or maybe I miss something big... > > > > > > > 2. if one or more Internet Gateway is reachable, provide routable > > > > unique global prefixes to each MANET router > > > > > > YEs, makes sense to me because I see a DHCP Server on that Internet > > > Gateway, or maybe a Router sending RAs. But yes, makes sense to me. > > > > > > > 3. detect and resolve if non-unique prefixes are assigned to MANET > > > > routers (e.g. as a result of a network partitioning/merger) > > > > > > I'm not sure what's meant by this. It seems related to the > > > "MANET-wide unique prefixes". > > > > > > 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 > > -- > > =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws > > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 >=20 --=20 =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-grox6W86HfsYCAWVQLiE Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHTEdZNdy6TdFwT2cRAlSfAJ4ksvdifr0yBvj0nLVa51oNSsYilQCfRzXj pJUIxcMAfaNlfDG/eX1V3NU= =0yJr -----END PGP SIGNATURE----- --=-grox6W86HfsYCAWVQLiE-- --===============0231118101== 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 --===============0231118101==-- From autoconf-bounces@ietf.org Tue Nov 27 11:38: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 1Ix3Sb-0006gP-BH; Tue, 27 Nov 2007 11:38:57 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Ix3Sa-0006fS-0Y for autoconf-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 11:38:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix3SZ-0006f6-MV for autoconf@ietf.org; Tue, 27 Nov 2007 11:38:55 -0500 Received: from balu3.urz.unibas.ch ([131.152.1.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix3SY-00041J-1u for autoconf@ietf.org; Tue, 27 Nov 2007 11:38:55 -0500 Received: from [131.152.55.200] (baobab.cs.unibas.ch [131.152.55.200]) by balu3.urz.unibas.ch (8.13.1/8.13.1) with ESMTP id lARGcrtV021014 for ; Tue, 27 Nov 2007 17:38:53 +0100 Message-ID: <474C4874.20502@unibas.ch> Date: Tue, 27 Nov 2007 17:40:20 +0100 From: Christophe Jelger Organization: University of Basel User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070828) MIME-Version: 1.0 To: autoconf@ietf.org Subject: Re: [Autoconf] Goals of MANET autoconf References: <474BEF32.6000808@inria.fr> <474C3927.7060205@gmail.com> <005d01c8310c$bde94890$39bbd9b0$@nl> <474C4195.8030409@gmail.com> In-Reply-To: <474C4195.8030409@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-Vilter-Version: 1.3.2 X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Spam-Score: -4.0 (----) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 longest prefix match cares about finding the ... longest match, but you don't have to indicate any prefix length a priori: you just use that later for interpreting the result fd67::(/16) and fd67:1000::(/24) absolute longest match is 19 bits - interpretation: 16 <= 19 <= 24 so one prefix is a subpart of the other. I here want to highlight the fact that longest match is one thing, interpretation of the result is another thing. Christophe Alexandru Petrescu wrote: > > For example, if I try to match fd67::/16 to fd67:1000::/24 then I have > two cases: > -I consider the /16 to be the full length, I longest prefix > match and I find they really match(!). So they're not unique. > -I consider the /128 to be the full address length, then I find > fd67::/24 doesn't match at all fd67:1000::/24. So they're unique. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 27 11:48:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix3bd-0002gW-Dk; Tue, 27 Nov 2007 11:48:17 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Ix3bc-0002g0-Fu for autoconf-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 11:48:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix3bc-0002fi-62 for autoconf@ietf.org; Tue, 27 Nov 2007 11:48:16 -0500 Received: from balu3.urz.unibas.ch ([131.152.1.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix3bb-00065V-N4 for autoconf@ietf.org; Tue, 27 Nov 2007 11:48:16 -0500 Received: from [131.152.55.200] (baobab.cs.unibas.ch [131.152.55.200]) by balu3.urz.unibas.ch (8.13.1/8.13.1) with ESMTP id lARGmE1R027644 for ; Tue, 27 Nov 2007 17:48:15 +0100 Message-ID: <474C4AA6.9020108@unibas.ch> Date: Tue, 27 Nov 2007 17:49:42 +0100 From: Christophe Jelger Organization: University of Basel User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070828) MIME-Version: 1.0 To: autoconf@ietf.org Subject: Re: [Autoconf] Goals of MANET autoconf References: <474BEF32.6000808@inria.fr> <474C3927.7060205@gmail.com> <1196178901.4021.2.camel@localhost> <006c01c83110$b8b1b1b0$2a151510$@nl> <1196181337.4021.18.camel@localhost> In-Reply-To: <1196181337.4021.18.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-SMTP-Vilter-Version: 1.3.2 X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balu3.urz.unibas.ch id lARGmE1R027644 X-Spam-Score: -4.0 (----) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 Carlos Jes=FAs Bernardos Cano wrote: >=20 > Then, coming back to the uniqueness of addresses and prefixes, if we > are thinking about delegation of prefixes to a MANET router, which is > going to use it to configure its/their interface/s (and maybe those of > attached nodes), then prefixes should be unique in the sense that the > IPv6 addresses that can be formed out of these prefixes are unique, > compared to the addresses that can be formed out of other prefixes > delegated within the MANET. This is different from prefix aggregation i= n > routing, we are talking about prefix delegation within a MANET > (delegated prefixes used by MANET routers should not overlap). Maybe I'= m > missing something... >=20 talking about overlapping prefixes is certainly much better (and=20 precise) terminology than talking about unique prefixes (which can be=20 confusing). Note the term "unique" is very tricky as an address is=20 always unique with respect to its namespace (e.g. 10.1.2.3 is unique in=20 the IPv4 namespace): whether it is used by multiple hosts or not is=20 another story, but what really matters is that there is no overlap with=20 respect to some scope. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 27 11:52:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix3fP-000215-V7; Tue, 27 Nov 2007 11:52:12 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Ix3fO-0001xZ-Ek for autoconf-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 11:52:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix3fO-0001v6-3v for autoconf@ietf.org; Tue, 27 Nov 2007 11:52:10 -0500 Received: from hpsmtp-eml18.kpnxchange.com ([213.75.38.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix3fL-0006uR-NW for autoconf@ietf.org; Tue, 27 Nov 2007 11:52:10 -0500 Received: from hpsmtp-eml09.kpnxchange.com ([213.75.38.109]) by hpsmtp-eml18.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 17:52:06 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml09.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 17:52:06 +0100 From: "Teco Boot" To: References: <474BEF32.6000808@inria.fr> <474C3927.7060205@gmail.com> <1196178901.4021.2.camel@localhost> <006c01c83110$b8b1b1b0$2a151510$@nl> <1196181337.4021.18.camel@localhost> In-Reply-To: <1196181337.4021.18.camel@localhost> Subject: RE: [Autoconf] Goals of MANET autoconf Date: Tue, 27 Nov 2007 17:52:04 +0100 Message-ID: <007501c83115$d705b990$85112cb0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgxE5yCfGOncJNkT5mYOc59ZH695QAAGgMQ Content-Language: nl X-OriginalArrivalTime: 27 Nov 2007 16:52:06.0654 (UTC) FILETIME=[D7E989E0:01C83115] X-Spam-Score: -1.0 (-) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd 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 > -----Oorspronkelijk bericht----- > Van: Carlos Jes=FAs Bernardos Cano [mailto:cjbc@it.uc3m.es] > Verzonden: dinsdag 27 november 2007 17:36 > Aan: Teco Boot > CC: 'Alexandru Petrescu'; autoconf@ietf.org; 'Emmanuel Baccelli' > Onderwerp: RE: [Autoconf] Goals of MANET autoconf >=20 > Hi Teco, >=20 > > Please do not mess up addresses and prefixes. > > fd67::/8 and fd67::1/63 are not a valid prefixes. Those are FD::/8 > and > > FD67:0:0:0::/63 (or FD67::/63 in short). > > FD67:: is an address. fd67::1 also. >=20 > Although conceptually I agree that FD::/8 is more correct when > referring to a prefix, FD67::/8 can also be used (it is actually the > same prefix: FD::/8, nothing more). FD67::1/63 is also a valid prefix > (it's just FD67::/63). I agree FD67:: and FD67::1 are addresses (I > didn't say otherwise), but, on the other hand, we can use FD67::1/64 > both to refer to a prefix or an address combined with the prefix > (RFC4291), it depends on the context (I was talking about prefixes in > my previous mail, I just copied and pasted, I agree I could have been > more correct...). OK. You intended "IPv6 address prefix" >=20 > Then, coming back to the uniqueness of addresses and prefixes, if > we are thinking about delegation of prefixes to a MANET router, which > is going to use it to configure its/their interface/s (and maybe those > of attached nodes), then prefixes should be unique in the sense that > the > IPv6 addresses that can be formed out of these prefixes are unique, > compared to the addresses that can be formed out of other prefixes > delegated within the MANET.=20 I think prefix delegation is stepping into solution space. We are = working on PS now. I would never assign a wide prefix to an interface and delegate parts of = it to other routers. This should be prohibited somewhere in an RFC. If not, = I write one!!!! > This is different from prefix aggregation > in routing, we are talking about prefix delegation within a MANET > (delegated prefixes used by MANET routers should not overlap). Maybe > I'm missing something... What is different with existing PD? I don't get it.=20 If some entity provides a prefix to you, it is owned by you, respecting expiration timers or whatever condition (NEMO use existence of tunnel). You can use the prefix by assigning to an interface ___or____ use the = prefix for further delegation. Parts of the prefix could be reserved for own usage, other parts for = further delegation.=20 There should not occur a collision. If so, some of the nodes is false. = What can we do? Yell? Hit someone? OK, swap to another prefix can be used. But I prefer introducing some security features first. Teco. >=20 > Regards, >=20 > Carlos >=20 > > > > Addresses should be unique. Prefixes should be unique (forget = anycast > > for a second). > > > > Check RFC1812 for some history on subnets / masks, CIDR and = prefixes: > > The use of networks and subnets is now historical, although the > > language used to describe them remains in current use. They have > > been replaced by the more tractable concept of a network prefix. > A > > network prefix is, by definition, a contiguous set of bits at the > > more significant end of the address that defines a set of = systems; > > host numbers select among those systems. There is no requirement > > that all the internet use network prefixes uniformly. To = collapse > > routing information, it is useful to divide the internet into > > addressing domains. Within such a domain, detailed information = is > > available about constituent networks; outside it, only the common > > network prefix is advertised. > > > > Teco. > > > > > > > > > > Carlos > > > > > > > > > > > Or maybe I miss something big... > > > > > > > > > 2. if one or more Internet Gateway is reachable, provide > > > > > routable unique global prefixes to each MANET router > > > > > > > > YEs, makes sense to me because I see a DHCP Server on that > > > > Internet Gateway, or maybe a Router sending RAs. But yes, makes > sense to me. > > > > > > > > > 3. detect and resolve if non-unique prefixes are assigned to > > > > > MANET routers (e.g. as a result of a network > > > > > partitioning/merger) > > > > > > > > I'm not sure what's meant by this. It seems related to the > > > > "MANET-wide unique prefixes". > > > > > > > > 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 > > > -- > > > =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws > > > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > > > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > > > -- > =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 27 12: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 1Ix49t-0000oE-DP; Tue, 27 Nov 2007 12:23:41 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Ix49s-0000ny-G1 for autoconf-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 12:23:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix49s-0000nn-52 for autoconf@ietf.org; Tue, 27 Nov 2007 12:23:40 -0500 Received: from mail.um.es ([155.54.212.109]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix49r-0007VA-Df for autoconf@ietf.org; Tue, 27 Nov 2007 12:23:40 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id AB54C6C1E6 for ; Tue, 27 Nov 2007 18:23:36 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.4.2 (20060627) (Debian) at xenon1.telemat.um.es Received: from mail.um.es ([127.0.0.1]) by localhost (xenon1.telemat.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hAsfCNM3Dppb for ; Tue, 27 Nov 2007 18:23:35 +0100 (CET) Received: from aries.dif.um.es (aries.inf.um.es [155.54.210.253]) by mail.um.es (Postfix) with SMTP id C9B056C1B9 for ; Tue, 27 Nov 2007 18:23:35 +0100 (CET) Received: (qmail 14583 invoked from network); 27 Nov 2007 17:43:34 -0000 Received: from inf-205-38.um.es (155.54.205.38) by aries.dif.um.es with SMTP; 27 Nov 2007 17:43:34 -0000 From: "Francisco J. Ros" Organization: University of Murcia To: "Teco Boot" Subject: Re: [Autoconf] Goals of MANET autoconf Date: Tue, 27 Nov 2007 18:29:53 +0100 User-Agent: KMail/1.9.5 References: <474BEF32.6000808@inria.fr> <200711271655.27469.fjrm@dif.um.es> <006401c8310f$05a614e0$10f23ea0$@nl> In-Reply-To: <006401c8310f$05a614e0$10f23ea0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711271829.53779.fjrm@dif.um.es> X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 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 Teco, On Tuesday 27 November 2007 17:03, Teco Boot wrote: > > > > On item 3, the text: "as a result of a network > > > > partitioning/merger", I > > > > > > think it is impossible having non-unique global addresses after a > > > > merge; > > > > > > where before the merge addresses were globally unique. Or maybe > > > > earth > > > > > > merged with mars;-) > > > > > > > > And partitioning should be removed, as discussed before. > > > > > > I agree with removing the mention of partitionning here. But as far > > > > as > > > > > non-unique addresses are concerned, I disagree. There are types of > > > addresses other than global. And in this case they may not be unique > > > after a merger for instance. So maybe we could talk more specifically > > > about non-unicity of addresses of types other than global? > > > > That seems to preclude the use of in-service DAD for globally routable > > addresses. However, duplicates could appear e.g. if some addresses are > > manually assigned or any node presents some kind of misbehavior. > > Therefore, I > > wouldn't exclude global addresses from the uniqueness check. > > I think we agree on removing partitioning, OK? > Yes :) > On merges: yes, some types of address generation have a somewhat high > probability on collisions. > But we are scoped on autoconfiguration, or am I missing something? > Manually configured addresses was just an example. Depending on the final [autoconf] protocol(s), we could find situations where duplicated global addresses appear. So, in the context of the P-S, are we sure that this is never going to happen? If not, why exclude global addresses from the (in-service) uniqueness check if, in fact, it could come "for free" with the same mechanism for non-global? My suggestion is not being so explicit right now, and just talk about "configured address uniqueness in the situation where different ad hoc networks merge" (from the charter). Regards, fran > My personal experience in real world: many years ago I had to deal with a > malware attack, utilizing duplicate checks. Still, this is one of my > nightmares. Just to place DAD in perspective, it has also a large, large > drawback. I am not against DAD, but I want to use it very carefully. > > By the way, I like using anycast a lot, especially in an ad-hoc > environment. Typically addresses are configured manually and must not be > blocked by multi-link DAD. > > Teco. > > > Regards, > > fran > > > > > _______________________________________________ > > > Autoconf mailing list > > > Autoconf@ietf.org > > > https://www1.ietf.org/mailman/listinfo/autoconf > > > > -- > > Francisco J. Ros, Ph.D. Student > > Dept. of Information and Communications Engineering > > University of Murcia, Murcia (Spain) > > > > http://masimum.inf.um.es/fjrm/ > > > > > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www1.ietf.org/mailman/listinfo/autoconf -- Francisco J. Ros, Ph.D. Student Dept. of Information and Communications Engineering University of Murcia, Murcia (Spain) http://masimum.inf.um.es/fjrm/ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 27 13:06:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix4p0-0000DH-57; Tue, 27 Nov 2007 13:06:10 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Ix4ox-0000Cn-0q for autoconf-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 13:06:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix4ow-0000CY-HG for autoconf@ietf.org; Tue, 27 Nov 2007 13:06:06 -0500 Received: from hpsmtp-eml18.kpnxchange.com ([213.75.38.118]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix4ov-0000Xj-Ud for autoconf@ietf.org; Tue, 27 Nov 2007 13:06:06 -0500 Received: from hpsmtp-eml07.kpnxchange.com ([213.75.38.107]) by hpsmtp-eml18.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 19:06:04 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml07.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 19:06:04 +0100 From: "Teco Boot" To: "'Francisco J. Ros'" References: <474BEF32.6000808@inria.fr> <200711271655.27469.fjrm@dif.um.es> <006401c8310f$05a614e0$10f23ea0$@nl> <200711271829.53779.fjrm@dif.um.es> In-Reply-To: <200711271829.53779.fjrm@dif.um.es> Subject: RE: [Autoconf] Goals of MANET autoconf Date: Tue, 27 Nov 2007 19:05:59 +0100 Message-ID: <008401c83120$2bf04420$83d0cc60$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgxGlEfO3xu/a5vTaabV3c+EZJLTwABbw9A Content-Language: nl X-OriginalArrivalTime: 27 Nov 2007 18:06:04.0167 (UTC) FILETIME=[2CE04970:01C83120] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b 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 > -----Oorspronkelijk bericht----- > Van: Francisco J. Ros [mailto:fjrm@dif.um.es] > Verzonden: dinsdag 27 november 2007 18:30 > Aan: Teco Boot > CC: autoconf@ietf.org > Onderwerp: Re: [Autoconf] Goals of MANET autoconf > > Hi Teco, > > On Tuesday 27 November 2007 17:03, Teco Boot wrote: > > > > > On item 3, the text: "as a result of a network > > > > > > partitioning/merger", I > > > > > > > > think it is impossible having non-unique global addresses after > a > > > > > > merge; > > > > > > > > where before the merge addresses were globally unique. Or maybe > > > > > > earth > > > > > > > > merged with mars;-) > > > > > > > > > > And partitioning should be removed, as discussed before. > > > > > > > > I agree with removing the mention of partitionning here. But as > far > > > > > > as > > > > > > > non-unique addresses are concerned, I disagree. There are types > of > > > > addresses other than global. And in this case they may not be > unique > > > > after a merger for instance. So maybe we could talk more > specifically > > > > about non-unicity of addresses of types other than global? > > > > > > That seems to preclude the use of in-service DAD for globally > routable > > > addresses. However, duplicates could appear e.g. if some addresses > are > > > manually assigned or any node presents some kind of misbehavior. > > > Therefore, I > > > wouldn't exclude global addresses from the uniqueness check. > > > > I think we agree on removing partitioning, OK? > > > Yes :) > > > On merges: yes, some types of address generation have a somewhat high > > probability on collisions. > > But we are scoped on autoconfiguration, or am I missing something? > > > Manually configured addresses was just an example. Depending on the > final > [autoconf] protocol(s), we could find situations where duplicated > global > addresses appear. So, in the context of the P-S, are we sure that this > is > never going to happen? If not, why exclude global addresses from the > (in-service) uniqueness check if, in fact, it could come "for free" > with the > same mechanism for non-global? > > My suggestion is not being so explicit right now, and just talk > about "configured address uniqueness in the situation where different > ad hoc > networks merge" (from the charter). Ack. Teco > > Regards, > fran > > > My personal experience in real world: many years ago I had to deal > with a > > malware attack, utilizing duplicate checks. Still, this is one of my > > nightmares. Just to place DAD in perspective, it has also a large, > large > > drawback. I am not against DAD, but I want to use it very carefully. > > > > By the way, I like using anycast a lot, especially in an ad-hoc > > environment. Typically addresses are configured manually and must not > be > > blocked by multi-link DAD. > > > > Teco. > > > > > Regards, > > > fran > > > > > > > _______________________________________________ > > > > Autoconf mailing list > > > > Autoconf@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/autoconf > > > > > > -- > > > Francisco J. Ros, Ph.D. Student > > > Dept. of Information and Communications Engineering > > > University of Murcia, Murcia (Spain) > > > > > > http://masimum.inf.um.es/fjrm/ > > > > > > > > > _______________________________________________ > > > Autoconf mailing list > > > Autoconf@ietf.org > > > https://www1.ietf.org/mailman/listinfo/autoconf > > -- > Francisco J. Ros, Ph.D. Student > Dept. of Information and Communications Engineering > University of Murcia, Murcia (Spain) > > http://masimum.inf.um.es/fjrm/ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 27 17:20: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 1Ix8nN-0005U4-2Q; Tue, 27 Nov 2007 17:20:45 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Ix8nL-0005Tq-J8 for autoconf-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 17:20:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix8nL-0005Ti-8O for autoconf@ietf.org; Tue, 27 Nov 2007 17:20:43 -0500 Received: from mail4-relais-sop.national.inria.fr ([192.134.164.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix8nJ-0006wz-8c for autoconf@ietf.org; Tue, 27 Nov 2007 17:20:43 -0500 X-IronPort-AV: E=Sophos;i="4.23,220,1194217200"; d="scan'208";a="19750590" Received: from ras75-3-82-226-221-97.fbx.proxad.net (HELO BoolfightMaN-Laptop.local) ([82.226.221.97]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Nov 2007 23:20:40 +0100 Message-ID: <474C9837.5050904@inria.fr> Date: Tue, 27 Nov 2007 23:20:39 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org Subject: Re: [Autoconf] Goals of MANET autoconf References: <474BEF32.6000808@inria.fr> <200711271655.27469.fjrm@dif.um.es> <006401c8310f$05a614e0$10f23ea0$@nl> <200711271829.53779.fjrm@dif.um.es> <008401c83120$2bf04420$83d0cc60$@nl> In-Reply-To: <008401c83120$2bf04420$83d0cc60$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 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 OK, here is an updated tentative item list, reflecting the latest comments. Let us continue this healthy discussion and try to boil down to an expression most people agree with. So what do we think of this? 1. provide unique addresses and/or non-overlapping prefixes valid for communication within the MANET, to MANET routers requiring such configuration. 2. if one (or more) ICP is reachable, provide routable, globally unique addresses and/or routable non-overlapping prefixes to MANET routers requiring such configuration. 3. detect and resolve cases of duplicated addresses and/or prefixes assigned to MANET routers (e.g. as a result of a network merger, or of a manual misconfiguration). The term ICP here is used for being more precise than Internet Gateway, as defined in the tentative -03 : Internet Configuration Provider (ICP) - An entity that can provide routers requesting configuration with routable addresses or prefixes. A typical example of ICP is a DHCP server. Emmanuel Teco Boot a écrit : > >> -----Oorspronkelijk bericht----- >> Van: Francisco J. Ros [mailto:fjrm@dif.um.es] >> Verzonden: dinsdag 27 november 2007 18:30 >> Aan: Teco Boot >> CC: autoconf@ietf.org >> Onderwerp: Re: [Autoconf] Goals of MANET autoconf >> >> Hi Teco, >> >> On Tuesday 27 November 2007 17:03, Teco Boot wrote: >>>>>> On item 3, the text: "as a result of a network >>>> partitioning/merger", I >>>> >>>>>> think it is impossible having non-unique global addresses after >> a >>>> merge; >>>> >>>>>> where before the merge addresses were globally unique. Or maybe >>>> earth >>>> >>>>>> merged with mars;-) >>>>>> >>>>> > And partitioning should be removed, as discussed before. >>>>> >>>>> I agree with removing the mention of partitionning here. But as >> far >>>> as >>>> >>>>> non-unique addresses are concerned, I disagree. There are types >> of >>>>> addresses other than global. And in this case they may not be >> unique >>>>> after a merger for instance. So maybe we could talk more >> specifically >>>>> about non-unicity of addresses of types other than global? >>>> That seems to preclude the use of in-service DAD for globally >> routable >>>> addresses. However, duplicates could appear e.g. if some addresses >> are >>>> manually assigned or any node presents some kind of misbehavior. >>>> Therefore, I >>>> wouldn't exclude global addresses from the uniqueness check. >>> I think we agree on removing partitioning, OK? >>> >> Yes :) >> >>> On merges: yes, some types of address generation have a somewhat high >>> probability on collisions. >>> But we are scoped on autoconfiguration, or am I missing something? >>> >> Manually configured addresses was just an example. Depending on the >> final >> [autoconf] protocol(s), we could find situations where duplicated >> global >> addresses appear. So, in the context of the P-S, are we sure that this >> is >> never going to happen? If not, why exclude global addresses from the >> (in-service) uniqueness check if, in fact, it could come "for free" >> with the >> same mechanism for non-global? >> >> My suggestion is not being so explicit right now, and just talk >> about "configured address uniqueness in the situation where different >> ad hoc >> networks merge" (from the charter). > > Ack. > Teco > > >> Regards, >> fran >> >>> My personal experience in real world: many years ago I had to deal >> with a >>> malware attack, utilizing duplicate checks. Still, this is one of my >>> nightmares. Just to place DAD in perspective, it has also a large, >> large >>> drawback. I am not against DAD, but I want to use it very carefully. >>> >>> By the way, I like using anycast a lot, especially in an ad-hoc >>> environment. Typically addresses are configured manually and must not >> be >>> blocked by multi-link DAD. >>> >>> Teco. >>> >>>> Regards, >>>> fran >>>> >>>>> _______________________________________________ >>>>> Autoconf mailing list >>>>> Autoconf@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/autoconf >>>> -- >>>> Francisco J. Ros, Ph.D. Student >>>> Dept. of Information and Communications Engineering >>>> University of Murcia, Murcia (Spain) >>>> >>>> http://masimum.inf.um.es/fjrm/ >>>> >>>> >>>> _______________________________________________ >>>> Autoconf mailing list >>>> Autoconf@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/autoconf >> -- >> Francisco J. Ros, Ph.D. Student >> Dept. of Information and Communications Engineering >> University of Murcia, Murcia (Spain) >> >> http://masimum.inf.um.es/fjrm/ > > > > _______________________________________________ > 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 Wed Nov 28 00:18:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxFJg-0003p2-LC; Wed, 28 Nov 2007 00:18:32 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IxFJe-0003nZ-9z for autoconf-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 00:18:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxFJe-0003nQ-08 for autoconf@ietf.org; Wed, 28 Nov 2007 00:18:30 -0500 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 1IxFJb-0002ui-Sp for autoconf@ietf.org; Wed, 28 Nov 2007 00:18:29 -0500 Received: from mxav02.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D333E45438D for ; Wed, 28 Nov 2007 14:18:26 +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 C1332454053 for ; Wed, 28 Nov 2007 14:18:26 +0900 (JST) Received: (qmail 26071 invoked from network); 28 Nov 2007 14:18:26 +0900 Received: from unknown (HELO chamame.ie.niigata-u.ac.jp) (133.35.169.34) by mxav02.cc.niigata-u.ac.jp with SMTP; 28 Nov 2007 14:18:26 +0900 Received: (qmail 7720 invoked from network); 28 Nov 2007 14:18: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; 28 Nov 2007 14:18:26 +0900 Message-Id: <7.0.0.16.2.20071128135448.0337aed0@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Wed, 28 Nov 2007 14:18:25 +0900 To: Emmanuel Baccelli , autoconf@ietf.org From: mase Subject: Re: [Autoconf] Goals of MANET autoconf In-Reply-To: <474C9837.5050904@inria.fr> References: <474BEF32.6000808@inria.fr> <200711271655.27469.fjrm@dif.um.es> <006401c8310f$05a614e0$10f23ea0$@nl> <200711271829.53779.fjrm@dif.um.es> <008401c83120$2bf04420$83d0cc60$@nl> <474C9837.5050904@inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 Dear Emmanuel. Thank you for updating goal item lists. My comments and questions are in line. Thanks, Kenichi At 07:20 07/11/28, Emmanuel Baccelli wrote: >OK, here is an updated tentative item list, reflecting the latest >comments. Let us continue this healthy discussion and try to boil >down to an expression most people agree with. So what do we think of this? > >1. provide unique addresses and/or non-overlapping prefixes valid >for communication within the MANET, to MANET routers requiring such >configuration. I am aware that use of non-overlapping" has been suggeted. But, I am not sure about the difference between unique and non-overlapping. Given any scope, unique and non-overlapping have the same meaning. And, if so, use of two terms, one for address and the other for prefix is confusing. >2. if one (or more) ICP is reachable, provide routable, globally >unique addresses and/or routable non-overlapping prefixes to MANET >routers requiring such configuration. I am not sure why "routable"is not used in$B!!#1(B. and used in 2. Maybe, routable here means routable in the Internet toward MANET. If so, routable and globally unique seem redundant, because it is trivial that we do not use a globally unique but not routable address in the Internet. Am I missing something here? >3. detect and resolve cases of duplicated addresses and/or prefixes >assigned to MANET routers (e.g. as a result of a network merger, or >of a manual misconfiguration). > >The term ICP here is used for being more precise than Internet >Gateway, as defined in the tentative -03 : > >Internet Configuration Provider (ICP) - An entity that can provide >routers requesting configuration with routable addresses or >prefixes. A typical example of ICP is a DHCP server. "routabe" may be replaced by "globally unique". _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 28 04:19:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxJ4h-0004A3-N7; Wed, 28 Nov 2007 04:19:19 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IxJ4g-00049v-JT for autoconf-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 04:19:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxJ4b-00048v-1D for autoconf@ietf.org; Wed, 28 Nov 2007 04:19:13 -0500 Received: from mail3-relais-sop.national.inria.fr ([192.134.164.104]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxJ4a-000524-IV for autoconf@ietf.org; Wed, 28 Nov 2007 04:19:12 -0500 X-IronPort-AV: E=Sophos;i="4.23,223,1194217200"; d="scan'208";a="6262057" Received: from ras75-3-82-226-221-97.fbx.proxad.net (HELO BoolfightMaN-Laptop.local) ([82.226.221.97]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Nov 2007 10:19:11 +0100 Message-ID: <474D328E.7020201@inria.fr> Date: Wed, 28 Nov 2007 10:19:10 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org Subject: Re: [Autoconf] Goals of MANET autoconf References: <474BEF32.6000808@inria.fr> <200711271655.27469.fjrm@dif.um.es> <006401c8310f$05a614e0$10f23ea0$@nl> <200711271829.53779.fjrm@dif.um.es> <008401c83120$2bf04420$83d0cc60$@nl> <474C9837.5050904@inria.fr> <7.0.0.16.2.20071128135448.0337aed0@ie.niigata-u.ac.jp> In-Reply-To: <7.0.0.16.2.20071128135448.0337aed0@ie.niigata-u.ac.jp> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 Kenichi, mase a e'crit : >> >> 1. provide unique addresses and/or non-overlapping prefixes valid for >> communication within the MANET, to MANET routers requiring such >> configuration. > > I am aware that use of non-overlapping" has been suggeted. But, I am not > sure about the difference between unique and non-overlapping. Given any > scope, unique and non-overlapping have the same meaning. And, if so, use > of two terms, one for address and the other for prefix is confusing. > I think that the adjectives "unique addresses" and "non-overlapping prefixes" are the more precise in order to describe what we mean here. > >> 2. if one (or more) ICP is reachable, provide routable, globally >> unique addresses and/or routable non-overlapping prefixes to MANET >> routers requiring such configuration. > > I am not sure why "routable"is not used in$B!!#1(B. and used in 2. Maybe, > routable here means routable in the Internet toward MANET. If so, > routable and globally unique seem redundant, because it is trivial that > we do not use a globally unique but not routable address in the > Internet. Am I missing something here? > By "routable" it is meant "globally unique and topologically correct", which is different from merely "globally unique". > >> 3. detect and resolve cases of duplicated addresses and/or prefixes >> assigned to MANET routers (e.g. as a result of a network merger, or of >> a manual misconfiguration). >> >> The term ICP here is used for being more precise than Internet >> Gateway, as defined in the tentative -03 : >> >> Internet Configuration Provider (ICP) - An entity that can provide >> routers requesting configuration with routable addresses or prefixes. >> A typical example of ICP is a DHCP server. > > "routabe" may be replaced by "globally unique". Here again, "routable" is meant as "globally unique and topologically correct", and not simply "globally unique". Maybe we should define the term "routable address"? _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 28 04:40: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 1IxJOp-0005rx-Bw; Wed, 28 Nov 2007 04:40:07 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IxJOo-0005qH-MP for autoconf-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 04:40:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxJOo-0005n5-7I for autoconf@ietf.org; Wed, 28 Nov 2007 04:40:06 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IxJOn-00028C-S6 for autoconf@ietf.org; Wed, 28 Nov 2007 04:40:06 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-119.messagelabs.com!1196242804!41764088!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 28165 invoked from network); 28 Nov 2007 09:40:04 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-119.messagelabs.com with SMTP; 28 Nov 2007 09:40:04 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lAS9e3eq009738; Wed, 28 Nov 2007 02:40:03 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id lAS9e30k027218; Wed, 28 Nov 2007 03:40:03 -0600 (CST) 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 lAS9e1V3027196; Wed, 28 Nov 2007 03:40:01 -0600 (CST) Message-ID: <474D3770.90305@gmail.com> Date: Wed, 28 Nov 2007 10:40:00 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: cjbc@it.uc3m.es Subject: Re: [Autoconf] Goals of MANET autoconf References: <474BEF32.6000808@inria.fr> <474C3927.7060205@gmail.com> <1196178901.4021.2.camel@localhost> <006c01c83110$b8b1b1b0$2a151510$@nl> <1196181337.4021.18.camel@localhost> In-Reply-To: <1196181337.4021.18.camel@localhost> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 071125-0, 25/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 Carlos Jesús Bernardos Cano wrote: > Hi Teco, > >> Please do not mess up addresses and prefixes. fd67::/8 and >> fd67::1/63 are not a valid prefixes. Those are FD::/8 and >> FD67:0:0:0::/63 (or FD67::/63 in short). FD67:: is an address. >> fd67::1 also. > > Although conceptually I agree that FD::/8 is more correct when > referring to a prefix, FD67::/8 can also be used (it is actually the > same prefix: FD::/8, nothing more). Fits my understanding. > FD67::1/63 is also a valid prefix (it's just FD67::/63). This too. > I agree FD67:: and FD67::1 are addresses (I didn't say otherwise), > but, on the other hand, we can use FD67::1/64 both to refer to a > prefix or an address combined with the prefix (RFC4291), it depends > on the context (I was talking about prefixes in my previous mail, I > just copied and pasted, I agree I could have been more correct...). I agree. > Then, coming back to the uniqueness of addresses and prefixes, if we > are thinking about delegation of prefixes to a MANET router, which > is going to use it to configure its/their interface/s (and maybe > those of attached nodes), then prefixes should be unique in the sense > that the IPv6 addresses that can be formed out of these prefixes are > unique, compared to the addresses that can be formed out of other > prefixes delegated within the MANET. I agree. > This is different from prefix aggregation in routing, we are talking > about prefix delegation within a MANET (delegated prefixes used by > MANET routers should not overlap). Maybe I'm missing something... I think prefix aggregation in routing is inter-mixed with what we think we respect to address uniqueness and relationship between prefixes. 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 Nov 28 04:40:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxJPW-0006JW-R5; Wed, 28 Nov 2007 04:40:50 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IxJPW-0006JR-2L for autoconf-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 04:40:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxJPV-0006JJ-Ox for autoconf@ietf.org; Wed, 28 Nov 2007 04:40:49 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IxJPV-00029y-E9 for autoconf@ietf.org; Wed, 28 Nov 2007 04:40:49 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-119.messagelabs.com!1196242848!22699736!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 24629 invoked from network); 28 Nov 2007 09:40:48 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-119.messagelabs.com with SMTP; 28 Nov 2007 09:40:48 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lAS9emH2009947; Wed, 28 Nov 2007 02:40:48 -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 lAS9emeY027690; Wed, 28 Nov 2007 03:40:48 -0600 (CST) 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 lAS9ekq6027675; Wed, 28 Nov 2007 03:40:47 -0600 (CST) Message-ID: <474D379E.9090008@gmail.com> Date: Wed, 28 Nov 2007 10:40:46 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Christophe Jelger Subject: Re: [Autoconf] Goals of MANET autoconf References: <474BEF32.6000808@inria.fr> <474C3927.7060205@gmail.com> <005d01c8310c$bde94890$39bbd9b0$@nl> <474C4195.8030409@gmail.com> <474C4874.20502@unibas.ch> In-Reply-To: <474C4874.20502@unibas.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071125-0, 25/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 Christophe Jelger wrote: > longest prefix match cares about finding the ... longest match, but you > don't have to indicate any prefix length a priori: you just use that > later for interpreting the result > > fd67::(/16) and fd67:1000::(/24) > > absolute longest match is 19 bits - interpretation: 16 <= 19 <= 24 so > one prefix is a subpart of the other. I here want to highlight the fact > that longest match is one thing, interpretation of the result is another > thing. Fits my understanding too. Alex > > Christophe > > Alexandru Petrescu wrote: >> >> For example, if I try to match fd67::/16 to fd67:1000::/24 then I have >> two cases: >> -I consider the /16 to be the full length, I longest prefix >> match and I find they really match(!). So they're not unique. >> -I consider the /128 to be the full address length, then I find >> fd67::/24 doesn't match at all fd67:1000::/24. So they're unique. > > > _______________________________________________ > 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 Wed Nov 28 04:42: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 1IxJQm-0006zz-Je; Wed, 28 Nov 2007 04:42:08 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IxJQk-0006zs-T9 for autoconf-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 04:42:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxJQk-0006zZ-IE for autoconf@ietf.org; Wed, 28 Nov 2007 04:42:06 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IxJQk-0006KI-2b for autoconf@ietf.org; Wed, 28 Nov 2007 04:42:06 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-153.messagelabs.com!1196242924!14589158!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 24007 invoked from network); 28 Nov 2007 09:42:04 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-15.tower-153.messagelabs.com with SMTP; 28 Nov 2007 09:42:04 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id lAS9g4PE025100; Wed, 28 Nov 2007 02:42:04 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id lAS9g3PX021446; Wed, 28 Nov 2007 03:42:04 -0600 (CST) 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 lAS9g1Vi021432; Wed, 28 Nov 2007 03:42:02 -0600 (CST) Message-ID: <474D37E9.609@gmail.com> Date: Wed, 28 Nov 2007 10:42:01 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Christophe Jelger Subject: Re: [Autoconf] Goals of MANET autoconf References: <474BEF32.6000808@inria.fr> <474C3927.7060205@gmail.com> <1196178901.4021.2.camel@localhost> <006c01c83110$b8b1b1b0$2a151510$@nl> <1196181337.4021.18.camel@localhost> <474C4AA6.9020108@unibas.ch> In-Reply-To: <474C4AA6.9020108@unibas.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 071125-0, 25/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Christophe Jelger wrote: > Carlos Jesús Bernardos Cano wrote: >> >> Then, coming back to the uniqueness of addresses and prefixes, if we >> are thinking about delegation of prefixes to a MANET router, which is >> going to use it to configure its/their interface/s (and maybe those of >> attached nodes), then prefixes should be unique in the sense that the >> IPv6 addresses that can be formed out of these prefixes are unique, >> compared to the addresses that can be formed out of other prefixes >> delegated within the MANET. This is different from prefix aggregation in >> routing, we are talking about prefix delegation within a MANET >> (delegated prefixes used by MANET routers should not overlap). Maybe I'm >> missing something... >> > > talking about overlapping prefixes is certainly much better (and > precise) terminology than talking about unique prefixes (which can be > confusing). Note the term "unique" is very tricky as an address is > always unique with respect to its namespace (e.g. 10.1.2.3 is unique in > the IPv4 namespace): whether it is used by multiple hosts or not is > another story, but what really matters is that there is no overlap with > respect to some scope. I agree. And I think we don't have common understanding of that scope. That leads to round and round issues. 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 Nov 28 05:04: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 1IxJmU-0000qg-AM; Wed, 28 Nov 2007 05:04:34 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IxJmS-0000qQ-Uf for autoconf-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 05:04:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxJmS-0000qE-IA for autoconf@ietf.org; Wed, 28 Nov 2007 05:04:32 -0500 Received: from ccmail.cc.niigata-u.ac.jp ([133.35.23.1] helo=mxav03.cc.niigata-u.ac.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxJmQ-0003Nz-A7 for autoconf@ietf.org; Wed, 28 Nov 2007 05:04:32 -0500 Received: from mxav03.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 413F8291C13 for ; Wed, 28 Nov 2007 19:04:28 +0900 (JST) Received: from mxav03.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by mxav03.cc.niigata-u.ac.jp (Postfix) with SMTP id 2DDD1291B22 for ; Wed, 28 Nov 2007 19:04:28 +0900 (JST) Received: (qmail 7058 invoked from network); 28 Nov 2007 19:04:28 +0900 Received: from unknown (HELO chamame.ie.niigata-u.ac.jp) (133.35.169.34) by mxav03.cc.niigata-u.ac.jp with SMTP; 28 Nov 2007 19:04:28 +0900 Received: (qmail 21003 invoked from network); 28 Nov 2007 19:04:27 +0900 Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 28 Nov 2007 19:04:27 +0900 Message-Id: <7.0.0.16.2.20071128183501.047f8210@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Wed, 28 Nov 2007 19:04:27 +0900 To: Emmanuel Baccelli , autoconf@ietf.org From: mase Subject: Re: [Autoconf] Goals of MANET autoconf In-Reply-To: <474D328E.7020201@inria.fr> References: <474BEF32.6000808@inria.fr> <200711271655.27469.fjrm@dif.um.es> <006401c8310f$05a614e0$10f23ea0$@nl> <200711271829.53779.fjrm@dif.um.es> <008401c83120$2bf04420$83d0cc60$@nl> <474C9837.5050904@inria.fr> <7.0.0.16.2.20071128135448.0337aed0@ie.niigata-u.ac.jp> <474D328E.7020201@inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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 Hi, Emmanuel, At 18:19 07/11/28, Emmanuel Baccelli wrote: >Hi Kenichi, > >mase a e'crit : > >> > >> 1. provide unique addresses and/or non-overlapping prefixes valid for > >> communication within the MANET, to MANET routers requiring such > >> configuration. > > > > I am aware that use of non-overlapping" has been suggeted. But, I am not > > sure about the difference between unique and non-overlapping. Given any > > scope, unique and non-overlapping have the same meaning. And, if so, use > > of two terms, one for address and the other for prefix is confusing. > > > >I think that the adjectives "unique addresses" and "non-overlapping >prefixes" are the more precise in order to describe what we mean here. Now, I understand. ok, but I think that we should give an explanation what non-overlapping prefix means in the PS document. > > > >> 2. if one (or more) ICP is reachable, provide routable, globally > >> unique addresses and/or routable non-overlapping prefixes to MANET > >> routers requiring such configuration. > > > > I am not sure why "routable"is not used in$B!!#1(B. and used in 2. Maybe, > > routable here means routable in the Internet toward MANET. If so, > > routable and globally unique seem redundant, because it is trivial that > > we do not use a globally unique but not routable address in the > > Internet. Am I missing something here? > > > >By "routable" it is meant "globally unique and topologically correct", >which is different from merely "globally unique". I understant. But, I just think that it is trivial that we do not use a globally unique but not-routable address in the Internet. If you think that just "globally unique" is insufficient, I still prefer "globally unique and topologically correct addresses and/or globally non-overlapping and topologically correct prefixes ". Do you think that the adjective "globally" is not required for non-overlapping prefixes? > > > >> 3. detect and resolve cases of duplicated addresses and/or prefixes > >> assigned to MANET routers (e.g. as a result of a network merger, or of > >> a manual misconfiguration). > >> > >> The term ICP here is used for being more precise than Internet > >> Gateway, as defined in the tentative -03 : > >> > >> Internet Configuration Provider (ICP) - An entity that can provide > >> routers requesting configuration with routable addresses or prefixes. > >> A typical example of ICP is a DHCP server. > > > > "routabe" may be replaced by "globally unique". > >Here again, "routable" is meant as "globally unique and topologically >correct", and not simply "globally unique". Maybe we should define the >term "routable address"? If we avoid use of "routable", we don't need the definition. 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 Wed Nov 28 05:14:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxJvp-0002MB-3M; Wed, 28 Nov 2007 05:14:13 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IxJvm-00026q-DQ for autoconf-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 05:14:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxJvk-00026P-KE for autoconf@ietf.org; Wed, 28 Nov 2007 05:14:10 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IxJvk-0008FR-3B for autoconf@ietf.org; Wed, 28 Nov 2007 05:14:08 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1196244846!23782188!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 24327 invoked from network); 28 Nov 2007 10:14:06 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-119.messagelabs.com with SMTP; 28 Nov 2007 10:14:06 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lASAE1rh017456; Wed, 28 Nov 2007 03:14:05 -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 lASAE0Sr019202; Wed, 28 Nov 2007 04:14:00 -0600 (CST) 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 lASADxwA019176; Wed, 28 Nov 2007 04:13:59 -0600 (CST) Message-ID: <474D3F66.3050705@gmail.com> Date: Wed, 28 Nov 2007 11:13:58 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Teco Boot Subject: Re: delegated, allocated, assigned, configured, provided (was: [Autoconf] Goals of MANET autoconf) References: <474BEF32.6000808@inria.fr> <474C3927.7060205@gmail.com> <1196178901.4021.2.camel@localhost> <006c01c83110$b8b1b1b0$2a151510$@nl> <1196181337.4021.18.camel@localhost> <007501c83115$d705b990$85112cb0$@nl> In-Reply-To: <007501c83115$d705b990$85112cb0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 071125-0, 25/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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 Teco Boot wrote: > >> -----Oorspronkelijk bericht----- Van: Carlos Jesús Bernardos Cano >> [mailto:cjbc@it.uc3m.es] [...] >> Then, coming back to the uniqueness of addresses and prefixes, if >> we are thinking about delegation of prefixes to a MANET router, >> which is going to use it to configure its/their interface/s (and >> maybe those of attached nodes), then prefixes should be unique in >> the sense that the IPv6 addresses that can be formed out of these >> prefixes are unique, compared to the addresses that can be formed >> out of other prefixes delegated within the MANET. > > I think prefix delegation is stepping into solution space. We are > working on PS now. Ok, I agree. > I would never assign a wide prefix to an interface and delegate parts > of it to other routers. This should be prohibited somewhere in an > RFC. If not, I write one!!!! I wouldn't agree :-) If we look at the Figure 6 of manetarch it says that P::/62 prefix is delegated to MANET Router, and it's not shown configured on any of its interface, so that "P::/62" is not in any of its routing tables. What does then mean to "delegate P::/62 to a MANET Router". To me it can mean there's at least one other router having an entry in its routing table for P::/62 with NextHop one of the MANET Router's IP address. This will not stop that 'other' Router to have another entry with a longer P::/63 and NextHop address of 'yet another' Router (different than that MANET Router). IF on the other hand we said that P::/62 and all its subprefixes are administratively allocated to MANET Router then I'd be sure that MANET Router is entirely in charge of P::/62 and no other Router would be in charge of any of its subprefixes. I will thus not agree with you to prohibit assigning one wide prefix to one interface and delegate parts of it to other routers. (and at the same time I think you meant short (less bits) prefix not wide). (sorry!) Think that the prefix ::/0 is allocated to the Internet and 2001::/3 (a subprefix of ::/0) is allocated to somebody else within that Internet. >> This is different from prefix aggregation in routing, we are >> talking about prefix delegation within a MANET (delegated prefixes >> used by MANET routers should not overlap). Maybe I'm missing >> something... > > What is different with existing PD? I don't get it. If some entity > provides a prefix to you, it is owned by you, respecting expiration > timers or whatever condition (NEMO use existence of tunnel). You can > use the prefix by assigning to an interface ___or____ use the prefix > for further delegation. Parts of the prefix could be reserved for > own usage, other parts for further delegation. There should not occur > a collision. If so, some of the nodes is false. What can we do? Yell? > Hit someone? OK, swap to another prefix can be used. But I prefer > introducing some security features first. I kind of understand what you mean, I won't yell :-) I think we need to use consistently the following terms with respect to prefixes: "delegated" "allocated" "assigned" "configured" "provided" I think I've read it with sometimes conflicting meanings in AUTOCONF, MIP6 and DHC WGs discussions. Sometimes I could understand ok even if meanings are conflicting but sometimes the terminology conflict is obviously the issue. Just a thought. 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 Nov 28 05:23: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 1IxK5H-00042M-8P; Wed, 28 Nov 2007 05:23:59 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IxK5F-0003pc-KM for autoconf-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 05:23:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxK5F-0003nc-7n for autoconf@ietf.org; Wed, 28 Nov 2007 05:23:57 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IxK5E-0000XO-JZ for autoconf@ietf.org; Wed, 28 Nov 2007 05:23:57 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-128.messagelabs.com!1196245434!9785633!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 11643 invoked from network); 28 Nov 2007 10:23:54 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-10.tower-128.messagelabs.com with SMTP; 28 Nov 2007 10:23:54 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id lASANrGC013488; Wed, 28 Nov 2007 03:23:53 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id lASANqpF004924; Wed, 28 Nov 2007 04:23:52 -0600 (CST) 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 lASANn6P004899; Wed, 28 Nov 2007 04:23:50 -0600 (CST) Message-ID: <474D41B5.4010200@gmail.com> Date: Wed, 28 Nov 2007 11:23:49 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: mase Subject: Re: [Autoconf] Goals of MANET autoconf References: <474BEF32.6000808@inria.fr> <200711271655.27469.fjrm@dif.um.es> <006401c8310f$05a614e0$10f23ea0$@nl> <200711271829.53779.fjrm@dif.um.es> <008401c83120$2bf04420$83d0cc60$@nl> <474C9837.5050904@inria.fr> <7.0.0.16.2.20071128135448.0337aed0@ie.niigata-u.ac.jp> In-Reply-To: <7.0.0.16.2.20071128135448.0337aed0@ie.niigata-u.ac.jp> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071125-0, 25/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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 mase wrote: > Dear Emmanuel. > > Thank you for updating goal item lists. My comments and questions are in > line. > > Thanks, > Kenichi > > At 07:20 07/11/28, Emmanuel Baccelli wrote: >> OK, here is an updated tentative item list, reflecting the latest >> comments. Let us continue this healthy discussion and try to boil down >> to an expression most people agree with. So what do we think of this? >> >> 1. provide unique addresses and/or non-overlapping prefixes valid for >> communication within the MANET, to MANET routers requiring such >> configuration. > > I am aware that use of non-overlapping" has been suggeted. But, I am not > sure about the difference between unique and non-overlapping. Given any > scope, unique and non-overlapping have the same meaning. And, if so, use > of two terms, one for address and the other for prefix is confusing. I agree 'non-overlapping' has been suggested and I'm not sure either about the difference. If we knew the 'scope' precisely then I think I could understand better. But 'scope' itself is not defined. >> 2. if one (or more) ICP is reachable, provide routable, globally >> unique addresses and/or routable non-overlapping prefixes to MANET >> routers requiring such configuration. > > I am not sure why "routable"is not used in$B!!#1(B. and used in 2. Maybe, > routable here means routable in the Internet toward MANET. If so, > routable and globally unique seem redundant, because it is trivial that > we do not use a globally unique but not routable address in the > Internet. Am I missing something here? I agree. BEsides, I don't think IPv6 has non-routable addresses other than the link-local address and ULAs. So we'd need our position with respect to these two. Is a MLA a link-local address? A ULA? ("IPv6 Unique Local Address" RFC4193). None of these two? >> 3. detect and resolve cases of duplicated addresses and/or prefixes >> assigned to MANET routers (e.g. as a result of a network merger, or of >> a manual misconfiguration). >> >> The term ICP here is used for being more precise than Internet >> Gateway, as defined in the tentative -03 : >> >> Internet Configuration Provider (ICP) - An entity that can provide >> routers requesting configuration with routable addresses or prefixes. >> A typical example of ICP is a DHCP server. > > "routabe" may be replaced by "globally unique". ULAs (and link-local addresses to a certain extent) seem to be globally unique but non-routable. And I think Emmanuel's intention is that ICP distributes addresses that are not ULAs nor link-local addresses. Alex > > > > > > _______________________________________________ > 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 Wed Nov 28 05:37:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxKIU-0007AM-B6; Wed, 28 Nov 2007 05:37:38 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IxKIS-00079o-PI for autoconf-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 05:37:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxKIS-00079g-ET for autoconf@ietf.org; Wed, 28 Nov 2007 05:37:36 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IxKIR-0001Oz-Vx for autoconf@ietf.org; Wed, 28 Nov 2007 05:37:36 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-2.tower-153.messagelabs.com!1196246254!13129714!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 1484 invoked from network); 28 Nov 2007 10:37:34 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-2.tower-153.messagelabs.com with SMTP; 28 Nov 2007 10:37:34 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id lASAbYCU007108; Wed, 28 Nov 2007 03:37:34 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id lASAbXiL024752; Wed, 28 Nov 2007 04:37:33 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id lASAbVfh024734; Wed, 28 Nov 2007 04:37:32 -0600 (CST) Message-ID: <474D44EA.7040302@gmail.com> Date: Wed, 28 Nov 2007 11:37:30 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Emmanuel Baccelli Subject: Re: [Autoconf] Goals of MANET autoconf References: <474BEF32.6000808@inria.fr> <200711271655.27469.fjrm@dif.um.es> <006401c8310f$05a614e0$10f23ea0$@nl> <200711271829.53779.fjrm@dif.um.es> <008401c83120$2bf04420$83d0cc60$@nl> <474C9837.5050904@inria.fr> In-Reply-To: <474C9837.5050904@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071125-0, 25/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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: > OK, here is an updated tentative item list, reflecting the latest > comments. Let us continue this healthy discussion and try to boil down > to an expression most people agree with. So what do we think of this? > > > 1. provide unique addresses and/or non-overlapping prefixes valid for > communication within the MANET, to MANET routers requiring such > configuration. > > 2. if one (or more) ICP is reachable, provide routable, globally unique > addresses and/or routable non-overlapping prefixes to MANET routers > requiring such configuration. > > 3. detect and resolve cases of duplicated addresses and/or prefixes > assigned to MANET routers (e.g. as a result of a network merger, or of a > manual misconfiguration). But we said we _can't_ detect cases of duplicated prefixes. Given two prefixes of different lengths sometimes I think they're duplicates sometimes I think they're unique. What do you think? 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 Nov 28 05:45: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 1IxKPc-0006WU-1d; Wed, 28 Nov 2007 05:45:00 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IxKPa-0006WN-MZ for autoconf-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 05:44:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxKPa-0006WD-CW for autoconf@ietf.org; Wed, 28 Nov 2007 05:44:58 -0500 Received: from an-out-0708.google.com ([209.85.132.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxKPX-0005rD-VV for autoconf@ietf.org; Wed, 28 Nov 2007 05:44:58 -0500 Received: by an-out-0708.google.com with SMTP id d11so315553and for ; Wed, 28 Nov 2007 02:44:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=uS26pAdb/U52UbDLcmYQkQvF0PikyrXJoREPM90gC+U=; b=qAKoaN0NbLe3LYsCG0weq56M8ekPWAVzKh2h25BHfI7Snwec91qMllQC33l2l75/tHjiNL6SN4OPClh4yVW7+bgGtn6IwmErSt+VclfYgSCO/ofu7QTtXW0k/Wf+gc+9amyAb1FXIiqx52ZWEFemICFg6ee9KMG5vZayMHr7L+8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=pF3zcKbyftV4+D+OD63CylK1KKY78lErlDw3ZhMYqPLBwT+rVtOW6vrx6ldfxeHzIfDvMlfycn+PATarCJ9abdr9E/EFL6kM2A8AlLgOCKw/H656wnKMbIsLpYf0VruvwejW9Cyu0uIixIgeMhgA1qOiE1+c1AFwNxPBd0qsois= Received: by 10.100.152.19 with SMTP id z19mr8767547and.1196246695665; Wed, 28 Nov 2007 02:44:55 -0800 (PST) Received: by 10.100.229.8 with HTTP; Wed, 28 Nov 2007 02:44:55 -0800 (PST) Message-ID: Date: Wed, 28 Nov 2007 16:14:55 +0530 From: Shubhranshu To: "Alexandru Petrescu" Subject: Re: [Autoconf] Re: Some Thoughts on Problem Statement. MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 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 comments ----- Original Message ----- From: "Alexandru Petrescu" To: "Shubhranshu" > Shubhranshu, thanks for your message. To my reading, your message has > structure in it; e.g. it says which are the cases to be followed. It > also seems to take into account most major ideas having already been > exposed (since the little while I follow it). I agree with it. I have > some comments. Good to hear that. > > Overall, I'm trying to identify where and how do protocols break. > > Shubhranshu wrote: > Also, MANET Scope is somehting I need to understand better. Is MANET > Scope in any relationship with the existing scopes: link-local scope, > global scope? Is MANET Scope in some relationship with the scope of the > all-manet-routers IP multicast group requested by manet-iana document? > > Is MANET scope in some relationship with the scopes of the following > Ethernet MAC multicast addresses: 33::1 (all Ethernet hosts), 33::2 (all > Ethernet routers), or other Ethernet MAC multicast group scopes? > > _some_ relationship? _No_ relationship whatsoever? IMO, MANET scope would be same as all-manet-routers multicast address but the manet-iana document authors can confirm this. > > This makes me think the MANET Router doesn't communicate to anybody > else than self. Its (real) network interface has no hosts attached to > it (has Routers attached to it?), MANET interface is virtual and > loopback interface leads to self. I may misunderstand you. > > Also, I will have to read other documents to understand why the loopback > interface needs to have address/prefix. If I understand that then maybe > I can understand the above as well. Not sure why you think MANET router does not communicate with anyone else than self. Its network interface may or may not have any attached hosts, depending on the application / deployment scenario. MANET routers are expected to run manet-protocols on their MANET interface only. > >> 2) Configuration of MANET interface: >> >> MANET Router uses this interface to communicate with other MANET >> Routers. MANET routing and other MANET specific protocols are >> expected to run on this interface. This interface SHOULD be >> configured with a link local address and/or a /128 (in case of IPv6) >> or with /32 (in case of IPv4) address. MANET interface may also use >> smaller prefix provided the prefix uniqueness is guaranteed. >> Configuration of MANET interface with a link local address and/or a >> /128 address is straightforward, as it can use existing mechanisms, >> except the issue of address uniqueness test over "multi-hop network". > > I agree. Ok. > > If the MANET interface is virtual then I think there's no standard for > defining link-local address on a virtual interface. People do different > things for these, sometimes random. > > I think a good virtual interface (MANET interface or other) would need: > -a link-local address (/128 length). > -a link-local prefix (the fe80 /10 length). > -maybe a global subnet prefix with global address. > -maybe another global subnet prefix with a global address. > > I think you mean that "MANET Interface" means a sort of a label we put > on a real network interface. Something that in some contexts some > people call "egress interface", or "ingress interface". > > So, if you mean MANET Interface is a real interface, then we may already > have a means to form a link-local address for it. Agree, MANET interface is real interface and, in your words, MANET interface is a sort of label we put on real network interface because manet-protocols are suppose to run on this interface. > >> The probability of address duplication is quite low if most of the >> /128 bits are randomly generated and so a node may skip address >> uniqueness test. However, address uniqueness detection / resolution >> is a requirement when smaller prefixes are used and also in military >> & other critical MANET application scenarios. The address uniqueness >> detection / resolution should be done across the entire network thus >> requiring that the specific broadcast/multicast messages used for >> this purpose be propagated "even to MANET Routers that are multi-hop >> away". Currently there is no standard specification that addresses >> this requirement. > > I think I'd suggest that when the MANET network uses subnets with > well-defined link-layer multicast behaviour then the duplication should > be ensured by DAD. If the MANET network doesn't use such subnets, or > uses SBI (semi-broadcast interface) then the address uniqueness > detection should be indeed done across the semi-subnets (maybe define > semi-subnet). > > Or maybe that address uniqueness should be _ensured_ across the entire > MANET network, probably with a detection mechanism that acts on a scope > lesser than the entire MANET network. I think it needs to be done across the network. Not sure why you suggest to use some detection mechanism to act on a scope lesser than the entire network. May be for performance optimization ? - Shubhranshu > > This is related to that MANET scope... > > I will read the tail of this message later. > > Thanks, > > Alex > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 28 05:47: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 1IxKS7-0000xj-HU; Wed, 28 Nov 2007 05:47:35 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IxKS6-0000x0-TS for autoconf-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 05:47:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxKS6-0000wp-Hg for autoconf@ietf.org; Wed, 28 Nov 2007 05:47:34 -0500 Received: from an-out-0708.google.com ([209.85.132.240]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxKS6-00023j-7V for autoconf@ietf.org; Wed, 28 Nov 2007 05:47:34 -0500 Received: by an-out-0708.google.com with SMTP id d11so315672and for ; Wed, 28 Nov 2007 02:47:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=8lGFrsqCyqmOKKIg/AYBysUXxjDQIWxWE6Es44fHwVM=; b=DCZ7jxNQ2khVGiBY3TUUngMNymP0IjGcrdfNNJjr1BmPr5OILEqJx7BBNRHFcHU3J417zq2ftWtsWGz3LggNn0FYS+UVvDf41ZIf63PDpxsPpOIg6gRhpawl+43kakS7secqnWT46L4uDlvVWoIOE6vKadHbLvVBlLh+GujQbUs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=X8Clg3FvpuePjCgQW7lK0J8xp93xQaBRrgQT5ePIi6TKYR6rrGaHQYKp1ca+wIqrW1t5k1U/L7p+QdJUPhrDt+H5tZB1zqxD6WBOk2r21l6uLJLCthCk4BGCaI/ih1vdXr13Kw+uO19Nkcs8E8Wg/+kmomqQ4Tqw63pH3M81/eE= Received: by 10.100.112.6 with SMTP id k6mr8753814anc.1196246854039; Wed, 28 Nov 2007 02:47:34 -0800 (PST) Received: by 10.100.229.8 with HTTP; Wed, 28 Nov 2007 02:47:34 -0800 (PST) Message-ID: Date: Wed, 28 Nov 2007 16:17:34 +0530 From: Shubhranshu To: "Francisco J. Ros" Subject: Re: [Autoconf] Goals of MANET autoconf MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 Francisco, Please see below: ----- Original Message ----- From: "Francisco J. Ros" > >> On merges: yes, some types of address generation have a somewhat high >> probability on collisions. >> But we are scoped on autoconfiguration, or am I missing something? >> > Manually configured addresses was just an example. Depending on the final > [autoconf] protocol(s), we could find situations where duplicated global > addresses appear. So, in the context of the P-S, are we sure that this is > never going to happen? If not, why exclude global addresses from the > (in-service) uniqueness check if, in fact, it could come "for free" with the > same mechanism for non-global? > > My suggestion is not being so explicit right now, and just talk > about "configured address uniqueness in the situation where different ad hoc > networks merge" (from the charter). Agree, as said before since initially isolated MANETs had allocated addresses independent with each other, there remains some probability, after merger, of more than one node using same address. - Shubhranshu > > Regards, > fran > >> My personal experience in real world: many years ago I had to deal with a >> malware attack, utilizing duplicate checks. Still, this is one of my >> nightmares. Just to place DAD in perspective, it has also a large, large >> drawback. I am not against DAD, but I want to use it very carefully. >> >> By the way, I like using anycast a lot, especially in an ad-hoc >> environment. Typically addresses are configured manually and must not be >> blocked by multi-link DAD. >> >> Teco. >> >> > Regards, >> > fran _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 28 06:18:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxKvi-0005kw-KC; Wed, 28 Nov 2007 06:18:10 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IxKvg-0005kk-Qt for autoconf-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 06:18:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxKvg-0005kc-DE for autoconf@ietf.org; Wed, 28 Nov 2007 06:18:08 -0500 Received: from an-out-0708.google.com ([209.85.132.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxKvf-0007ax-IR for autoconf@ietf.org; Wed, 28 Nov 2007 06:18:08 -0500 Received: by an-out-0708.google.com with SMTP id d11so317247and for ; Wed, 28 Nov 2007 03:18:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=Br3K8JpR2RRwjowRjPq90xv910uPh3yaufcJno6mNDU=; b=Vvryb8oP91L7sxE/Z8+lqcG5jZSSj2mqA1FwIiJMxVvEGtEDxOG+7gvoPN+1rIQ/3s2Y1E08VO+kUMxsFuuU0KXHSRcr7vaI2kXmDiYQeyJc6RFohgyYFbPZPCXuUOQyPCmPRrfIJMshz8AcNVMuKP1vm/ki+cQVgCH/wU9b+/w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=odDZc7geb9HC6x998evcQpTAMUoyRhZOjrHtTIwGlqI5ydiHaWM2L42ZfKDtyOuCo6FABJ9AbqtXM+vFDGMYdOxsyWZLXObXTNKaoCR1VZN7U0EKpPxQJQStmGiSuPPjFztFCddG9AZQdyr0/abjsjEa7r95YjUiAj/u8P5RnrM= Received: by 10.100.247.14 with SMTP id u14mr8808374anh.1196248687267; Wed, 28 Nov 2007 03:18:07 -0800 (PST) Received: by 10.100.229.8 with HTTP; Wed, 28 Nov 2007 03:18:07 -0800 (PST) Message-ID: Date: Wed, 28 Nov 2007 16:48:07 +0530 From: Shubhranshu To: "Ulrich Herberg" Subject: Re: [Autoconf] Re: Some Thoughts on Problem Statement. MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 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 Ulrich, Please see inline commnets. ----- Original Message ----- From: "Ulrich Herberg" To: "Alexandru Petrescu" Cc: ; "Shubhranshu" > Hello Alexandru, hello Shubhranshu, > > I also think that the text by Shubhranshu is very useful; some > comments inline... Good to hear that. > > On 11/26/07, Alexandru Petrescu wrote: >> > A MANET router needs to configure an IPv6 prefix(es) on its host >> > interface and/or an IPv6 address on its loopback interface. Besides, >> > it needs to configure a /128 (or /32 in case of IPv4) and/or a link >> > local address on its MANET interface. >> >> I yet have to understand why MANET router has to configure a prefix on >> its loopback interface. It's probably by proper definition of MANET - >> in that case, sorry, froget it. > > To my understanding, this loopback interface serves as a "logical" > host on the MANET node (correct me if I am wrong). As in real-life > scenarios, most of the time a mobile node will not only be a router > but some mobile device (PDA, laptop, ...), it will run some > applications on it (e.g. web browser). The loopback interface > definitely needs to be explained in the manetarch draft as I am also > not sure whether my explanation is correct. Loopback interface is just a logical interface and more of implementation details. Here it is mentioned to show the integrity with respect to classical IP addressing architecture. If there are confusions then perhaps PS ID can clarify them, while remaining within the document scope. > > Another reason of using the loopback interface could be to not > attribute an IP address to the MANET interface but using unnumbered > interfaces (as specified by Cisco). > >> On another hand, if a Router has a prefix in its config file and looks >> for a way to configure a address from that prefix on one of its real >> interfaces, then one possibility is to derive itself an address from its >> Ethernet MAC address, attach it to that prefix and then 'ifconfig' and >> 'route add'. Another alternative is to send RAs on its loopback >> interface with that prefix, and let the IPv6 stack autoconfigure >> address, prefix and route as usual. These are two choices. > I think that this is correct. While the first case is simpler, it > would mean changing the way of how a network interface is configured. > By the way, do you know how the loopback interface in for example > Linux is configured? That would be an interesting comparison. Sure, it > normally has ::1/128 as fixed address, but could one assign prefixes > to it using RA messages? Loopback interface is configured same way as other interfaces i.e. you still do ifconfig, etc just the name changes. The difference is in that one is real and other is logical and linux and other implementation would route the packets to self if sent to the loopback interface. - Shubhranshu >> Also, MANET Scope is somehting I need to understand better. Is MANET >> Scope in any relationship with the existing scopes: link-local scope, >> global scope? Is MANET Scope in some relationship with the scope of the >> all-manet-routers IP multicast group requested by manet-iana document? >> >> Is MANET scope in some relationship with the scopes of the following >> Ethernet MAC multicast addresses: 33::1 (all Ethernet hosts), 33::2 (all >> Ethernet routers), or other Ethernet MAC multicast group scopes? >> >> _some_ relationship? _No_ relationship whatsoever? > > I don't know... I do not think that there is a common agreement on > this term. The border between a MANET and the Internet using an ICP > might be understandable (even though it has also been remarked that > when a MANET is connected to the Internet, it is at that moment part > of the Internet). However, when two or more MANETs are in the direct > neighborhod and do not merge but instead add inter-MANET routes > between them using aggregation, the MANET scope is less evident for > me. If MANETs could for example use aggregation for different > hierarchical levels of prefixes, it might be difficult to say: "The > MANET ends _here_". >> > As mentioned above, there are three interfaces under consideration >> > for address auto-configuration. Further detail related to these >> > address auto-configuration is provided below: >> > >> > 1) Configuration of loopback interface: >> > >> > It is possible that a MANET Router does not have any host attached to >> > its network interface or it has only MANET interface which can be >> > used for intra-manet communication. In the absence of any "external" >> > host, MANET router may configure an IPv6 global address on its >> > loopback interface. The traditional auto configuration procedure such >> > as RFC 2462, can be used for this purpose provided the MANET router >> > has been assigned a suitable prefix. As usual, this interface is >> > expected to send multicast RA/RS messages. However, in this case, >> > these messages would be limited to the Router's loopback interface >> > only. >> >> This makes me think the MANET Router doesn't communicate to anybody >> else than self. Its (real) network interface has no hosts attached to >> it (has Routers attached to it?), MANET interface is virtual and >> loopback interface leads to self. I may misunderstand you. >> >> Also, I will have to read other documents to understand why the loopback >> interface needs to have address/prefix. If I understand that then maybe >> I can understand the above as well. > > Same for me :-) That's why a description of the loopback interface > would be nice in the manetarch draft. > >> >> > 2) Configuration of MANET interface: >> > >> > MANET Router uses this interface to communicate with other MANET >> > Routers. MANET routing and other MANET specific protocols are >> > expected to run on this interface. This interface SHOULD be >> > configured with a link local address and/or a /128 (in case of IPv6) >> > or with /32 (in case of IPv4) address. MANET interface may also use >> > smaller prefix provided the prefix uniqueness is guaranteed. >> > Configuration of MANET interface with a link local address and/or a >> > /128 address is straightforward, as it can use existing mechanisms, >> > except the issue of address uniqueness test over "multi-hop network". >> >> I agree. >> >> If the MANET interface is virtual then I think there's no standard for >> defining link-local address on a virtual interface. People do different >> things for these, sometimes random. > > I don't understand this. Why do you say it is a virtual interface? I > thought that it is a real interface on a mobile node, and that it is > the only interface on the node which knows and cares about MANET > characteristics (e.g. by running a MANET routing protocol on it). > >> >> I think a good virtual interface (MANET interface or other) would need: >> -a link-local address (/128 length). >> -a link-local prefix (the fe80 /10 length). >> -maybe a global subnet prefix with global address. >> -maybe another global subnet prefix with a global address. >> >> I think you mean that "MANET Interface" means a sort of a label we put >> on a real network interface. Something that in some contexts some >> people call "egress interface", or "ingress interface". >> >> So, if you mean MANET Interface is a real interface, then we may already >> have a means to form a link-local address for it. > > Ah, know I think I understood you. So you mean that a MANET interface > is virtual in the sense that it only a "caption" somehow for a real > (e.g. 802.11) network interface, do you? Well, to my understanding it > probably makes thinks more complicate to talk about a virtual > interface instead of a "real" MANET interface > > Regards, > Ulrich _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 28 06:37:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxLEd-0003J2-23; Wed, 28 Nov 2007 06:37:43 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IxLEa-0003Ic-VR for autoconf-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 06:37:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxLEa-0003IU-Eh for autoconf@ietf.org; Wed, 28 Nov 2007 06:37:40 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IxLEZ-0000hH-R3 for autoconf@ietf.org; Wed, 28 Nov 2007 06:37:40 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-119.messagelabs.com!1196249859!22615334!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 12156 invoked from network); 28 Nov 2007 11:37:39 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-119.messagelabs.com with SMTP; 28 Nov 2007 11:37:39 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lASBbXm6005344; Wed, 28 Nov 2007 04:37:33 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id lASBbXSG024096; Wed, 28 Nov 2007 05:37:33 -0600 (CST) 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 lASBbVaU024077; Wed, 28 Nov 2007 05:37:32 -0600 (CST) Message-ID: <474D52FA.3010401@gmail.com> Date: Wed, 28 Nov 2007 12:37:30 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Shubhranshu Subject: Re: [Autoconf] Re: Some Thoughts on Problem Statement. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071125-0, 25/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 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: > >> Also, MANET Scope is somehting I need to understand better. Is >> MANET Scope in any relationship with the existing scopes: >> link-local scope, global scope? Is MANET Scope in some >> relationship with the scope of the all-manet-routers IP multicast >> group requested by manet-iana document? >> >> Is MANET scope in some relationship with the scopes of the >> following Ethernet MAC multicast addresses: 33::1 (all Ethernet >> hosts), 33::2 (all Ethernet routers), or other Ethernet MAC >> multicast group scopes? >> >> _some_ relationship? _No_ relationship whatsoever? > > IMO, MANET scope would be same as all-manet-routers multicast address > but the manet-iana document authors can confirm this. Ok, I would like to know whether MANET Scope is the same as all-manet-routers multicast address scope. If that is the case, then it is necessary what is the relationship between that scope and Ethernet link scope. >> This makes me think the MANET Router doesn't communicate to >> anybody else than self. Its (real) network interface has no hosts >> attached to it (has Routers attached to it?), MANET interface is >> virtual and loopback interface leads to self. I may misunderstand >> you. >> >> Also, I will have to read other documents to understand why the >> loopback interface needs to have address/prefix. If I understand >> that then maybe I can understand the above as well. > > Not sure why you think MANET router does not communicate with anyone > else than self. Its network interface may or may not have any > attached hosts, depending on the application / deployment scenario. > MANET routers are expected to run manet-protocols on their MANET > interface only. Ok, I understand that on some MANET Router all other nodes are connected to the MANET Router's MANET interface(s). >> If the MANET interface is virtual then I think there's no standard >> for defining link-local address on a virtual interface. People do >> different things for these, sometimes random. >> >> I think a good virtual interface (MANET interface or other) would >> need: -a link-local address (/128 length). -a link-local prefix >> (the fe80 /10 length). -maybe a global subnet prefix with global >> address. -maybe another global subnet prefix with a global address. >> >> >> I think you mean that "MANET Interface" means a sort of a label we >> put on a real network interface. Something that in some contexts >> some people call "egress interface", or "ingress interface". >> >> So, if you mean MANET Interface is a real interface, then we may >> already have a means to form a link-local address for it. > > Agree, MANET interface is real interface and, in your words, MANET > interface is a sort of label we put on real network interface because > manet-protocols are suppose to run on this interface. I understand. >>> The probability of address duplication is quite low if most of >>> the /128 bits are randomly generated and so a node may skip >>> address uniqueness test. However, address uniqueness detection / >>> resolution is a requirement when smaller prefixes are used and >>> also in military & other critical MANET application scenarios. >>> The address uniqueness detection / resolution should be done >>> across the entire network thus requiring that the specific >>> broadcast/multicast messages used for this purpose be propagated >>> "even to MANET Routers that are multi-hop away". Currently there >>> is no standard specification that addresses this requirement. >> I think I'd suggest that when the MANET network uses subnets with >> well-defined link-layer multicast behaviour then the duplication >> should be ensured by DAD. If the MANET network doesn't use such >> subnets, or uses SBI (semi-broadcast interface) then the address >> uniqueness detection should be indeed done across the semi-subnets >> (maybe define semi-subnet). >> >> Or maybe that address uniqueness should be _ensured_ across the >> entire MANET network, probably with a detection mechanism that acts >> on a scope lesser than the entire MANET network. > > I think it needs to be done across the network. Not sure why you > suggest to use some detection mechanism to act on a scope lesser than > the entire network. May be for performance optimization ? Not for performance optimization, just to say that DAD acts on the well-define Ethernet link scope. That is supposedly lesser scope than MANET scope. But I'm not sure you mean that MANET scope is lesser scope than Ethernet, or the same scope, or wider scope. If we say that MANET scope is same as Ethernet link scope then DAD can work on MANET scope. If we say MANET scope can contain several Ethernet link scopes then one would do DAD on each of these links, each link would be a subnet. If we say that Ethernet scope can contain several MANET scopes then IP DAD would not work. 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 Nov 29 04:39:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxfrT-0003Yf-2D; Thu, 29 Nov 2007 04:39:11 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IxfrR-0003YT-9W for autoconf-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 04:39:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxfrQ-0003YH-TJ for autoconf@ietf.org; Thu, 29 Nov 2007 04:39:08 -0500 Received: from rn-out-0910.google.com ([64.233.170.191] helo=rn-out-0102.google.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxfrQ-0002OC-44 for autoconf@ietf.org; Thu, 29 Nov 2007 04:39:08 -0500 Received: by rn-out-0102.google.com with SMTP id i50so1624382rne for ; Thu, 29 Nov 2007 01:39:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:x-google-sender-auth; bh=KKAxEd0kcRu/qD9pMu8yZZhQHc84W8docwN+KWRYaxs=; b=nMZp9v5ogmTh+M+vXaCfyQNg7g0d32cSadapzS0kgm37SI2XBZzKGRpXhTHp24VDL9Woco+tmHlkwOzQxbL81aSH8FVDhlI3GAX+61OnUgcD0cJZxOFP6/ZBfFw5t2XJDXKwp8LcIHOQ6tA6b9d25PHQE3FFY+CXwzNdvTHYXCo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:x-google-sender-auth; b=tqmCYTHUJpOsUcyH/HZq/jtnNGynv6421a9ArzzNkPdzlAunP5MW8TqDdgRQCKKEzwYPram2FMR+HNDW2BLaVRnbFKevHOYUOMy2URPTPYWuUoWkXsbbnhv0XdcNjXsg+Jn1yS14jcVcbXBPFrn5E5OXiFBSHsryPWUDPmbI9Rs= Received: by 10.70.52.8 with SMTP id z8mr276859wxz.1196329147088; Thu, 29 Nov 2007 01:39:07 -0800 (PST) Received: by 10.70.25.16 with HTTP; Thu, 29 Nov 2007 01:39:07 -0800 (PST) Message-ID: Date: Thu, 29 Nov 2007 18:39:07 +0900 From: "Kazuki AKIMA" To: thomas.hahusseau@eads.com Subject: RE:[Autoconf] Autoconf implementations ? MIME-Version: 1.0 X-Google-Sender-Auth: 2bc0f1d57975cb01 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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="===============0540544079==" Errors-To: autoconf-bounces@ietf.org --===============0540544079== Content-Type: multipart/alternative; boundary="----=_Part_7028_32516809.1196329147073" ------=_Part_7028_32516809.1196329147073 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello Thomas, Thank you for comment. Our NOA-OLSR imprementation haven't be enchecked on kernel "2.6.x", and it can't work on kernel "2.6.x.", sorry. But we are sure that our implimentation works on kernel " 2.4.x". We are continuing the project about OLSRv2 and autoconfiguration implementation. Our OLSRv2 implementation (called "nOLSRv2") is available. nOLSRv2 runs as Linux routing daemon if you just compile it on a Linux platform. nOLSRv2 is also able to run on QualNet Internet Simulator, if you compile it with QualNet source code. Please see this URI. http://www.net.ie.niigata-u.ac.jp/~yowada/v2/ Additionaly, We impremented a new Passive DAD algorithms (not yet published) for nOLSRv2. This new DAD implementation works on linux (kernel "2.4.x"), but it isn't released yet, sorry. (I think that some bugs and problems are exist yet...) Your sincerely Kazuki Akima P.S. Some kernel modules and softwares (ex. "ipqueue", "iptable_filter" and "iptables") are reqired by our NOA-OLSR imprementation. All of them are installed in your linux? Please check them! --- Kazuki AKIMA Information and Communication Network Lab. Graduate School of Science and Technology, Niigata University Hahusseau, Thomas wrote: > Hello, > > This is my first email on that list. I would like to know if there is some implementation of autoconfiguration protocols for standalone MANETs under development ? the only ones I found were a couple years old : > > - Pacman feb 2005 > > - Manet:Prophet may 2004 > > - NOA-OLSR jul 2005 > > The only one which seems to be still supported is AHCPd : nov 2007 > > Most of them doesn't work on recent kernel ( 2.6.x), because they use ipqueue which seems to be deprecated on 2.6.x kernels. Does anyone know where I could find recent implementation of autoconfiguration protocols for MANETs ? All projects about autoconfiguration implementations seems to be dead (except AHCP) or what ? It's hard to believe that nobody works on it, because there few mails on that list about comments on draft and the WG doesn't look to be dead. > > Your sincerely > > Thomas Hahusseau > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf ------=_Part_7028_32516809.1196329147073 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello Thomas,

Thank you for comment.

Our NOA-OLSR imprementation haven't be enchecked on kernel "2.6.x", and it can't work on kernel "2.6.x.", sorry.
But we are sure that our implimentation works on kernel " 2.4.x".

We are continuing the project about OLSRv2 and autoconfiguration implementation. 
Our OLSRv2 implementation (called "nOLSRv2") is available.
nOLSRv2 runs as Linux routing daemon if you just compile it on a Linux platform.
nOLSRv2 is also able to run on QualNet Internet Simulator, if you compile it with QualNet source code.
Please see this URI.
http://www.net.ie.niigata-u.ac.jp/~yowada/v2/

Additionaly, We impremented a new Passive DAD algorithms (not yet published) for nOLSRv2. This new DAD implementation works on linux (kernel "2.4.x"), but it isn't released yet, sorry. (I think that some bugs and problems are exist yet...)

Your sincerely
Kazuki Akima

P.S. Some kernel modules and softwares (ex. "ipqueue", "iptable_filter" and "iptables") are reqired by our NOA-OLSR imprementation. All of them are installed in your linux? Please check them!

---
Kazuki AKIMA$B!!(B<kakima@net.ie.niigata-u.ac.jp>
Information and Communication Network Lab.
Graduate School of Science and Technology, Niigata University

Hahusseau, Thomas wrote:
> Hello,
>
> This is my first email on that list. I would like to know if there is some implementation of autoconfiguration protocols for standalone MANETs under development ? the only ones I found were a couple years old :
>
> - Pacman feb 2005
>
> - Manet:Prophet may 2004
>
> - NOA-OLSR jul 2005
>
> The only one which seems to be still supported is AHCPd : nov 2007
>
> Most of them doesn't work on recent kernel ( 2.6.x), because they use ipqueue which seems to be deprecated on 2.6.x kernels. Does anyone know where I could find recent implementation of autoconfiguration protocols for MANETs ? All projects about autoconfiguration implementations seems to be dead (except AHCP) or what ? It's hard to believe that nobody works on it, because there few mails on that list about comments on draft and the WG doesn't look to be dead.
>
> Your sincerely
>
> Thomas Hahusseau
>
>  
> _______________________________________________
> Autoconf mailing list
> Autoconf@ietf.org
> https://www1.ietf.org/mailman/listinfo/autoconf

------=_Part_7028_32516809.1196329147073-- --===============0540544079== 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 --===============0540544079==-- From autoconf-bounces@ietf.org Thu Nov 29 08:39: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 1IxjcS-0006MK-89; Thu, 29 Nov 2007 08:39:56 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IxjcR-0006MC-Kk for autoconf-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 08:39:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxjcR-0006M4-7M for autoconf@ietf.org; Thu, 29 Nov 2007 08:39:55 -0500 Received: from mail2-relais-roc.national.inria.fr ([192.134.164.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxjcP-0000XO-NE for autoconf@ietf.org; Thu, 29 Nov 2007 08:39:55 -0500 X-IronPort-AV: E=Sophos;i="4.23,229,1194217200"; d="scan'208";a="4734344" Received: from monteverdi.inria.fr ([128.93.17.56]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Nov 2007 14:39:50 +0100 Message-ID: <474EC126.3030909@inria.fr> Date: Thu, 29 Nov 2007 14:39:50 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org Subject: Re: [Autoconf] Goals of MANET autoconf References: <474BEF32.6000808@inria.fr> <200711271655.27469.fjrm@dif.um.es> <006401c8310f$05a614e0$10f23ea0$@nl> <200711271829.53779.fjrm@dif.um.es> <008401c83120$2bf04420$83d0cc60$@nl> <474C9837.5050904@inria.fr> <474D44EA.7040302@gmail.com> In-Reply-To: <474D44EA.7040302@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 Alexandru Petrescu a écrit : > Emmanuel Baccelli wrote: >> >> 3. detect and resolve cases of duplicated addresses and/or prefixes >> assigned to MANET routers (e.g. as a result of a network merger, or of >> a manual misconfiguration). > > But we said we _can't_ detect cases of duplicated prefixes. > > Given two prefixes of different lengths sometimes I think they're > duplicates sometimes I think they're unique. > > What do you think? > > Alex > > OK. So if we say instead "detect and resolve cases of duplicated addresses and overlapping prefixes", does this answer your question? Emmanuel _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 29 09:32: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 1IxkQx-0002fd-Ng; Thu, 29 Nov 2007 09:32:07 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IxkQv-0002er-SP for autoconf-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 09:32:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxkQu-0002eJ-UZ for autoconf@ietf.org; Thu, 29 Nov 2007 09:32:04 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IxkQu-0000hh-HL for autoconf@ietf.org; Thu, 29 Nov 2007 09:32:04 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-119.messagelabs.com!1196346722!29954388!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 2509 invoked from network); 29 Nov 2007 14:32:03 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-5.tower-119.messagelabs.com with SMTP; 29 Nov 2007 14:32:03 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id lATEW0IU027153; Thu, 29 Nov 2007 07:32:02 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id lATEVxS5010953; Thu, 29 Nov 2007 08:31:59 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id lATEVvcL010912; Thu, 29 Nov 2007 08:31:57 -0600 (CST) Message-ID: <474ECD5C.7060709@gmail.com> Date: Thu, 29 Nov 2007 15:31:56 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Emmanuel Baccelli Subject: Re: [Autoconf] Goals of MANET autoconf References: <474BEF32.6000808@inria.fr> <200711271655.27469.fjrm@dif.um.es> <006401c8310f$05a614e0$10f23ea0$@nl> <200711271829.53779.fjrm@dif.um.es> <008401c83120$2bf04420$83d0cc60$@nl> <474C9837.5050904@inria.fr> <474D44EA.7040302@gmail.com> <474EC126.3030909@inria.fr> In-Reply-To: <474EC126.3030909@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 071128-0, 28/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 It's good to keep an ongoing 3-item list of goals to better focus the work. But why detecting this duplication of stuff? What breaks if we don't? Detecting overlapping for the sake of qualifying it as such? Emmanuel Baccelli wrote: > > > Alexandru Petrescu a écrit : >> Emmanuel Baccelli wrote: >>> >>> 3. detect and resolve cases of duplicated addresses and/or prefixes >>> assigned to MANET routers (e.g. as a result of a network merger, or >>> of a manual misconfiguration). >> >> But we said we _can't_ detect cases of duplicated prefixes. >> >> Given two prefixes of different lengths sometimes I think they're >> duplicates sometimes I think they're unique. >> >> What do you think? >> >> Alex >> >> > > > OK. So if we say instead "detect and resolve cases of duplicated > addresses and overlapping prefixes", does this answer your question? Detecting duplicate address use sounds ok. But prefixes? Why should one detect when two prefixes overlap, is this an error condition? Two networks may merge, their prefixes overlap, and everything is fine - there's nothing to solve. What do I miss? I mean if we define a more precise scope/subnet/multicast structure of MANET then we can talk about prefixes of fixed lengths eventually overlapping or duplicating (compare same-prefix lengths). Until then we (or just I) just turn round and round around issues we'd suppose are problems. (as it was presented at a certain MANEMO activity meeting: two NEMO MRs connecting egress-egress do have a certain defined subnet/multicast/scope structure, and there may be a need to detect when two /64 MNPs are different. But I can't say that in the MANET context because there's no structure in MANET by its own definition. If there's no scope/multicast/subnet structure then we can't say that we work towards the goal of detecting duplicate/overlapping prefixes. That is turning round and round for me - I can say: yes, you're right, that's it; as well as I can say I completely disagree.) 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 Nov 29 10:01:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxktJ-00067E-0m; Thu, 29 Nov 2007 10:01:25 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IxktH-0005xJ-6W for autoconf-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 10:01:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxktG-0005uW-R2 for autoconf@ietf.org; Thu, 29 Nov 2007 10:01:22 -0500 Received: from mail1-relais-roc.national.inria.fr ([192.134.164.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxktF-0003Cd-5D for autoconf@ietf.org; Thu, 29 Nov 2007 10:01:22 -0500 X-IronPort-AV: E=Sophos;i="4.23,229,1194217200"; d="scan'208";a="5065930" Received: from monteverdi.inria.fr ([128.93.17.56]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Nov 2007 16:01:20 +0100 Message-ID: <474ED440.1030806@inria.fr> Date: Thu, 29 Nov 2007 16:01:20 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org Subject: Re: [Autoconf] Goals of MANET autoconf References: <474BEF32.6000808@inria.fr> <200711271655.27469.fjrm@dif.um.es> <006401c8310f$05a614e0$10f23ea0$@nl> <200711271829.53779.fjrm@dif.um.es> <008401c83120$2bf04420$83d0cc60$@nl> <474C9837.5050904@inria.fr> <474D44EA.7040302@gmail.com> <474EC126.3030909@inria.fr> <474ECD5C.7060709@gmail.com> In-Reply-To: <474ECD5C.7060709@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 Alexandru Petrescu a écrit : > It's good to keep an ongoing 3-item list of goals to better focus the work. > I agree. Agreeing on a few items is the first step towards a consensus on a whole text, is it not? > But why detecting this duplication of stuff? What breaks if we don't? > Detecting overlapping for the sake of qualifying it as such? > If you have duplicate addresses, this breaks routing, for starters. And if some routers manage independently overlapping prefixes it may lead to duplicate address assignment. Do you agree? > Emmanuel Baccelli wrote: >> >> >> Alexandru Petrescu a écrit : >>> Emmanuel Baccelli wrote: >>>> >>>> 3. detect and resolve cases of duplicated addresses and/or prefixes >>>> assigned to MANET routers (e.g. as a result of a network merger, or >>>> of a manual misconfiguration). >>> >>> But we said we _can't_ detect cases of duplicated prefixes. >>> >>> Given two prefixes of different lengths sometimes I think they're >>> duplicates sometimes I think they're unique. >>> >>> What do you think? >>> >>> Alex >>> >>> >> >> >> OK. So if we say instead "detect and resolve cases of duplicated >> addresses and overlapping prefixes", does this answer your question? > > Detecting duplicate address use sounds ok. But prefixes? > > Why should one detect when two prefixes overlap, is this an error > condition? Two networks may merge, their prefixes overlap, and > everything is fine - there's nothing to solve. > > What do I miss? > > I mean if we define a more precise scope/subnet/multicast structure of > MANET then we can talk about prefixes of fixed lengths eventually > overlapping or duplicating (compare same-prefix lengths). Until then we > (or just I) just turn round and round around issues we'd suppose are > problems. > > (as it was presented at a certain MANEMO activity meeting: two NEMO MRs > connecting egress-egress do have a certain defined > subnet/multicast/scope structure, and there may be a need to detect > when two /64 MNPs are different. But I can't say that in the MANET > context because there's no structure in MANET by its own definition. > If there's no scope/multicast/subnet structure then we can't say that > we work towards the goal of detecting duplicate/overlapping prefixes. > That is turning round and round for me - I can say: yes, you're right, > that's it; as well as I can say I completely disagree.) > > 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 Nov 29 10:34:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxlPE-0005gU-85; Thu, 29 Nov 2007 10:34:24 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IxlPD-0005gL-8i for autoconf-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 10:34:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxlPC-0005gA-TN for autoconf@ietf.org; Thu, 29 Nov 2007 10:34:22 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IxlPC-0000at-Bx for autoconf@ietf.org; Thu, 29 Nov 2007 10:34:22 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-3.tower-119.messagelabs.com!1196350461!37018727!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 5538 invoked from network); 29 Nov 2007 15:34:21 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-119.messagelabs.com with SMTP; 29 Nov 2007 15:34:21 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lATFYLI5019737; Thu, 29 Nov 2007 08:34:21 -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 lATFYKwW027173; Thu, 29 Nov 2007 09:34:21 -0600 (CST) 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 lATFYJx8027134; Thu, 29 Nov 2007 09:34:20 -0600 (CST) Message-ID: <474EDBFB.8060105@gmail.com> Date: Thu, 29 Nov 2007 16:34:19 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Emmanuel Baccelli Subject: Re: [Autoconf] Goals of MANET autoconf References: <474BEF32.6000808@inria.fr> <200711271655.27469.fjrm@dif.um.es> <006401c8310f$05a614e0$10f23ea0$@nl> <200711271829.53779.fjrm@dif.um.es> <008401c83120$2bf04420$83d0cc60$@nl> <474C9837.5050904@inria.fr> <474D44EA.7040302@gmail.com> <474EC126.3030909@inria.fr> <474ECD5C.7060709@gmail.com> <474ED440.1030806@inria.fr> In-Reply-To: <474ED440.1030806@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 071128-0, 28/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 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 > > Alexandru Petrescu a écrit : >> It's good to keep an ongoing 3-item list of goals to better focus >> the work. >> > > I agree. Agreeing on a few items is the first step towards a > consensus on a whole text, is it not? I agree. >> But why detecting this duplication of stuff? What breaks if we >> don't? Detecting overlapping for the sake of qualifying it as such? >> >> >> > > If you have duplicate addresses, this breaks routing, for starters. It may or it may not. My first temptation is to say yes, duplicate addresses is not good. People have seen storms of packets filling screens when two hosts configure same address on the same subnet - this led to DAD mechanism. That's a problem seen by many people and very impressing such as to motivate a new and reliable mechanism. But two duplicate addresses may not break routing, it's possible to design translating schemes that work. > And if some routers manage independently overlapping prefixes it may > lead to duplicate address assignment. Do you agree? Certainly I don't agree. Every two prefixes in this Internet _are_ overlapping (the only exceptions are the pairs of prefixes whose first bit is different). Yet Internet works by using these overlapping prefixes. Alex >> Emmanuel Baccelli wrote: >>> >>> >>> Alexandru Petrescu a écrit : >>>> Emmanuel Baccelli wrote: >>>>> >>>>> 3. detect and resolve cases of duplicated addresses and/or >>>>> prefixes assigned to MANET routers (e.g. as a result of a >>>>> network merger, or of a manual misconfiguration). >>>> >>>> But we said we _can't_ detect cases of duplicated prefixes. >>>> >>>> Given two prefixes of different lengths sometimes I think >>>> they're duplicates sometimes I think they're unique. >>>> >>>> What do you think? >>>> >>>> Alex >>>> >>>> >>> >>> >>> OK. So if we say instead "detect and resolve cases of duplicated >>> addresses and overlapping prefixes", does this answer your >>> question? >> >> Detecting duplicate address use sounds ok. But prefixes? >> >> Why should one detect when two prefixes overlap, is this an error >> condition? Two networks may merge, their prefixes overlap, and >> everything is fine - there's nothing to solve. >> >> What do I miss? >> >> I mean if we define a more precise scope/subnet/multicast structure >> of MANET then we can talk about prefixes of fixed lengths >> eventually overlapping or duplicating (compare same-prefix >> lengths). Until then we (or just I) just turn round and round >> around issues we'd suppose are problems. >> >> (as it was presented at a certain MANEMO activity meeting: two NEMO >> MRs connecting egress-egress do have a certain defined >> subnet/multicast/scope structure, and there may be a need to detect >> when two /64 MNPs are different. But I can't say that in the >> MANET context because there's no structure in MANET by its own >> definition. If there's no scope/multicast/subnet structure then we >> can't say that we work towards the goal of detecting >> duplicate/overlapping prefixes. That is turning round and round for >> me - I can say: yes, you're right, that's it; as well as I can say >> I completely disagree.) >> >> 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 > ______________________________________________________________________ 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 Nov 29 10:47:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixlbh-0001sC-Qq; Thu, 29 Nov 2007 10:47:17 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Ixlbg-0001rr-GB for autoconf-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 10:47:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixlbg-0001rf-4i for autoconf@ietf.org; Thu, 29 Nov 2007 10:47:16 -0500 Received: from mail2-relais-roc.national.inria.fr ([192.134.164.83]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ixlbf-0002fZ-GC for autoconf@ietf.org; Thu, 29 Nov 2007 10:47:16 -0500 X-IronPort-AV: E=Sophos;i="4.23,229,1194217200"; d="scan'208";a="4738999" Received: from monteverdi.inria.fr ([128.93.17.56]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Nov 2007 16:47:13 +0100 Message-ID: <474EDF02.30206@inria.fr> Date: Thu, 29 Nov 2007 16:47:14 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org Subject: Re: [Autoconf] Goals of MANET autoconf References: <474BEF32.6000808@inria.fr> <200711271655.27469.fjrm@dif.um.es> <006401c8310f$05a614e0$10f23ea0$@nl> <200711271829.53779.fjrm@dif.um.es> <008401c83120$2bf04420$83d0cc60$@nl> <474C9837.5050904@inria.fr> <474D44EA.7040302@gmail.com> <474EC126.3030909@inria.fr> <474ECD5C.7060709@gmail.com> <474ED440.1030806@inria.fr> <474EDBFB.8060105@gmail.com> In-Reply-To: <474EDBFB.8060105@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 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 Alexandru Petrescu a écrit : > Emmanuel Baccelli wrote: >> Hi Alex >> >> Alexandru Petrescu a écrit : >>> It's good to keep an ongoing 3-item list of goals to better focus the >>> work. >>> >> >> I agree. Agreeing on a few items is the first step towards a consensus >> on a whole text, is it not? > > I agree. > >>> But why detecting this duplication of stuff? What breaks if we >>> don't? Detecting overlapping for the sake of qualifying it as such? >>> >>> >>> >> >> If you have duplicate addresses, this breaks routing, for starters. > > It may or it may not. My first temptation is to say yes, duplicate > addresses is not good. People have seen storms of packets filling > screens when two hosts configure same address on the same subnet - this > led to DAD mechanism. That's a problem seen by many people and very > impressing such as to motivate a new and reliable mechanism. > > But two duplicate addresses may not break routing, it's possible to > design translating schemes that work. So you agree it is a problem that needs attention. Good ;) > >> And if some routers manage independently overlapping prefixes it may >> lead to duplicate address assignment. Do you agree? > > Certainly I don't agree. > > Every two prefixes in this Internet _are_ overlapping (the only > exceptions are the pairs of prefixes whose first bit is different). Yet > Internet works by using these overlapping prefixes. > I see what you mean. But the routers in the Internet do not manage these prefixes independently, right? There is a hierarchy. In MANETs, there is no "natural" or "long lasting" hierarchy, or dependence... This is an issue. Do you agree? Emmanuel > Alex > >>> Emmanuel Baccelli wrote: >>>> >>>> >>>> Alexandru Petrescu a écrit : >>>>> Emmanuel Baccelli wrote: >>>>>> >>>>>> 3. detect and resolve cases of duplicated addresses and/or >>>>>> prefixes assigned to MANET routers (e.g. as a result of a network >>>>>> merger, or of a manual misconfiguration). >>>>> >>>>> But we said we _can't_ detect cases of duplicated prefixes. >>>>> >>>>> Given two prefixes of different lengths sometimes I think they're >>>>> duplicates sometimes I think they're unique. >>>>> >>>>> What do you think? >>>>> >>>>> Alex >>>>> >>>>> >>>> >>>> >>>> OK. So if we say instead "detect and resolve cases of duplicated >>>> addresses and overlapping prefixes", does this answer your question? >>> >>> Detecting duplicate address use sounds ok. But prefixes? >>> >>> Why should one detect when two prefixes overlap, is this an error >>> condition? Two networks may merge, their prefixes overlap, and >>> everything is fine - there's nothing to solve. >>> >>> What do I miss? >>> >>> I mean if we define a more precise scope/subnet/multicast structure >>> of MANET then we can talk about prefixes of fixed lengths eventually >>> overlapping or duplicating (compare same-prefix lengths). Until then >>> we (or just I) just turn round and round around issues we'd suppose >>> are problems. >>> >>> (as it was presented at a certain MANEMO activity meeting: two NEMO >>> MRs connecting egress-egress do have a certain defined >>> subnet/multicast/scope structure, and there may be a need to detect >>> when two /64 MNPs are different. But I can't say that in the MANET >>> context because there's no structure in MANET by its own definition. >>> If there's no scope/multicast/subnet structure then we can't say that >>> we work towards the goal of detecting duplicate/overlapping prefixes. >>> That is turning round and round for >>> me - I can say: yes, you're right, that's it; as well as I can say >>> I completely disagree.) >>> >>> 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 >> > > > ______________________________________________________________________ > 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 Nov 29 12:36: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 1IxnJS-00050H-RQ; Thu, 29 Nov 2007 12:36:34 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IxnJR-000509-MV for autoconf-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 12:36:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxnJR-0004zy-Bf for autoconf@ietf.org; Thu, 29 Nov 2007 12:36:33 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IxnJQ-0004kG-No for autoconf@ietf.org; Thu, 29 Nov 2007 12:36:33 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-153.messagelabs.com!1196357791!11671465!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 29159 invoked from network); 29 Nov 2007 17:36:31 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-153.messagelabs.com with SMTP; 29 Nov 2007 17:36:31 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lATHaVSR029416; Thu, 29 Nov 2007 10:36:31 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id lATHaUe5025995; Thu, 29 Nov 2007 11:36:30 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id lATHaTo0025990; Thu, 29 Nov 2007 11:36:29 -0600 (CST) Message-ID: <474EF89C.3080703@gmail.com> Date: Thu, 29 Nov 2007 18:36:28 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Emmanuel Baccelli Subject: Re: [Autoconf] Goals of MANET autoconf References: <474BEF32.6000808@inria.fr> <200711271655.27469.fjrm@dif.um.es> <006401c8310f$05a614e0$10f23ea0$@nl> <200711271829.53779.fjrm@dif.um.es> <008401c83120$2bf04420$83d0cc60$@nl> <474C9837.5050904@inria.fr> <474D44EA.7040302@gmail.com> <474EC126.3030909@inria.fr> <474ECD5C.7060709@gmail.com> <474ED440.1030806@inria.fr> <474EDBFB.8060105@gmail.com> <474EDF02.30206@inria.fr> In-Reply-To: <474EDF02.30206@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071128-0, 28/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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: >>> If you have duplicate addresses, this breaks routing, for >>> starters. >> >> It may or it may not. My first temptation is to say yes, duplicate >> addresses is not good. People have seen storms of packets filling >> screens when two hosts configure same address on the same subnet - >> this led to DAD mechanism. That's a problem seen by many people >> and very impressing such as to motivate a new and reliable >> mechanism. >> >> But two duplicate addresses may not break routing, it's possible to >> design translating schemes that work. > > So you agree it is a problem that needs attention. Good ;) It's a pencil and paper problem. We need problems that make a receiver break in pieces when an emitter sends something really bad. >>> And if some routers manage independently overlapping prefixes it >>> may lead to duplicate address assignment. Do you agree? >> >> Certainly I don't agree. >> >> Every two prefixes in this Internet _are_ overlapping (the only >> exceptions are the pairs of prefixes whose first bit is different). >> Yet Internet works by using these overlapping prefixes. >> > > I see what you mean. But the routers in the Internet do not manage > these prefixes independently, right? There is a hierarchy. There is neither topological hierarchy nor prefix hierarchy in the Internet. Not even DNS. Neither for IPv4 nor for IPv6. One buys a router: its routing table is really empty, not even a default route. Then some humans add some routes that make loopless sense, that's all. Computers help computing the loopless paths but there's no hardcoded universally agreed method for that, lots of heuristics involved. There's no hierarchy or hardcoded automatic delegation of responsibility for prefixes. There are humans behind all that doing stuff that makes sense. > In MANETs, there is no "natural" or "long lasting" hierarchy, or > dependence... This is an issue. Do you agree? When you say there's no long lasting hierarchy - what do you mean? Is it that the prefixes are completely unaggregated? Is it that topology is a mesh? Is it that the rate of change of attachment of a node from one link to another is very high? What do you mean more precisely? I really can't agree with you when you try to imply that because MANETs are unknown we have a big problem. All that said... If we could just describe the subnet/multicast/scope models for MANET networks... then we could picture the addressing architecture on it... and then we could talk about prefixes, addresses and the problems we think they have. That's just one oppinion... 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 Nov 29 13:33:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxoCr-0007PV-2f; Thu, 29 Nov 2007 13:33:49 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IxoCq-0007PH-Hc for autoconf-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 13:33:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxoCq-0007P8-7Y for autoconf@ietf.org; Thu, 29 Nov 2007 13:33:48 -0500 Received: from wr-out-0506.google.com ([64.233.184.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxoCp-00080M-Fj for autoconf@ietf.org; Thu, 29 Nov 2007 13:33:48 -0500 Received: by wr-out-0506.google.com with SMTP id 68so1550022wra for ; Thu, 29 Nov 2007 10:33:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:content-type:content-transfer-encoding:subject:mime-version:date:x-mailer; bh=Ohvj6bt8POprf2tBnYYU/SYnQZBEkEgUyFrQLuOUBCQ=; b=v60Nk8xNMhs8Wj9yVsCdlTlxz4S3xxCC5svLg5WeSo0r2JFPzZtJkgPYGr2Syv3xN+ABuxcbTdGxBXEktKr3i7bItdDOxvXcPvfuWK132Y84IQtA8mMMPJlfh4dMG/ONZVA5mKAHONR7J0qquQgc9/l5LCMaxomUJX/2XH3SxiM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:from:to:content-type:content-transfer-encoding:subject:mime-version:date:x-mailer; b=XhYYQtJQB/pscafNR9pfafIvs3TSVnT6IGAn4mcsoCfbH2IJg04pzE7yxZkzq8sIVWc175xaFqbB/V+CeGzeRe94LwCLycntHXCjI+DLRA1lj12m1zdS/5n7JF2ksZWPZ2J8EVwFZ1W7acr6bjY5VM3N0RoNO3O7TjRGQmkyzW4= Received: by 10.100.106.1 with SMTP id e1mr12206041anc.1196361226788; Thu, 29 Nov 2007 10:33:46 -0800 (PST) Received: from ?203.178.143.240? ( [203.178.143.240]) by mx.google.com with ESMTPS id 38sm11852064aga.2007.11.29.10.33.41 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Nov 2007 10:33:44 -0800 (PST) Message-Id: From: RYUJI WAKIKAWA To: autoconf@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Fri, 30 Nov 2007 03:33:35 +0900 X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Subject: [Autoconf] comments to autoconf PS 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 and all, First of all, i am sorry for my long silence, I needed some time to recover from MANEMO wars in previous IETFs:-p I finally reviewed this document and have a lot of comments, though some of my comments may be overlapped with others or already be discussed in ML. To be honest, I am not such comfortable with this document (except for the description of uniqueness issue which is well explained!). There are so many unclear explanation. Let me explain the general comments first and then detail my comments later. - Do you assume DHCP and RA(NDP) as solutions of AUTOCONF? NDP does not deal with prefix assignment. If you want to assign prefix, stateless approach defined in RFC4862 is impossible, IMO. A "stateful" mechanism using NDP might be possible if we can design so. - Scope Issue There is nowhere to discuss which scope of address/prefix should be assigned to which interface. It is very important to consider the address scope in IPv6. For example, there is no discussion whether manet nodes in a same manet uses the same scope for MLP/MLA. Can MANET-A having link-local sends packets to MANET-B having only global ? This goes against IPv6 spec. According to manet-arch, each manet node needs to obtain "unique prefix" instead of address for its local network and also must obtain "unique prefix or address" for manet interface, too. Am I right? For the first prefix, there are two possibility: global prefix or uniquelocal prefix. For the second, five possibility: global prefix, global address, uniquelocal prefix, uniquelocal address, link local address. How can AUTOCONF deal with these scope and differences? I think it's very important to use the same scope specially for MANET interface. You can not send packets from link-local scope to global scope over link. Other direction is OK. Do we agree on relaxing this scope limitation in manet? Is there any definition that the same scope MUST be used for MLP/MLA? Does the word "valid" below indicate this? It should explicitly write so. " MANET Local Prefix (MLP) - An IP prefix delegated to a MANET router, consisting in chunks of IP addresses valid for communications inside the MANET. MANET Local Address (MLA) - An IP address configured on a MANET interface, and valid for communications inside the MANET." Actually, I am not clear what is MLA/MLP... The document said in section 4.1 "a MANET router needs to configure at least one IP address on its MANET interface, this being a link local address, an MLA or a global address." Does it mean MLA is unique local address?? - How can each manet node decide whether it can obtain prefix or address on a manet interface? In IPv6, it is simpler that every node generates a link-local address on its interface, while manet node may not assign a link-local address on manet interface. How can this node decide whether it should wait for prefix or simply generate a link-local address? There is related question. How can a manet node detects whether it attaches to manet or not? In IPv6, as soon as an interface becomes active, it will start assigning a link-local address. However, a manet node may wait this operation until it detects characteristics of attached network (regular IPv6 or manet)... This is also one of issue how a node can deploy both in manet and regular IPv6. In addition to this, a manet node may need to detect connected or standalone manet when it attaches to a network in order to discover ICP?!. - Last general question: for the prefix assignment to manet (not manet interface), There are two possibility depending on ICP availability: topologically correct prefix or non correct prefix. I think this is two different things though the goal is same assigning prefix to manet. Shall a solution support both scenarios? -------------------------------------------------------------------------------- Detailed comments - In section 4.1.1, it only said " IPv6 Stateless Address Autoconfiguration [5] and Neighbor Discovery for IPv6 [3] do not account for potential address duplication beyond a single multicast-capable link." NDP actually does not consider "multi-hop" support at all. I think this address duplication is side-effect of no multi-hop consideration. - Why do you say "p2p link" between border router and ISP edge router in figure 1??? - In section 4.1.2, it said Fig. 1, even if MR1 would be able to provision MR3 with prefixes, using DHCP [4], it cannot be assumed that MR1 or MR3 will not move and become unable to communicate directly. On the other hand, frequent reconfiguration may cause IPv6 Stateless Address Autoconfiguration [5] to be much less efficient than expected, due to large amounts of control signalling. This paragraph assume running DHCP and AUTOCONF over multihop. Do you assume that MR1 is DHCP relay ?? There is no way to forward DHCP messages by MR1. The document repeated to say that "as-is" existing solution does not fit to manet environment. I don't think these texts are useful explanation in this document. If you want to explain the constraints of existing solutions, you should have independent section how DHCP/NDP cannot fit to manet more in detail, please. Problem statement document should not suggest or assume any solutions. - I'm not sure but "broadcast" may be IPv4 term!? - Section 4.2.3 When a router changes its ICP affiliation, some routes may be broken, affecting MANET packet forwarding performance and applications. In a multiple border router / multiple-prefixes MANET, frequent reconfiguration could cause a large amount of control signalling (for instance if [5] is used). Isn't this problem of DHCP? Do you assume that a manet node can unicast renew message over connected ICP to the previous ICP and continue using the same address?!:-p Or you just mention NDP? It is no clear to me what is the intention you refer only NDP here. - Section 5, It contains only general considerations. Not specific to AUTOCONF solutions. - Section 6, if you mention the security issue specific to AUTOCONF (Not NDP), you should write in the section 4. You can refer the section in the security consideration section. It will be nice if you can list up all possible security threats regarding AUTOCONF solutions (rather than referring security considerations of existing solutions). _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 30 05:59: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 1Iy3b8-00032z-Pm; Fri, 30 Nov 2007 05:59:54 -0500 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Iy3b7-0002zN-OS for autoconf-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 05:59:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy3b7-0002xh-DB for autoconf@ietf.org; Fri, 30 Nov 2007 05:59:53 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iy3b6-0006Cc-QQ for autoconf@ietf.org; Fri, 30 Nov 2007 05:59:53 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-128.messagelabs.com!1196420390!10091640!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 28522 invoked from network); 30 Nov 2007 10:59:50 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-10.tower-128.messagelabs.com with SMTP; 30 Nov 2007 10:59:50 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id lAUAxojk015098; Fri, 30 Nov 2007 03:59:50 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id lAUAxn9J012602; Fri, 30 Nov 2007 04:59:49 -0600 (CST) 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 lAUAxlch012527; Fri, 30 Nov 2007 04:59:48 -0600 (CST) Message-ID: <474FED1B.4060107@gmail.com> Date: Fri, 30 Nov 2007 11:59:39 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: RYUJI WAKIKAWA Subject: Re: [Autoconf] comments to autoconf PS References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071128-0, 28/11/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 RYUJI WAKIKAWA wrote: [...] Snipping much of the text you wrote to which I already agree. > - In section 4.1.2, it said Fig. 1, even if MR1 would be able to > provision MR3 with prefixes, using DHCP [4], it cannot be assumed > that MR1 or MR3 will not move and become unable to communicate > directly. On the other hand, frequent reconfiguration may cause IPv6 > Stateless Address Autoconfiguration [5] to be much less efficient > than expected, due to large amounts of control signalling. > > This paragraph assume running DHCP and AUTOCONF over multihop. > > Do you assume that MR1 is DHCP relay ?? There is no way to forward > DHCP messages by MR1. If MR1 is right next to MR3 (no dots) then MR1 can be a DHCP Relay and the ISP Edge Router can be a DHCP Server, and MR3 the DHCP Client. This DHCPv6-PD is specified to work ok. In implementation there are however some issues with some DHCPv6-PD implementations. For example, this works ok with addresses (DHCPv6 for addresses not prefixes), but for delegating a prefix: one implementation crashes the Relay and another implementation does not add a route on the Server, IIRC. For reference the figure is: > > ----- MR1...MR3 > / . > +-------------+ +------------+ / . > | | p2p | |/ . (MANET) > | ISP Edge | Link | Border | . > | Router +---------+ Router |\ . > | | | | \ . > +-------------+ +------------+ \----- MR2 > > Fig. 1. Connected MANET router topology. > The document repeated to say that "as-is" existing solution does not > fit to manet environment. I don't think these texts are useful > explanation in this document. If you want to explain the constraints > of existing solutions, you should have independent section how > DHCP/NDP cannot fit to manet more in detail, please. Problem > statement document should not suggest or assume any solutions. I kind of agree. > - I'm not sure but "broadcast" may be IPv4 term!? I saw very little 'broadcast' in IPv6 contexts. I mainly see 'multicast' when discussing IPv6. 'Multicast' is also largely used when talking link-layer MAC scope multicast. [...] > - Section 6, if you mention the security issue specific to AUTOCONF > (Not NDP), you should write in the section 4. You can refer the > section in the security consideration section. It will be nice if you > can list up all possible security threats regarding AUTOCONF > solutions (rather than referring security considerations of existing > solutions). I agree. 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