From charles.perkins@earthlink.net Tue Jul 14 00:02:30 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 590403A69E3 for ; Tue, 14 Jul 2009 00:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEQKf+SqHQfS for ; Tue, 14 Jul 2009 00:02:29 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 64E593A68AF for ; Tue, 14 Jul 2009 00:02:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=uCvQ82OPl20Z0daxG7l/1VMPGjiOgsvDjnZ2zP/mSksmKbhgkW828v76uNEcBgqp; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.74.16] (helo=[192.168.1.105]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MQc2T-0005Af-RX for autoconf@ietf.org; Tue, 14 Jul 2009 03:02:58 -0400 Message-ID: <4A5C2D9F.70806@earthlink.net> Date: Tue, 14 Jul 2009 00:02:55 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "autoconf@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52cd47618b602b6d55117a53e9cdaf5bac350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Subject: [Autoconf] New I-D submitted X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 07:02:30 -0000 Hello folks, The autoconf design team has arrived at a documentation milestone, with the publication of the following Internet Draft: http://www.ietf.org/internet-drafts/draft-baccelli-autoconf-adhoc-addr-model-01.txt From the Abstract: This document describes a model for configuration of IP addresses and subnet prefixes on the interfaces of routers which connect to links with undetermined connectivity properties. Indeed, the document is quite narrowly focussed, limited to discussing only the issues minimally required for the working group to move forward. Comments are encouraged! Regards, Charlie P. From sratliff@cisco.com Tue Jul 14 07:46:36 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F75B28C0DF for ; Tue, 14 Jul 2009 07:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XGB3nFdUYxJ for ; Tue, 14 Jul 2009 07:46:35 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 13E4028C0CE for ; Tue, 14 Jul 2009 07:46:35 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAI82XEpAZnme/2dsb2JhbAC3fogjkC4FhAiCHw X-IronPort-AV: E=Sophos;i="4.42,397,1243814400"; d="scan'208";a="50327018" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 14 Jul 2009 14:46:27 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6EEkQrr023738; Tue, 14 Jul 2009 10:46:26 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6EEkQ6Q010265; Tue, 14 Jul 2009 14:46:26 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 10:46:26 -0400 Received: from [64.102.54.37] ([64.102.54.37]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 10:46:26 -0400 Message-ID: <4A5C9A42.4050803@cisco.com> Date: Tue, 14 Jul 2009 10:46:26 -0400 From: Stan Ratliff User-Agent: Thunderbird 1.5.0.12 (X11/20080131) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4A5C2D9F.70806@earthlink.net> In-Reply-To: <4A5C2D9F.70806@earthlink.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jul 2009 14:46:26.0555 (UTC) FILETIME=[DD72FCB0:01CA0491] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1645; t=1247582787; x=1248446787; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20Stan=20Ratliff=20 |Subject:=20Re=3A=20[Autoconf]=20New=20I-D=20submitted |Sender:=20 |To:=20=22Charles=20E.=20Perkins=22=20; bh=eIxeKK3CWMPqma0PMyu6+f/+wXaPtk0IbFFXWc4ueDQ=; b=c4LIYORKTF/oV17Zy82qhQmvjznSdYqxHNJPBhuiPTB4Y30B56c91uTKhL jIeSjqB7gn7fsZGBsox5UhmMVS+Kx6PrXqctAQiuPteOS4XTToS8aaUCEghd ZmCXRM/hxu; Authentication-Results: rtp-dkim-1; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] New I-D submitted X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 14:46:36 -0000 In section4, the authors state : "Subnet prefix configuration on such interfaces must thus not make any promises in terms of direct (one hop) IP connectivity to IP addresses other than that of the interface itself. This translates in the following policy: no two such interfaces in the network should be configured with the same subnet prefix." Later, in section 6.1 and 6.2, the authors get around to stating that prefix length should be 32 bits for V4, 128 bits for V6. My question is this -- Since prefix length really defines what is or isn't a "subnet", why monkey around with all of the text up front? This looks like you took 6 pages to say "For V4, use prefix length 32. For V6, use 128. Use of V6 Link-locals? Beats us!" Or, am I missing something? Regards, Stan Charles E. Perkins wrote: > > Hello folks, > > The autoconf design team has arrived at a documentation milestone, > with the publication of the following Internet Draft: > http://www.ietf.org/internet-drafts/draft-baccelli-autoconf-adhoc-addr-model-01.txt > > > From the Abstract: > > This document describes a model for configuration of IP addresses and > subnet prefixes on the interfaces of routers which connect to links > with undetermined connectivity properties. > > Indeed, the document is quite narrowly focussed, limited to discussing > only the issues minimally required for the working group to move forward. > > Comments are encouraged! > > Regards, > Charlie P. > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From ryuji.wakikawa@gmail.com Tue Jul 14 11:05:02 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37BB83A6AAA for ; Tue, 14 Jul 2009 11:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lntXlGdgeKpL for ; Tue, 14 Jul 2009 11:05:01 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by core3.amsl.com (Postfix) with ESMTP id 7B17B3A6A79 for ; Tue, 14 Jul 2009 11:05:01 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id f9so786275rvb.49 for ; Tue, 14 Jul 2009 11:04:14 -0700 (PDT) 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:mime-version:subject:date :references:x-mailer; bh=Gw3UklnlYx/pytbMuOsXsbYhpf4C2PVWPTZJwGW46Ng=; b=RnM0J/1Ox77nwBwCYyoXed0aqh5s47QO1AHLHid6AS6V4VQoWgdSD++TnwHGEhvXWO Y5Di5DyhzApILASWIZzXFULHG7V/fR3NEU22l5rDtWZalyPbTFECmlh9gMPS0Yr1oYIe k0Z1koQ5ZndDIt2av62udYPvwIdyhS1YLoi8g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:references:x-mailer; b=BlleSc6XTdSa/BR4YkMH/CU8k8iU/7JogB7kXoa/el/VQrvZeMY5w1QWy5A8a56S8O wEkHPDKtxPKwKSa0Lw9yOhuh5bdKnDh/VrJQ3fY2GycoCaG9eJ/aG9D6Xx+qHMJv6x++ T0B7J7jVX/2WmWmGwJy20O8PatQ6ZzvxAgyyk= Received: by 10.140.187.10 with SMTP id k10mr3912819rvf.23.1247594277324; Tue, 14 Jul 2009 10:57:57 -0700 (PDT) Received: from macbookpro-ryuji.paloalto.toyota-itc.com ([206.132.173.18]) by mx.google.com with ESMTPS id g31sm3466198rvb.10.2009.07.14.10.57.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 14 Jul 2009 10:57:56 -0700 (PDT) Message-Id: <2BD98996-2E7C-46F8-A781-FB3DEDDABF1B@gmail.com> 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 v935.3) Date: Tue, 14 Jul 2009 10:57:53 -0700 References: <4A5C2D9F.70806@earthlink.net> X-Mailer: Apple Mail (2.935.3) Subject: [Autoconf] Fwd: New I-D submitted X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 18:05:02 -0000 Hi all, The agenda is available here. http://www.ietf.org/proceedings/09jul/agenda/autoconf.txt We have two hours slot for the AUTOCONF and will discuss the one charter item. The design team published the initial document as Charlie announced. In Appendix A, open issues are listed. Please review this document and provide your comments. Your proposal for the open issues are mostly welcome. thanks, Thomas&ryuji Begin forwarded message: > From: "Charles E. Perkins" > Date: 2009/07/14 0:02:55:PDT > To: "autoconf@ietf.org" > Subject: [Autoconf] New I-D submitted > > > Hello folks, > > The autoconf design team has arrived at a documentation milestone, > with the publication of the following Internet Draft: > http://www.ietf.org/internet-drafts/draft-baccelli-autoconf-adhoc-addr-model-01.txt > > From the Abstract: > > This document describes a model for configuration of IP addresses and > subnet prefixes on the interfaces of routers which connect to links > with undetermined connectivity properties. > > Indeed, the document is quite narrowly focussed, limited to discussing > only the issues minimally required for the working group to move > forward. > > Comments are encouraged! > > Regards, > Charlie P. > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From alexandru.petrescu@gmail.com Tue Jul 21 03:22:24 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AED3A3A6A1D for ; Tue, 21 Jul 2009 03:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvJBPRX8FsFx for ; Tue, 21 Jul 2009 03:22:24 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id BCA143A69FE for ; Tue, 21 Jul 2009 03:22:23 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6LAM65S015722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 21 Jul 2009 12:22:06 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6LAM5BK014283 for ; Tue, 21 Jul 2009 12:22:06 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6LAM5Bc014250 for ; Tue, 21 Jul 2009 12:22:05 +0200 Message-ID: <4A6596CD.9040404@gmail.com> Date: Tue, 21 Jul 2009 12:22:05 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: autoconf@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Autoconf] Link with undetermined connectivity properties X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 10:22:24 -0000 AUTOCONFers, The draft-baccelli-autoconf-adhoc-addr-model-01 mentions at several places Links with undetermined connectivity properties. And makes these Links the central point of the draft. This is a problem. We can't work with things we don't understand. As far as I know there is no link with undetermined connectivity properties. The links I am aware of do have determined connectivity properties or, at least, properties desired by their designers as set in specs. True, Links may diverge from specs: accidents, aging of components, buggy implementations, operator's errors. No surprise, these factors will affect any new method of AUTOCONF which we're about to write. In this sense, I don't understand why do we have to deal with Links with undetermined connectivity properties. What do you think? Alex From alexandru.petrescu@gmail.com Tue Jul 21 04:09:05 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C07828C217 for ; Tue, 21 Jul 2009 04:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.519 X-Spam-Level: X-Spam-Status: No, score=-0.519 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, J_CHICKENPOX_61=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfVQmL7Be61Y for ; Tue, 21 Jul 2009 04:09:04 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id DB79128C1DE for ; Tue, 21 Jul 2009 04:09:03 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6LA966M023485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Jul 2009 12:09:06 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6LA95EL012142; Tue, 21 Jul 2009 12:09:06 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6LA95sm010661; Tue, 21 Jul 2009 12:09:05 +0200 Message-ID: <4A6593C1.9050905@gmail.com> Date: Tue, 21 Jul 2009 12:09:05 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Ryuji Wakikawa References: <4A5C2D9F.70806@earthlink.net> <2BD98996-2E7C-46F8-A781-FB3DEDDABF1B@gmail.com> In-Reply-To: <2BD98996-2E7C-46F8-A781-FB3DEDDABF1B@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: [Autoconf] Comments on draft-baccelli-autoconf-adhoc-addr-model-01 (was: Re: Fwd: New I-D submitted) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 11:09:05 -0000 Dear AUTOCONFers, I have read the draft-baccelli-autoconf-adhoc-addr-model-01 "IP Addressing Model in Ad Hoc Networks" Authors of the draft-baccelli draft - thank you for putting up this draft. I followed the discussion on the DT list and realize there was struggle for consensus and much work was done to reach agreement. I have several remarks on it. There is a slight difference between what the Charter requires and what the draft offers. The Charter requires to describe how _nodes_ configure their addresses, whereas the draft sounds as describing how one (a human) should or should not configure addresses on these nodes. Charter: > [...] ad hoc nodes (refer to RFC 2501) need to configure their > network interface(s) with local addresses that are valid within an ad > hoc network. Ad hoc nodes may also need to configure globally > routable addresses [...] draft: > no two such interfaces in the network should be configured with the > same subnet prefix.[...] [in some cases] and the corresponding > interfaces MAY be configured with the same subnet prefix. This sounds as advice to some human risking making a mistake and wrongly configure prefixes on interfaces. If it were formulated like "the autoconf mechanism should[n't] configure same/different prefix on an interface" then the text would be more aligned with the Charter. > 4. IP Subnet Prefix Configuration > > If the link to which an interface connects enables no assumptions of > connectivity to other interfaces, the only addresses which can be > assumed "on link", are the address(es) of that interface itself. [...] > If on the contrary, assumptions can be made regarding connectivity to > other interfaces on the link, these SHOULD be considered when > configuring IP subnet prefixes, and the corresponding interfaces MAY > be configured with the same subnet prefix. To my reading, the order of these two paragraphs is wrong. The second paragraph should be mentioned first. The first paragraph should be mentioned second, and _that_ should start with "If on the contrary". I suggest that because I have a hard time imagining an interface which enables no assumptions of the connectivity to other interfaces. This is a very special case, and as such I think it should be mentioned second. > Configuring an IP address that is unique within the routing domain > satisfies the less stringent uniqueness requirements of local > uniqueness, while also enabling protocols which have the most > stringent requirements of uniqueness within the routing domain. This > translates in the following policy: an IP address assigned to an > interface that connects to a link with undetermined connectivity > properties should be unique at least within the routing domain. By extension, I can not understand how a link with undetermined connectivity properties can be part of an apparently coherent routing domain. If the parts of the domain are undetermined then by logical extension the routing domain is undetermined too. > when that interface connects to a link with undetermined connectivity > properties. Again, I do _not_ understand what is a link with undetermined connectivity properties. I think you make abstraction of the existence of link layers. > o A subnet prefix configured on this interface should be of length > /32. I could agree with this recommendation for links with undetermined connectivity properties. But since I don't understand the latter I can't accept the recommendation either. I suggest to make first recommendation for links which have determined connectivity properties, and then in later sections make recommendations for links with undetermined connectivity properties. The same for IPv6 section 6.2. > MANET Link Model - no satisfying MANET link model was formulated to > date. Lacking a better definition so far, a MANET link is: a link > with undetermined connectivity properties. I don't understand link with undetermined connectivity properties. Are you sure they're undetermined or are they simply unkown to this draft? > Use of Link Local Addresses - while the use of link local addresses > on interfaces connecting to a MANET link is not prohibited, the > semantics of "link local" in this context is yet to be defined, > taking into account the unusual requirements that follow, concerning > such addresses. These requirements include for example uniqueness > within a scope spanning beyond a single IP hop. I suggest reformulation and re-positioning of this paragraph. IPv6 link-local addresses are mandatory, and are the first thing self-configured by all implementations, before anything else. Please mention that. Even on non-standardized IPv6-over-foo links, the implementations do self-configure link-local addresses (like USB, and more). "link local" is already defined. It spans a link. Links are already defined. I would suggest to remove this paragraph and re-write a new paragraph about link-local addresses and position it near the beginning of the draft, which says the first addresses configured by the nodes are the IPv6 link-local addresses, before any other types of addresses. Alex Ryuji Wakikawa a écrit : > Hi all, > > The agenda is available here. > http://www.ietf.org/proceedings/09jul/agenda/autoconf.txt > > We have two hours slot for the AUTOCONF and will discuss the one > charter item. The design team published the initial document as > Charlie announced. > > In Appendix A, open issues are listed. Please review this document > and provide your comments. Your proposal for the open issues are > mostly welcome. > > thanks, Thomas&ryuji > > > Begin forwarded message: > >> From: "Charles E. Perkins" Date: >> 2009/07/14 0:02:55:PDT To: "autoconf@ietf.org" >> Subject: [Autoconf] New I-D submitted >> >> >> Hello folks, >> >> The autoconf design team has arrived at a documentation milestone, >> with the publication of the following Internet Draft: >> >> http://www.ietf.org/internet-drafts/draft-baccelli-autoconf-adhoc-addr-model-01.txt >> >> >> >> >> >> >> >> >> >> From the Abstract: >> >> This document describes a model for configuration of IP addresses >> and subnet prefixes on the interfaces of routers which connect to >> links with undetermined connectivity properties. >> >> Indeed, the document is quite narrowly focussed, limited to >> discussing only the issues minimally required for the working group >> to move forward. >> >> Comments are encouraged! >> >> Regards, Charlie P. >> >> >> _______________________________________________ Autoconf mailing >> list Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > _______________________________________________ Autoconf mailing list > Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf > From emmanuel.baccelli@gmail.com Tue Jul 21 04:59:38 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 607A33A6AF9 for ; Tue, 21 Jul 2009 04:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fr9DwZ9DbxSb for ; Tue, 21 Jul 2009 04:59:37 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id A9F9D3A69FE for ; Tue, 21 Jul 2009 04:59:36 -0700 (PDT) Received: by fxm18 with SMTP id 18so2545765fxm.37 for ; Tue, 21 Jul 2009 04:57:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to :content-type; bh=M/xYQCbqI9oxGOqsZAtuqZ9KJuGU6WYtfxEiFKgp+o8=; b=PPwMk7TynbvA3Wg5M4zyhdbaZXTBAgWP9VItFzNZ3ZbBl8GuDcSJhbMkYguPp002Da e+4oQ4YHptDPYU0NR9BNUX3RZP4E4IFLthNi+r6TBfxonSSI+78oqwZL8rc5StnHDsTG 7qMl3QjQ1fry6a0Egyharr6fANlfwFKLCa4xs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=YJ/nYPbeWI1ydMaLcFc/d5/3wqYwR7xLyw4UASjLH0oBY8Z2ZmygfQzCCCwcXUligX jmR0Fgxh90JrY9+ECARF7otOa3oJAcj/8AxZXK9rEz5XT7w51jZxbb8PRbieNVck+k3T hAiTj80BBw0/Jj/uCYwmPo3JX7lWQ4BuzGUE8= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.103.224.2 with SMTP id b2mr2843915mur.30.1248177438276; Tue, 21 Jul 2009 04:57:18 -0700 (PDT) In-Reply-To: <4A6596CD.9040404@gmail.com> References: <4A6596CD.9040404@gmail.com> From: Emmanuel Baccelli Date: Tue, 21 Jul 2009 13:56:58 +0200 X-Google-Sender-Auth: 5f5aaa8429969562 Message-ID: To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=001636a7d825d33e3b046f35f411 Subject: Re: [Autoconf] Link with undetermined connectivity properties X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 11:59:38 -0000 --001636a7d825d33e3b046f35f411 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Alex, I understand your concern. However, I do not agree. Saying that a link has "undetermined connectivity properties" does not mean that we do not understand this link. It rather means that for this type of link, there is no connectivity property that is planned in advance -- quite a difference ;) Would it be clearer for you if instead of using the word "undetermined", there was "not pre-determined"? So we would talk about links with "no pre-determined connectivity properties"? Cheers Emmanuel On Tue, Jul 21, 2009 at 12:22 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > AUTOCONFers, > > The draft-baccelli-autoconf-adhoc-addr-model-01 mentions at > several places Links with undetermined connectivity properties. And > makes these Links the central point of the draft. > > This is a problem. > > We can't work with things we don't understand. > > As far as I know there is no link with undetermined connectivity > properties. The links I am aware of do have determined connectivity > properties or, at least, properties desired by their designers as set > in specs. > > True, Links may diverge from specs: accidents, aging of components, > buggy implementations, operator's errors. No surprise, these factors > will affect any new method of AUTOCONF which we're about to write. > > In this sense, I don't understand why do we have to deal with Links with > undetermined connectivity properties. > > What do you think? > > Alex > --001636a7d825d33e3b046f35f411 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alex,<= div>
I understand your concern. However, I do not agree.=A0

Saying that a link has=A0"undetermined connectivit= y properties" does not mean that we do not understand this link. It ra= ther means that for this type of link, there is no=A0connectivity=A0propert= y that is planned in advance -- quite a difference ;)=A0

Would it be clearer for you if instead of using the wor= d "undetermined", there was "not pre-determined"? So we= would talk about links with "no pre-determined connectivity propertie= s"?=A0

Cheers
Emmanuel



On Tue, Jul 21, 2009 at 12:22 PM, Alexandru Petrescu=A0<alexandru.petrescu@gmail.com&= gt;=A0wrote:
AUTOCONFers,

The draft-baccelli-autoconf-adhoc-addr-model-01 mention= s at
several places Links with undetermined connectivity properties. =A0= And
makes these Links the central point of the draft.

This is a p= roblem.

We can't work with things we don't understand.

As far as= I know there is no link with undetermined connectivity
properties. =A0T= he links I am aware of do have determined connectivity
properties or, at= least, properties desired by their designers as set
in specs.

True, Links may diverge from specs: accidents, aging of co= mponents,
buggy implementations, operator's errors. =A0No surprise, = these factors
will affect any new method of AUTOCONF which we're abo= ut to write.

In this sense, I don't understand why do we have to deal with Links= with
undetermined connectivity properties.

What do you think?
Alex
--001636a7d825d33e3b046f35f411-- From alexandru.petrescu@gmail.com Tue Jul 21 06:08:58 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D8ED3A67D3 for ; Tue, 21 Jul 2009 06:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.819 X-Spam-Level: X-Spam-Status: No, score=-0.819 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nmn6sj03meJu for ; Tue, 21 Jul 2009 06:08:57 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 4362B3A68E8 for ; Tue, 21 Jul 2009 06:08:49 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6LCHseu007549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Jul 2009 14:17:54 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6LCHrpc002313; Tue, 21 Jul 2009 14:17:53 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6LCHrjd002685; Tue, 21 Jul 2009 14:17:53 +0200 Message-ID: <4A65B1F1.4030009@gmail.com> Date: Tue, 21 Jul 2009 14:17:53 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Emmanuel Baccelli References: <4A6596CD.9040404@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Link with undetermined connectivity properties X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 13:08:58 -0000 Emmanuel Baccelli a écrit : > Alex, > > I understand your concern. However, I do not agree. > > Saying that a link has "undetermined connectivity properties" does not > mean that we do not understand this link. It rather means that for this > type of link, there is no connectivity property that is planned in > advance -- quite a difference ;) :-) Well yes, but there is at least one planned connectivity property for any link - the connectivity is established after link establishment. One can't say that this connectivity property is not planned in advance. > Would it be clearer for you if instead of using the word "undetermined", > there was "not pre-determined"? So we would talk about links with "no > pre-determined connectivity properties"? "undetermined" and "not pre-determined" are equivalent to my reading, (thus it isn't clearer); except if you meant "pre not-determined" - previously we may have thought it's not-determined and now we think it is determined. It's a stretch... I think I will be happily satisfied if the first paragraphs and cases of each section were for describing the determined cases and exceptions (unplanned and not pre-determined) came explained in second paragraphs, or appendices. For example the IPv6 link-layer addresses should come first. Alex From Chris.Dearlove@baesystems.com Tue Jul 21 07:02:46 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A46283A6D07 for ; Tue, 21 Jul 2009 07:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iz0RIucv+PTP for ; Tue, 21 Jul 2009 07:02:46 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id B96DD3A6B95 for ; Tue, 21 Jul 2009 07:02:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,240,1246834800"; d="scan'208";a="13340569" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 21 Jul 2009 15:02:30 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.0/Switch-3.4.0) with ESMTP id n6LE2YqP015203; Tue, 21 Jul 2009 15:02:34 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Jul 2009 15:02:29 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 21 Jul 2009 15:02:28 +0100 Message-ID: In-Reply-To: <4A65B1F1.4030009@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Link with undetermined connectivity properties Thread-Index: AcoKBHFOjXZX7akkTMePXVLA+v+uWgABuZAA References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" , "Emmanuel Baccelli" X-OriginalArrivalTime: 21 Jul 2009 14:02:29.0315 (UTC) FILETIME=[E26C5930:01CA0A0B] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Link with undetermined connectivity properties X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 14:02:46 -0000 > Well yes, but there is at least one planned connectivity property for > any link - the connectivity is established after link establishment. > > One can't say that this connectivity property is not planned in advance. I can certainly say that I didn't plan whether A and B would be directly connected, i.e. have a link between them, in advance. I can only plan that if the physics etc. permit it then I will (probably) establish it and use it. > For example the IPv6 link-layer addresses should come first. The document clearly says this is not agreed. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From alexandru.petrescu@gmail.com Tue Jul 21 07:10:32 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E6753A6B54 for ; Tue, 21 Jul 2009 07:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.919 X-Spam-Level: X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwCa1g1qL79s for ; Tue, 21 Jul 2009 07:10:30 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 693743A68DD for ; Tue, 21 Jul 2009 07:10:30 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6LEA2ZA025007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Jul 2009 16:10:02 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6LEA2xZ000433; Tue, 21 Jul 2009 16:10:02 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6LE9x2i017781; Tue, 21 Jul 2009 16:10:01 +0200 Message-ID: <4A65CC37.2080703@gmail.com> Date: Tue, 21 Jul 2009 16:09:59 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] Link with undetermined connectivity properties X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 14:10:32 -0000 Dearlove, Christopher (UK) a écrit : >> Well yes, but there is at least one planned connectivity property >> for any link - the connectivity is established after link >> establishment. >> >> One can't say that this connectivity property is not planned in > advance. > > I can certainly say that I didn't plan whether A and B would be > directly connected, i.e. have a link between them, in advance. I can > only plan that if the physics etc. permit it then I will (probably) > establish it and use it. I agree, sometimes connections are possible, and the first obvious thing to do when a connection is possible is to use an IPv6 link-local address. >> For example the IPv6 link-layer addresses should come first. > > The document clearly says this is not agreed. I personally do not agree with the document as it stands with respect to link-local addresses. Why do you oppose the use of IPv6 link-local addresses? And what do others think please? Alex From Chris.Dearlove@baesystems.com Tue Jul 21 07:22:34 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3B403A6D07 for ; Tue, 21 Jul 2009 07:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AtYDWtAE31X for ; Tue, 21 Jul 2009 07:22:34 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id CBC773A6B95 for ; Tue, 21 Jul 2009 07:22:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,240,1246834800"; d="scan'208";a="13347571" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 21 Jul 2009 15:21:13 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.0/Switch-3.4.0) with ESMTP id n6LELHW1027816; Tue, 21 Jul 2009 15:21:17 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Jul 2009 15:21:12 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 21 Jul 2009 15:21:11 +0100 Message-ID: In-Reply-To: <4A65CC37.2080703@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Link with undetermined connectivity properties Thread-Index: AcoKDQXvtck5sEFCQ0GNNSvtInGEJQAABnRQ References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 21 Jul 2009 14:21:12.0370 (UTC) FILETIME=[7FD0F120:01CA0A0E] Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] Link with undetermined connectivity properties X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 14:22:34 -0000 >> The document clearly says this is not agreed. > > I personally do not agree with the document as it stands with respect to > link-local addresses. You can't diagree with the document in that it says "The following issues were extensively discussed among the design team, without reaching a conclusion." You may think there should be a conclusion, you may think you know what it should be. But you can't disagree with that the Design Team has (currently at least) failed to reach an agreement. (Yes, there's some discussion, but it only points out issues, it doesn't form a conclusion.) > Why do you oppose the use of IPv6 link-local addresses? I didn't say I did, you are misreading what I said. I said "The document clearly says this is not agreed." And that's a fact. I made no personal comment on the matter in any way. The disagreement I referred to is among the document contributors, of which I am not one. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From teco@inf-net.nl Tue Jul 21 07:30:54 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A5CD3A6DCE for ; Tue, 21 Jul 2009 07:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwAL4qyvJrzd for ; Tue, 21 Jul 2009 07:30:48 -0700 (PDT) Received: from CPSMTPM-EML101.kpnxchange.com (cpsmtpm-eml101.kpnxchange.com [195.121.3.5]) by core3.amsl.com (Postfix) with ESMTP id 803823A6B98 for ; Tue, 21 Jul 2009 07:30:48 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML101.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Tue, 21 Jul 2009 16:28:18 +0200 From: "Teco Boot" To: "'Alexandru Petrescu'" , "'Dearlove, Christopher \(UK\)'" References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> In-Reply-To: <4A65CC37.2080703@gmail.com> Date: Tue, 21 Jul 2009 16:28:08 +0200 Message-ID: <010c01ca0a0f$781dda50$68598ef0$@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: AcoKDQUbnzKQRG5eQB69En0k+XM/LAAAajIA Content-Language: nl X-OriginalArrivalTime: 21 Jul 2009 14:28:18.0610 (UTC) FILETIME=[7DE00120:01CA0A0F] Cc: autoconf@ietf.org, 'Emmanuel Baccelli' Subject: Re: [Autoconf] Link with undetermined connectivity properties X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 14:30:54 -0000 |Why do you oppose the use of IPv6 link-local addresses? And what do |others think please? For IPv6, routers have link-locals for running some protocols (e.g. sending ND RA or OSPFv3 packets). If one doesn't need those protocols (e.g. no IPv6), I say link-locals are not mandatory. I think it makes sense an Autoconf protocol that works for IPv6 and that is independent of a routing protocol makes use of IPv6 link-locals. I would run any IPv6 MANET protocol with link-locals. Repeating myself here. Teco. |Alex From teco@inf-net.nl Tue Jul 21 07:37:47 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB9553A6D1F for ; Tue, 21 Jul 2009 07:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZk3zQCGjC7d for ; Tue, 21 Jul 2009 07:37:47 -0700 (PDT) Received: from CPSMTPM-EML110.kpnxchange.com (cpsmtpm-eml110.kpnxchange.com [195.121.3.14]) by core3.amsl.com (Postfix) with ESMTP id E35413A6D07 for ; Tue, 21 Jul 2009 07:37:46 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML110.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Tue, 21 Jul 2009 16:33:58 +0200 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <4A5C2D9F.70806@earthlink.net> <2BD98996-2E7C-46F8-A781-FB3DEDDABF1B@gmail.com> <4A6593C1.9050905@gmail.com> In-Reply-To: <4A6593C1.9050905@gmail.com> Date: Tue, 21 Jul 2009 16:33:48 +0200 Message-ID: <010d01ca0a10$42b0fbd0$c812f370$@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: AcoJ865VssKjA1EJRbChwvgP6y5SbgAHBX1Q Content-Language: nl X-OriginalArrivalTime: 21 Jul 2009 14:33:58.0662 (UTC) FILETIME=[488FD260:01CA0A10] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Comments on draft-baccelli-autoconf-adhoc-addr-model-01 (was: Re: Fwd: New I-D submitted) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 14:37:47 -0000 |By extension, I can not understand how a link with undetermined |connectivity properties can be part of an apparently coherent routing |domain. If the parts of the domain are undetermined then by logical |extension the routing domain is undetermined too. Many MANET protocols are out there and being used today. This is the evidence you are missing something. I suggested in DT to refer to an updated draft-baccelli-multi-hop-wireless-communication. I think this document is helpful, especially for you :-) Teco. |Alex From teco@inf-net.nl Tue Jul 21 07:41:07 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE48628C2C8 for ; Tue, 21 Jul 2009 07:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.452 X-Spam-Level: X-Spam-Status: No, score=-1.452 tagged_above=-999 required=5 tests=[AWL=-0.582, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_61=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ufw-BkVritCm for ; Tue, 21 Jul 2009 07:41:07 -0700 (PDT) Received: from CPSMTPM-EML105.kpnxchange.com (cpsmtpm-eml105.kpnxchange.com [195.121.3.9]) by core3.amsl.com (Postfix) with ESMTP id C70493A68DD for ; Tue, 21 Jul 2009 07:41:06 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML105.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Tue, 21 Jul 2009 16:37:58 +0200 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <4A5C2D9F.70806@earthlink.net> <2BD98996-2E7C-46F8-A781-FB3DEDDABF1B@gmail.com> <4A6593C1.9050905@gmail.com> In-Reply-To: <4A6593C1.9050905@gmail.com> Date: Tue, 21 Jul 2009 16:37:48 +0200 Message-ID: <010e01ca0a10$d1d40cd0$757c2670$@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: AcoJ865VssKjA1EJRbChwvgP6y5SbgAHK+RA Content-Language: nl X-OriginalArrivalTime: 21 Jul 2009 14:37:58.0608 (UTC) FILETIME=[D794AD00:01CA0A10] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Comments on draft-baccelli-autoconf-adhoc-addr-model-01 (was: Re: Fwd: New I-D submitted) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 14:41:07 -0000 |draft: |> no two such interfaces in the network should be configured with the |> same subnet prefix.[...] [in some cases] and the corresponding |> interfaces MAY be configured with the same subnet prefix. | |This sounds as advice to some human risking making a mistake and wrongly |configure prefixes on interfaces. | |If it were formulated like "the autoconf mechanism should[n't] configure | same/different prefix on an interface" then the text would be more |aligned with the Charter. We are not describing an Autoconf mechanism. We tried to describe a practical addressing model for MANETs. Charter: > However, the first task of the working group is to describe > one practical addressing model for ad hoc networks. Teco. |Alex From alexandru.petrescu@gmail.com Tue Jul 21 08:17:27 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAC0328C2F9 for ; Tue, 21 Jul 2009 08:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.669 X-Spam-Level: X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, J_CHICKENPOX_61=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChxuVHKFfjMo for ; Tue, 21 Jul 2009 08:17:26 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 9264F28C2FE for ; Tue, 21 Jul 2009 08:17:26 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6LElMNx013631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Jul 2009 16:47:22 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6LElMxq009960; Tue, 21 Jul 2009 16:47:22 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6LElM73029180; Tue, 21 Jul 2009 16:47:22 +0200 Message-ID: <4A65D4F9.7000601@gmail.com> Date: Tue, 21 Jul 2009 16:47:21 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Teco Boot References: <4A5C2D9F.70806@earthlink.net> <2BD98996-2E7C-46F8-A781-FB3DEDDABF1B@gmail.com> <4A6593C1.9050905@gmail.com> <010e01ca0a10$d1d40cd0$757c2670$@nl> In-Reply-To: <010e01ca0a10$d1d40cd0$757c2670$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Comments on draft-baccelli-autoconf-adhoc-addr-model-01 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 15:17:27 -0000 Teco Boot a écrit : > |draft: > |> no two such interfaces in the network should be configured with the > |> same subnet prefix.[...] [in some cases] and the corresponding > |> interfaces MAY be configured with the same subnet prefix. > | > |This sounds as advice to some human risking making a mistake and wrongly > |configure prefixes on interfaces. > | > |If it were formulated like "the autoconf mechanism should[n't] configure > | same/different prefix on an interface" then the text would be more > |aligned with the Charter. > > We are not describing an Autoconf mechanism. Yes, right, no AUTOCONF mechanism described; I was trying to say that the Charter requires nodes to configure addresses whereas the draft reads as if humans configure those addresses on their interfaces. A slight change in the formulation could make it more aligned to the Charter. Instead of draft saying: "no two such interfaces in the network should be configured..." it could say: "no two such interfaces in the network should configure" because the Charter says: "ad hoc nodes [...] need to configure their network interface(s)" This is just a slight modification. Alex From alexandru.petrescu@gmail.com Tue Jul 21 08:17:29 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23C6928C2FD for ; Tue, 21 Jul 2009 08:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.939 X-Spam-Level: X-Spam-Status: No, score=-0.939 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6QIv7WvobuU for ; Tue, 21 Jul 2009 08:17:28 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 2AEEE28C2F9 for ; Tue, 21 Jul 2009 08:17:28 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6LESXa4008548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Jul 2009 16:28:34 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6LESXJP005193; Tue, 21 Jul 2009 16:28:33 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6LESXQx023607; Tue, 21 Jul 2009 16:28:33 +0200 Message-ID: <4A65D090.9060003@gmail.com> Date: Tue, 21 Jul 2009 16:28:32 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] Link with undetermined connectivity properties X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 15:17:29 -0000 Dearlove, Christopher (UK) a écrit : >>> The document clearly says this is not agreed. >> I personally do not agree with the document as it stands with respect > to >> link-local addresses. > > You can't diagree with the document in that it says > > "The following issues were extensively discussed among the design > team, without reaching a conclusion." > > You may think there should be a conclusion, you may think you know > what it should be. But you can't disagree with that the Design Team > has (currently at least) failed to reach an agreement. (Yes, there's > some discussion, but it only points out issues, it doesn't form a > conclusion.) I could however provide my comments on the list about the IPv6 link-local addresses. And I hope more people will comment on the use of IPv6 link-local addresses in ad-hoc networks, such that we could help the DT reach a conclusion. >> Why do you oppose the use of IPv6 link-local addresses? > > I didn't say I did, you are misreading what I said. I said > "The document clearly says this is not agreed." And that's > a fact. I made no personal comment on the matter in any way. Ah, I understand. But I would be very curious to know what you think about the use of IPv6 link-local addresses in the context of ad-hoc networks. Shouldn't they be used? Should one avoid them? Would implementations block them? Etc. Any other point? Alex From alexandru.petrescu@gmail.com Tue Jul 21 08:24:27 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B294C3A6A35 for ; Tue, 21 Jul 2009 08:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.969 X-Spam-Level: X-Spam-Status: No, score=-0.969 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UY9mhsslkPst for ; Tue, 21 Jul 2009 08:24:27 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 2C18E3A682F for ; Tue, 21 Jul 2009 08:23:37 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6LEWkpq009280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Jul 2009 16:32:46 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6LEWkhF006428; Tue, 21 Jul 2009 16:32:46 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6LEWjRm017895; Tue, 21 Jul 2009 16:32:46 +0200 Message-ID: <4A65D18D.9080301@gmail.com> Date: Tue, 21 Jul 2009 16:32:45 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Teco Boot References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <010c01ca0a0f$781dda50$68598ef0$@nl> In-Reply-To: <010c01ca0a0f$781dda50$68598ef0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, "'Dearlove, Christopher \(UK\)'" , 'Emmanuel Baccelli' Subject: Re: [Autoconf] Link with undetermined connectivity properties X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 15:24:27 -0000 Teco Boot a écrit : > |Why do you oppose the use of IPv6 link-local addresses? And what do > |others think please? > > For IPv6, routers have link-locals for running some protocols (e.g. > sending ND RA or OSPFv3 packets). If one doesn't need those protocols > (e.g. no IPv6), I say link-locals are not mandatory. Well, I think we need IPv6 in AUTOCONF, thus we need IPv6 link-local addresses mandatorily. > I think it makes sense an Autoconf protocol that works for IPv6 and > that is independent of a routing protocol makes use of IPv6 > link-locals. I agree, one can build an AUTOCONF protocol that works for IPv6, that is not OSPF, and that uses IPv6 link-local addresses. Alex > I would run any IPv6 MANET protocol with link-locals. Repeating > myself here. > > Teco. > > > |Alex > > > From Chris.Dearlove@baesystems.com Tue Jul 21 08:28:59 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5228E3A6989 for ; Tue, 21 Jul 2009 08:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSbgOa0oYS2R for ; Tue, 21 Jul 2009 08:28:58 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 01C6328C1DD for ; Tue, 21 Jul 2009 08:28:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,240,1246834800"; d="scan'208";a="13367850" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 21 Jul 2009 16:28:42 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.0/Switch-3.4.0) with ESMTP id n6LFSkkI006611; Tue, 21 Jul 2009 16:28:46 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Jul 2009 16:28:41 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 21 Jul 2009 16:28:39 +0100 Message-ID: In-Reply-To: <4A65D4F9.7000601@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Comments ondraft-baccelli-autoconf-adhoc-addr-model-01 Thread-Index: AcoKFmYJBzyn/4EkQGqLrWRLPfXI3gAAQNCQ References: <4A5C2D9F.70806@earthlink.net> <2BD98996-2E7C-46F8-A781-FB3DEDDABF1B@gmail.com><4A6593C1.9050905@gmail.com> <010e01ca0a10$d1d40cd0$757c2670$@nl> <4A65D4F9.7000601@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" , "Teco Boot" X-OriginalArrivalTime: 21 Jul 2009 15:28:41.0313 (UTC) FILETIME=[ED2C9D10:01CA0A17] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Comments ondraft-baccelli-autoconf-adhoc-addr-model-01 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 15:28:59 -0000 > the draft > reads as if humans configure those addresses on their interfaces. Not to me. > Instead of draft saying: > "no two such interfaces in the network should be configured..." Nowhere does that say what or who does the configuration. It thus applies whether configured by humans, software, Martians, or anything else. This form of wording is in many specifications. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From teco@inf-net.nl Tue Jul 21 08:38:22 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBEFF28C2EF for ; Tue, 21 Jul 2009 08:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCJ2IkZig6RN for ; Tue, 21 Jul 2009 08:38:22 -0700 (PDT) Received: from CPSMTPM-EML101.kpnxchange.com (cpsmtpm-eml101.kpnxchange.com [195.121.3.5]) by core3.amsl.com (Postfix) with ESMTP id D555328C2FF for ; Tue, 21 Jul 2009 08:38:21 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML101.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Tue, 21 Jul 2009 17:37:59 +0200 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <4A5C2D9F.70806@earthlink.net> <2BD98996-2E7C-46F8-A781-FB3DEDDABF1B@gmail.com> <4A6593C1.9050905@gmail.com> In-Reply-To: <4A6593C1.9050905@gmail.com> Date: Tue, 21 Jul 2009 17:37:49 +0200 Message-ID: <012601ca0a19$33f058d0$9bd10a70$@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: AcoJ865VssKjA1EJRbChwvgP6y5SbgAI8YYg Content-Language: nl X-OriginalArrivalTime: 21 Jul 2009 15:37:59.0057 (UTC) FILETIME=[399D9810:01CA0A19] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Comments on draft-baccelli-autoconf-adhoc-addr-model-01 (was: Re: Fwd: New I-D submitted) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 15:38:22 -0000 |"link local" is already defined. It spans a link. Links are already |defined. We had lots of discussions on "what is a link?". I defined some terms, but those were not included in the draft. Now we don't know if link-locals span the link. I do not agree on this. I say: packets with link-local source or destination are not forwarded. RFC4291: > Routers must not forward any packets with > Link-Local source or destination addresses > to other links. So if two interfaces on the same link do not have connectivity, your statement is false. There was consensus on "MANET link". That term was used for a _line_ on some diagram. The MANET _cloud_ was "the link", i.e. the communication facility. The line indicates a (symmetric / bi-directional) connection between two nodes. On this diagram, the MANET link was not fully connected, so link-local does not span the link. Teco. |Alex From alexandru.petrescu@gmail.com Tue Jul 21 08:45:19 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 884803A6AFA for ; Tue, 21 Jul 2009 08:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V80oXJIvjtrZ for ; Tue, 21 Jul 2009 08:45:18 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 7E4EC3A6AED for ; Tue, 21 Jul 2009 08:45:18 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6LFiXBw026956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Jul 2009 17:44:33 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6LFiWNw019931; Tue, 21 Jul 2009 17:44:32 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6LFiWaD003051; Tue, 21 Jul 2009 17:44:32 +0200 Message-ID: <4A65E260.1060209@gmail.com> Date: Tue, 21 Jul 2009 17:44:32 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <4A5C2D9F.70806@earthlink.net> <2BD98996-2E7C-46F8-A781-FB3DEDDABF1B@gmail.com><4A6593C1.9050905@gmail.com> <010e01ca0a10$d1d40cd0$757c2670$@nl> <4A65D4F9.7000601@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Comments ondraft-baccelli-autoconf-adhoc-addr-model-01 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 15:45:19 -0000 Dearlove, Christopher (UK) a écrit : >> the draft reads as if humans configure those addresses on their >> interfaces. > > Not to me. > >> Instead of draft saying: "no two such interfaces in the network >> should be configured..." > > Nowhere does that say what or who does the configuration. It thus > applies whether configured by humans, software, Martians, or anything > else. > > This form of wording is in many specifications. ... draft says: > This translates in the following policy: no two such interfaces in > the network should be configured with the same subnet prefix. I think 'policy' is what people do and impose. > these [assumptions] SHOULD be considered when configuring IP subnet > prefixes The capitalized 'SHOULD' makes me think it is for the implementer to read carefully when implementing. I don't see DHCP SHOULD consider some assumptions. Alex From Chris.Dearlove@baesystems.com Tue Jul 21 08:49:30 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21B6028C2FD for ; Tue, 21 Jul 2009 08:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7V9mOXykr+fW for ; Tue, 21 Jul 2009 08:49:29 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 177A228C2EF for ; Tue, 21 Jul 2009 08:49:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,240,1246834800"; d="scan'208";a="13373253" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 21 Jul 2009 16:49:09 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.0/Switch-3.4.0) with ESMTP id n6LFn9HP018933; Tue, 21 Jul 2009 16:49:13 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Jul 2009 16:49:06 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 21 Jul 2009 16:49:05 +0100 Message-ID: In-Reply-To: <4A65E260.1060209@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Comments ondraft-baccelli-autoconf-adhoc-addr-model-01 Thread-Index: AcoKGicGHo+6gPK/REmQaHCKmuakZQAAFawA References: <4A5C2D9F.70806@earthlink.net> <2BD98996-2E7C-46F8-A781-FB3DEDDABF1B@gmail.com><4A6593C1.9050905@gmail.com> <010e01ca0a10$d1d40cd0$757c2670$@nl> <4A65D4F9.7000601@gmail.com> <4A65E260.1060209@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 21 Jul 2009 15:49:06.0742 (UTC) FILETIME=[C7963D60:01CA0A1A] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Comments ondraft-baccelli-autoconf-adhoc-addr-model-01 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 15:49:30 -0000 > I think 'policy' is what people do and impose. Policy may possibly be what people impose. It isn't what people do. Google, for example, "policy based routing". It's not humans doing the routing. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From teco@inf-net.nl Tue Jul 21 09:10:07 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 722D928C2FD for ; Tue, 21 Jul 2009 09:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.791 X-Spam-Level: X-Spam-Status: No, score=-0.791 tagged_above=-999 required=5 tests=[AWL=-0.811, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDSpsI7coXiL for ; Tue, 21 Jul 2009 09:10:06 -0700 (PDT) Received: from CPSMTPM-EML102.kpnxchange.com (cpsmtpm-eml102.kpnxchange.com [195.121.3.6]) by core3.amsl.com (Postfix) with ESMTP id 7CCC028C2E5 for ; Tue, 21 Jul 2009 09:10:06 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML102.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Tue, 21 Jul 2009 18:09:50 +0200 From: "Teco Boot" To: "'Stan Ratliff'" References: <4A5C2D9F.70806@earthlink.net> <4A5C9A42.4050803@cisco.com> In-Reply-To: <4A5C9A42.4050803@cisco.com> Date: Tue, 21 Jul 2009 18:09:40 +0200 Message-ID: <012e01ca0a1d$a6fdf130$f4f9d390$@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: AcoEkffwLEoUYPFtSqW7fHSMFKii8gFibfLw Content-Language: nl X-OriginalArrivalTime: 21 Jul 2009 16:09:50.0158 (UTC) FILETIME=[ACB876E0:01CA0A1D] Cc: autoconf@ietf.org Subject: Re: [Autoconf] New I-D submitted X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 16:10:07 -0000 Hi Stan, |This looks like you say |Use of V6 Link-locals? Beats us! I don't think it was someone's intention to start a competition. I think some majority in DT had IPv4 in mind, and using link-locals in IPv4 is not an obvious choice for routers. Some said the charter says "come up with a (single?) addressing model for MANETs". And because IPv4 link-locals is not an obvious choice, here we have this outcome. Yes, I think link-locals can be used in a MANET. But with limited use. And practical use. The argument against is that there are addresses needed for multi-hop communication also. And one could say: why using multiple addresses where one can do the job? Others say all addresses must be defended using DAD, whatever overhead is involved. Nevertheless, IPv6 link-locals is fact of live. I am still shocked due to suggestions stepping away from it. Teco. |Regards, |Stan From charles.perkins@earthlink.net Tue Jul 21 09:14:10 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A649F28C2E5 for ; Tue, 21 Jul 2009 09:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VWigu6EhSUA for ; Tue, 21 Jul 2009 09:14:10 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 64D4C28C33C for ; Tue, 21 Jul 2009 09:13:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=PKfLrHeE5BZ+66Cc4HCRnUcnN4nKRVp7gxx6DJ2g2SeDMxQZbq+pWQpZCJp5p69w; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.13]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MTHxv-0004tv-8L; Tue, 21 Jul 2009 12:13:19 -0400 Message-ID: <4A65E91C.2080209@earthlink.net> Date: Tue, 21 Jul 2009 09:13:16 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Alexandru Petrescu References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> In-Reply-To: <4A65CC37.2080703@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52118073fdbb1c5cd7274b5dd7a653f47d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 16:14:10 -0000 Hello Alex, Alexandru Petrescu wrote: > I agree, sometimes connections are possible, and the first obvious thing > to do when a connection is possible is to use an IPv6 link-local address. > >>> For example the IPv6 link-layer addresses should come first. >> >> The document clearly says this is not agreed. > > I personally do not agree with the document as it stands with respect to > link-local addresses. > > Why do you oppose the use of IPv6 link-local addresses? And what do > others think please? I was part of the discussion on this point. Quoting some previous email: > > >> |> => you can presumably always communicate with neighbor using >> |> => link-local addresses. >> | >> |Yes, of course, once it is known that a node is a neighbor. >> >> > You have to know that > the node _is_ a _neighbor_. That means within range > and within range RIGHT NOW. How are you going to > know that? How are you going to invalidate the > link-local address as soon as _any_ other node > becomes a new neighbor of the node? I am myself in favor of enabling the use of link-local addresses, once these questions are answered. Up until now no one has been able to answer, and we can demonstrably make excellent progress even without knowing the answers. I think the right thing to do is to delay the standardization of using link-locals within our presumed [autoconf] networks. Regards, Charlie P. From alexandru.petrescu@gmail.com Tue Jul 21 09:33:03 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EC793A6B69 for ; Tue, 21 Jul 2009 09:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.007 X-Spam-Level: X-Spam-Status: No, score=-1.007 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXlCArji5Vl8 for ; Tue, 21 Jul 2009 09:33:02 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 9A2CE3A6B2A for ; Tue, 21 Jul 2009 09:33:02 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6LGX14k003620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Jul 2009 18:33:01 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6LGX0gX027883; Tue, 21 Jul 2009 18:33:01 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6LGX0i8013439; Tue, 21 Jul 2009 18:33:00 +0200 Message-ID: <4A65EDBC.9050103@gmail.com> Date: Tue, 21 Jul 2009 18:33:00 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Teco Boot References: <4A5C2D9F.70806@earthlink.net> <2BD98996-2E7C-46F8-A781-FB3DEDDABF1B@gmail.com> <4A6593C1.9050905@gmail.com> <012601ca0a19$33f058d0$9bd10a70$@nl> In-Reply-To: <012601ca0a19$33f058d0$9bd10a70$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Comments on draft-baccelli-autoconf-adhoc-addr-model-01 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 16:33:03 -0000 Teco Boot a écrit : > |"link local" is already defined. It spans a link. Links are already > |defined. > > We had lots of discussions on "what is a link?". > > I defined some terms, but those were not included in the draft. What are these definitions of a link? Could you post them here? Are they related to the definition of link already in rfc4861? > Now we don't know if link-locals span the link. > > I do not agree on this. I say: packets with link-local source or > destination are not forwarded. That is true, I agree with this, it is an essential characteristic of link-local addresses. >> RFC4291: >> Routers must not forward any packets with Link-Local source or >> destination addresses to other links. > So if two interfaces on the same link do not have connectivity, your > statement is false. I assume two interfaces on the same link _do_ have connectivity. I don't understand what you mean by two interfaces on the same link not having connectivity. If you mean two interfaces on the same link _and_ not having connectivity then I believe they are not on the same link, and they are on two different links. Being on the same link and being connected can't be dissociated. > There was consensus on "MANET link". That term was used for a _line_ > on some diagram. The MANET _cloud_ was "the link", i.e. the > communication facility. The line indicates a (symmetric / > bi-directional) connection between two nodes. On this diagram, the > MANET link was not fully connected, so link-local does not span the > link. I don't agree with this picture. A link-local address reaches all nodes on the link. If you want to define other meanings for "link-local" or for "link" then please do so. We'll have to compare it against the one in rfc4861. Alex > > Teco. > > > |Alex > > > From alexandru.petrescu@gmail.com Tue Jul 21 09:37:13 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 658CF3A684F for ; Tue, 21 Jul 2009 09:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nwa1YfvbgIP3 for ; Tue, 21 Jul 2009 09:37:12 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 6C5053A6813 for ; Tue, 21 Jul 2009 09:37:12 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6LGbAR4032133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Jul 2009 18:37:10 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6LGbAJa028339; Tue, 21 Jul 2009 18:37:10 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6LGb9st014257; Tue, 21 Jul 2009 18:37:09 +0200 Message-ID: <4A65EEB5.3080500@gmail.com> Date: Tue, 21 Jul 2009 18:37:09 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> In-Reply-To: <4A65E91C.2080209@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 16:37:13 -0000 Hello Charles, Charles E. Perkins a écrit : > > Hello Alex, > > Alexandru Petrescu wrote: >> I agree, sometimes connections are possible, and the first obvious >> thing to do when a connection is possible is to use an IPv6 >> link-local address. >> >>>> For example the IPv6 link-layer addresses should come first. >>> >>> The document clearly says this is not agreed. >> >> I personally do not agree with the document as it stands with >> respect to link-local addresses. >> >> Why do you oppose the use of IPv6 link-local addresses? And what >> do others think please? > > I was part of the discussion on this point. Quoting some previous > email: > >> >> >>> |> => you can presumably always communicate with neighbor using >>> |> => link-local addresses. | |Yes, of course, once it is known >>> that a node is a neighbor. >>> >>> >> You have to know that the node _is_ a _neighbor_. That means >> within range and within range RIGHT NOW. How are you going to know >> that? By sending it an NS, it's standardized, it's NUD. >> How are you going to invalidate the link-local address as soon as >> _any_ other node becomes a new neighbor of the node? With NUD. > I am myself in favor of enabling the use of link-local addresses, > once these questions are answered. > > Up until now no one has been able to answer, and we can demonstrably > make excellent progress even without knowing the answers. Anybody discarded NUD? > I think the right thing to do is to delay the standardization of > using link-locals within our presumed [autoconf] networks. I think a good thing to do is to put it first in the discussions. Alex From charles.perkins@earthlink.net Tue Jul 21 09:49:26 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A31453A6E7B for ; Tue, 21 Jul 2009 09:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASkq8UXouyUN for ; Tue, 21 Jul 2009 09:49:26 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id B57113A69C4 for ; Tue, 21 Jul 2009 09:49:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Ycl6Ac91q6FjG/u9onMwB5g3RjccXzBNCHxyEAL53XHG1/wtU8VuYSncpINhMv6B; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.13]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MTIWr-000280-Lk; Tue, 21 Jul 2009 12:49:25 -0400 Message-ID: <4A65F192.3010801@earthlink.net> Date: Tue, 21 Jul 2009 09:49:22 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Alexandru Petrescu References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> In-Reply-To: <4A65EEB5.3080500@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5247808d206939b35ba53d8235fbfbca1e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 16:49:26 -0000 Hello Alex, Alexandru Petrescu wrote: > >>>> >>> You have to know that the node _is_ a _neighbor_. That means within >>> range and within range RIGHT NOW. How are you going to know >>> that? > > By sending it an NS, it's standardized, it's NUD. And re-sending. And waiting for answers. > >>> How are you going to invalidate the link-local address as soon as >>> _any_ other node becomes a new neighbor of the node? > > With NUD. I'd like to see you try this in real life. And then please report back your maximal handover outage while the nodes are enjoying life in the NUD. > >> I think the right thing to do is to delay the standardization of >> using link-locals within our presumed [autoconf] networks. > > I think a good thing to do is to put it first in the discussions. That was easy, wasn't it! No pain whatsoever. I can't imagine why nobody else thought of it. Regards, Charlie P. From sratliff@cisco.com Tue Jul 21 09:53:21 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DFA53A6813 for ; Tue, 21 Jul 2009 09:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.017 X-Spam-Level: X-Spam-Status: No, score=-5.017 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5N2RFkhjidFd for ; Tue, 21 Jul 2009 09:53:20 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 00E063A6857 for ; Tue, 21 Jul 2009 09:53:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEuPZUpAZnme/2dsb2JhbAC6eIgjj34FhAyBRQ X-IronPort-AV: E=Sophos;i="4.43,241,1246838400"; d="scan'208";a="51229902" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 21 Jul 2009 16:53:19 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6LGrJsc025832; Tue, 21 Jul 2009 12:53:19 -0400 Received: from [10.116.179.218] (rtp-sratliff-8719.cisco.com [10.116.179.218]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6LGrIfZ001948; Tue, 21 Jul 2009 16:53:19 GMT Message-ID: <4A65F27E.5050301@cisco.com> Date: Tue, 21 Jul 2009 12:53:18 -0400 From: Stan Ratliff User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> In-Reply-To: <4A65E91C.2080209@earthlink.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2664; t=1248195199; x=1249059199; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20Stan=20Ratliff=20 |Subject:=20Re=3A=20[Autoconf]=20Link-locals=20=3D?UTF-8?B? dmlzLcOgLXZpcyB0aGUgbmV3IFth?=3D=0A=20=3D?UTF-8?B?dXRvY29uZl 0gZG9jdW1lbnQ=3D?=3D |Sender:=20 |To:=20=22Charles=20E.=20Perkins=22=20; bh=mS21bm5dGWKqDm56ZpTVRR6GmUPevLvyO5oV5DJPhXM=; b=k6eBb8q5Da/7dGK+UlrbJuIgl7PzOO1UnaLE70MR8JL2MhROl7O1kmpcmq mpo5tJqfViIPLxbrJPmh1dvVx9KsZoAW4/Vr1XFq3NTfzJS5v+GRes8k19i8 S9G370St3O; Authentication-Results: rtp-dkim-1; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?utf-8?q?Link-locals_vis-=C3=A0-vis_the_new_=5Bautoco?= =?utf-8?q?nf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 16:53:21 -0000 Charles E. Perkins wrote: > > Hello Alex, > > Alexandru Petrescu wrote: >> I agree, sometimes connections are possible, and the first obvious thing >> to do when a connection is possible is to use an IPv6 link-local >> address. >> >>>> For example the IPv6 link-layer addresses should come first. >>> >>> The document clearly says this is not agreed. >> >> I personally do not agree with the document as it stands with respect to >> link-local addresses. >> >> Why do you oppose the use of IPv6 link-local addresses? And what do >> others think please? > > I was part of the discussion on this point. Quoting some > previous email: > >> >> >>> |> => you can presumably always communicate with neighbor using >>> |> => link-local addresses. >>> | >>> |Yes, of course, once it is known that a node is a neighbor. >>> >>> >> You have to know that >> the node _is_ a _neighbor_. That means within range >> and within range RIGHT NOW. How are you going to >> know that? How are you going to invalidate the >> link-local address as soon as _any_ other node >> becomes a new neighbor of the node? > Please don't get me wrong - I'm not trying to re-start the firestorm here. I think the AUTOCONF document as-is represents consensus on some fundamental level, and advances the discussion. It's a good thing. Referencing the above included email - I don't have all of the context of the thread, but the above statement confuses me a bit. If the concern is that you could theoretically have duplicate addresses, then isn't that what DAD is for? And concerning duplicate addresses, how is this any different from, say, duplicate IPv4 addresses? As I said, I'm OK with the document as it stands for now, complete with the lack of consensus on V6 link-local addresses. That being said, I've had some experiences with deploying MANETs using V6 link-locals; it's worked like a champ. So I'm with Teco where link-locals are concerned -- if your deployment lets you utilize them (e.g. an OSPFv3 implementation), they work very well. Regards, Stan > I am myself in favor of enabling the use of link-local > addresses, once these questions are answered. > > Up until now no one has been able to answer, and we can > demonstrably make excellent progress even without knowing > the answers. I think the right thing to do is to delay the > standardization of using link-locals within our presumed > [autoconf] networks. > > Regards, > Charlie P. > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From charles.perkins@earthlink.net Tue Jul 21 10:01:28 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48B333A69DB for ; Tue, 21 Jul 2009 10:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.604 X-Spam-Level: X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_SORBS_WEB=0.619, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHG+Qr18QM8p for ; Tue, 21 Jul 2009 10:01:27 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 594233A6848 for ; Tue, 21 Jul 2009 10:01:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=NkR4rQax6roWpcJQN1D+52vqx80JY13WGv2Y1BBqkK9S3b/FdiX7dGOZ3yVlG6qC; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.13]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MTIiV-0008Ky-5s; Tue, 21 Jul 2009 13:01:27 -0400 Message-ID: <4A65F463.6010907@earthlink.net> Date: Tue, 21 Jul 2009 10:01:23 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Stan Ratliff References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65F27E.5050301@cisco.com> In-Reply-To: <4A65F27E.5050301@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f524fdbc27aa029dc2e90c433076b4aaf86350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?utf-8?q?Link-locals_vis-=C3=A0-vis_the_new_=5Bautoco?= =?utf-8?q?nf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 17:01:28 -0000 Hello Stan, Stan Ratliff wrote: > >>> >>>> |> => you can presumably always communicate with neighbor using >>>> |> => link-local addresses. >>>> | >>>> |Yes, of course, once it is known that a node is a neighbor. >>>> >>>> >>> You have to know that >>> the node _is_ a _neighbor_. That means within range >>> and within range RIGHT NOW. How are you going to >>> know that? How are you going to invalidate the >>> link-local address as soon as _any_ other node >>> becomes a new neighbor of the node? >> > ... the above statement confuses me a bit. If the concern is that > you could theoretically have duplicate addresses, then isn't that what > DAD is for? And concerning duplicate addresses, how is this any > different from, say, duplicate IPv4 addresses? It's not much different. The point overall is that DAD isn't engineered for such networks where topology can change on a timescale shorter than DAD protocol sequences could handle. And, the problem gets worse as DAD is required to traverse a greater number of radio links. There was a lot of discussion earlier about "weak-DAD" vs. "strong-DAD". The discussion didn't really reach many useful conclusions, but did open the door for some really great puns. So it was definitely worthwhile for me. > > As I said, I'm OK with the document as it stands for now, complete > with the lack of consensus on V6 link-local addresses. That being > said, I've had some experiences with deploying MANETs using V6 > link-locals; it's worked like a champ. So I'm with Teco where > link-locals are concerned -- if your deployment lets you utilize them > (e.g. an OSPFv3 implementation), they work very well. Yes, I also agree with this. As I mentioned, I am also in favor of enabling the use of link-locals -- whenever possible. I think that if someone wanted to contribute a document delimiting the sphere of applicability for DAD and link-locals that would be a fine thing, and would get my support and attention. Regards, Charlie P. From sratliff@cisco.com Tue Jul 21 10:07:50 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 996E028C2EF for ; Tue, 21 Jul 2009 10:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.017 X-Spam-Level: X-Spam-Status: No, score=-5.017 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lG75e9sATRIz for ; Tue, 21 Jul 2009 10:07:49 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 738F128C356 for ; Tue, 21 Jul 2009 10:07:49 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAM+SZUpAZnmf/2dsb2JhbAC7BIgjkAMFhAyBRQ X-IronPort-AV: E=Sophos;i="4.43,241,1246838400"; d="scan'208";a="51232565" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 21 Jul 2009 17:07:45 +0000 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 n6LH7j3b024901; Tue, 21 Jul 2009 13:07:45 -0400 Received: from [10.116.179.218] (rtp-sratliff-8719.cisco.com [10.116.179.218]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6LH7iFc015553; Tue, 21 Jul 2009 17:07:44 GMT Message-ID: <4A65F5E0.903@cisco.com> Date: Tue, 21 Jul 2009 13:07:44 -0400 From: Stan Ratliff User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65F27E.5050301@cisco.com> <4A65F463.6010907@earthlink.net> In-Reply-To: <4A65F463.6010907@earthlink.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2505; t=1248196065; x=1249060065; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20Stan=20Ratliff=20 |Subject:=20Re=3A=20[Autoconf]=20Link-locals=20=3D?UTF-8?B? dmlzLcOgLXZpcyB0aGUgbmV3IFth?=3D=0A=20=3D?UTF-8?B?dXRvY29uZl 0gZG9jdW1lbnQ=3D?=3D |Sender:=20 |To:=20=22Charles=20E.=20Perkins=22=20; bh=/dDgr99N263bIbxR6srdsBq9owp1vFJYZWwHPd1m/94=; b=yF96MYQgK0iiC5ezUTuqkJGGLYOYrz26u/MZwrXh5EYiclUbbl7EfzD42w rrw7g9rRYweHYF9dTQ5YvfpE7soF2QOLP9hkO/VRjgcrhApqH1l0VSjbsD+j tOinsju4wg; Authentication-Results: rtp-dkim-2; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?utf-8?q?Link-locals_vis-=C3=A0-vis_the_new_=5Bautoco?= =?utf-8?q?nf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 17:07:50 -0000 Charles E. Perkins wrote: > > Hello Stan, > > Stan Ratliff wrote: >> >>>> >>>>> |> => you can presumably always communicate with neighbor using >>>>> |> => link-local addresses. >>>>> | >>>>> |Yes, of course, once it is known that a node is a neighbor. >>>>> >>>>> >>>> You have to know that >>>> the node _is_ a _neighbor_. That means within range >>>> and within range RIGHT NOW. How are you going to >>>> know that? How are you going to invalidate the >>>> link-local address as soon as _any_ other node >>>> becomes a new neighbor of the node? >>> >> ... the above statement confuses me a bit. If the concern is that >> you could theoretically have duplicate addresses, then isn't that >> what DAD is for? And concerning duplicate addresses, how is this any >> different from, say, duplicate IPv4 addresses? > > It's not much different. The point overall is that DAD isn't engineered > for such networks where topology can change on a timescale shorter > than DAD protocol sequences could handle. And, the problem gets > worse as DAD is required to traverse a greater number of radio links. > > There was a lot of discussion earlier about "weak-DAD" vs. > "strong-DAD". The discussion didn't really reach many useful > conclusions, but did open the door for some really great puns. > So it was definitely worthwhile for me. > Fair enough. So as I read this, there's an unsolved problem here in general dealing with duplicate addresses -- regardless of whether they are V4 or V6. I don't think the WG should come to a screeching halt and deal with the problem before making any progress, but it's something we should at least discuss. Regards, Stan >> >> As I said, I'm OK with the document as it stands for now, complete >> with the lack of consensus on V6 link-local addresses. That being >> said, I've had some experiences with deploying MANETs using V6 >> link-locals; it's worked like a champ. So I'm with Teco where >> link-locals are concerned -- if your deployment lets you utilize them >> (e.g. an OSPFv3 implementation), they work very well. > > Yes, I also agree with this. As I mentioned, I am also in > favor of enabling the use of link-locals -- whenever possible. > I think that if someone wanted to contribute a document > delimiting the sphere of applicability for DAD and link-locals > that would be a fine thing, and would get my support and > attention. > > > Regards, > Charlie P. > > > From charles.perkins@earthlink.net Tue Jul 21 10:18:03 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD7AB3A6E90 for ; Tue, 21 Jul 2009 10:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.579 X-Spam-Level: X-Spam-Status: No, score=-1.579 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_SORBS_WEB=0.619, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJujcpfrdjh0 for ; Tue, 21 Jul 2009 10:18:02 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 87E2C3A6869 for ; Tue, 21 Jul 2009 10:18:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=YScim6quvvMn98H9BbwbtveYS+kly3USgSCWQUvtBADMCG8E+jf/NERzQdYWNuCU; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.13]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MTIyN-0000ir-Fa; Tue, 21 Jul 2009 13:17:51 -0400 Message-ID: <4A65F83C.4090009@earthlink.net> Date: Tue, 21 Jul 2009 10:17:48 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Stan Ratliff References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65F27E.5050301@cisco.com> <4A65F463.6010907@earthlink.net> <4A65F5E0.903@cisco.com> In-Reply-To: <4A65F5E0.903@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52e1123975c46ba66726fc3e1b4481e4f6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?utf-8?q?Link-locals_vis-=C3=A0-vis_the_new_=5Bautoco?= =?utf-8?q?nf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 17:18:03 -0000 Hello Stan, Stan Ratliff wrote: > >> >> ... DAD isn't engineered >> for such networks where topology can change on a timescale shorter >> than DAD protocol sequences could handle. And, the problem gets >> worse as DAD is required to traverse a greater number of radio links. >> >> There was a lot of discussion earlier about "weak-DAD" vs. >> "strong-DAD". The discussion didn't really reach many useful >> conclusions, but did open the door for some really great puns. >> So it was definitely worthwhile for me. >> > Fair enough. So as I read this, there's an unsolved problem here in > general dealing with duplicate addresses -- regardless of whether they > are V4 or V6. I don't think the WG should come to a screeching halt > and deal with the problem before making any progress, but it's > something we should at least discuss. Yes, it should be discussed in solution space (so to speak). The problem with duplicate addresses has received quite a bit of attention in the past, as I mentioned. I can try to unearth some of that discussion and send pointers to the list. As far as I know, there has never been any perfect solution published. Attempts to reduce the impace of the problem include - (the obvious) pick highly random local addresses - (more obvious) use guaranteed unique MAC addresses - attach more information to the link-local addresses, for instance neighborhood information. This is on the theory that two different nodes that unfortunately have the same link-local address will still have different neighborhoods - (for the despotic dictators) blast the network with DAD from every node once a second or - clever routing annotations to reduce the impact of duplicate address faults - distribute unique cryptographic keys to all nodes I'm sure you get the picture. None of these solutions is really universally applicable. But at least it's a lot of fun to talk about them. Regards, Charlie P. From teco@inf-net.nl Tue Jul 21 10:19:02 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EEE23A6869 for ; Tue, 21 Jul 2009 10:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.373 X-Spam-Level: X-Spam-Status: No, score=-1.373 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3hHf2R8DAzC for ; Tue, 21 Jul 2009 10:19:01 -0700 (PDT) Received: from CPSMTPM-EML103.kpnxchange.com (cpsmtpm-eml103.kpnxchange.com [195.121.3.7]) by core3.amsl.com (Postfix) with ESMTP id B8BB53A6A81 for ; Tue, 21 Jul 2009 10:18:59 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML103.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Tue, 21 Jul 2009 19:18:47 +0200 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <4A5C2D9F.70806@earthlink.net> <2BD98996-2E7C-46F8-A781-FB3DEDDABF1B@gmail.com> <4A6593C1.9050905@gmail.com> <012601ca0a19$33f058d0$9bd10a70$@nl> <4A65EDBC.9050103@gmail.com> In-Reply-To: <4A65EDBC.9050103@gmail.com> Date: Tue, 21 Jul 2009 19:18:37 +0200 Message-ID: <000001ca0a27$492b7eb0$db827c10$@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: AcoKIOy1V/ndeD72TC661IjOyJm4dAABRHhw Content-Language: nl X-OriginalArrivalTime: 21 Jul 2009 17:18:47.0642 (UTC) FILETIME=[4EDA6BA0:01CA0A27] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Comments on draft-baccelli-autoconf-adhoc-addr-model-01 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 17:19:02 -0000 |If you want to define other meanings for "link-local" or for "link" then |please do so. We'll have to compare it against the one in rfc4861. My link definition is from 4861. Here the terms I suggested before, with minor adjustment (comments Charlie): =========== link - a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP. (out of RFC4861) MANET link - 1-hop connectivity between two MANET interfaces. Called edge in graph theory. MANET interface - MANET router interface with a MANET protocol enabled. Radio link - a link with undetermined connectivity properties, such as asymmetry, non-transitivity and time-variation as described in [draft-baccelli-multi-hop-wireless-communication]. Wireless links have often undetermined connectivity properties. Radio interface - MANET router interface to a Radio link. =========== The term "MANET link" needs another thought. The word "link" in "MANET link" would be associated with term "link", and as pointed out this is confusing. I am OK on any better term, but I still can't come up with something. "MANET edge" ?? No, this wouldn't work. Teco. | |Alex From roque.rafael@gmail.com Tue Jul 21 10:21:23 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2E7B28C235 for ; Tue, 21 Jul 2009 10:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.168 X-Spam-Level: X-Spam-Status: No, score=-1.168 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-TgHf7wS058 for ; Tue, 21 Jul 2009 10:21:22 -0700 (PDT) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id 8DCB03A68E9 for ; Tue, 21 Jul 2009 10:21:21 -0700 (PDT) Received: by bwz28 with SMTP id 28so2737197bwz.37 for ; Tue, 21 Jul 2009 10:21:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=AYTe0DSvwS3VQ+rnBjD5m455PfkAO4IVSA1STi8FkI0=; b=hIt0PSvm8Hq7LLEdXHSE8hGMIu3+5XlOISTla0QyQ8TZZ3S/Npt+EEsVIj0GYWXKlJ vqK7ACqNQwSDWjA9mGYsMpwLEq7kC44a8Xg5s6C6CEWE72g6cd1hNB/m9Fj8sv6VZ1wK iPmTZlwBvaubTlL1Csq4ukGoUBo4uwOZ4M2+4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=oi2WcIE664HEdSL8Jm32zK1fsVcyEaRzgvbBS0ywFEHAlKcotAceUZM1bw4reuDYnh E4X+YO276q5R8jMIGkgXUimQEZKURA8UpDMMJ94RaWBgKcL/ZNvKX4t4yNKg14qk4PX9 eiqoU9w+Fn3wfGH5CobtR7V1qlpVlgoozcik8= MIME-Version: 1.0 Received: by 10.204.123.83 with SMTP id o19mr5729136bkr.12.1248196876017; Tue, 21 Jul 2009 10:21:16 -0700 (PDT) In-Reply-To: <4A65F83C.4090009@earthlink.net> References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65F27E.5050301@cisco.com> <4A65F463.6010907@earthlink.net> <4A65F5E0.903@cisco.com> <4A65F83C.4090009@earthlink.net> Date: Tue, 21 Jul 2009 14:21:15 -0300 Message-ID: <1726274c0907211021n7c0e2db3of321ded19bf6b5b2@mail.gmail.com> From: Rafael Roque To: "Charles E. Perkins" Content-Type: multipart/alternative; boundary=0016e6d6478967a359046f3a7bf0 Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 17:21:23 -0000 --0016e6d6478967a359046f3a7bf0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Tue, Jul 21, 2009 at 2:17 PM, Charles E. Perkins < charles.perkins@earthlink.net> wrote: > > Hello Stan, > > Stan Ratliff wrote: > >> >> >>> ... DAD isn't engineered >>> for such networks where topology can change on a timescale shorter >>> than DAD protocol sequences could handle. And, the problem gets >>> worse as DAD is required to traverse a greater number of radio links. >>> >>> There was a lot of discussion earlier about "weak-DAD" vs. >>> "strong-DAD". The discussion didn't really reach many useful >>> conclusions, but did open the door for some really great puns. >>> So it was definitely worthwhile for me. >>> >>> Fair enough. So as I read this, there's an unsolved problem here in >> general dealing with duplicate addresses -- regardless of whether they are >> V4 or V6. I don't think the WG should come to a screeching halt and deal >> with the problem before making any progress, but it's something we should at >> least discuss. >> > > Yes, it should be discussed in solution space (so to speak). > The problem with duplicate addresses has received quite a bit > of attention in the past, as I mentioned. I can try to unearth some > of that discussion and send pointers to the list. As far as I know, > there has never been any perfect solution published. Attempts > to reduce the impace of the problem include > - (the obvious) pick highly random local addresses > - (more obvious) use guaranteed unique MAC addresses > - attach more information to the link-local addresses, for > instance neighborhood information. This is on the theory > that two different nodes that unfortunately have the same > link-local address will still have different neighborhoods > - (for the despotic dictators) blast the network with DAD from > every node once a second or > - clever routing annotations to reduce the impact of duplicate > address faults > - distribute unique cryptographic keys to all nodes > > I'm sure you get the picture. None of these solutions is > really universally applicable. But at least it's a lot of fun > to talk about them. > > > Regards, > Charlie P. > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > I know that no autoconf mechanisms are being discussed but... What about existing ad-hoc addressing allocation methods that suppress the need for DAD, that is, guarantees address uniqueness, they will not get into account? Regards, Rafael -- Rafael Roque Aschoff GPRT/UFPE --0016e6d6478967a359046f3a7bf0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jul 21, 2009 at 2:17 PM, Charles= E. Perkins <charles.perkins@earthlink.net> wrote:

Hello Stan,

Stan Ratliff wrote:


=A0... =A0 DAD isn't engineered

for such networks where topology can change on a timescale shorter
than DAD protocol sequences could handle. =A0And, the problem gets
worse as DAD is required to traverse a greater number of radio links.

There was a lot of discussion earlier about "weak-DAD" vs.
"strong-DAD". =A0The discussion didn't really reach many usef= ul
conclusions, but did open the door for some really great puns.
So it was definitely worthwhile for me.

Fair enough. So as I read this, there's an unsolved problem here in gen= eral dealing with duplicate addresses -- regardless of whether they are V4 = or V6. I don't think the WG should come to a screeching halt and deal w= ith the problem before making any progress, but it's something we shoul= d at least discuss.

Yes, it should be discussed in solution space (so to speak).
The problem with duplicate addresses has received quite a bit
of attention in the past, as I mentioned. =A0I can try to unearth some
of that discussion and send pointers to the list. =A0As far as I know,
there has never been any perfect solution published. =A0Attempts
to reduce the impace of the problem include
- (the obvious) pick highly random local addresses
- (more obvious) use guaranteed unique MAC addresses
- attach more information to the link-local addresses, for
=A0 instance neighborhood information. =A0This is on the theory
=A0 that two different nodes that unfortunately have the same
=A0 link-local address will still have different neighborhoods
- (for the despotic dictators) blast the network with DAD from
=A0every node once a second or <pick your poisonous interval>
- clever routing annotations to reduce the impact of duplicate
=A0address faults
- distribute unique cryptographic keys to all nodes

I'm sure you get the picture. =A0None of these solutions is
really universally applicable. =A0But at least it's a lot of fun
to talk about them.


Regards,
Charlie P.

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

I know that no autoconf mechanisms are b= eing discussed but...
What about existing ad-hoc addressing allocation methods that suppress the need for DAD, that is, guarantees address uniqueness, they will not get into account?

Regards,

Rafael

--
Rafael Roque Aschoff
GPRT= /UFPE

--0016e6d6478967a359046f3a7bf0-- From teco@inf-net.nl Tue Jul 21 10:21:57 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E495628C33E for ; Tue, 21 Jul 2009 10:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nV-RGgWHXmf for ; Tue, 21 Jul 2009 10:21:57 -0700 (PDT) Received: from CPSMTPM-EML106.kpnxchange.com (Cpsmtpm-eml106.kpnxchange.com [195.121.3.10]) by core3.amsl.com (Postfix) with ESMTP id AF69028C33D for ; Tue, 21 Jul 2009 10:21:56 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML106.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Tue, 21 Jul 2009 19:21:50 +0200 From: "Teco Boot" To: "'Charles E. Perkins'" , "'Stan Ratliff'" References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65F27E.5050301@cisco.com> <4A65F463.6010907@earthlink.net> <4A65F5E0.903@cisco.com> <4A65F83C.4090009@earthlink.net> In-Reply-To: <4A65F83C.4090009@earthlink.net> Date: Tue, 21 Jul 2009 19:21:40 +0200 Message-ID: <000101ca0a27$b6388480$22a98d80$@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: AcoKJ03fw8iA6NoQRy6oUYY+fc5MdwAABuRA Content-Language: nl X-OriginalArrivalTime: 21 Jul 2009 17:21:50.0542 (UTC) FILETIME=[BBDEBEE0:01CA0A27] Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 17:21:58 -0000 It was no fun to handle a DAD DOS attack. I remember this like yesterday. It was in the SNA days... Am I getting old ?? But I am experienced !! Teco. |-----Oorspronkelijk bericht----- |Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] = Namens |Charles E. Perkins |Verzonden: dinsdag 21 juli 2009 19:18 |Aan: Stan Ratliff |CC: autoconf@ietf.org |Onderwerp: Re: [Autoconf] Link-locals vis-=E0-vis the new [autoconf] |document | | |Hello Stan, | |Stan Ratliff wrote: |> |>> |>> ... DAD isn't engineered |>> for such networks where topology can change on a timescale shorter |>> than DAD protocol sequences could handle. And, the problem gets |>> worse as DAD is required to traverse a greater number of radio = links. |>> |>> There was a lot of discussion earlier about "weak-DAD" vs. |>> "strong-DAD". The discussion didn't really reach many useful |>> conclusions, but did open the door for some really great puns. |>> So it was definitely worthwhile for me. |>> |> Fair enough. So as I read this, there's an unsolved problem here in |> general dealing with duplicate addresses -- regardless of whether = they |> are V4 or V6. I don't think the WG should come to a screeching halt |> and deal with the problem before making any progress, but it's |> something we should at least discuss. | |Yes, it should be discussed in solution space (so to speak). |The problem with duplicate addresses has received quite a bit |of attention in the past, as I mentioned. I can try to unearth some |of that discussion and send pointers to the list. As far as I know, |there has never been any perfect solution published. Attempts |to reduce the impace of the problem include |- (the obvious) pick highly random local addresses |- (more obvious) use guaranteed unique MAC addresses |- attach more information to the link-local addresses, for | instance neighborhood information. This is on the theory | that two different nodes that unfortunately have the same | link-local address will still have different neighborhoods |- (for the despotic dictators) blast the network with DAD from | every node once a second or |- clever routing annotations to reduce the impact of duplicate | address faults |- distribute unique cryptographic keys to all nodes | |I'm sure you get the picture. None of these solutions is |really universally applicable. But at least it's a lot of fun |to talk about them. | |Regards, |Charlie P. | |_______________________________________________ |Autoconf mailing list |Autoconf@ietf.org |https://www.ietf.org/mailman/listinfo/autoconf From sratliff@cisco.com Tue Jul 21 10:29:48 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82A7B28C355 for ; Tue, 21 Jul 2009 10:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.093 X-Spam-Level: X-Spam-Status: No, score=-5.093 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIJ7+5MMRjMm for ; Tue, 21 Jul 2009 10:29:47 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 636F428C3A4 for ; Tue, 21 Jul 2009 10:24:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFSWZUpAZnmf/2dsb2JhbAC6b4gjkAQFhAw X-IronPort-AV: E=Sophos;i="4.43,241,1246838400"; d="scan'208";a="51235272" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 21 Jul 2009 17:24:22 +0000 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 n6LHOMXa002928; Tue, 21 Jul 2009 13:24:22 -0400 Received: from [10.116.179.218] (rtp-sratliff-8719.cisco.com [10.116.179.218]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6LHOLVp022757; Tue, 21 Jul 2009 17:24:21 GMT Message-ID: <4A65F9C5.2080008@cisco.com> Date: Tue, 21 Jul 2009 13:24:21 -0400 From: Stan Ratliff User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Teco Boot References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65F27E.5050301@cisco.com> <4A65F463.6010907@earthlink.net> <4A65F5E0.903@cisco.com> <4A65F83C.4090009@earthlink.net> <000101ca0a27$b6388480$22a98d80$@nl> In-Reply-To: <000101ca0a27$b6388480$22a98d80$@nl> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2962; t=1248197062; x=1249061062; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20Stan=20Ratliff=20 |Subject:=20Re=3A=20[Autoconf]=20Link-locals=20=3D?ISO-8859 -1?Q?vis-=3DE0-vis_the_ne?=3D=0A=20=3D?ISO-8859-1?Q?w_=3D5Ba utoconf=3D5D_document?=3D |Sender:=20 |To:=20Teco=20Boot=20; bh=wxbah9u6ByvcFLYBLDGGZpJ3o9UX+jNE4i41dlOXFEI=; b=ZXmuRdDTxx3JkukYnPzY4ql8h0M2/4fzGij126opA7nvuj71lqLK0wEKOF DhnB4kgOE+9yed72hGNzJsxV4tA3jjKK7p305Ta/KLj0rmGsGvHo54gjxphm 67jNzUDHre; Authentication-Results: rtp-dkim-2; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 17:29:48 -0000 SNA?!? When I want to reference an old, out-of-date networking technology, I normally refer to Wang-Net... ;-) ;-) ;-) Stan Teco Boot wrote: > It was no fun to handle a DAD DOS attack. > I remember this like yesterday. It was in the SNA days... > Am I getting old ?? But I am experienced !! > Teco. > > |-----Oorspronkelijk bericht----- > |Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens > |Charles E. Perkins > |Verzonden: dinsdag 21 juli 2009 19:18 > |Aan: Stan Ratliff > |CC: autoconf@ietf.org > |Onderwerp: Re: [Autoconf] Link-locals vis-à-vis the new [autoconf] > |document > | > | > |Hello Stan, > | > |Stan Ratliff wrote: > |> > |>> > |>> ... DAD isn't engineered > |>> for such networks where topology can change on a timescale shorter > |>> than DAD protocol sequences could handle. And, the problem gets > |>> worse as DAD is required to traverse a greater number of radio links. > |>> > |>> There was a lot of discussion earlier about "weak-DAD" vs. > |>> "strong-DAD". The discussion didn't really reach many useful > |>> conclusions, but did open the door for some really great puns. > |>> So it was definitely worthwhile for me. > |>> > |> Fair enough. So as I read this, there's an unsolved problem here in > |> general dealing with duplicate addresses -- regardless of whether they > |> are V4 or V6. I don't think the WG should come to a screeching halt > |> and deal with the problem before making any progress, but it's > |> something we should at least discuss. > | > |Yes, it should be discussed in solution space (so to speak). > |The problem with duplicate addresses has received quite a bit > |of attention in the past, as I mentioned. I can try to unearth some > |of that discussion and send pointers to the list. As far as I know, > |there has never been any perfect solution published. Attempts > |to reduce the impace of the problem include > |- (the obvious) pick highly random local addresses > |- (more obvious) use guaranteed unique MAC addresses > |- attach more information to the link-local addresses, for > | instance neighborhood information. This is on the theory > | that two different nodes that unfortunately have the same > | link-local address will still have different neighborhoods > |- (for the despotic dictators) blast the network with DAD from > | every node once a second or > |- clever routing annotations to reduce the impact of duplicate > | address faults > |- distribute unique cryptographic keys to all nodes > | > |I'm sure you get the picture. None of these solutions is > |really universally applicable. But at least it's a lot of fun > |to talk about them. > | > |Regards, > |Charlie P. > | > |_______________________________________________ > |Autoconf mailing list > |Autoconf@ietf.org > |https://www.ietf.org/mailman/listinfo/autoconf > > From teco@inf-net.nl Tue Jul 21 11:13:19 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2ECD3A67B5 for ; Tue, 21 Jul 2009 11:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTSGp5dCgeQF for ; Tue, 21 Jul 2009 11:13:19 -0700 (PDT) Received: from CPSMTPM-EML109.kpnxchange.com (Cpsmtpm-eml109.kpnxchange.com [195.121.3.13]) by core3.amsl.com (Postfix) with ESMTP id E9A173A6407 for ; Tue, 21 Jul 2009 11:13:18 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML109.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Tue, 21 Jul 2009 20:13:17 +0200 From: "Teco Boot" To: "'Stan Ratliff'" , "'Charles E. Perkins'" References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65F27E.5050301@cisco.com> <4A65F463.6010907@earthlink.net> <4A65F5E0.903@cisco.com> <4A65F83C.4090009@earthlink.net> <000101ca0a27$b6388480$22a98d80$@nl> <4A65F9C5.2080008@cisco.com> In-Reply-To: <4A65F9C5.2080008@cisco.com> Date: Tue, 21 Jul 2009 20:13:08 +0200 Message-ID: <000801ca0a2e$e6656ae0$b33040a0$@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: AcoKKBrqNX2zZFUXSIOSecXDImAcDwABW9EQ Content-Language: nl X-OriginalArrivalTime: 21 Jul 2009 18:13:17.0798 (UTC) FILETIME=[EC04A060:01CA0A2E] Cc: autoconf@ietf.org Subject: [Autoconf] Link locals and address selection X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 18:13:19 -0000 I think the DAD discussion leads us from more important topics. Link-locals are fine for MANET protocols, neighborhood discovery and other communication to nearby / in range nodes. But using them for other traffic can introduce problems. When nodes move, the direct connection is broken. So in a MANET, usage of domain wide or global is preferred, even when a destination node and source node have link-locals. This, because loss of connection should be circumvented. Is this an update of RFC3483 ?? I'll take some beers before reading back and understand 3484 rule 2: > Rule 2: Prefer appropriate scope. > If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB > and otherwise prefer SA. Similarly, if Scope(SB) < Scope(SA): If > Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB. Teco. From charles.perkins@earthlink.net Tue Jul 21 11:14:03 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E57383A6909 for ; Tue, 21 Jul 2009 11:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jbVpjbC3Ndd for ; Tue, 21 Jul 2009 11:14:03 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 967493A6407 for ; Tue, 21 Jul 2009 11:13:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=LrcTt9FpyBZLp9/aHr6bUewKiwYf6ldk71iwKl5ZTJFkZ9Sn0Q5RiVaqPf+CZPnz; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.13]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MTJqU-0007yw-9D; Tue, 21 Jul 2009 14:13:46 -0400 Message-ID: <4A660557.9080701@earthlink.net> Date: Tue, 21 Jul 2009 11:13:43 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Rafael Roque References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65F27E.5050301@cisco.com> <4A65F463.6010907@earthlink.net> <4A65F5E0.903@cisco.com> <4A65F83C.4090009@earthlink.net> <1726274c0907211021n7c0e2db3of321ded19bf6b5b2@mail.gmail.com> In-Reply-To: <1726274c0907211021n7c0e2db3of321ded19bf6b5b2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f528109ada2084b2940df6d72fb88458828350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 18:14:04 -0000 Hello Rafael, Rafael Roque wrote: > > > ... None of these solutions is > really universally applicable. > > > I know that no autoconf mechanisms are being discussed but... > What about existing ad-hoc addressing allocation methods that suppress > the need for DAD, that is, guarantees address uniqueness, they will > not get into account? Which existing allocation methods did you mean? Regards. Charlie P. From roque.rafael@gmail.com Tue Jul 21 11:34:59 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71AD73A6A99 for ; Tue, 21 Jul 2009 11:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.168 X-Spam-Level: X-Spam-Status: No, score=-1.168 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fypmytYxP6oS for ; Tue, 21 Jul 2009 11:34:58 -0700 (PDT) Received: from mail-fx0-f223.google.com (mail-fx0-f223.google.com [209.85.220.223]) by core3.amsl.com (Postfix) with ESMTP id 2D47F3A6978 for ; Tue, 21 Jul 2009 11:34:58 -0700 (PDT) Received: by fxm23 with SMTP id 23so848045fxm.42 for ; Tue, 21 Jul 2009 11:34:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=X7/nnr9a3ABe1BlItT56Z43GS9eYK6sa2mqAQSeXCY0=; b=Xd3QAs2GvDnKJreSsD1+aU5BLTu8u+ZjuVpao4m0+3QcmButAwlLHtVLzQlvrGLgeb Tqqmi4Yark1whkDGFBDOK5bVYhn+PTIko2k30O4IprjIH0EW4r2GXjmwygwTziTaDG2X qsgNy8UtUxKvsb8XaPed5rmZZXOR8JojYT4Os= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WzO2bcIYf63hJ/ZAEuAiwl2jGG3EvudKJCOz37hP6jJfByQ5mDET3oK/xN267v5msN m364oOUNez5sVHNhz0v4grVlPmjptNXpBb5CpWLyTkYIEzFbpi2GzQ6h13aMuCqmvGqq pHjHutwMCuamp7bH3hdSt5FjgAEtofURVixj8= MIME-Version: 1.0 Received: by 10.204.102.15 with SMTP id e15mr5745038bko.196.1248201293523; Tue, 21 Jul 2009 11:34:53 -0700 (PDT) In-Reply-To: <4A660557.9080701@earthlink.net> References: <4A6596CD.9040404@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65F27E.5050301@cisco.com> <4A65F463.6010907@earthlink.net> <4A65F5E0.903@cisco.com> <4A65F83C.4090009@earthlink.net> <1726274c0907211021n7c0e2db3of321ded19bf6b5b2@mail.gmail.com> <4A660557.9080701@earthlink.net> Date: Tue, 21 Jul 2009 15:34:53 -0300 Message-ID: <1726274c0907211134r15c3041er5626f4c91af3db8d@mail.gmail.com> From: Rafael Roque To: "Charles E. Perkins" Content-Type: multipart/alternative; boundary=0016e6d7845bb56db4046f3b8234 Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 18:34:59 -0000 --0016e6d7845bb56db4046f3b8234 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks for reply Charles. Charles E. Perkins wrote: > > > > Which existing allocation methods did you mean? There are some examples, like Prime DHCP, and Buddy System. Prime DHCP uses a distributed allocation function that assures unique number generation, while Buddy System splits address allocation space by half for each configuration process. Regards. R. Rafael. -- Rafael Roque Aschoff GPRT/UFPE --0016e6d7845bb56db4046f3b8234 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for reply Charles.

Charles E. Perkins wrote:


Which existing allocation methods did you mean?


There are some examples, like Prime DHCP, and Buddy System.
Prime DHCP uses a distributed allocation function that assures unique= number generation, while Buddy System splits address allocation space by h= alf for each configuration process.


Regards.
R. Rafael.



--
Rafael Roque Aschoff
GPRT/UFPE

--0016e6d7845bb56db4046f3b8234-- From charles.perkins@earthlink.net Tue Jul 21 12:10:37 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE28028C0E2 for ; Tue, 21 Jul 2009 12:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHT-PK3zLk6N for ; Tue, 21 Jul 2009 12:10:36 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id BE5BF28C205 for ; Tue, 21 Jul 2009 12:10:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Rl5X2+inn93LQkO3Mcsx/0jU1GwBhQNxff6pEwGLr/dRmBPpQkQUp6xqEccoN1kh; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.13]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MTKjU-0005oN-SX; Tue, 21 Jul 2009 15:10:36 -0400 Message-ID: <4A6612A9.9020308@earthlink.net> Date: Tue, 21 Jul 2009 12:10:33 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Rafael Roque References: <4A6596CD.9040404@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65F27E.5050301@cisco.com> <4A65F463.6010907@earthlink.net> <4A65F5E0.903@cisco.com> <4A65F83C.4090009@earthlink.net> <1726274c0907211021n7c0e2db3of321ded19bf6b5b2@mail.gmail.com> <4A660557.9080701@earthlink.net> <1726274c0907211134r15c3041er5626f4c91af3db8d@mail.gmail.com> In-Reply-To: <1726274c0907211134r15c3041er5626f4c91af3db8d@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5244db9423b2b207f71d6dd6e45f8b8c68350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: [Autoconf] Proposals for Prime DHCP and the buddy system of allocation X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 19:10:37 -0000 Hello Rafael, Those protocols would definitely belong in a discussion about eliminating duplicate addresses. Thanks for sharing the citations. I think it is fair to say that the work in [autoconf] should proceed without waiting for standardization work to begin on these proposals. As far as I know neither of these systems have seriously been considered in any working group of the IETF before now. I had suggested the buddy system for possible consideration during the [autoconf] BOFs, and Prophet is interesting but, at least for me at the time, had robustness issues that I thought were not well understood. Prime DHCP seems to be a useful refinement. Nevertheless, pushing these ideas into a Proposed Standard or even Experimental RFC is more work than I see anyone volunteering to do.... or, are you volunteering? Regards, Charlie P. Rafael Roque wrote: > Thanks for reply Charles. > > Charles E. Perkins wrote: > > > > Which existing allocation methods did you mean? > > > > There are some examples, like Prime DHCP > , and > Buddy System. > Prime DHCP uses a distributed allocation function that assures unique > number generation, while Buddy System splits address allocation space > by half for each configuration process. > > > Regards. > R. Rafael. > > > > -- > Rafael Roque Aschoff > GPRT/UFPE > From roque.rafael@gmail.com Tue Jul 21 13:32:44 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C13C128C364 for ; Tue, 21 Jul 2009 13:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQU5VTlRTBvT for ; Tue, 21 Jul 2009 13:32:43 -0700 (PDT) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id 5250028C30C for ; Tue, 21 Jul 2009 13:32:42 -0700 (PDT) Received: by bwz28 with SMTP id 28so2844287bwz.37 for ; Tue, 21 Jul 2009 13:32:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=cdAp7x0dLYB8q13VqTp5MDBmaAL8u/AhuQsnGf373Es=; b=W60vdv1ZuzsphiW632d712AvW4VS+C6JNIn9K3TVuWXh/okGkDCJeXJIgp0BvLK3ho HrNjrVoFkbIB9wYEh0P/4tNFzz4Nbr/xLDGh8ttWh1OsEAHp01/7Md/lde7u2JKmY0mT /1qsW2mHD+7YtkqBTf9oGRvFXZOpXfjajo6Y4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IGyTID6mXtjgXneTwdkQkPQD8rCfXyUhlddaNs58XFfuXBPA/FiKyW6+QSUB19OUQc /otYDOrx2dGxqturqSw+M5bK1ItKeZ7Gd6yBlg5V14bUiFfSI3upPoFhWqJwnwKT03wU GSAS+JnpIUjkojchXTH/GuKhNTS8iSP0VRcnM= MIME-Version: 1.0 Received: by 10.204.57.80 with SMTP id b16mr82404bkh.85.1248208361115; Tue, 21 Jul 2009 13:32:41 -0700 (PDT) In-Reply-To: <4A6612A9.9020308@earthlink.net> References: <4A6596CD.9040404@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65F27E.5050301@cisco.com> <4A65F463.6010907@earthlink.net> <4A65F5E0.903@cisco.com> <4A65F83C.4090009@earthlink.net> <1726274c0907211021n7c0e2db3of321ded19bf6b5b2@mail.gmail.com> <4A660557.9080701@earthlink.net> <1726274c0907211134r15c3041er5626f4c91af3db8d@mail.gmail.com> <4A6612A9.9020308@earthlink.net> Date: Tue, 21 Jul 2009 17:32:41 -0300 Message-ID: <1726274c0907211332p4bd02b2dm9aa2639ca217d9ca@mail.gmail.com> From: Rafael Roque To: "Charles E. Perkins" Content-Type: multipart/alternative; boundary=001636c92412f852af046f3d273f Cc: autoconf@ietf.org Subject: Re: [Autoconf] Proposals for Prime DHCP and the buddy system of allocation X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 20:32:44 -0000 --001636c92412f852af046f3d273f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'm currently working on a new proposal that is similar to Prime by the use of distributed allocation function, and similar to buddy system by the good address space distribution. It could be difficult to do both works right now. But I thing that eliminating duplicate addresses could lead to changes in address model discussed here, don=92t you think? Ps.: I must say sorry for any misspelling words or expressions, since English is not my first language! Regards. R. Rafael. Charles wrote: > > Hello Rafael, > > Those protocols would definitely belong in a discussion > about eliminating duplicate addresses. Thanks for > sharing the citations. I think it is fair to say that the > work in [autoconf] should proceed without waiting > for standardization work to begin on these proposals. > As far as I know neither of these systems have seriously > been considered in any working group of the IETF before > now. I had suggested the buddy system for possible > consideration during the [autoconf] BOFs, and Prophet > is interesting but, at least for me at the time, had > robustness issues that I thought were not well understood. > Prime DHCP seems to be a useful refinement. > > Nevertheless, pushing these ideas into a Proposed > Standard or even Experimental RFC is more work > than I see anyone volunteering to do.... or, are > you volunteering? > > Regards, > Charlie P. > > > > Rafael Roque wrote: > >> Thanks for reply Charles. >> >> Charles E. Perkins wrote: >> >> >> >> Which existing allocation methods did you mean? >> >> >> >> There are some examples, like Prime DHCP < >> http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=3D01496591>, and Bud= dy >> System. >> Prime DHCP uses a distributed allocation function that assures unique >> number generation, while Buddy System splits address allocation space by >> half for each configuration process. >> >> >> Regards. >> R. Rafael. >> >> >> >> -- >> Rafael Roque Aschoff >> GPRT/UFPE >> >> > --=20 Rafael Roque Aschoff GPRT/UFPE --001636c92412f852af046f3d273f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'm currently working on a new proposal that is similar to Prim= e by the use of distributed allocation function, and similar to buddy syste= m by the good address space distribution.=A0 It could be difficult to do bo= th works right now.

But I thing that eliminating duplicate addresses could lead to changes = in address model discussed here, don=92t you think?

Ps.: I must say sorry for any misspelling words or expressions, since Engli= sh is not my first language!

Regards.
R. Rafael.

Charles wrote:
Hello Rafael,

Those protocols would definitely belong in a discussion
about eliminating duplicate addresses. =A0Thanks for
sharing the citations. =A0I think it is fair to say that the
work in [autoconf] should proceed without waiting
for standardization work to begin on these proposals.
As far as I know neither of these systems have seriously
been considered in any working group of the IETF before
now. =A0I had suggested the buddy system for possible
consideration during the [autoconf] BOFs, and Prophet
is interesting but, at least for me at the time, had
robustness issues that I thought were not well understood.
Prime DHCP seems to be a useful refinement.

Nevertheless, pushing these ideas into a Proposed
Standard or even Experimental RFC is more work
than I see anyone volunteering to do.... =A0or, are
you volunteering?

Regards,
Charlie P.



Rafael Roque wrote:
Thanks for reply Charles.

Charles E. Perkins wrote:



=A0 =A0Which existing allocation methods did you mean?



There are some examples, like Prime DHCP <http://ieeex= plore.ieee.org/stamp/stamp.jsp?arnumber=3D01496591>, and Buddy Syste= m. <http://www.utdallas.edu/%7Eravip/papers/milcom02.pdf>=
Prime DHCP uses a distributed allocation function that assures unique numbe= r generation, while Buddy System splits address allocation space by half fo= r each configuration process.


Regards.
R. Rafael.



--
Rafael Roque Aschoff
GPRT/UFPE





--
Rafael Roque AschoffGPRT/UFPE

--001636c92412f852af046f3d273f-- From alexandru.petrescu@gmail.com Tue Jul 21 15:04:29 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 556CF3A6EA5 for ; Tue, 21 Jul 2009 15:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.651 X-Spam-Level: X-Spam-Status: No, score=0.651 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7e+jZYz9DIwp for ; Tue, 21 Jul 2009 15:04:28 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 6CF203A6AC0 for ; Tue, 21 Jul 2009 15:04:26 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 85FD9D480E6; Wed, 22 Jul 2009 00:04:22 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 1BA6ED480C3; Wed, 22 Jul 2009 00:04:20 +0200 (CEST) Message-ID: <4A663B5D.9030107@gmail.com> Date: Wed, 22 Jul 2009 00:04:13 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> In-Reply-To: <4A65F192.3010801@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090721-0, 21/07/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 22:04:29 -0000 Charles E. Perkins a écrit : > > Hello Alex, > > Alexandru Petrescu wrote: >> >>>>> >>>> You have to know that the node _is_ a _neighbor_. That means >>>> within range and within range RIGHT NOW. How are you going to >>>> know that? >> >> By sending it an NS, it's standardized, it's NUD. > > And re-sending. And waiting for answers. I suppose that's the only way one can do when one is not sure a neighbor is present at an instant t. It's called NUD but if one doesn't like one couldn't design anything more intelligent than just wait for an answer. I don't see what you could suggest otherwise. You may see otherwise. Alex From charles.perkins@earthlink.net Tue Jul 21 15:38:54 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 875EC3A694C for ; Tue, 21 Jul 2009 15:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Glquj1GKrESH for ; Tue, 21 Jul 2009 15:38:53 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id B76AA3A67A3 for ; Tue, 21 Jul 2009 15:38:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=dqGy999TakFq+2CiR4w8qM8QKcWFskfH0OA1k+1wFXwBPZUyiCeGNWm/+0ngcwnU; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.13]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MTNz3-0002oJ-TZ; Tue, 21 Jul 2009 18:38:53 -0400 Message-ID: <4A66437A.2050307@earthlink.net> Date: Tue, 21 Jul 2009 15:38:50 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Alexandru Petrescu References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> In-Reply-To: <4A663B5D.9030107@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52e44dd36b879e28622fcdd5c5a2672306350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 22:38:54 -0000 Hello Alex, I'm not suggesting I can design a better NUD. I'm suggesting that we can do address autoconfiguration without having to do NUD. That is, we _can_. If you can design a better address autoconfiguration that uses NUD, that will be great. In the meantime, we want to have address autoconfiguration, without having to figure out how to do NUD (and, without having to wait to figure out how to do link-local addresses). In other words, addresses could be assigned whether or not a neighbor is still neighboring, or unreachable, or able to verify that it satisfies the necessary properties that have to be satisfied by link-local addresses. What I thought you were mandating is that we solve those problems before getting address autoconfiguration to work. My belief is that we don't have to. Regards, Charlie P. Alexandru Petrescu wrote: > Charles E. Perkins a écrit : >> >> Hello Alex, >> >> Alexandru Petrescu wrote: >>> >>>>>> >>>>> You have to know that the node _is_ a _neighbor_. That means >>>>> within range and within range RIGHT NOW. How are you going to >>>>> know that? >>> >>> By sending it an NS, it's standardized, it's NUD. >> >> And re-sending. And waiting for answers. > > I suppose that's the only way one can do when one is not sure a neighbor > is present at an instant t. It's called NUD but if one doesn't like one > couldn't design anything more intelligent than just wait for an answer. > > I don't see what you could suggest otherwise. You may see otherwise. > > Alex > > From roque.rafael@gmail.com Tue Jul 21 20:14:39 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 051D03A6BAA for ; Tue, 21 Jul 2009 20:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.783 X-Spam-Level: X-Spam-Status: No, score=-1.783 tagged_above=-999 required=5 tests=[AWL=0.515, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kScL03-0FBKN for ; Tue, 21 Jul 2009 20:14:38 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 15F793A6B1B for ; Tue, 21 Jul 2009 20:14:37 -0700 (PDT) Received: by fxm18 with SMTP id 18so2987343fxm.37 for ; Tue, 21 Jul 2009 20:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=PONbEEo91lK3X8qx7Ez3q0KaOsUVdge/RfFoMi3i+b8=; b=aZS5mWzf8CoxEJ1SON5KI9VhY3J/4Ax6jjaRvfJNHYT0nuhgdL2F/pMyOFDFfgM34C saUSNIs+L3bG0OgP4wmbwvTVIcEzMD/xScd2EAaxJuPz/MqTTOlgcWWuCxQE60rooK3F mB071glzqjzKqlZhSUo0pyZSVt1P3bo1iq1YI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rxwUoVlRPLb3uBUlgB09hS/+j70oYuPONIKpVIIdVQOfbZnVYRtGG6tPnxeboqtUvm ockpgb8TwGcexHdd2a0Z4xfoaUd3r7oTgHPWjB+QVlEGE56ZH7aOlTExw2//1mAuChnN syEaChNKK95Bhil8OXPgUXZekyRyBYght6GaQ= MIME-Version: 1.0 Received: by 10.204.63.8 with SMTP id z8mr376223bkh.55.1248232475229; Tue, 21 Jul 2009 20:14:35 -0700 (PDT) In-Reply-To: <4A66437A.2050307@earthlink.net> References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> Date: Wed, 22 Jul 2009 00:14:35 -0300 Message-ID: <1726274c0907212014s7d08fd6cj262eb3891839f6da@mail.gmail.com> From: Rafael Roque To: "Charles E. Perkins" Content-Type: multipart/alternative; boundary=001636c5b7e4487eac046f42c543 Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 03:14:39 -0000 --001636c5b7e4487eac046f42c543 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Charles wrote: > > In other words, addresses could be assigned whether or > not a neighbor is still neighboring, or unreachable, or able > to verify that it satisfies the necessary properties that have > to be satisfied by link-local addresses. I think i have misunderstood something but, if there are no neighbours, there is no need for addresses too, since the node cannot communicate to anyone! Anyway, this kind of address assign is clearly going into stateless direction, where no network knowledge is need, even neighborhood. This is the idea? -- Rafael Roque Aschoff GPRT/UFPE --001636c5b7e4487eac046f42c543 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Charles wrote:

In other words, addresses could be assigned whether or
not a neighbor is still neighboring, or unreachable, or able
to verify that it satisfies the necessary properties that have
to be satisfied by link-local addresses.

I think i have misunderstood something but, if there are no neighbours, there is no need for addresses too, since the node cannot communicate to anyone!

Anyway, this kind of address assign is clearly going into stateless direction, where no network knowledge is need, even neighborhood. This is the idea?


--
Rafael Roque Aschoff
GPRT/UFPE

--001636c5b7e4487eac046f42c543-- From charles.perkins@earthlink.net Tue Jul 21 21:32:29 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72D7A3A68AA for ; Tue, 21 Jul 2009 21:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMoTSnOPDUyb for ; Tue, 21 Jul 2009 21:32:28 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 9CD783A67A1 for ; Tue, 21 Jul 2009 21:32:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=W7iKaRZqcR006++EtOkESlLWbT13ntWD0ngo7Dtiq+IxpFYoio4PqEKHUrOwS6aJ; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.74.16] (helo=[192.168.1.105]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MTTVE-0005BR-Ig; Wed, 22 Jul 2009 00:32:28 -0400 Message-ID: <4A669650.6050605@earthlink.net> Date: Tue, 21 Jul 2009 21:32:16 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Rafael Roque References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> <1726274c0907212014s7d08fd6cj262eb3891839f6da@mail.gmail.com> In-Reply-To: <1726274c0907212014s7d08fd6cj262eb3891839f6da@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52008084e7fa452788385abd66310c16c6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 04:32:29 -0000 Hello Rafael, I did not mean to imply stateless. Rafael Roque wrote: > > Charles wrote: > > > In other words, addresses could be assigned whether or > not a neighbor is still neighboring, or unreachable, or able > to verify that it satisfies the necessary properties that have > to be satisfied by link-local addresses. > > > I think i have misunderstood something but, if there are no > neighbours, there is no need for addresses too, since the node cannot > communicate to anyone! Here, I meant that a node which had been known to be a neighbor may not really be a neighbor any longer. I didn't mean to say that there weren't any neighbors! With no neighbors, a node is pretty much guaranteed that its autoconfigured address will be unique in its connected domain. > > Anyway, this kind of address assign is clearly going into stateless > direction, where no network knowledge is need, even neighborhood. This > is the idea? No, sorry for using such imprecise language. The idea is to maintain enough state to get the job done, but to minimize the amount of state that has to be kept. At least that is one idea -- as you can see, there are many competing ideas. Regards, Charlie P. From alexandru.petrescu@gmail.com Wed Jul 22 03:05:47 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 194FB28C22D for ; Wed, 22 Jul 2009 03:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1-Z9lCsB3AG for ; Wed, 22 Jul 2009 03:05:46 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 1D9933A6A58 for ; Wed, 22 Jul 2009 03:05:45 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6MA4HUU012652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Jul 2009 12:04:17 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6MA4Go6026948; Wed, 22 Jul 2009 12:04:17 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6MA4GQg015669; Wed, 22 Jul 2009 12:04:16 +0200 Message-ID: <4A66E420.8040604@gmail.com> Date: Wed, 22 Jul 2009 12:04:16 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> In-Reply-To: <4A66437A.2050307@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 10:05:47 -0000 Charles E. Perkins a écrit : > > Hello Alex, > > I'm not suggesting I can design a better NUD. > > I'm suggesting that we can do address autoconfiguration without > having to do NUD. That is, we _can_. If you can design a > better address autoconfiguration that uses NUD, that will be > great. In the meantime, we want to have address autoconfiguration, > without having to figure out how to do NUD (and, without > having to wait to figure out how to do link-local addresses). > > In other words, addresses could be assigned whether or > not a neighbor is still neighboring, or unreachable, or able > to verify that it satisfies the necessary properties that have > to be satisfied by link-local addresses. Sounds as if we decouple de necessity to do DAD and NUD (Neighbor Unreachability Detection) from the use of IPv6 link-local addresses then we could be free to let nodes configure IPv6 link-local addresses, as part of the AUTOCONF IPv6 practical addressing model. And state so in the draft(?) Alex From emmanuel.baccelli@gmail.com Wed Jul 22 04:19:52 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D14633A6A39 for ; Wed, 22 Jul 2009 04:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhtQ+xNFzFAh for ; Wed, 22 Jul 2009 04:19:52 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 981803A67D8 for ; Wed, 22 Jul 2009 04:19:51 -0700 (PDT) Received: by fxm18 with SMTP id 18so110661fxm.37 for ; Wed, 22 Jul 2009 04:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to :content-type; bh=PpMgHgIC5syrjsUUGrtXZFAep1E/kETNP5cT/NT8kqY=; b=FhbeGC6/HPYj7Ei4tw8G7gYctG70ZH6K+Hm7KVHz091mE+s1PUbYupBUUQwLhmosSW qhKqTcK8cZNYCOTjFhn2nyBPZJIqQI5RdYomQ8/EJFrCyLhhgXhSOi6LB9WYaT7VP6nl 9+5hiptYjr96gZfCrzPyFNlCLqZiEFMsD8ZZI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=HpeSBsKA1cjlntpJFs1Ato26EkJxUAaoiVdfWNEGnM14xK24aiClEBwJrvC3ElYwND 8nAp0twEyNN5edkOe0r62fXnxhe8fxFyOqf8rc4dbDXH8npGHjDxxe9o38wscsS3sfAb NqIKcHjl/Q4uh0oTo7+h0dTpti0Iqb07gGaJE= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.103.160.9 with SMTP id m9mr398130muo.96.1248261541092; Wed, 22 Jul 2009 04:19:01 -0700 (PDT) In-Reply-To: <4A66E420.8040604@gmail.com> References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> <4A66E420.8040604@gmail.com> From: Emmanuel Baccelli Date: Wed, 22 Jul 2009 13:18:41 +0200 X-Google-Sender-Auth: 0247a7cdc1f67ce4 Message-ID: To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=0016e65b41a0be66a4046f498912 Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 11:19:52 -0000 --0016e65b41a0be66a4046f498912 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Alex, On Wed, Jul 22, 2009 at 12:04 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > > >> I'm not suggesting I can design a better NUD. >> >> I'm suggesting that we can do address autoconfiguration without >> having to do NUD. That is, we _can_. If you can design a >> better address autoconfiguration that uses NUD, that will be >> great. In the meantime, we want to have address autoconfiguration, >> without having to figure out how to do NUD (and, without >> having to wait to figure out how to do link-local addresses). >> >> In other words, addresses could be assigned whether or >> not a neighbor is still neighboring, or unreachable, or able >> to verify that it satisfies the necessary properties that have >> to be satisfied by link-local addresses. >> > > Sounds as if we decouple de necessity to do DAD and NUD (Neighbor > Unreachability Detection) from the use of IPv6 link-local addresses then we > could be free to let nodes configure IPv6 link-local addresses, as part of > the AUTOCONF IPv6 practical addressing model. > > And state so in the draft(?) > Wouldn't that go a little too far in the solution space, for this particular document? This document is not supposed to propose an autoconfiguration solution... Emmanuel --0016e65b41a0be66a4046f498912 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alex,

On Wed, Jul 22, 2009 at 12:04 PM= , Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:

I'm not suggesting I can design a better NUD.

I'm suggesting that we can do address autoconfiguration without
having to do NUD. =A0That is, we _can_. =A0If you can design a
better address autoconfiguration that uses NUD, that will be
great. =A0In the meantime, we want to have address autoconfiguration,
without having to figure out how to do NUD (and, without
having to wait to figure out how to do link-local addresses).

In other words, addresses could be assigned whether or
not a neighbor is still neighboring, or unreachable, or able
to verify that it satisfies the necessary properties that have
to be satisfied by link-local addresses.

Sounds as if we decouple de necessity to do DAD and NUD (Neighbor Unreachab= ility Detection) from the use of IPv6 link-local addresses then we could be= free to let nodes configure IPv6 link-local addresses, as part of the AUTO= CONF IPv6 practical addressing model.

And state so in the draft(?)
<= /blockquote>


Wouldn't that go a littl= e too far in the solution space, for this particular document? This documen= t is not supposed to propose an autoconfiguration solution...


Emmanuel=A0
--0016e65b41a0be66a4046f498912-- From alexandru.petrescu@gmail.com Wed Jul 22 06:12:45 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEEA23A69C6 for ; Wed, 22 Jul 2009 06:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.438 X-Spam-Level: X-Spam-Status: No, score=-1.438 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGjGQC1vi78U for ; Wed, 22 Jul 2009 06:12:45 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id D9C263A6904 for ; Wed, 22 Jul 2009 06:12:44 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6MCe6n4025205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Jul 2009 14:40:06 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6MCe6xw024670; Wed, 22 Jul 2009 14:40:06 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6MCe54A022866; Wed, 22 Jul 2009 14:40:06 +0200 Message-ID: <4A6708A5.8090501@gmail.com> Date: Wed, 22 Jul 2009 14:40:05 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Emmanuel Baccelli References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> <4A66E420.8040604@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 13:12:46 -0000 Hi Emmanuel, Emmanuel Baccelli a écrit : > Hi Alex, > > On Wed, Jul 22, 2009 at 12:04 PM, Alexandru Petrescu > > wrote: > > > I'm not suggesting I can design a better NUD. > > I'm suggesting that we can do address autoconfiguration without > having to do NUD. That is, we _can_. If you can design a > better address autoconfiguration that uses NUD, that will be > great. In the meantime, we want to have address autoconfiguration, > without having to figure out how to do NUD (and, without > having to wait to figure out how to do link-local addresses). > > In other words, addresses could be assigned whether or > not a neighbor is still neighboring, or unreachable, or able > to verify that it satisfies the necessary properties that have > to be satisfied by link-local addresses. > > > Sounds as if we decouple de necessity to do DAD and NUD (Neighbor > Unreachability Detection) from the use of IPv6 link-local addresses > then we could be free to let nodes configure IPv6 link-local > addresses, as part of the AUTOCONF IPv6 practical addressing model. > > And state so in the draft(?) > > > > Wouldn't that go a little too far in the solution space, for this > particular document? This document is not supposed to propose an > autoconfiguration solution... But isn't it incomprehensible to read about links with unknown connectivity properties? Maybe recommending IPv6 link-local addresses without DAD and without NUD would sound more comprehensible. The draft already makes a few very strong recommendations in forbidding the use of prefixes different than /128 which I find also too far in the solution space. Alex > > > Emmanuel > > > ------------------------------------------------------------------------ > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From alexandru.petrescu@gmail.com Wed Jul 22 07:41:59 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA71428C164 for ; Wed, 22 Jul 2009 07:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.627 X-Spam-Level: X-Spam-Status: No, score=-1.627 tagged_above=-999 required=5 tests=[AWL=0.622, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgUAPGZOAYpU for ; Wed, 22 Jul 2009 07:41:59 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id BC64928C104 for ; Wed, 22 Jul 2009 07:41:58 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6MEdIGn022252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 22 Jul 2009 16:39:18 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6MEdIJ2024663 for ; Wed, 22 Jul 2009 16:39:18 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6MEdH61028627 for ; Wed, 22 Jul 2009 16:39:18 +0200 Message-ID: <4A672495.3040508@gmail.com> Date: Wed, 22 Jul 2009 16:39:17 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: autoconf@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Autoconf] Mandatory /128 prefix length forbids the use of IPv6 link-local addresses? X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 14:42:00 -0000 Mandatory /128 prefix length forbids the use of IPv6 link-local addresses? The current DT draft says: > 6.2. IPv6 Model > > > For IPv6, the principles described in Section 4 and Section 5 > translate as such: > > o An IP address configured on this interface should be unique, at > least within the routing domain, and > > o A subnet prefix configured on this interface should be of length > /128. > [section 6.2 ends here] IPv6 link-local addresses have a prefix /64 in implementations and /10 in the specs. Does this mean that the section 6.2 effectively forbids the use of IPv6 link-local addresses? Alex From alexandru.petrescu@gmail.com Wed Jul 22 08:11:35 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CA5A3A696C for ; Wed, 22 Jul 2009 08:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.522 X-Spam-Level: X-Spam-Status: No, score=-1.522 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXwCi4j+w1zE for ; Wed, 22 Jul 2009 08:11:34 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id CEF043A6882 for ; Wed, 22 Jul 2009 08:11:33 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6MF90em013061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Jul 2009 17:09:00 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6MF90oG030369; Wed, 22 Jul 2009 17:09:00 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6MF8wjo017547; Wed, 22 Jul 2009 17:09:00 +0200 Message-ID: <4A672B8A.5000200@gmail.com> Date: Wed, 22 Jul 2009 17:08:58 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> <4A66E420.8040604@gmail.com> <4A672731.9040009@earthlink.net> In-Reply-To: <4A672731.9040009@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 15:11:35 -0000 Charles E. Perkins a écrit : > > Hello Alex, > > Alexandru Petrescu wrote: >> >>> >>> In other words, addresses could be assigned whether or not a >>> neighbor is still neighboring, or unreachable, or able to verify >>> that it satisfies the necessary properties that have to be >>> satisfied by link-local addresses. >> >> Sounds as if we decouple de necessity to do DAD and NUD (Neighbor >> Unreachability Detection) from the use of IPv6 link-local addresses >> then we could be free to let nodes configure IPv6 link-local >> addresses, as part of the AUTOCONF IPv6 practical addressing model. >> > > If DAD and NUD are unsuitable for working with mobile devices, then > perhaps they should not be required for establishing the > characteristics of link-local addresses. > > But that's not really the relevant point. So far, I didn't see > consensus for any broadly applicable procedure for establishing > link-local addresses, regardless of DAD and NUD. Until you can show > that, I think the document cannot mandate the use of link-local > addresses. The document also does not prohibit their use. Hello Charlie, I don't see what you mean by lack of consensus on a broadly applicable procedure for establishing link-local addresses, but the way the IPv6 link-local addresses are formed is standardized, there is consensus, it's a broadly applicable procedure. There are only a _few_ links on which there is no consensus, counted on one hand's fingers, and they're not MANET-like. >> And state so in the draft(?) > > What, exactly, is it that you want to see stated? Can you provide > text? I would suggest text in section 6.2 IPv6 addressing model: Old: > 6.2. IPv6 Model > > > For IPv6, the principles described in Section 4 and Section 5 > translate as such: > > o An IP address configured on this interface should be unique, at > least within the routing domain, and > > o A subnet prefix configured on this interface should be of length > /128. New: > 6.2. IPv6 Model > > > For IPv6, the principles described in Section 4 and Section 5 > translate partially as follows: > > o An ad-hoc network node self-forms an IPv6 link-local address for > each of its interfaces. The procedure is described in the > document relevant to the interface type. For example, a WiFi > interface should use RFC2464; for a PPP link see RFC5072. For a > more exhaustive list of links see RFCXXXX. > > o An IP address configured on this interface should be unique, at > least within the routing domain, and > > o A subnet prefix configured on this interface should be of length > /128 (except, of course, the IPv6 link-local addresses whose > prefix is /10). What do you think about this suggested modification? Alex > > Regards, Charlie P. > > From alexandru.petrescu@gmail.com Wed Jul 22 08:19:31 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6202D3A6882 for ; Wed, 22 Jul 2009 08:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxIclRRxTM4y for ; Wed, 22 Jul 2009 08:19:30 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 652673A67EA for ; Wed, 22 Jul 2009 08:19:30 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6MEXaEf028110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Jul 2009 16:33:36 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6MEXaq9023439; Wed, 22 Jul 2009 16:33:36 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6MEXZcM008251; Wed, 22 Jul 2009 16:33:36 +0200 Message-ID: <4A67233E.3010808@gmail.com> Date: Wed, 22 Jul 2009 16:33:34 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Teco Boot References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> <4A66E420.8040604@gmail.com> <4A6708A5.8090501@gmail.com> <005301ca0ad6$ae7961b0$0b6c2510$@nl> In-Reply-To: <005301ca0ad6$ae7961b0$0b6c2510$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, 'Emmanuel Baccelli' Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 15:19:31 -0000 Teco Boot a écrit : > Can one explain the relation between link-locals and DAD/NUD? > DAD/NUD should run on any address. And may be disabled. I agree. And in this sense, DAD and NUD couldn't be an argument to deter the use of IPv6 link-local addresses. Alex From teco@inf-net.nl Wed Jul 22 09:02:18 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2C573A68F6 for ; Wed, 22 Jul 2009 09:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.655 X-Spam-Level: X-Spam-Status: No, score=0.655 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bd3X1PIdAhqv for ; Wed, 22 Jul 2009 09:02:18 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id AE26A3A6ACC for ; Wed, 22 Jul 2009 09:02:17 -0700 (PDT) Received: (qmail 2929 invoked from network); 22 Jul 2009 16:14:19 +0200 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 22 Jul 2009 16:14:19 +0200 From: "Teco Boot" To: "'Alexandru Petrescu'" , "'Emmanuel Baccelli'" References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> <4A66E420.8040604@gmail.com> <4A6708A5.8090501@gmail.com> In-Reply-To: <4A6708A5.8090501@gmail.com> Date: Wed, 22 Jul 2009 16:13:39 +0200 Message-ID: <005301ca0ad6$ae7961b0$0b6c2510$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoKzh43i4qxrvohQNSlJR0vhTzXKwACDh+g Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 16:02:18 -0000 Can one explain the relation between link-locals and DAD/NUD? DAD/NUD should run on any address. And may be disabled. Teco. From charles.perkins@earthlink.net Wed Jul 22 09:46:50 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5B8328C164 for ; Wed, 22 Jul 2009 09:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpDGe-tmc38q for ; Wed, 22 Jul 2009 09:46:50 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id CE7C93A6AE6 for ; Wed, 22 Jul 2009 09:46:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=YKT6fnh9Qrb0hQWtjPYZqFKMJaeVV4Fu3illK6HxfEsqpujiJSRrEprHD7fJ6aFq; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.12]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MTeRj-0005uU-Ad; Wed, 22 Jul 2009 12:13:35 -0400 Message-ID: <4A673AAB.2040704@earthlink.net> Date: Wed, 22 Jul 2009 09:13:31 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Alexandru Petrescu References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> <4A66E420.8040604@gmail.com> <4A6708A5.8090501@gmail.com> <005301ca0ad6$ae7961b0$0b6c2510$@nl> <4A67233E.3010808@gmail.com> In-Reply-To: <4A67233E.3010808@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f529dd061c924460080071aef3cc38d8e46350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org, 'Emmanuel Baccelli' Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 16:46:50 -0000 Hello folks, I wasn't the one who brought up DAD and NUD in the first place. And I didn't use them as an argument to deter the use of link-locals. On the other hand, I did post the following: > I was part of the discussion on this point. Quoting some > previous email: > >> >> >>> |> => you can presumably always communicate with neighbor using >>> |> => link-local addresses. >>> | >>> |Yes, of course, once it is known that a node is a neighbor. >>> >>> >> You have to know that >> the node _is_ a _neighbor_. That means within range >> and within range RIGHT NOW. How are you going to >> know that? How are you going to invalidate the >> link-local address as soon as _any_ other node >> becomes a new neighbor of the node? > > I am myself in favor of enabling the use of link-local > addresses, once these questions are answered. Please note the last sentence. And before alleging some shadowy "deterrence" that would prevent the use of link-locals, please exhibit your solution for insuring uniqueness in an environment where mobility is the rule (not the exception). Be recent discussion, waving hands in air and exclaiming "DAD" or "NUD" does not count as a solution. Regards, Charlie P. Alexandru Petrescu wrote: > Teco Boot a écrit : >> Can one explain the relation between link-locals and DAD/NUD? >> DAD/NUD should run on any address. And may be disabled. > > I agree. And in this sense, DAD and NUD couldn't be an argument to > deter the use of IPv6 link-local addresses. > > Alex > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > > From charles.perkins@earthlink.net Wed Jul 22 09:55:52 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAE3F3A6877 for ; Wed, 22 Jul 2009 09:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqQsIbXnC84I for ; Wed, 22 Jul 2009 09:55:52 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id D2BCF3A6B4C for ; Wed, 22 Jul 2009 09:55:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=N3LqubANI59RhCG0yPSenh6tnE32YFl4PY52cFYJY2rmWtIJb4eNCS2FpkE3taCb; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.12]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MTejN-0006ak-89; Wed, 22 Jul 2009 12:31:49 -0400 Message-ID: <4A673EF1.1020706@earthlink.net> Date: Wed, 22 Jul 2009 09:31:45 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Alexandru Petrescu References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> <4A66E420.8040604@gmail.com> <4A672731.9040009@earthlink.net> <4A672B8A.5000200@gmail.com> In-Reply-To: <4A672B8A.5000200@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52aece98c99d1a2b0b911de3b32d72e0fe350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 16:55:52 -0000 Hello Alex, Alexandru Petrescu wrote: > > > I don't see what you mean by lack of consensus on a broadly applicable > procedure for establishing link-local addresses, but the way the IPv6 > link-local addresses are formed is standardized, there is consensus, > it's a broadly applicable procedure. There are only a _few_ links on > which there is no consensus, counted on one hand's fingers, and > they're not MANET-like. We have a standard for transforming a MAC address to an IPv6 address on a wire -- in other words, on a physical medium where the range of physical packet transmission is well delimited. But, see below... > > > New: >> 6.2. IPv6 Model >> >> >> For IPv6, the principles described in Section 4 and Section 5 >> translate partially as follows: >> >> o An ad-hoc network node self-forms an IPv6 link-local address for >> each of its interfaces. The procedure is described in the >> document relevant to the interface type. For example, a WiFi >> interface should use RFC2464; for a PPP link see RFC5072. For a >> more exhaustive list of links see RFCXXXX. I would disagree with including this text, until someone can demonstrate the generally applicable solution that resolves the following issues that I have previously raised: > > You have to know that > > the node _is_ a _neighbor_. That means within range > > and within range RIGHT NOW. How are you going to > > know that? How are you going to invalidate the > > link-local address as soon as _any_ other node > > becomes a new neighbor of the node? > > I am myself in favor of enabling the use of link-local > addresses, once these questions are answered. Your text ignores the need for resolving these issues, and would create a mandate for something that (a) may be infeasible and (b) is not needed for a successful autoconfiguraiton protocol. > > What do you think about this suggested modification? I think it ignores the issues that have been under discussion for years now. Therefore, I would oppose the inclusion of that text. Regards, Charlie P. From sratliff@cisco.com Wed Jul 22 10:09:51 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A11353A6897 for ; Wed, 22 Jul 2009 10:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.683 X-Spam-Level: X-Spam-Status: No, score=-5.683 tagged_above=-999 required=5 tests=[AWL=0.616, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXxZyVwelOPn for ; Wed, 22 Jul 2009 10:09:50 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 803EF3A6827 for ; Wed, 22 Jul 2009 10:09:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFHkZkpAZnmf/2dsb2JhbAC7N4glkRAFhA6BRA X-IronPort-AV: E=Sophos;i="4.43,247,1246838400"; d="scan'208";a="51413217" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 22 Jul 2009 17:08:31 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6MH8VkD010429; Wed, 22 Jul 2009 13:08:31 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6MH8VAt006596; Wed, 22 Jul 2009 17:08:31 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 13:08:30 -0400 Received: from [64.102.54.37] ([64.102.54.37]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 13:08:30 -0400 Message-ID: <4A67478E.1030106@cisco.com> Date: Wed, 22 Jul 2009 13:08:30 -0400 From: Stan Ratliff User-Agent: Thunderbird 1.5.0.12 (X11/20080131) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> <4A66E420.8040604@gmail.com> <4A6708A5.8090501@gmail.com> <005301ca0ad6$ae7961b0$0b6c2510$@nl> <4A67233E.3010808@gmail.com> <4A673AAB.2040704@earthlink.net> In-Reply-To: <4A673AAB.2040704@earthlink.net> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 22 Jul 2009 17:08:30.0756 (UTC) FILETIME=[0992D640:01CA0AEF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2720; t=1248282511; x=1249146511; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20Stan=20Ratliff=20 |Subject:=20Re=3A=20[Autoconf]=20Link-locals=20=3D?ISO-8859 -1?Q?vis-=3DE0-vis_the_ne?=3D=0A=20=3D?ISO-8859-1?Q?w_=3D5Ba utoconf=3D5D_document?=3D |Sender:=20 |To:=20=22Charles=20E.=20Perkins=22=20; bh=JQfmkUuMTC/LmYxvdJ71H9irvuQjk2J2Cj/+lJDvweM=; b=xvpZd7ae+EoM5ucA1JCs1JgtKAHWOK30Z1MKV5QhV84XuY7xtgIUg6bij3 E/Bgh1imxbI8yCay9U8WxrEVBSG2Tr2nh9mCG5WIyPEWU59Yk82bYKG57npo QdkM79JLmz; Authentication-Results: rtp-dkim-2; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: autoconf@ietf.org, 'Emmanuel Baccelli' Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 17:09:51 -0000 Charlie, I take full responsibility for kicking this snowball off the side of the mountain -- my bad. :-( I'm in *full* agreement with you. We shouldn't let ourselves get side-tracked with this discussion, and I hereby present myself for verbal flogging for having brought it up in the first place... ;-) We can make good progress without solving this issue right here and now. We should take some time and collectively think about the evils of duplicate addresses and how to attack the problem, but that shouldn't stop us from making what progress we can. For now, I'm satisfied with the notion of using /32 prefixes for V4, /128 for V6, and the caveat "Duplicate addresses hurt *very* bad, so don't do it!" Regards, Stan Charles E. Perkins wrote: > > Hello folks, > > I wasn't the one who brought up DAD and NUD in the > first place. And I didn't use them as an argument to > deter the use of link-locals. > > On the other hand, I did post the following: > >> I was part of the discussion on this point. Quoting some >> previous email: >> >>> >>> >>>> |> => you can presumably always communicate with neighbor using >>>> |> => link-local addresses. >>>> | >>>> |Yes, of course, once it is known that a node is a neighbor. >>>> >>>> >>> You have to know that >>> the node _is_ a _neighbor_. That means within range >>> and within range RIGHT NOW. How are you going to >>> know that? How are you going to invalidate the >>> link-local address as soon as _any_ other node >>> becomes a new neighbor of the node? >> >> I am myself in favor of enabling the use of link-local >> addresses, once these questions are answered. > > Please note the last sentence. > > And before alleging some shadowy "deterrence" that would > prevent the use of link-locals, please exhibit your solution for > insuring uniqueness in an environment where mobility is > the rule (not the exception). Be recent discussion, waving > hands in air and exclaiming "DAD" or "NUD" does not > count as a solution. > > Regards, > Charlie P. > > > Alexandru Petrescu wrote: >> Teco Boot a écrit : >>> Can one explain the relation between link-locals and DAD/NUD? >>> DAD/NUD should run on any address. And may be disabled. >> >> I agree. And in this sense, DAD and NUD couldn't be an argument to >> deter the use of IPv6 link-local addresses. >> >> Alex >> >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >> >> > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From alexandru.petrescu@gmail.com Wed Jul 22 11:25:43 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 602BF3A685B for ; Wed, 22 Jul 2009 11:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWZgSqMJVynk for ; Wed, 22 Jul 2009 11:25:42 -0700 (PDT) Received: from smtpfb1-g21.free.fr (smtpfb1-g21.free.fr [212.27.42.9]) by core3.amsl.com (Postfix) with ESMTP id 327B93A6891 for ; Wed, 22 Jul 2009 11:25:40 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by smtpfb1-g21.free.fr (Postfix) with ESMTP id 4977A2E2BA for ; Wed, 22 Jul 2009 20:05:45 +0200 (CEST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id AA024D48127; Wed, 22 Jul 2009 20:00:21 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 7E53ED4813B; Wed, 22 Jul 2009 20:00:18 +0200 (CEST) Message-ID: <4A6753B2.9040109@gmail.com> Date: Wed, 22 Jul 2009 20:00:18 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> <4A66E420.8040604@gmail.com> <4A672731.9040009@earthlink.net> <4A672B8A.5000200@gmail.com> <4A673EF1.1020706@earthlink.net> In-Reply-To: <4A673EF1.1020706@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090722-0, 22/07/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 18:25:43 -0000 Charles E. Perkins a écrit : > > Hello Alex, > > Alexandru Petrescu wrote: >> >> >> I don't see what you mean by lack of consensus on a broadly >> applicable procedure for establishing link-local addresses, but the >> way the IPv6 link-local addresses are formed is standardized, there >> is consensus, it's a broadly applicable procedure. There are only >> a _few_ links on which there is no consensus, counted on one hand's >> fingers, and they're not MANET-like. > > We have a standard for transforming a MAC address to an IPv6 address > on a wire -- in other words, on a physical medium where the range of > physical packet transmission is well delimited. But, see below... >> >> >> New: >>> 6.2. IPv6 Model >>> >>> >>> For IPv6, the principles described in Section 4 and Section 5 >>> translate partially as follows: >>> >>> o An ad-hoc network node self-forms an IPv6 link-local address >>> for each of its interfaces. The procedure is described in the >>> document relevant to the interface type. For example, a WiFi >>> interface should use RFC2464; for a PPP link see RFC5072. For a >>> more exhaustive list of links see RFCXXXX. > > I would disagree with including this text, until someone can > demonstrate the generally applicable solution that resolves the > following issues that I have previously raised: > >>> You have to know that the node _is_ a _neighbor_. That means >>> within range and within range RIGHT NOW. How are you going to >>> know that? How are you going to invalidate the link-local >>> address as soon as _any_ other node becomes a new neighbor of the >>> node? >> >> I am myself in favor of enabling the use of link-local addresses, >> once these questions are answered. > > Your text ignores the need for resolving these issues, and would > create a mandate for something that (a) may be infeasible and (b) is > not needed for a successful autoconfiguraiton protocol. Charlie, ok, my suggestion for nodes to self-form IPv6 link-local addresses ignores the fuziness issue of neighborhood of links with undetermined connectivity characteristics. But requesting to configure a /128 on an interface instead of any other length isn't a solution to that issue either. I mean, if the prefix is /128 it does not mean that its neighbor is in range RIGHT NOW. These two things (/128 and and neighborness) have nothing to do with each other, one doesn't imply the other. The worse part is that this requirement of /128 - a real straw man argument - implies forbidding the use of link-local addresses which are /64 or /10. (I suppose the initial presence of 'straw man' in the title wasn't such intention, but it seems to turn out exactly that way - a strawman argumentation). I think we have very different views on this particular topic... Alex From charles.perkins@earthlink.net Wed Jul 22 11:45:55 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2341B3A6861 for ; Wed, 22 Jul 2009 11:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiGm5JFFQH0U for ; Wed, 22 Jul 2009 11:45:54 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 6C8BA3A69F3 for ; Wed, 22 Jul 2009 11:45:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=muxVnj0kIQeiv7HqX5o9qTQG7ezzIEGvSqKDl9TwJZlpaPYIR8ljUeETGJddddOt; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.74.16] (helo=[192.168.1.105]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MTd9I-0001YZ-Ml; Wed, 22 Jul 2009 10:50:28 -0400 Message-ID: <4A672731.9040009@earthlink.net> Date: Wed, 22 Jul 2009 07:50:25 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Alexandru Petrescu References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> <4A66E420.8040604@gmail.com> In-Reply-To: <4A66E420.8040604@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52f49aa947af7b907fbf768a4d6d6589d2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 18:45:55 -0000 Hello Alex, Alexandru Petrescu wrote: > >> >> In other words, addresses could be assigned whether or >> not a neighbor is still neighboring, or unreachable, or able >> to verify that it satisfies the necessary properties that have >> to be satisfied by link-local addresses. > > Sounds as if we decouple de necessity to do DAD and NUD (Neighbor > Unreachability Detection) from the use of IPv6 link-local addresses > then we could be free to let nodes configure IPv6 link-local > addresses, as part of the AUTOCONF IPv6 practical addressing model. If DAD and NUD are unsuitable for working with mobile devices, then perhaps they should not be required for establishing the characteristics of link-local addresses. But that's not really the relevant point. So far, I didn't see consensus for any broadly applicable procedure for establishing link-local addresses, regardless of DAD and NUD. Until you can show that, I think the document cannot mandate the use of link-local addresses. The document also does not prohibit their use. > And state so in the draft(?) What, exactly, is it that you want to see stated? Can you provide text? Regards, Charlie P. From charles.perkins@earthlink.net Wed Jul 22 11:58:22 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 839003A6B78 for ; Wed, 22 Jul 2009 11:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDPKgUdE6C1d for ; Wed, 22 Jul 2009 11:58:21 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id B92CE3A693F for ; Wed, 22 Jul 2009 11:58:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=GMLheRMI+oujHXjCE3LSvH386y61SdfkCDComaNofj1lk3vRpBRJG2zdJ4zw0QQU; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[192.168.1.102]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MTh0K-0001zb-Tk; Wed, 22 Jul 2009 14:57:29 -0400 Message-ID: <4A676115.8060202@earthlink.net> Date: Wed, 22 Jul 2009 11:57:25 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Alexandru Petrescu References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> <4A66E420.8040604@gmail.com> <4A672731.9040009@earthlink.net> <4A672B8A.5000200@gmail.com> <4A673EF1.1020706@earthlink.net> <4A6753B2.9040109@gmail.com> In-Reply-To: <4A6753B2.9040109@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52c5fab2ec36e792d4fffeb5c79d16cf61350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 18:58:22 -0000 Hello Alex, Alexandru Petrescu wrote: >> >> Your text ignores the need for resolving these issues, and would >> create a mandate for something that (a) may be infeasible and (b) is >> not needed for a successful autoconfiguraiton protocol. > > Charlie, ok, my suggestion for nodes to self-form IPv6 link-local > addresses ignores the fuziness issue of neighborhood of links with > undetermined connectivity characteristics. O.K. > But requesting to configure a /128 on an interface instead of any > other length isn't a solution to that issue either. Using this model of configuration, it is known that solutions can be developed. > > I mean, if the prefix is /128 it does not mean that its neighbor is in > range RIGHT NOW. These two things (/128 and and neighborness) have > nothing to do with each other, one doesn't imply the other. Right. > > The worse part is that this requirement of /128 - a real straw man > argument - implies forbidding the use of link-local addresses which > are /64 or /10. No, it does not. The document explains that we recommend use of the long prefixes unless you can somehow avoid the problems. If you can show how to avoid the problems, you should contribute a better document. Until then, it is not reasonable to have a working group document that mandates something we don't necessarily know how to do. Citing the acronyms DAD and UDP does not constitute proposing a solution. > (I suppose the initial presence of 'straw man' in the title wasn't > such intention, but it seems to turn out exactly that way - a strawman > argumentation). I know what a straw man argument is, and I don't recogize it in the document's use of /128. Or, ... what did you mean??? > > I think we have very different views on this particular topic... That is why we have mailing lists -- to discuss technical matters and arrive at resolutions. Regards, Charlie P. From alexandru.petrescu@gmail.com Wed Jul 22 12:32:47 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB3903A6C32 for ; Wed, 22 Jul 2009 12:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VF0eK+VHxSK2 for ; Wed, 22 Jul 2009 12:32:47 -0700 (PDT) Received: from smtpfb2-g21.free.fr (smtpfb2-g21.free.fr [212.27.42.10]) by core3.amsl.com (Postfix) with ESMTP id 9CA033A6C41 for ; Wed, 22 Jul 2009 12:32:45 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by smtpfb2-g21.free.fr (Postfix) with ESMTP id 77E05D1ABF3 for ; Wed, 22 Jul 2009 21:18:19 +0200 (CEST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 0A211D4818B; Wed, 22 Jul 2009 21:17:46 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id D9032D48187; Wed, 22 Jul 2009 21:17:43 +0200 (CEST) Message-ID: <4A6765D7.8080608@gmail.com> Date: Wed, 22 Jul 2009 21:17:43 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> <4A66E420.8040604@gmail.com> <4A672731.9040009@earthlink.net> <4A672B8A.5000200@gmail.com> <4A673EF1.1020706@earthlink.net> <4A6753B2.9040109@gmail.com> <4A676115.8060202@earthlink.net> In-Reply-To: <4A676115.8060202@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090722-0, 22/07/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 19:32:47 -0000 Charlie, Charles E. Perkins a écrit : >> But requesting to configure a /128 on an interface instead of any >> other length isn't a solution to that issue either. > > Using this model of configuration, it is known that solutions can be > developed. Solutions to problems or simply mechanisms that work? >> I mean, if the prefix is /128 it does not mean that its neighbor is >> in range RIGHT NOW. These two things (/128 and and neighborness) >> have nothing to do with each other, one doesn't imply the other. > > Right. > >> >> The worse part is that this requirement of /128 - a real straw man >> argument - implies forbidding the use of link-local addresses which >> are /64 or /10. > > No, it does not. The section 6.2 is clear - it says /128 prefixes exclusively. True, a later appendix suggests that link-local addresses are possible. However, I find that appendix too far from section 6.2 to qualify your above conviction. Were the section 6.2 to have a paragraph to mean that the /128 mandatory prefix recommendation does not forbid the /64 IPv6 link-local addresses then I'd agree with your statement above. It is about how people read the documents and go straight to the important sections, skipping the appendices eventually. Alex > The document explains that we recommend use of the long prefixes > unless you can somehow avoid the problems. If you can show how to > avoid the problems, you should contribute a better document. Until > then, it is not reasonable to have a working group document that > mandates something we don't necessarily know how to do. Citing the > acronyms DAD and UDP does not constitute proposing a solution. > >> (I suppose the initial presence of 'straw man' in the title wasn't >> such intention, but it seems to turn out exactly that way - a >> strawman argumentation). > > I know what a straw man argument is, and I don't recogize it in the > document's use of /128. Or, ... what did you mean??? >> >> I think we have very different views on this particular topic... > > That is why we have mailing lists -- to discuss technical matters and > arrive at resolutions. > > Regards, Charlie P. > > From charles.perkins@earthlink.net Wed Jul 22 13:40:14 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 011663A68A7 for ; Wed, 22 Jul 2009 13:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96k3w72gj461 for ; Wed, 22 Jul 2009 13:40:13 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id D61253A6858 for ; Wed, 22 Jul 2009 13:40:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=CS6Zurbe3kDLTfIZBCrCvs1GV1tv3gmTFrWDUbWx/14FENOAuJAh66XRQH83DRT5; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[192.168.1.102]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MTi8B-0002tL-2O; Wed, 22 Jul 2009 16:09:39 -0400 Message-ID: <4A6771FF.8030104@earthlink.net> Date: Wed, 22 Jul 2009 13:09:35 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Alexandru Petrescu References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> <4A66E420.8040604@gmail.com> <4A672731.9040009@earthlink.net> <4A672B8A.5000200@gmail.com> <4A673EF1.1020706@earthlink.net> <4A6753B2.9040109@gmail.com> <4A676115.8060202@earthlink.net> <4A6765D7.8080608@gmail.com> In-Reply-To: <4A6765D7.8080608@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5207ea6e485cfa4a1a2462925a384cad48350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 20:40:14 -0000 Hello Alex, Alexandru Petrescu wrote: > Charlie, > > Charles E. Perkins a écrit : >>> But requesting to configure a /128 on an interface instead of any >>> other length isn't a solution to that issue either. >> >> Using this model of configuration, it is known that solutions can be >> developed. > > Solutions to problems or simply mechanisms that work? You are being mysterious here. I reckon you meant to imply that the published solutions do not solve "real" problems. If so, then you should be up front about that and say so. But we did manage to build a test network and did find that the solution seemed to be workable. > >>> >>> The worse part is that this requirement of /128 - a real straw man >>> argument - implies forbidding the use of link-local addresses which >>> are /64 or /10. >> >> No, it does not. > > The section 6.2 is clear - it says /128 prefixes exclusively. True, a > later appendix suggests that link-local addresses are possible. > However, I find that appendix too far from section 6.2 to qualify your > above conviction. > > Were the section 6.2 to have a paragraph to mean that the /128 mandatory > prefix recommendation does not forbid the /64 IPv6 link-local addresses > then I'd agree with your statement above. It is about how people read > the documents and go straight to the important sections, skipping the > appendices eventually. If section 6.2 were to change emphasis to conform more closely with my description of what was meant, would that resolve your issue? Regards, Charlie P. From alexandru.petrescu@gmail.com Wed Jul 22 14:07:51 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 776ED28C0FE for ; Wed, 22 Jul 2009 14:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.516 X-Spam-Level: X-Spam-Status: No, score=-1.516 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71jSP-YperUp for ; Wed, 22 Jul 2009 14:07:50 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 70EB53A6BA9 for ; Wed, 22 Jul 2009 14:07:48 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id BBA4FD4805C; Wed, 22 Jul 2009 23:06:52 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 5E6B9D480E9; Wed, 22 Jul 2009 23:06:49 +0200 (CEST) Message-ID: <4A677F69.9080006@gmail.com> Date: Wed, 22 Jul 2009 23:06:49 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> <4A66E420.8040604@gmail.com> <4A672731.9040009@earthlink.net> <4A672B8A.5000200@gmail.com> <4A673EF1.1020706@earthlink.net> <4A6753B2.9040109@gmail.com> <4A676115.8060202@earthlink.net> <4A6765D7.8080608@gmail.com> <4A6771FF.8030104@earthlink.net> In-Reply-To: <4A6771FF.8030104@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090722-0, 22/07/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 21:07:51 -0000 Charles E. Perkins a écrit : > > Hello Alex, > > Alexandru Petrescu wrote: >> Charlie, >> >> Charles E. Perkins a écrit : >>>> But requesting to configure a /128 on an interface instead of any >>>> other length isn't a solution to that issue either. >>> >>> Using this model of configuration, it is known that solutions can be >>> developed. >> >> Solutions to problems or simply mechanisms that work? > > You are being mysterious here. I reckon you meant to imply > that the published solutions do not solve "real" problems. > If so, then you should be up front about that and say so. > But we did manage to build a test network and did find > that the solution seemed to be workable. The problem to be solved is not ready at hand. I am no more mysterious than that. >>>> The worse part is that this requirement of /128 - a real straw man >>>> argument - implies forbidding the use of link-local addresses which >>>> are /64 or /10. >>> >>> No, it does not. >> >> The section 6.2 is clear - it says /128 prefixes exclusively. True, a >> later appendix suggests that link-local addresses are possible. >> However, I find that appendix too far from section 6.2 to qualify your >> above conviction. >> >> Were the section 6.2 to have a paragraph to mean that the /128 mandatory >> prefix recommendation does not forbid the /64 IPv6 link-local addresses >> then I'd agree with your statement above. It is about how people read >> the documents and go straight to the important sections, skipping the >> appendices eventually. > > If section 6.2 were to change emphasis to conform more closely with > my description of what was meant, would that resolve your issue? I think you would like to write something better, more convincing to me and hopefully aligned not only to your own description but according to at least 4 oppinions expressed on this list stating they have nothing against the use of IPv6 link-local addresses. I would like to read what you plan to write in 6.2. Alex From teco@inf-net.nl Wed Jul 22 15:15:58 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D42FA3A68B0 for ; Wed, 22 Jul 2009 15:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzEB-OawiNke for ; Wed, 22 Jul 2009 15:15:57 -0700 (PDT) Received: from smtp.bit.nl (smtp.ipv6.bit.nl [IPv6:2001:7b8:3:5::25:1]) by core3.amsl.com (Postfix) with ESMTP id 7EFE33A67F3 for ; Wed, 22 Jul 2009 15:15:57 -0700 (PDT) Received: from [87.251.46.4] (port=54117 helo=M90Teco) by smtp2.smtp.dmz.bit.nl with esmtp (Exim 4.69) (envelope-from ) id 1MTk6K-00029O-I0; Thu, 23 Jul 2009 00:15:52 +0200 From: "Teco Boot" To: "'Charles E. Perkins'" References: <4A4CECCF.1030202@earthlink.net> <005001c9fbb6$bcfa9c10$36efd430$@nl> <4A4E25C0.5010201@computer.org> <00e601c9fc8f$42097a10$c61c6e30$@nl> <4A536396.5060108@computer.org> In-Reply-To: <4A536396.5060108@computer.org> Date: Thu, 23 Jul 2009 00:15:42 +0200 Message-ID: <005d01ca0b19$f3da0500$db8e0f00$@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: Acn/FAVLq2+vA9zSSS6QsgKw4ORhZwL/A+bg Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] [autoconf-dt] On-link, X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 22:15:58 -0000 Hi Charlie, I owe you response on DT mail on 7/20 (yes, we have a 20th month here in Europe:-) Here is a first one. |> RFC4861: |> => on-link - an address that is assigned to an interface on a |> => specified link. A node considers an address to be on- |> => link if: |> => - it is covered by one of the link's prefixes (e.g., |> => as indicated by the on-link flag in the Prefix |> => Information option), or |> => - a neighboring router specifies the address as the |> => target of a Redirect message, or |> => - a Neighbor Advertisement message is received for |> => the (target) address, or |> => - any Neighbor Discovery message is received from |> => the address | |We can try to use this definition, especially for |_our_ Neighbor Discovery messages. However, we should |be very explicit to point out that using the latter |conditions is going to lead to an understanding of |"on-link" [and, presumably, link] that is quite at |variance with the "traditional" Ethernet-inspired |model of a link. Not to mention that it is quite |time-variant. | |In this connection, I once proposed that we |legislate the terminology "on-link" to be understood |as node-local. Do you agree with that? Yes, I agree. To be annoying accurate: it is local to [the node and the attachment to the link]. The MANET nodes are routers and I think an address configured on a router interface in an UP state is on-link. Another annoying accuracy: the draft uses "on link". Let's use "on-link". |> The problem is that a MANET router cannot guarantee |> that all addresses that are on-link can be reached with a single |> hop. | |Now I am confused. If they aren't reachable in a single hop |then they should not be on link. They do not satisfy any |of the conditions in the definition you quoted. If there |were such a situation for which nodes with the same prefix |were [effectively] multiple hops away, then the prefix |would have been assigned incorrectly. Let's face the non-transitivity characteristic. A has connectivity with B, B with C. But A not with B. I say addresses A, B and C are on-link. Agreed? If agreed, we can say two on-link addresses configured on Interfaces to the same link (in this case MANET communication facility) says little on connectivity between those. My MANET router here in the Netherlands and yours in USA can both be on-link. But out of range. Maybe we are in range next week. |> Question: shall ARP support multiple IP (sub)networks on the same |> link? RFC826 does not prohibit this. But as said: it is not always |> supported. | |Again, my answer would be "no". Now I have some questions: how to support L2 address resolving on MANET on 802.11-IBSS ? I suggest ARP. But when interfaces are configured with /32, how does ARP deal with it ? Do we need an ARP enhancement ? |> |Well it has enough value to, for instance, enable the |> |solution built by Ryuji and me. So it's nonzero. It |> |has enough value to enable other solutions. |> |> Teco: |> But it doesn't describe practical addressing models for MANETs, with |> other solutions. Some other solutions are extensions on ND / SLAAC / |> OSPFv3. | | |Are you saying that the solution built by Ryuji and me |does not offer a practical addressing model? I did not intent to (dis)qualify a solution. I intended to say solutions is something else as an addressing model. If you had draft-perkins-manet-autoconf-01.txt in mind, this is configuring IPv4 link-locals, right? Didn't I suggest this at last IETF? Why not using IPv6 link-locals, as it works fine for IPv4? More comments on this draft: I have little against a MANET_PREFIX. But why not using ULA? |> |> My other points were: |> |> - describe usage of link locals |> | |> |I'd prefer to keep this in solution space. |> |> Teco: |> Then we do not agree. Link-locals is part of the addressing model. |> We can say we cannot use it in a MANET, or that we can build solutions |> on it. Not mentioning it makes the document less meaningful. | | |O.K. Let's mention in the document that we do |not require use of link-locals, but we do not |prohibit them as long as the appropriate uniqueness |conditions are maintained. Again: what makes uniqueness conditions special for link-locals? Can we accept duplicates for non link-locals? Teco. From charles.perkins@earthlink.net Wed Jul 22 15:18:25 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CD713A6C45 for ; Wed, 22 Jul 2009 15:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-+8FgEhVfWC for ; Wed, 22 Jul 2009 15:18:24 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 8898D3A6BDD for ; Wed, 22 Jul 2009 15:18:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=cukezp9cEaBIb0QoO0W2FoPpWDzhO7F74+dLXBK2ooRt6XVYgF0ZZzOHTHit1N+d; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.12]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MTjq8-0002A0-LV; Wed, 22 Jul 2009 17:59:08 -0400 Message-ID: <4A678BA9.8050408@earthlink.net> Date: Wed, 22 Jul 2009 14:59:05 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Alexandru Petrescu References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> <4A66E420.8040604@gmail.com> <4A672731.9040009@earthlink.net> <4A672B8A.5000200@gmail.com> <4A673EF1.1020706@earthlink.net> <4A6753B2.9040109@gmail.com> <4A676115.8060202@earthlink.net> <4A6765D7.8080608@gmail.com> <4A6771FF.8030104@earthlink.net> <4A677F69.9080006@gmail.com> In-Reply-To: <4A677F69.9080006@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f521d404e70352a9100dd587259a92f4488350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 22:18:25 -0000 Hello Alex, Alexandru Petrescu wrote: > >>> >>> The section 6.2 is clear - it says /128 prefixes exclusively. True, >>> a later appendix suggests that link-local addresses are possible. >>> However, I find that appendix too far from section 6.2 to qualify >>> your above conviction. >>> >>> ... >> >> If section 6.2 were to change emphasis to conform more closely with >> my description of what was meant, would that resolve your issue? > > I think you would like to write something better, more convincing to > me and hopefully aligned not only to your own description but > according to at least 4 oppinions expressed on this list stating they > have nothing against the use of IPv6 link-local addresses. I also have nothing against the use of link-local addresses. I can be in favor of using them when possible, without wanting to put others in the position of having to use them when the methods for appropriate use aren't understood. > > I would like to read what you plan to write in 6.2. I provided my input to the design team, and you have seen the result. Now it's your turn to provide input to the document editor :-) I did make comments on your earlier proposal, and did not get a direct response: > The document explains that we recommend use of the long prefixes > unless you can somehow avoid the problems. If you can show how to > avoid the problems, you should contribute a better document. Until > then, it is not reasonable to have a working group document that > mandates something we don't necessarily know how to do. Since according to this, your earlier submission wouldn't be suitable, perhaps you could take the initiative to craft some new text that (a) does make use of the long discussion about link-locals and (b) helps us to progress towards a resolution and common understanding. Regards, Charlie P. From teco@inf-net.nl Wed Jul 22 15:30:50 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2A8D3A6930 for ; Wed, 22 Jul 2009 15:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hh87+3g4PjqB for ; Wed, 22 Jul 2009 15:30:50 -0700 (PDT) Received: from smtp.bit.nl (smtp.ipv6.bit.nl [IPv6:2001:7b8:3:5::25:1]) by core3.amsl.com (Postfix) with ESMTP id D07D63A68A5 for ; Wed, 22 Jul 2009 15:30:49 -0700 (PDT) Received: from [87.251.46.4] (port=54130 helo=M90Teco) by smtp3.smtp.dmz.bit.nl with esmtp (Exim 4.69) (envelope-from ) id 1MTkKc-0000Gm-UI; Thu, 23 Jul 2009 00:30:38 +0200 From: "Teco Boot" To: "'Charles E. Perkins'" References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> <4A66E420.8040604@gmail.com> <4A6708A5.8090501@gmail.com> <005301ca0ad6$ae7961b0$0b6c2510$@nl> <4A67233E.3010808@gmail.com> <4A673AAB.2040704@earthlink.net> In-Reply-To: <4A673AAB.2040704@earthlink.net> Date: Thu, 23 Jul 2009 00:30:28 +0200 Message-ID: <005e01ca0b1c$04273a70$0c75af50$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoK52HrWtjlgPr/R6GNLF7SXg+mdAAMy9KA Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 22:30:51 -0000 Hi Charlie, Here another response, also with large delay. >>> |> => you can presumably always communicate with neighbor using >>> |> => link-local addresses. >>> | >>> |Yes, of course, once it is known that a node is a neighbor. >>> >>> >> You have to know that >> the node _is_ a _neighbor_. That means within range >> and within range RIGHT NOW. How are you going to >> know that? How are you going to invalidate the >> link-local address as soon as _any_ other node >> becomes a new neighbor of the node? > > I am myself in favor of enabling the use of link-local > addresses, once these questions are answered. What makes a link-local different form an address with other scope? One answer would be: the other addresses can be used via single-hop or multi-hop paths. Multi-hop paths could be preferred over single- hop paths when link-metrics are in place. Link-locals are used on single-hop paths only. This has impact on address selection. If addresses are needed for a session on whatever path, link-local addresses are not preferred. If addresses are needed for single-hop only, link-local addresses are fine and moreover, it guarantees packets are not forwarded. This makes link-local addresses a candidate for network layer protocols, and that is why I use link-locals for the MANET protocols I run. I asked on RFC3484 rule 2. I had my beer. I still do not understand. Can you translate for me? Teco. From charles.perkins@earthlink.net Wed Jul 22 16:46:02 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B6173A6C85 for ; Wed, 22 Jul 2009 16:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJiu5KSQZFwq for ; Wed, 22 Jul 2009 16:46:01 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 863843A6C86 for ; Wed, 22 Jul 2009 16:46:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=UEELEG/yBL8IOhrIfB4xUjWobAetwCO+f/6Rk0eFYqK76vEUvvHOXyznPsBqYUj6; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.12]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MTlIV-0000ZU-Fy; Wed, 22 Jul 2009 19:32:31 -0400 Message-ID: <4A67A18C.20202@earthlink.net> Date: Wed, 22 Jul 2009 16:32:28 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Teco Boot References: <4A4CECCF.1030202@earthlink.net> <005001c9fbb6$bcfa9c10$36efd430$@nl> <4A4E25C0.5010201@computer.org> <00e601c9fc8f$42097a10$c61c6e30$@nl> <4A536396.5060108@computer.org> <005d01ca0b19$f3da0500$db8e0f00$@nl> In-Reply-To: <005d01ca0b19$f3da0500$db8e0f00$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f526b0ff3c178095a3139057ae0b0f71af8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] [autoconf-dt] On-link, X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 23:46:02 -0000 Hello Teco, Here are some comments on your reply. Teco Boot wrote: > Hi Charlie, > > I owe you response on DT mail on 7/20 (yes, we have a 20th > month here in Europe:-) > I could myself use a few extra months per year. > | > |In this connection, I once proposed that we > |legislate the terminology "on-link" to be understood > |as node-local. Do you agree with that? > > Yes, I agree. > To be annoying accurate: it is local to [the node and > the attachment to the link]. > The MANET nodes are routers and I think an address > configured on a router interface in an UP state is > on-link. > O.K. > Another annoying accuracy: the draft uses "on link". > Let's use "on-link". > O.K. > Let's face the non-transitivity characteristic. > A has connectivity with B, B with C. But A not with B. > I say addresses A, B and C are on-link. > Agreed? > I assume you meant "But A not with C" instead of "But A not with B". It depends. If "on-link" is node-local, then A, B, and C are "on-link" as far as B is concerned. But, C is not "on-link" as far as A is concerned. > If agreed, we can say two on-link addresses configured on > Interfaces to the same link (in this case MANET communication > facility) says little on connectivity between those. > My MANET router here in the Netherlands and yours in USA can both > be on-link. But out of range. Maybe we are in range next week. > This is too confusing for me. I'd prefer to have it so that nodes that are "on-link" are on link. ... so to speak. > > |> Question: shall ARP support multiple IP (sub)networks on the same > |> link? RFC826 does not prohibit this. But as said: it is not always > |> supported. > | > |Again, my answer would be "no". > > Now I have some questions: how to support L2 address resolving on > MANET on 802.11-IBSS ? > I suggest ARP. But when interfaces are configured with /32, > how does ARP deal with it ? Do we need an ARP enhancement ? > How about scatternets :-)? More seriously, I'd prefer to keep ARP out of the discussion about "on-link". > > |> |Well it has enough value to, for instance, enable the > |> |solution built by Ryuji and me. So it's nonzero. It > |> |has enough value to enable other solutions. > |> > |> Teco: > |> But it doesn't describe practical addressing models for MANETs, with > |> other solutions. Some other solutions are extensions on ND / SLAAC / > |> OSPFv3. > | > | > |Are you saying that the solution built by Ryuji and me > |does not offer a practical addressing model? > > I did not intent to (dis)qualify a solution. > I intended to say solutions is something else as an addressing model. > Well.... O.K. But still the choice of addressing model has to allow for useful solutions. > If you had draft-perkins-manet-autoconf-01.txt in mind, this is > configuring IPv4 link-locals, right? Didn't I suggest this at > last IETF? > Our earlier draft was not restricted to link-locals. In particular, that design was intended to allow free movement of nodes between different MANETs, and to allow nodes to leave the MANET cloud and come back without restriction. > More comments on this draft: I have little against a MANET_PREFIX. > But why not using ULA? > Either way is fine with me. When we wrote the draft, I don't think ULAs were standardized. > > > |> |> My other points were: > |> |> - describe usage of link locals > |> | > |> |I'd prefer to keep this in solution space. > |> > |> Teco: > |> Then we do not agree. Link-locals is part of the addressing model. > |> We can say we cannot use it in a MANET, or that we can build solutions > |> on it. Not mentioning it makes the document less meaningful. > | > | > |O.K. Let's mention in the document that we do > |not require use of link-locals, but we do not > |prohibit them as long as the appropriate uniqueness > |conditions are maintained. > > Again: what makes uniqueness conditions special for link-locals? > Can we accept duplicates for non link-locals? > What makes link-local special, is that you don't have multihop protocols for resolving link-local problems. And it would seem very very weird to design such a thing. Or, if you want to extend "link-local" to include nodes that are not on link but are (by fiat) defined to be "on-link", then I start to glaze over. Regards, Charlie P. From charles.perkins@earthlink.net Wed Jul 22 16:46:46 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CDDC3A6918 for ; Wed, 22 Jul 2009 16:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.691 X-Spam-Level: X-Spam-Status: No, score=-1.691 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFIL8cgxZhjA for ; Wed, 22 Jul 2009 16:46:45 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 954003A6C5F for ; Wed, 22 Jul 2009 16:46:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=YDiirxC6odilzQly2VeyaJv1jN4wkjDDHKKXMEQaa+njUIr3pWvNQUelV+9a03qu; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.12]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MTlTA-0007rV-35; Wed, 22 Jul 2009 19:43:32 -0400 Message-ID: <4A67A420.50205@earthlink.net> Date: Wed, 22 Jul 2009 16:43:28 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Teco Boot References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> <4A66E420.8040604@gmail.com> <4A6708A5.8090501@gmail.com> <005301ca0ad6$ae7961b0$0b6c2510$@nl> <4A67233E.3010808@gmail.com> <4A673AAB.2040704@earthlink.net> <005e01ca0b1c$04273a70$0c75af50$@nl> In-Reply-To: <005e01ca0b1c$04273a70$0c75af50$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52ef8c20884193f766a0baf39794b9ceda350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 23:46:46 -0000 Hello Teco, Teco Boot wrote: > >>>> |> => you can presumably always communicate with neighbor using >>>> |> => link-local addresses. >>>> | >>>> |Yes, of course, once it is known that a node is a neighbor. >>>> >>>> >>>> >>> You have to know that >>> the node _is_ a _neighbor_. That means within range >>> and within range RIGHT NOW. How are you going to >>> know that? How are you going to invalidate the >>> link-local address as soon as _any_ other node >>> becomes a new neighbor of the node? >>> >> I am myself in favor of enabling the use of link-local >> addresses, once these questions are answered. >> > > What makes a link-local different form an address with other scope? > One answer would be: the other addresses can be used via single-hop > or multi-hop paths. Multi-hop paths could be preferred over single- > hop paths when link-metrics are in place. Link-locals are used on > single-hop paths only. > Check. > This has impact on address selection. If addresses are needed for > a session on whatever path, link-local addresses are not preferred. > If addresses are needed for single-hop only, link-local addresses > are fine and moreover, it guarantees packets are not forwarded. > This makes link-local addresses a candidate for network layer > protocols, and that is why I use link-locals for the MANET protocols > I run. > How do you know that a particular link-local destination has not been replaced by another node that just happens to have the same link-local address? Presumably, by requiring address uniqueness. How do you enforce uniqueness? Ahhh.... that's a toughie when you are only allowed to use packets that cannot be forwarded... Plus you can swamp out your network with uniqueness-enforcement traffic if you have too many nodes or brute-force design. > I asked on RFC3484 rule 2. I had my beer. I still do not understand. > Can you translate for me? > > Yes. I can translate this rule for you. Where's _my_ beer? Regards, Charlie P. From teco@inf-net.nl Wed Jul 22 23:07:37 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFF9B3A68CB for ; Wed, 22 Jul 2009 23:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.823 X-Spam-Level: X-Spam-Status: No, score=-0.823 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5be+R3iwPVJa for ; Wed, 22 Jul 2009 23:07:37 -0700 (PDT) Received: from smtp.bit.nl (smtp.ipv6.bit.nl [IPv6:2001:7b8:3:5::25:1]) by core3.amsl.com (Postfix) with ESMTP id 941FB3A6823 for ; Wed, 22 Jul 2009 23:07:35 -0700 (PDT) Received: from [87.251.46.4] (port=54620 helo=M90Teco) by smtp3.smtp.dmz.bit.nl with esmtp (Exim 4.69) (envelope-from ) id 1MTrSe-0005HX-VP; Thu, 23 Jul 2009 08:07:25 +0200 From: "Teco Boot" To: "'Charles E. Perkins'" References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> <4A66E420.8040604@gmail.com> <4A6708A5.8090501@gmail.com> <005301ca0ad6$ae7961b0$0b6c2510$@nl> <4A67233E.3010808@gmail.com> <4A673AAB.2040704@earthlink.net> <005e01ca0b1c$04273a70$0c75af50$@nl> <4A67A420.50205@earthlink.net> In-Reply-To: <4A67A420.50205@earthlink.net> Date: Thu, 23 Jul 2009 08:07:13 +0200 Message-ID: <000f01ca0b5b$d2b5f4f0$7821ded0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoLJjwxhjFbgLoeQc28zdEw8VYrfAAMQtOg Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 06:07:37 -0000 Hi Charlie, |How do you know that a particular link-local destination has |not been replaced by another node that just happens to have the |same link-local address? How do you know that a particular global destination has not been replaced by another node that just happens to have the same global address? |Presumably, by requiring address uniqueness. |How do you enforce uniqueness? Ahhh.... that's a toughie when you |are only allowed to use packets that cannot be forwarded... It's easy. I buy products that comply with standards and Recommendations published by IETF and IEEE. I don't need any packet. It guarantees uniqueness for globals and link-locals, based on guaranteed unique L2 addresses. This doesn't work for IPv4. |Plus you can swamp out your network with uniqueness-enforcement |traffic if you have too many nodes or brute-force design. I could, but I don't. |> I asked on RFC3484 rule 2. I had my beer. I still do not understand. |> Can you translate for me? |> |Yes. I can translate this rule for you. | |Where's _my_ beer? Out of reach for you? I can't bring one with me (customs). I buy you one in Sweden. Know this cost me a lot, prices are extreme high out there. Now serious: Assume router A has addresses LL_A an G_A and router B LL_B and G_B. When a connection from A to B is initiated, and destination LL_B is selected, address LL_A would be the source. With destination G_B is selected, address G_A would be the source. Is this RFC3484 SA selection rule 2? When a destination address needs selection, would it be LL_B or G_B? I use MANET protocols with link-metrics. When I initiate a ping, I select LL_B or G_B for testing the benefit of link-metrics (which is tremendous in some cases, a path via C could perform much better). But what should be the address selection policy for normal applications? I say: use globals. Can you confirm this needs and update on RFC3484 DA selection rule 8? RFC3484 DA selection, Rule 8: Prefer smaller scope. If Scope(DA) < Scope(DB), then prefer DA. Similarly, if Scope(DA) > Scope(DB), then prefer DB. Teco. |Regards, |Charlie P. From teco@inf-net.nl Wed Jul 22 23:32:03 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E10D3A6A62 for ; Wed, 22 Jul 2009 23:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.948 X-Spam-Level: X-Spam-Status: No, score=-0.948 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oceOxNWBo6gx for ; Wed, 22 Jul 2009 23:32:02 -0700 (PDT) Received: from smtp.bit.nl (smtp.ipv6.bit.nl [IPv6:2001:7b8:3:5::25:1]) by core3.amsl.com (Postfix) with ESMTP id 5F87B3A67B3 for ; Wed, 22 Jul 2009 23:32:01 -0700 (PDT) Received: from [87.251.46.4] (port=54639 helo=M90Teco) by smtp1.smtp.dmz.bit.nl with esmtp (Exim 4.69) (envelope-from ) id 1MTrqR-00059P-Bf; Thu, 23 Jul 2009 08:31:59 +0200 From: "Teco Boot" To: "'Charles E. Perkins'" References: <4A4CECCF.1030202@earthlink.net> <005001c9fbb6$bcfa9c10$36efd430$@nl> <4A4E25C0.5010201@computer.org> <00e601c9fc8f$42097a10$c61c6e30$@nl> <4A536396.5060108@computer.org> <005d01ca0b19$f3da0500$db8e0f00$@nl> <4A67A18C.20202@earthlink.net> In-Reply-To: <4A67A18C.20202@earthlink.net> Date: Thu, 23 Jul 2009 08:31:47 +0200 Message-ID: <001001ca0b5f$4179a410$c46cec30$@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: AcoLJLBqjx+5vJAwQJWsforSSVO2AgANzpxw Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] [autoconf-dt] On-link, X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 06:32:03 -0000 Hi Charlie, |I could myself use a few extra months per year. Become an accountant. They use month 13, 14 and even more. Or go for a job here in the Netherlands. Some employers (used to, crisis...) pay 13th month salary! |> Let's face the non-transitivity characteristic. |> A has connectivity with B, B with C. But A not with B. |> I say addresses A, B and C are on-link. |> Agreed? |> | |I assume you meant "But A not with C" instead of |"But A not with B". Sorry. 2nd time I made this mistake :-(( |It depends. If "on-link" is node-local, then A, B, and C are |"on-link" as far as B is concerned. But, C is not "on-link" |as far as A is concerned. So "on-link" is for a status in the neighbor table. I say we keep neighbor state in the MANET routing protocol, and leave L2 address resolving to ARP and ND. If agreed, we can skip the term "on-link". We use other, more accurate terms in our hello protocols. Now, we can say the term "link" in "on-link" has little to do with "link". It has also little to do with addresses configured on the router's own interfaces. Avoid "on-link" in the draft? The following needs rewording: If the link to which an interface connects enables no assumptions of connectivity to other interfaces, the only addresses which can be assumed "on link", are the address(es) of that interface itself. |> If agreed, we can say two on-link addresses configured on |> Interfaces to the same link (in this case MANET communication |> facility) says little on connectivity between those. |> My MANET router here in the Netherlands and yours in USA can both |> be on-link. But out of range. Maybe we are in range next week. |> | |This is too confusing for me. I'd prefer to have it so that nodes |that are "on-link" are on link. ... so to speak. But this is confusing for me. |> |> Question: shall ARP support multiple IP (sub)networks on the same |> |> link? RFC826 does not prohibit this. But as said: it is not always |> |> supported. |> | |> |Again, my answer would be "no". |> |> Now I have some questions: how to support L2 address resolving on |> MANET on 802.11-IBSS ? |> I suggest ARP. But when interfaces are configured with /32, |> how does ARP deal with it ? Do we need an ARP enhancement ? |> | |How about scatternets :-)? | |More seriously, I'd prefer to keep ARP out of the |discussion about "on-link". Yes, ARP discussion has nothing to do with "on-link". My point is, ARP is not specified for handling addresses out of different subnets. We could come up with this specification or continue assuming undocumented features are in place. This is important for me. |> Again: what makes uniqueness conditions special for link-locals? |> Can we accept duplicates for non link-locals? |> | |What makes link-local special, is that you don't have |multihop protocols for resolving link-local problems. |And it would seem very very weird to design such a |thing. Maybe there are no problems.... Teco. From alexandru.petrescu@gmail.com Thu Jul 23 01:56:20 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 197D93A6983 for ; Thu, 23 Jul 2009 01:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.575 X-Spam-Level: X-Spam-Status: No, score=-1.575 tagged_above=-999 required=5 tests=[AWL=0.374, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5D8nY1mASMO for ; Thu, 23 Jul 2009 01:56:19 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 088B83A69FC for ; Thu, 23 Jul 2009 01:56:18 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6N8ZnZJ025402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Jul 2009 10:35:49 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6N8ZnDn020122; Thu, 23 Jul 2009 10:35:49 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6N8ZlSY026337; Thu, 23 Jul 2009 10:35:48 +0200 Message-ID: <4A6820E3.5070801@gmail.com> Date: Thu, 23 Jul 2009 10:35:47 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> <4A66E420.8040604@gmail.com> <4A672731.9040009@earthlink.net> <4A672B8A.5000200@gmail.com> <4A673EF1.1020706@earthlink.net> <4A6753B2.9040109@gmail.com> <4A676115.8060202@earthlink.net> <4A6765D7.8080608@gmail.com> <4A6771FF.8030104@earthlink.net> <4A677F69.9080006@gmail.com> <4A678BA9.8050408@earthlink.net> In-Reply-To: <4A678BA9.8050408@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 08:56:20 -0000 Charles E. Perkins a écrit : > > Hello Alex, > > Alexandru Petrescu wrote: >> >>>> >>>> The section 6.2 is clear - it says /128 prefixes exclusively. True, >>>> a later appendix suggests that link-local addresses are possible. >>>> However, I find that appendix too far from section 6.2 to qualify >>>> your above conviction. >>>> >>>> ... >>> >>> If section 6.2 were to change emphasis to conform more closely with >>> my description of what was meant, would that resolve your issue? >> >> I think you would like to write something better, more convincing to >> me and hopefully aligned not only to your own description but >> according to at least 4 oppinions expressed on this list stating they >> have nothing against the use of IPv6 link-local addresses. > > I also have nothing against the use of link-local addresses. > I can be in favor of using them when possible, without > wanting to put others in the position of having to use them > when the methods for appropriate use aren't understood. I agree. There must be a way to formulate that, and not in the appendix, but in the main section 6.2. >> I would like to read what you plan to write in 6.2. > > I provided my input to the design team, and you have seen > the result. Now it's your turn to provide input to the > document editor :-) > I did make comments on your earlier proposal, and did > not get a direct response: > >> The document explains that we recommend use of the long prefixes >> unless you can somehow avoid the problems. If you can show how to >> avoid the problems, you should contribute a better document. Until >> then, it is not reasonable to have a working group document that >> mandates something we don't necessarily know how to do. > > Since according to this, your earlier submission wouldn't > be suitable, perhaps you could take the initiative to craft > some new text that (a) does make use of the long discussion > about link-locals and (b) helps us to progress towards a > resolution and common understanding. How about this text which says IPv6 link-local addresses are recommended when the link layer has determined connectivity properties. New: > 6.2. IPv6 Model > > > For IPv6, the principles described in Section 4 and Section 5 > translate partially as follows: > > o An ad-hoc network node self-forms an IPv6 link-local address for > each of its interfaces. The procedure is described in the > document relevant to the interface type. For example, a WiFi > interface should use RFC2464; for a PPP link see RFC5072. For a > more exhaustive list of links see RFCXXXX. > > This IPv6 link-local address are recommended when the link-layer > has determined connectivity properties. > > o An IP address configured on this interface should be unique, at > least within the routing domain, and > > o A subnet prefix configured on this interface should be of length > /128 (except, of course, the IPv6 link-local addresses whose > prefix is /10). What do you think? Alex From charles.perkins@earthlink.net Thu Jul 23 02:00:49 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10BB33A6A3B for ; Thu, 23 Jul 2009 02:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16V-v3Zn2lki for ; Thu, 23 Jul 2009 02:00:48 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 460EC3A6903 for ; Thu, 23 Jul 2009 02:00:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=tsSR851wlcAg2jkAsFZDaG3c2k9wEMRMTEvKqqUVqgvaJrON2M1ZrO7m+qPzhD1x; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.74.16] (helo=[192.168.1.105]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MTswG-0000et-TT; Thu, 23 Jul 2009 03:42:05 -0400 Message-ID: <4A68144B.6030109@earthlink.net> Date: Thu, 23 Jul 2009 00:42:03 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Teco Boot References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> <4A66E420.8040604@gmail.com> <4A6708A5.8090501@gmail.com> <005301ca0ad6$ae7961b0$0b6c2510$@nl> <4A67233E.3010808@gmail.com> <4A673AAB.2040704@earthlink.net> <005e01ca0b1c$04273a70$0c75af50$@nl> <4A67A420.50205@earthlink.net> <000f01ca0b5b$d2b5f4f0$7821ded0$@nl> In-Reply-To: <000f01ca0b5b$d2b5f4f0$7821ded0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f522c4743b3f9c6b493908c624e208f4316350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 09:00:49 -0000 Teco Boot wrote: > Hi Charlie, > > |How do you know that a particular link-local destination has > |not been replaced by another node that just happens to have the > |same link-local address? > > How do you know that a particular global destination has > not been replaced by another node that just happens to have the > same global address? > For the case of globals, we can use protocol methods to insure uniqueness. > > |Presumably, by requiring address uniqueness. > |How do you enforce uniqueness? Ahhh.... that's a toughie when you > |are only allowed to use packets that cannot be forwarded... > > It's easy. I buy products that comply with standards and > Recommendations published by IETF and IEEE. I don't need > any packet. It guarantees uniqueness for globals and link-locals, > based on guaranteed unique L2 addresses. > This doesn't work for IPv4. > My understanding is that IPv6 has a sphere of applicability which includes devices for which IEEE addresses may not exist, or may be duplicated by accident. > > > |> I asked on RFC3484 rule 2. I had my beer. I still do not understand. > |> Can you translate for me? > |> > |Yes. I can translate this rule for you. > | > |Where's _my_ beer? > > Out of reach for you? > I can't bring one with me (customs). > I buy you one in Sweden. Know this cost me a lot, prices are extreme > high out there. > Does this mean that, on average, Swedes are more sober than the Dutch? > Now serious: > Assume router A has addresses LL_A an G_A and router B LL_B and G_B. > When a connection from A to B is initiated, and destination LL_B is > selected, address LL_A would be the source. With destination G_B is > selected, address G_A would be the source. Is this RFC3484 SA > selection rule 2? > Selection 2 covers this case, but the example only requires a small subset of the rule. > When a destination address needs selection, would it be LL_B or > G_B? The rules governing application selection of destination address seem tricky to me, and maybe weren't completely thought out for mobile devices. Right now I can't study that problem, unfortunately. I would not make the assumption that the RFC is correct for cases of interest to [autoconf]. Regards, Charlie P. From alexandru.petrescu@gmail.com Thu Jul 23 02:25:14 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 040EC3A693B for ; Thu, 23 Jul 2009 02:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.597 X-Spam-Level: X-Spam-Status: No, score=-1.597 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttBvgxt-3WsZ for ; Thu, 23 Jul 2009 02:25:13 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 043223A67F8 for ; Thu, 23 Jul 2009 02:25:12 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6N9M3fR011790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Jul 2009 11:22:03 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6N9M3Ci000396; Thu, 23 Jul 2009 11:22:03 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6N9M1F0025127; Thu, 23 Jul 2009 11:22:03 +0200 Message-ID: <4A682BB9.4040604@gmail.com> Date: Thu, 23 Jul 2009 11:22:01 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> <4A66E420.8040604@gmail.com> <4A6708A5.8090501@gmail.com> <005301ca0ad6$ae7961b0$0b6c2510$@nl> <4A67233E.3010808@gmail.com> <4A673AAB.2040704@earthlink.net> <005e01ca0b1c$04273a70$0c75af50$@nl> <4A67A420.50205@earthlink.net> <000f01ca0b5b$d2b5f4f0$7821ded0$@nl> <4A68144B.6030109@earthlink.net> In-Reply-To: <4A68144B.6030109@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 09:25:14 -0000 Charles E. Perkins a écrit : > Teco Boot wrote: >> Hi Charlie, >> >> |How do you know that a particular link-local destination has |not >> been replaced by another node that just happens to have the |same >> link-local address? How do you know that a particular global >> destination has not been replaced by another node that just happens >> to have the same global address? >> > > For the case of globals, we can use protocol methods to insure > uniqueness. > >> >> |Presumably, by requiring address uniqueness. |How do you enforce >> uniqueness? Ahhh.... that's a toughie when you |are only allowed >> to use packets that cannot be forwarded... >> >> It's easy. I buy products that comply with standards and >> Recommendations published by IETF and IEEE. I don't need any >> packet. It guarantees uniqueness for globals and link-locals, based >> on guaranteed unique L2 addresses. This doesn't work for IPv4. >> > > My understanding is that IPv6 has a sphere of applicability which > includes devices for which IEEE addresses may not exist, or may be > duplicated by accident. Or may be negotiated to ensure uniqueness, like with PPP. Uniqueness is easier to ensure on a link. Alex From teco@inf-net.nl Thu Jul 23 03:03:06 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E5563A6983 for ; Thu, 23 Jul 2009 03:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.275 X-Spam-Level: X-Spam-Status: No, score=-0.275 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Idd18f9HdzFb for ; Thu, 23 Jul 2009 03:03:05 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 48D9A3A67B3 for ; Thu, 23 Jul 2009 03:03:04 -0700 (PDT) Received: (qmail 22268 invoked from network); 23 Jul 2009 12:01:04 +0200 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 23 Jul 2009 12:01:04 +0200 From: "Teco Boot" To: "'Charles E. Perkins'" References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> <4A66E420.8040604@gmail.com> <4A6708A5.8090501@gmail.com> <005301ca0ad6$ae7961b0$0b6c2510$@nl> <4A67233E.3010808@gmail.com> <4A673AAB.2040704@earthlink.net> <005e01ca0b1c$04273a70$0c75af50$@nl> <4A67A420.50205@earthlink.net> <000f01ca0b5b$d2b5f4f0$7821ded0$@nl> <4A68144B.6030109@earthlink.net> In-Reply-To: <4A68144B.6030109@earthlink.net> Date: Thu, 23 Jul 2009 12:00:22 +0200 Message-ID: <001401ca0b7c$7684def0$638e9cd0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoLaRZ5RwMTz2nfRMe368YSWJjRYwAAPwtA Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 10:03:06 -0000 Hi Charlie, |> |How do you know that a particular link-local destination has |> |not been replaced by another node that just happens to have the |> |same link-local address? |> |> How do you know that a particular global destination has |> not been replaced by another node that just happens to have the |> same global address? |> | |For the case of globals, we can use protocol methods to insure |uniqueness. I still do not see any difference with link-locals. When the address is not known to be unique, it is not used as source. I think it is also not advertized in the MANET. So other addresses are needed for verification. This may work for link-locals also. Anyway, we are back at DAD. Let's continue on the addressing model itself and I say link-locals works great. |> |Presumably, by requiring address uniqueness. |> |How do you enforce uniqueness? Ahhh.... that's a toughie when you |> |are only allowed to use packets that cannot be forwarded... |> |> It's easy. I buy products that comply with standards and |> Recommendations published by IETF and IEEE. I don't need |> any packet. It guarantees uniqueness for globals and link-locals, |> based on guaranteed unique L2 addresses. |> This doesn't work for IPv4. |> | |My understanding is that IPv6 has a sphere of applicability which |includes |devices for which IEEE addresses may not exist, or may be duplicated |by accident. This leaves open usage of technology that works. I recommend using it. And I recommend defining a practical addressing model for it. I am facing non-IEEE L2 addresses also. But I did not face a scenario with problems yet. I work with stuff I can rely on. |Does this mean that, on average, Swedes are more sober than the Dutch? I thought we were famous. So no need to answer. Did consumption go down during Prohibition? |I would not make the assumption that RFC3484 |is correct for cases of interest to [autoconf]. OK, so we add this in the Open Issues list. Teco. From teco@inf-net.nl Thu Jul 23 03:19:28 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B8693A69C0 for ; Thu, 23 Jul 2009 03:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxnnQd1+hdEh for ; Thu, 23 Jul 2009 03:19:27 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 904413A6971 for ; Thu, 23 Jul 2009 03:19:19 -0700 (PDT) Received: (qmail 30554 invoked from network); 23 Jul 2009 12:10:04 +0200 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 23 Jul 2009 12:10:04 +0200 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> <4A66E420.8040604@gmail.com> <4A672731.9040009@earthlink.net> <4A672B8A.5000200@gmail.com> <4A673EF1.1020706@earthlink.net> <4A6753B2.9040109@gmail.com> <4A676115.8060202@earthlink.net> <4A6765D7.8080608@gmail.com> <4A6771FF.8030104@earthlink.net> <4A677F69.9080006@gmail.com> <4A678BA9.8050408@earthlink.net> <4A6820E3.5070801@gmail.com> In-Reply-To: <4A6820E3.5070801@gmail.com> Date: Thu, 23 Jul 2009 12:09:21 +0200 Message-ID: <001501ca0b7d$b8720c60$29562520$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoLc3emwnhVm0aZSlWuPNui7cH5FQACVfpA Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 10:19:28 -0000 Hi Alex, > o A subnet prefix configured on this interface should be of > length /128 (except, of course, the IPv6 link-local > addresses whose prefix is /10). The link-local is defined in RFC4291 and has a /64 well-known prefix, which is FE80::/64. The 54 bits after the 10 bits allocated for link-local are zero. It is minor, but let's use /64. Teco. From alexandru.petrescu@gmail.com Thu Jul 23 04:05:08 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10F353A69D6 for ; Thu, 23 Jul 2009 04:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.617 X-Spam-Level: X-Spam-Status: No, score=-1.617 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndd8Dt6UNw3u for ; Thu, 23 Jul 2009 04:05:07 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 2CD2F3A63EB for ; Thu, 23 Jul 2009 04:05:07 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6NB3l5E025250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Jul 2009 13:03:47 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6NB3lWM020099; Thu, 23 Jul 2009 13:03:47 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6NB3ksw019195; Thu, 23 Jul 2009 13:03:46 +0200 Message-ID: <4A684392.7020903@gmail.com> Date: Thu, 23 Jul 2009 13:03:46 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Teco Boot References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> <4A66E420.8040604@gmail.com> <4A672731.9040009@earthlink.net> <4A672B8A.5000200@gmail.com> <4A673EF1.1020706@earthlink.net> <4A6753B2.9040109@gmail.com> <4A676115.8060202@earthlink.net> <4A6765D7.8080608@gmail.com> <4A6771FF.8030104@earthlink.net> <4A677F69.9080006@gmail.com> <4A678BA9.8050408@earthlink.net> <4A6820E3.5070801@gmail.com> <001501ca0b7d$b8720c60$29562520$@nl> In-Reply-To: <001501ca0b7d$b8720c60$29562520$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 11:05:08 -0000 Teco Boot a écrit : > Hi Alex, > >> o A subnet prefix configured on this interface should be of >> length /128 (except, of course, the IPv6 link-local >> addresses whose prefix is /10). > > The link-local is defined in RFC4291 and has a /64 well-known prefix, > which is FE80::/64. The 54 bits after the 10 bits allocated for > link-local are zero. It is minor, but let's use /64. Teco, thanks for digging this out. I agree with you to use /64 for IPv6 link-local addresses. Alex From roque.rafael@gmail.com Thu Jul 23 06:14:32 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78BD03A69EE for ; Thu, 23 Jul 2009 06:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.062 X-Spam-Level: X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[AWL=0.536, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qrbtts0ontrw for ; Thu, 23 Jul 2009 06:14:31 -0700 (PDT) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id 9B1E23A6A04 for ; Thu, 23 Jul 2009 06:14:05 -0700 (PDT) Received: by bwz28 with SMTP id 28so803153bwz.37 for ; Thu, 23 Jul 2009 06:13:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=YJlMN/pxXhu346r3rBbyVyKWFgzYp0T5LWBSiVi3bDE=; b=PxDjCcWRmcZ7saahPo72zhVKO0SqeRrgILh7izcvuVRPz+eLWVJM9WS8O0HlnQeu+n eRtHfLZW5rO3vg4Ml4lc+j0fgcOIglZffuPnjADT9yEJdnmAZs9VAHcJPtg30YYPNqMP Q9MSS57+/txuP1nn+38mxC9hEyqE14+fb++GY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PydT5GVZSRmJmsjdMpOghDzwvP4gDRM+vvyZiqOkZOjz2LmXkqerS9rAWEwMLZecp0 rn3xZSUgpF5lRV7joKkCyzJR+vO0omiXK4pz1Nvp9fceZk+vBV/bPESJEs360JFRXPtc LG/gJ2DvWghRfTwsxCmWlLc4J0zGMvTYMCiRY= MIME-Version: 1.0 Received: by 10.204.55.15 with SMTP id s15mr2064466bkg.53.1248354819532; Thu, 23 Jul 2009 06:13:39 -0700 (PDT) In-Reply-To: <001001ca0b5f$4179a410$c46cec30$@nl> References: <4A4CECCF.1030202@earthlink.net> <005001c9fbb6$bcfa9c10$36efd430$@nl> <4A4E25C0.5010201@computer.org> <00e601c9fc8f$42097a10$c61c6e30$@nl> <4A536396.5060108@computer.org> <005d01ca0b19$f3da0500$db8e0f00$@nl> <4A67A18C.20202@earthlink.net> <001001ca0b5f$4179a410$c46cec30$@nl> Date: Thu, 23 Jul 2009 10:13:39 -0300 Message-ID: <1726274c0907230613h4db6d6c8l7a5aaa175a89ebe0@mail.gmail.com> From: Rafael Roque To: Teco Boot Content-Type: multipart/alternative; boundary=001636c5990b926962046f5f414f Cc: autoconf@ietf.org Subject: Re: [Autoconf] [autoconf-dt] On-link, X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 13:14:32 -0000 --001636c5990b926962046f5f414f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello Teco, > |> If agreed, we can say two on-link addresses configured on > |> Interfaces to the same link (in this case MANET communication > |> facility) says little on connectivity between those. > |> My MANET router here in the Netherlands and yours in USA can both > |> be on-link. But out of range. Maybe we are in range next week. > |> > | > |This is too confusing for me. I'd prefer to have it so that nodes > |that are "on-link" are on link. ... so to speak. > > But this is confusing for me. it would be clearer to use words like "same cell" and "in range"? Yes, ARP discussion has nothing to do with "on-link". > My point is, ARP is not specified for handling addresses out > of different subnets. We could come up with this specification > or continue assuming undocumented features are in place. > This is important for me. there is an extension of arp dealing with subnets on different interfaces [RFC 1027]. Moreover, linux comes with a default implementation of this which i already tested. -- Rafael Roque Aschoff GPRT/UFPE --001636c5990b926962046f5f414f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Teco,
=A0
|> If agreed, we can say two on-link addresses configured on
|> Interfaces to the same link (in this case MANET communication
|> facility) says little on connectivity between those.
|> My MANET router here in the Netherlands and yours in USA can both
|> be on-link. But out of range. Maybe we are in range next week.
|>
|
|This is too confusing for me. =A0I'd prefer to have it so that nodes |that are "on-link" are on link. =A0... so to speak.

But this is confusing for me.

it would be clearer to use words like "same cell&q= uot; and "in range"?



Yes, ARP = discussion has nothing to do with "on-link".
My point is, ARP is not specified for handling addresses out
of different subnets. We could come up with this specification
or continue assuming undocumented features are in place.
This is important for me.

there is a= n extension of arp dealing with subnets on different interfaces [RFC 1027].=
Moreover, linux comes with a default implement= ation of this which i already tested.


--
Rafael Roque Aschoff
GPRT/UFPE
--001636c5990b926962046f5f414f-- From roque.rafael@gmail.com Thu Jul 23 06:36:02 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8189B3A6A04 for ; Thu, 23 Jul 2009 06:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHUIIfOKkkV3 for ; Thu, 23 Jul 2009 06:36:01 -0700 (PDT) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id 7A3F03A672F for ; Thu, 23 Jul 2009 06:36:01 -0700 (PDT) Received: by bwz28 with SMTP id 28so816587bwz.37 for ; Thu, 23 Jul 2009 06:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=cLCkkwQcUvsBqwrywt9s7SPRXzbrBDB5no5UQ+FhfIU=; b=yBB1DWWmXk8/kXW0gv2ohMkflrQnJjKuxguIKtSrI3Vt5L9DOmucZh5kl/f8JQ1VvR VjBkuryvxddEwR153gOLWJXc9EaxZLxZ/Z03gR/XFUv56n1Xlrxw2xhX1M081ndhYz2u ZnRP7Hs8tD6+levDP2ZursnKLKReREQcDcrlc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tPsZ0vyxMIPje087t7Sk1GlplFUSrqtML62ej9n5j/vqsWZKa27gQt8RnHPMW71Y90 /bRaGdLDKgEeBFzWLRA5M/PmflL5YwEcr2CmgLZTRNkwEzRqL5caYvM2htNg4CkIfPre vVg4meRJeR5Rg13Ijt8jRXwY17TFWq+Uj8Grk= MIME-Version: 1.0 Received: by 10.204.112.130 with SMTP id w2mr2084044bkp.56.1248355649310; Thu, 23 Jul 2009 06:27:29 -0700 (PDT) In-Reply-To: <000f01ca0b5b$d2b5f4f0$7821ded0$@nl> References: <4A6596CD.9040404@gmail.com> <4A66E420.8040604@gmail.com> <4A6708A5.8090501@gmail.com> <005301ca0ad6$ae7961b0$0b6c2510$@nl> <4A67233E.3010808@gmail.com> <4A673AAB.2040704@earthlink.net> <005e01ca0b1c$04273a70$0c75af50$@nl> <4A67A420.50205@earthlink.net> <000f01ca0b5b$d2b5f4f0$7821ded0$@nl> Date: Thu, 23 Jul 2009 10:27:29 -0300 Message-ID: <1726274c0907230627g2d0c7e4ft460a453f0973a70e@mail.gmail.com> From: Rafael Roque To: Teco Boot Content-Type: multipart/alternative; boundary=0016e6de17c307fb1e046f5f734d Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 13:36:02 -0000 --0016e6de17c307fb1e046f5f734d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Teco, |Presumably, by requiring address uniqueness. > |How do you enforce uniqueness? Ahhh.... that's a toughie when you > |are only allowed to use packets that cannot be forwarded... > > > > It's easy. I buy products that comply with standards and > Recommendations published by IETF and IEEE. I don't need > any packet. It guarantees uniqueness for globals and link-locals, > based on guaranteed unique L2 addresses. > This doesn't work for IPv4. > as we can see from the messages, you have a good testbad, didn't you find some privacy problems by using l2 address to generate IPv6? This is a issue treated in [rfc 4941]. Regards, R. Rafael. -- Rafael Roque Aschoff GPRT/UFPE --0016e6de17c307fb1e046f5f734d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Teco,

|Presumably, by requiring address uniqueness.
|How do you enforce uniqueness? =A0Ahhh.... that's a toughie when you |are only allowed to use packets that cannot be forwarded...



It's easy. I buy products that comply with standards and<= br> Recommendations published by IETF and IEEE. I don't need
any packet. It guarantees uniqueness for globals and link-locals,
based on guaranteed unique L2 addresses.
This doesn't work for IPv4.


as we can see= from the messages, you have a good testbad, didn't you find some priva= cy problems by using l2 address to generate IPv6?
This is a issue treated in [rfc 4941].


Regards,

R. Rafael.

--
Rafael Roque= Aschoff
GPRT/UFPE

--0016e6de17c307fb1e046f5f734d-- From Chris.Dearlove@baesystems.com Thu Jul 23 06:38:58 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09E413A69F2 for ; Thu, 23 Jul 2009 06:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REUVvwl2q8Hm for ; Thu, 23 Jul 2009 06:38:57 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 8C92E3A6A86 for ; Thu, 23 Jul 2009 06:38:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,255,1246834800"; d="scan'208,217";a="13772330" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 23 Jul 2009 14:38:04 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.0/Switch-3.4.0) with ESMTP id n6NDc8UW015783; Thu, 23 Jul 2009 14:38:08 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Jul 2009 14:38:03 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA0B9A.CD50C7C1" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 23 Jul 2009 14:38:02 +0100 Message-ID: In-Reply-To: <1726274c0907230613h4db6d6c8l7a5aaa175a89ebe0@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] [autoconf-dt] On-link, thread-index: AcoLl69XO2WykOviS0+kdKSEjI2TEQAArdHw References: <4A4CECCF.1030202@earthlink.net><005001c9fbb6$bcfa9c10$36efd430$@nl> <4A4E25C0.5010201@computer.org><00e601c9fc8f$42097a10$c61c6e30$@nl> <4A536396.5060108@computer.org><005d01ca0b19$f3da0500$db8e0f00$@nl> <4A67A18C.20202@earthlink.net><001001ca0b5f$4179a410$c46cec30$@nl> <1726274c0907230613h4db6d6c8l7a5aaa175a89ebe0@mail.gmail.com> From: "Dearlove, Christopher (UK)" To: "Rafael Roque" , "Teco Boot" X-OriginalArrivalTime: 23 Jul 2009 13:38:03.0272 (UTC) FILETIME=[CD6B7080:01CA0B9A] Cc: autoconf@ietf.org Subject: Re: [Autoconf] [autoconf-dt] On-link, X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 13:38:58 -0000 ------_=_NextPart_001_01CA0B9A.CD50C7C1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > it would be clearer to use words like "same cell" and "in range"? Same cell is definitely bad terminology, there may not be any cells. In range is less bad, as it is probably the most common cause of failed connections in a MANET. But it is not the only one, so it can't be used as the general term for why there is no link. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** ------_=_NextPart_001_01CA0B9A.CD50C7C1 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
>  it would be clearer to use words like "same cell" and "in range"?
 
Same cell is definitely bad terminology, there may not be any cells.
 
In range is less bad, as it is probably the most common cause of failed
connections in a MANET. But it is not the only one, so it can't be used
as the general term for why there is no link.

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

------_=_NextPart_001_01CA0B9A.CD50C7C1-- From Chris.Dearlove@baesystems.com Thu Jul 23 06:59:09 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C4163A6A86 for ; Thu, 23 Jul 2009 06:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJnUu6vPQfF2 for ; Thu, 23 Jul 2009 06:59:08 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 068953A67F4 for ; Thu, 23 Jul 2009 06:59:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,255,1246834800"; d="scan'208";a="13778171" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 23 Jul 2009 14:58:31 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.0/Switch-3.4.0) with ESMTP id n6NDwZaE028598; Thu, 23 Jul 2009 14:58:36 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Jul 2009 14:58:30 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 23 Jul 2009 14:58:30 +0100 Message-ID: In-Reply-To: <4A6820E3.5070801@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?iso-8859-1?Q?=5BAutoconf=5D_Link-locals_vis-=E0-vis_the_new_=5Bautoconf?= =?iso-8859-1?Q?=5D_document?= thread-index: AcoLc36WlCo8ezubRsuoZcXc5cWkcAAKg0cA References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net><4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net><4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net><4A66E420.8040604@gmail.com> <4A672731.9040009@earthlink.net><4A672B8A.5000200@gmail.com> <4A673EF1.1020706@earthlink.net><4A6753B2.9040109@gmail.com> <4A676115.8060202@earthlink.net><4A6765D7.8080608@gmail.com> <4A6771FF.8030104@earthlink.net><4A677F69.9080006@gmail.com> <4A678BA9.8050408@earthlink.net> <4A6820E3.5070801@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" , "Charles E. Perkins" X-OriginalArrivalTime: 23 Jul 2009 13:58:30.0870 (UTC) FILETIME=[A9200760:01CA0B9D] Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 13:59:09 -0000 > What do you think? I think you are trying to take us back down the same route that has consumed two or three years. There was a DT formed, they could agree on some things, but not everything. (They could agree that link-local addresses weren't to be excluded, but not that they should be mandatory, for example.) Trying to force the issue(s) that couldn't be agreed misses that point. It would be better at this point, as Stan (among others) has said, to take this as a starting point for actually doing some work (the sort that ends up with a way to autoconfigure addresses, rather than the sort that ends up with definitions and nothing else) rather than argue points that it's clear that not all agree - but which we may not need to all agree. (If someone has a "good" algorithm that hands out addresses from a limited size pool, without non-transient duplicate assignment, for example, then we can apply it to several different sorts of address.) ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From teco@inf-net.nl Thu Jul 23 07:00:17 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C1C63A687C for ; Thu, 23 Jul 2009 07:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chnpgDXXvEcH for ; Thu, 23 Jul 2009 07:00:16 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 4C8F13A67F4 for ; Thu, 23 Jul 2009 07:00:16 -0700 (PDT) Received: (qmail 31170 invoked from network); 23 Jul 2009 15:59:21 +0200 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 23 Jul 2009 15:59:21 +0200 From: "Teco Boot" To: "'Rafael Roque'" References: <4A4CECCF.1030202@earthlink.net> <005001c9fbb6$bcfa9c10$36efd430$@nl> <4A4E25C0.5010201@computer.org> <00e601c9fc8f$42097a10$c61c6e30$@nl> <4A536396.5060108@computer.org> <005d01ca0b19$f3da0500$db8e0f00$@nl> <4A67A18C.20202@earthlink.net> <001001ca0b5f$4179a410$c46cec30$@nl> <1726274c0907230613h4db6d6c8l7a5aaa175a89ebe0@mail.gmail.com> In-Reply-To: <1726274c0907230613h4db6d6c8l7a5aaa175a89ebe0@mail.gmail.com> Date: Thu, 23 Jul 2009 15:58:38 +0200 Message-ID: <003701ca0b9d$c00192a0$4004b7e0$@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: AcoLl4kB1NfU1TafS+Gcr4LkB+sbOgAASANw Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] On-link, X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 14:00:17 -0000 Hi Rafael, |> If agreed, we can say two on-link addresses configured on |> Interfaces to the same link (in this case MANET communication |> facility) says little on connectivity between those. |> My MANET router here in the Netherlands and yours in USA can both |> be on-link. But out of range. Maybe we are in range next week. |> | |This is too confusing for me. =A0I'd prefer to have it so that nodes |that are "on-link" are on link. =A0... so to speak. But this is confusing for me. it would be clearer to use words like "same cell" and "in range"? Teco: I dislike "same cell" I think confusing is caused by not using definitions. "On link" means to me having an interface to a communication facility, e.g. "connected to link". This does not imply connectivity. I think Charlie has a different opinion on what "on link" means. Yes, ARP discussion has nothing to do with "on-link". My point is, ARP is not specified for handling addresses out of different subnets. We could come up with this specification or continue assuming undocumented features are in place. This is important for me. there is an extension of arp dealing with subnets on different = interfaces [RFC 1027]. Moreover, linux comes with a default implementation of this which i = already tested. Teco: Thanks for this pointer. It clearly shows one cannot assume links with multiple subnets is supported by ARP. Teco. From ulrich@herberg.name Thu Jul 23 07:19:41 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BBD03A68F1 for ; Thu, 23 Jul 2009 07:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gzpNrjOWx37 for ; Thu, 23 Jul 2009 07:19:40 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 1D26A3A6B17 for ; Thu, 23 Jul 2009 07:19:39 -0700 (PDT) Received: by fxm18 with SMTP id 18so849691fxm.37 for ; Thu, 23 Jul 2009 07:17:43 -0700 (PDT) MIME-Version: 1.0 Sender: ulrich@herberg.name Received: by 10.204.50.212 with SMTP id a20mr2120061bkg.35.1248358311206; Thu, 23 Jul 2009 07:11:51 -0700 (PDT) In-Reply-To: References: <4A6596CD.9040404@gmail.com> <4A673EF1.1020706@earthlink.net> <4A6753B2.9040109@gmail.com> <4A676115.8060202@earthlink.net> <4A6765D7.8080608@gmail.com> <4A6771FF.8030104@earthlink.net> <4A677F69.9080006@gmail.com> <4A678BA9.8050408@earthlink.net> <4A6820E3.5070801@gmail.com> Date: Thu, 23 Jul 2009 16:11:50 +0200 X-Google-Sender-Auth: 97a0e878aa6c1424 Message-ID: <25c114b90907230711i719750bbr20b2a81dd22dbd05@mail.gmail.com> From: Ulrich Herberg To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=001636d34d54b154b0046f601179 Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 14:19:41 -0000 --001636d34d54b154b0046f601179 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I agree with Stan and Chris, that we should move forward with the points we have agreed on in the strawman draft and continue the discussion about link-local addresses later, as soon as we have understood better how to solve the issues with these addresses in autoconf. Ulrich On Thu, Jul 23, 2009 at 3:58 PM, Dearlove, Christopher (UK) < Chris.Dearlove@baesystems.com> wrote: > > What do you think? > > I think you are trying to take us back down the same route > that has consumed two or three years. There was a DT formed, > they could agree on some things, but not everything. (They > could agree that link-local addresses weren't to be excluded, > but not that they should be mandatory, for example.) Trying to > force the issue(s) that couldn't be agreed misses that point. > > It would be better at this point, as Stan (among others) has > said, to take this as a starting point for actually doing some > work (the sort that ends up with a way to autoconfigure > addresses, rather than the sort that ends up with definitions > and nothing else) rather than argue points that it's clear > that not all agree - but which we may not need to all agree. > (If someone has a "good" algorithm that hands out addresses > from a limited size pool, without non-transient duplicate > assignment, for example, then we can apply it to several > different sorts of address.) > > ******************************************************************** > 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://www.ietf.org/mailman/listinfo/autoconf > --001636d34d54b154b0046f601179 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree with Stan and Chris, that we should move forward with the points we= have agreed on in the strawman draft and continue the discussion about lin= k-local addresses later, as soon as we have understood better how to solve = the issues with these addresses in autoconf.

Ulrich

On Thu, Jul 23, 2009 at 3:58 P= M, Dearlove, Christopher (UK) <Chris.Dearlove@baesystems.com> wrot= e:
> What do you = think?

I think you are trying to take us back down the same route
that has consumed two or three years. There was a DT formed,
they could agree on some things, but not everything. (They
could agree that link-local addresses weren't to be excluded,
but not that they should be mandatory, for example.) Trying to
force the issue(s) that couldn't be agreed misses that point.

It would be better at this point, as Stan (among others) has
said, to take this as a starting point for actually doing some
work (the sort that ends up with a way to autoconfigure
addresses, rather than the sort that ends up with definitions
and nothing else) rather than argue points that it's clear
that not all agree - but which we may not need to all agree.
(If someone has a "good" algorithm that hands out addresses
from a limited size pool, without non-transient duplicate
assignment, for example, then we can apply it to several
different sorts of address.)

********************************************************************
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://www.ietf.org/mailman/listinfo/autoconf

--001636d34d54b154b0046f601179-- From alexandru.petrescu@gmail.com Thu Jul 23 07:22:57 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B2B13A69E3 for ; Thu, 23 Jul 2009 07:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.634 X-Spam-Level: X-Spam-Status: No, score=-1.634 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmqD6frEHpwo for ; Thu, 23 Jul 2009 07:22:56 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 94D853A67A2 for ; Thu, 23 Jul 2009 07:22:56 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6NEJxDS009795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Jul 2009 16:19:59 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6NEJwYp002519; Thu, 23 Jul 2009 16:19:58 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6NEJw8s032557; Thu, 23 Jul 2009 16:19:58 +0200 Message-ID: <4A68718E.2010700@gmail.com> Date: Thu, 23 Jul 2009 16:19:58 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net><4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net><4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net><4A66E420.8040604@gmail.com> <4A672731.9040009@earthlink.net><4A672B8A.5000200@gmail.com> <4A673EF1.1020706@earthlink.net><4A6753B2.9040109@gmail.com> <4A676115.8060202@earthlink.net><4A6765D7.8080608@gmail.com> <4A6771FF.8030104@earthlink.net><4A677F69.9080006@gmail.com> <4A678BA9.8050408@earthlink.net> <4A6820E3.5070801@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 14:22:57 -0000 Dearlove, Christopher (UK) a écrit : >> What do you think? > > I think you are trying to take us back down the same route that has > consumed two or three years. There was a DT formed, they could agree > on some things, but not everything. (They could agree that link-local > addresses weren't to be excluded, but not that they should be > mandatory, for example.) Trying to force the issue(s) that couldn't > be agreed misses that point. > > It would be better at this point, as Stan (among others) has said, to > take this as a starting point for actually doing some work (the sort > that ends up with a way to autoconfigure addresses, rather than the > sort that ends up with definitions and nothing else) rather than > argue points that it's clear that not all agree - but which we may > not need to all agree. (If someone has a "good" algorithm that hands > out addresses from a limited size pool, without non-transient > duplicate assignment, for example, then we can apply it to several > different sorts of address.) Christopher, if you expect a reply about how I don't want to take anybody back, or about the draft forbidding link-locals, please let me know. Otherwise I contend myself reading your email above and having my thoughts about it. Alex > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > From Chris.Dearlove@baesystems.com Thu Jul 23 07:25:21 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C8E93A6A98 for ; Thu, 23 Jul 2009 07:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjTSTsTZFr44 for ; Thu, 23 Jul 2009 07:25:20 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 90EEE3A67A2 for ; Thu, 23 Jul 2009 07:25:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,255,1246834800"; d="scan'208";a="13787298" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 23 Jul 2009 15:23:38 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.0/Switch-3.4.0) with ESMTP id n6NENgOS013339; Thu, 23 Jul 2009 15:23:43 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Jul 2009 15:23:38 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 23 Jul 2009 15:23:37 +0100 Message-ID: In-Reply-To: <4A68718E.2010700@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?iso-8859-1?Q?=5BAutoconf=5D_Link-locals_vis-=E0-vis_the_new_=5Bautoconf?= =?iso-8859-1?Q?=5D_document?= thread-index: AcoLoK+hzLW1ZWzGQdOf4GqtMdRjtAAAFK9Q References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net><4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net><4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net><4A66E420.8040604@gmail.com> <4A672731.9040009@earthlink.net><4A672B8A.5000200@gmail.com> <4A673EF1.1020706@earthlink.net><4A6753B2.9040109@gmail.com> <4A676115.8060202@earthlink.net><4A6765D7.8080608@gmail.com> <4A6771FF.8030104@earthlink.net><4A677F69.9080006@gmail.com> <4A678BA9.8050408@earthlink.net> <4A6820E3.5070801@gmail.com> <4A68718E.2010700@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 23 Jul 2009 14:23:38.0048 (UTC) FILETIME=[2B792400:01CA0BA1] Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 14:25:21 -0000 Alexandru > the draft forbidding link-locals Where? ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Thu Jul 23 07:43:12 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD9B73A687C for ; Thu, 23 Jul 2009 07:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNA3JF0B+5OB for ; Thu, 23 Jul 2009 07:43:12 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 03FA63A682B for ; Thu, 23 Jul 2009 07:43:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,255,1246834800"; d="scan'208";a="13793333" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 23 Jul 2009 15:40:16 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.0/Switch-3.4.0) with ESMTP id n6NEeKWY023948; Thu, 23 Jul 2009 15:40:21 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Jul 2009 15:40:15 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 23 Jul 2009 15:40:15 +0100 Message-ID: In-Reply-To: <4A68732C.2000300@cea.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?iso-8859-1?Q?=5BAutoconf=5D_Link-locals_vis-=E0-vis_the_new_=5Bautoconf?= =?iso-8859-1?Q?=5D_document?= thread-index: AcoLoap06rqfJGbDSDOxqvOEkYuUIgAAGN/Q References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net><4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net><4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net><4A66E420.8040604@gmail.com> <4A672731.9040009@earthlink.net><4A672B8A.5000200@gmail.com> <4A673EF1.1020706@earthlink.net><4A6753B2.9040109@gmail.com> <4A676115.8060202@earthlink.net><4A6765D7.8080608@gmail.com> <4A6771FF.8030104@earthlink.net><4A677F69.9080006@gmail.com> <4A678BA9.8050408@earthlink.net> <4A6820E3.5070801@gmail.com> <4A68718E.2010700@gmail.com> <4A68732C.2000300@cea.fr> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 23 Jul 2009 14:40:15.0989 (UTC) FILETIME=[7E4ADA50:01CA0BA3] Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 14:43:12 -0000 Alexandru: > Dearlove, Christopher (UK) a =E9crit : >> Alexandru >>> the draft forbidding link-locals >> >> Where? >Section 6.2: >> 6.2. IPv6 Model >>=20 >> For IPv6, the principles described in Section 4 and Section 5 >> translate as such: >>=20 >> o An IP address configured on this interface should be unique, at >> least within the routing domain, and >>=20 >> o A subnet prefix configured on this interface should be of length >> /128. > An IPv6 link-local address has prefix length /64, not /128. >From RFC 4291 2.5.6. Link-Local IPv6 Unicast Addresses Link-Local addresses are for use on a single link. Link-Local addresses have the following format: | 10 | | bits | 54 bits | 64 bits | +----------+-------------------------+----------------------------+ |1111111010| 0 | interface ID | +----------+-------------------------+----------------------------+ That shows a single link local address as being taken from a particular /64 allocation (fe80::/64) with a chosen interface ID (which would then make it a /128), not as being a /64. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From ulrich@herberg.name Thu Jul 23 07:44:57 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A73E33A682B for ; Thu, 23 Jul 2009 07:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvHTMNI59E7C for ; Thu, 23 Jul 2009 07:44:57 -0700 (PDT) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id A5D673A63EB for ; Thu, 23 Jul 2009 07:44:56 -0700 (PDT) Received: by bwz28 with SMTP id 28so861407bwz.37 for ; Thu, 23 Jul 2009 07:43:41 -0700 (PDT) MIME-Version: 1.0 Sender: ulrich@herberg.name Received: by 10.204.71.15 with SMTP id f15mr2147186bkj.113.1248360221703; Thu, 23 Jul 2009 07:43:41 -0700 (PDT) In-Reply-To: <4A6871C7.8090802@gmail.com> References: <4A6596CD.9040404@gmail.com> <4A676115.8060202@earthlink.net> <4A6765D7.8080608@gmail.com> <4A6771FF.8030104@earthlink.net> <4A677F69.9080006@gmail.com> <4A678BA9.8050408@earthlink.net> <4A6820E3.5070801@gmail.com> <25c114b90907230711i719750bbr20b2a81dd22dbd05@mail.gmail.com> <4A6871C7.8090802@gmail.com> Date: Thu, 23 Jul 2009 16:43:41 +0200 X-Google-Sender-Auth: 7964615c8bf0a92f Message-ID: <25c114b90907230743t61e1806at2ff50a7aff0d5ef9@mail.gmail.com> From: Ulrich Herberg To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=0016e6de0033910103046f608328 Cc: "Dearlove, Christopher \(UK\)" , autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 14:44:57 -0000 --0016e6de0033910103046f608328 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable No. It says: (in the appendix) "the use of link local addresses on interfaces connecting to a MANET link i= s not prohibited" Ulrich On Thu, Jul 23, 2009 at 4:20 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Ulrich Herberg a =E9crit : > >> I agree with Stan and Chris, that we should move forward with the points >> we have agreed on in the strawman draft and continue the discussion abou= t >> link-local addresses later, as soon as we have understood better how to >> solve the issues with these addresses in autoconf. >> > > The draft forbids the IPv6 link-local addresses - do you agree with that? > > Alex > > > --0016e6de0033910103046f608328 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable No. It says: (in the appendix)

"the use of link local addresses= on interfaces connecting to a MANET link is not prohibited"

Ul= rich

On Thu, Jul 23, 2009 at 4:20 PM, Ale= xandru Petrescu <alexandru.petrescu@gmail.com> wrote:
Ulrich Herberg a = =E9crit :

I agree with Stan and Chris, that we should move forward with the points we= have agreed on in the strawman draft and continue the discussion about lin= k-local addresses later, as soon as we have understood better how to solve = the issues with these addresses in autoconf.

The draft forbids the IPv6 link-local addresses - do you agree with that?
Alex



--0016e6de0033910103046f608328-- From alexandru.petrescu@gmail.com Thu Jul 23 07:48:57 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0675C3A6A14 for ; Thu, 23 Jul 2009 07:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1F6eydx+xGZv for ; Thu, 23 Jul 2009 07:48:56 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 00F533A6987 for ; Thu, 23 Jul 2009 07:48:48 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6NEjZK9014171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Jul 2009 16:45:35 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6NEjYom008681; Thu, 23 Jul 2009 16:45:34 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6NEjYll008470; Thu, 23 Jul 2009 16:45:34 +0200 Message-ID: <4A68778E.4010005@gmail.com> Date: Thu, 23 Jul 2009 16:45:34 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Ulrich Herberg References: <4A6596CD.9040404@gmail.com> <4A676115.8060202@earthlink.net> <4A6765D7.8080608@gmail.com> <4A6771FF.8030104@earthlink.net> <4A677F69.9080006@gmail.com> <4A678BA9.8050408@earthlink.net> <4A6820E3.5070801@gmail.com> <25c114b90907230711i719750bbr20b2a81dd22dbd05@mail.gmail.com> <4A6871C7.8090802@gmail.com> <25c114b90907230743t61e1806at2ff50a7aff0d5ef9@mail.gmail.com> In-Reply-To: <25c114b90907230743t61e1806at2ff50a7aff0d5ef9@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "Dearlove, Christopher \(UK\)" , autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 14:48:57 -0000 Ulrich Herberg a écrit : > No. It says: (in the appendix) > > "the use of link local addresses on interfaces connecting to a MANET > link is not prohibited" 1 - in appendix it is too late, too far from first read. 2 - appendix contradicts section 6.2 Alex From alexandru.petrescu@gmail.com Thu Jul 23 07:54:25 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC6913A68B3 for ; Thu, 23 Jul 2009 07:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.364 X-Spam-Level: X-Spam-Status: No, score=-1.364 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_54=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgXmelKTcxZ7 for ; Thu, 23 Jul 2009 07:54:25 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id B4BFD3A63EB for ; Thu, 23 Jul 2009 07:54:23 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6NEqFm8024482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Jul 2009 16:52:15 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6NEqE5E010162; Thu, 23 Jul 2009 16:52:15 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6NEqEOt021016; Thu, 23 Jul 2009 16:52:14 +0200 Message-ID: <4A68791E.4020307@gmail.com> Date: Thu, 23 Jul 2009 16:52:14 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net><4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net><4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net><4A66E420.8040604@gmail.com> <4A672731.9040009@earthlink.net><4A672B8A.5000200@gmail.com> <4A673EF1.1020706@earthlink.net><4A6753B2.9040109@gmail.com> <4A676115.8060202@earthlink.net><4A6765D7.8080608@gmail.com> <4A6771FF.8030104@earthlink.net><4A677F69.9080006@gmail.com> <4A678BA9.8050408@earthlink.net> <4A6820E3.5070801@gmail.com> <4A68718E.2010700@gmail.com> <4A68732C.2000300@cea.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 14:54:26 -0000 Dearlove, Christopher (UK) a écrit : > Alexandru: >> Dearlove, Christopher (UK) a écrit : >>> Alexandru >>>> the draft forbidding link-locals >>> Where? > >> Section 6.2: >>> 6.2. IPv6 Model >>> >>> For IPv6, the principles described in Section 4 and Section 5 >>> translate as such: >>> >>> o An IP address configured on this interface should be unique, at >>> least within the routing domain, and >>> >>> o A subnet prefix configured on this interface should be of length >>> /128. > >> An IPv6 link-local address has prefix length /64, not /128. > >>From RFC 4291 > > 2.5.6. Link-Local IPv6 Unicast Addresses > > Link-Local addresses are for use on a single link. Link-Local > addresses have the following format: > > | 10 | > | bits | 54 bits | 64 bits | > +----------+-------------------------+----------------------------+ > |1111111010| 0 | interface ID | > +----------+-------------------------+----------------------------+ > > > That shows a single link local address as being taken from a particular > /64 allocation (fe80::/64) with a chosen interface ID (which would then > make it a /128), not as being a /64. Does that make the IPv6 link-local address have a /128 subnet prefix? I doubt so. What do you mean by "A subnet prefix configured on this interface should be of length /128."? By "a subnet prefix configured on an interface" I thought you mean that number after the slash, near the address. For example, if I say: # ifconfig eth0 adr inet6: fe80::210:b5ff:fe40:b704/64 Scope:Lien Then the "subnet prefix configured on an interface" is that /64 appearing above. What do you mean by "subnet prefix configured on an interface"? Alex From roque.rafael@gmail.com Thu Jul 23 08:00:25 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 351B43A6A8F for ; Thu, 23 Jul 2009 08:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRdixFYFa64D for ; Thu, 23 Jul 2009 08:00:24 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 16ADB3A6856 for ; Thu, 23 Jul 2009 08:00:23 -0700 (PDT) Received: by fxm18 with SMTP id 18so877510fxm.37 for ; Thu, 23 Jul 2009 07:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ds+r0xnqrxJkhfyqj7EwqrVlUHOZXtKdjI0eaIQ5iIM=; b=qSZSslB56yj+fwbKcW/elAcncyzK7iQkHVjEWEAIEsJbRLuwZzvwWuYJwqCPLfLLSL z4uj3SzJPR0tHM8SCxrAuY9k5rTOkwXt8uJ9ttRdGP1A5VfAilKLHzkahGtUEtjiw8Df 9HMZpg6H1WVCigptV2zbPdbDcCZgJb2PV5R6I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fgSArkko5aFaZCfgGiwUtsGu6/mIBDJTNntqM3XcCf+yBxJ3Pc/g4kma5LnPfY8BgD kkNP4KkEP6H9Otszz2WjRrSzDg3prVSCmlaje1AcBTTQT6FKogEYY/qMtGnoX5C3MYq2 LWG8fJ2TTs+o/4wp/JAX0sH6y/dO12CAAY8qY= MIME-Version: 1.0 Received: by 10.204.71.15 with SMTP id f15mr2130210bkj.42.1248360659644; Thu, 23 Jul 2009 07:50:59 -0700 (PDT) In-Reply-To: <003701ca0b9d$c00192a0$4004b7e0$@nl> References: <4A4CECCF.1030202@earthlink.net> <005001c9fbb6$bcfa9c10$36efd430$@nl> <4A4E25C0.5010201@computer.org> <00e601c9fc8f$42097a10$c61c6e30$@nl> <4A536396.5060108@computer.org> <005d01ca0b19$f3da0500$db8e0f00$@nl> <4A67A18C.20202@earthlink.net> <001001ca0b5f$4179a410$c46cec30$@nl> <1726274c0907230613h4db6d6c8l7a5aaa175a89ebe0@mail.gmail.com> <003701ca0b9d$c00192a0$4004b7e0$@nl> Date: Thu, 23 Jul 2009 11:50:59 -0300 Message-ID: <1726274c0907230750p4ab8d64ewa0b5248fe2deaa70@mail.gmail.com> From: Rafael Roque To: Teco Boot Content-Type: multipart/alternative; boundary=0016e6de0033ab7945046f609d8e Cc: autoconf@ietf.org Subject: Re: [Autoconf] On-link, X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 15:00:25 -0000 --0016e6de0033ab7945046f609d8e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Teco, Teco: > I dislike "same cell" > I think confusing is caused by not using definitions. > "On link" means to me having an interface to a communication facility, > e.g. "connected to link". This does not imply connectivity. > I think Charlie has a different opinion on what "on link" means. > thanks for this explanation, by not using definitions is really a problem. --0016e6de0033ab7945046f609d8e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Teco,

Teco:
I dislike "same ce= ll"
I think confusing is caused by not using definitions.
"= On link" means to me having an interface to a communication facility,<= br> e.g. "connected to link". This does not imply connectivity.
I = think Charlie has a different opinion on what "on link" means.
thanks for this explanation, by not using definitions is really a prob= lem.
=A0
=A0
--0016e6de0033ab7945046f609d8e-- From Chris.Dearlove@baesystems.com Thu Jul 23 08:01:26 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45D0D3A6A14 for ; Thu, 23 Jul 2009 08:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZpueFVhdV-L for ; Thu, 23 Jul 2009 08:01:25 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 57F9A3A68B3 for ; Thu, 23 Jul 2009 08:01:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,255,1246834800"; d="scan'208";a="13799781" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 23 Jul 2009 16:00:45 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.0/Switch-3.4.0) with ESMTP id n6NF0oE4006265; Thu, 23 Jul 2009 16:00:50 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Jul 2009 16:00:45 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 23 Jul 2009 16:00:44 +0100 Message-ID: In-Reply-To: <4A68791E.4020307@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?iso-8859-1?Q?=5BAutoconf=5D_Link-locals_vis-=E0-vis_the_new_=5Bautoconf?= =?iso-8859-1?Q?=5D_document?= thread-index: AcoLpS4ZOS2/HgocTMiGVVKEyA2dngAABbvA References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net><4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net><4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net><4A66E420.8040604@gmail.com> <4A672731.9040009@earthlink.net><4A672B8A.5000200@gmail.com> <4A673EF1.1020706@earthlink.net><4A6753B2.9040109@gmail.com> <4A676115.8060202@earthlink.net><4A6765D7.8080608@gmail.com> <4A6771FF.8030104@earthlink.net><4A677F69.9080006@gmail.com> <4A678BA9.8050408@earthlink.net> <4A6820E3.5070801@gmail.com> <4A68718E.2010700@gmail.com> <4A68732C.2000300@cea.fr> <4A68791E.4020307@gmai! l.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 23 Jul 2009 15:00:45.0122 (UTC) FILETIME=[5AE9AA20:01CA0BA6] Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 15:01:26 -0000 > What do you mean by "A subnet prefix configured on this interface should > be of length /128."? Ask the people who wrote the draft. But note that they include some people who know rather a lot about IP, who don't see a contradiction in what they wrote, and who commented that link local addresses are allowed; and also include some staunch supporters of link local addressing who wrote (or agreed to be an author of a document containing those words) what's there with that background. > By "a subnet prefix configured on an interface" I thought you mean that Again, try asking the people who wrote the draft, with whom you are confusing me. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From alexandru.petrescu@gmail.com Thu Jul 23 08:03:57 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2E833A69F2 for ; Thu, 23 Jul 2009 08:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.663 X-Spam-Level: X-Spam-Status: No, score=-1.663 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyDTF2Zx3Jdd for ; Thu, 23 Jul 2009 08:03:57 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 542673A6AE8 for ; Thu, 23 Jul 2009 08:03:45 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6NF2fLe014308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Jul 2009 17:02:41 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6NF2fHq012217; Thu, 23 Jul 2009 17:02:41 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6NF2eCZ013179; Thu, 23 Jul 2009 17:02:41 +0200 Message-ID: <4A687B91.7090003@gmail.com> Date: Thu, 23 Jul 2009 17:02:41 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <4A6596CD.9040404@gmail.com><4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net><4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net><4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net><4A66E420.8040604@gmail.com> <4A672731.9040009@earthlink.net><4A672B8A.5000200@gmail.com> <4A673EF1.1020706@earthlink.net><4A6753B2.9040109@gmail.com> <4A676115.8060202@earthlink.net><4A6765D7.8080608@gmail.com> <4A6771FF.8030104@earthlink.net><4A677F69.9080006@gmail.com> <4A678BA9.8050408@earthlink.net> <4A6820E3.5070801@gmail.com> <4A68718E.2010700@gmail.com> <4A68732C.2000300@cea.fr> <4A68791E.4020307@gmai! l.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 15:03:57 -0000 Dearlove, Christopher (UK) a écrit : >> What do you mean by "A subnet prefix configured on this interface should >> be of length /128."? > > Ask the people who wrote the draft. But note that they include > some people who know rather a lot about IP, who don't see a > contradiction in what they wrote, and who commented that link > local addresses are allowed; and also include some staunch > supporters of link local addressing who wrote (or agreed to > be an author of a document containing those words) what's > there with that background. > >> By "a subnet prefix configured on an interface" I thought you mean that > > Again, try asking the people who wrote the draft, with whom > you are confusing me. I think they're on the list. Alex From alexandru.petrescu@gmail.com Thu Jul 23 08:12:36 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DA6F3A6A62 for ; Thu, 23 Jul 2009 08:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgUJcbSvsVB5 for ; Thu, 23 Jul 2009 08:12:35 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 73B6B3A6955 for ; Thu, 23 Jul 2009 08:12:35 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6NEKu6k008516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Jul 2009 16:20:56 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6NEKuI5002692; Thu, 23 Jul 2009 16:20:56 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6NEKtgN000361; Thu, 23 Jul 2009 16:20:56 +0200 Message-ID: <4A6871C7.8090802@gmail.com> Date: Thu, 23 Jul 2009 16:20:55 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Ulrich Herberg References: <4A6596CD.9040404@gmail.com> <4A673EF1.1020706@earthlink.net> <4A6753B2.9040109@gmail.com> <4A676115.8060202@earthlink.net> <4A6765D7.8080608@gmail.com> <4A6771FF.8030104@earthlink.net> <4A677F69.9080006@gmail.com> <4A678BA9.8050408@earthlink.net> <4A6820E3.5070801@gmail.com> <25c114b90907230711i719750bbr20b2a81dd22dbd05@mail.gmail.com> In-Reply-To: <25c114b90907230711i719750bbr20b2a81dd22dbd05@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "Dearlove, Christopher \(UK\)" , autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 15:12:36 -0000 Ulrich Herberg a écrit : > I agree with Stan and Chris, that we should move forward with the points > we have agreed on in the strawman draft and continue the discussion > about link-local addresses later, as soon as we have understood better > how to solve the issues with these addresses in autoconf. The draft forbids the IPv6 link-local addresses - do you agree with that? Alex From alexandru.petrescu@gmail.com Thu Jul 23 08:21:22 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C14A3A6856 for ; Thu, 23 Jul 2009 08:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.687 X-Spam-Level: X-Spam-Status: No, score=-1.687 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 996Rl9yXKtVQ for ; Thu, 23 Jul 2009 08:21:21 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 4C4183A67B3 for ; Thu, 23 Jul 2009 08:21:20 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6NETeuW017156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Jul 2009 16:29:40 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6NETdq1004742; Thu, 23 Jul 2009 16:29:40 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6NETdd2013908; Thu, 23 Jul 2009 16:29:39 +0200 Message-ID: <4A6873D3.7080106@gmail.com> Date: Thu, 23 Jul 2009 16:29:39 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net><4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net><4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net><4A66E420.8040604@gmail.com> <4A672731.9040009@earthlink.net><4A672B8A.5000200@gmail.com> <4A673EF1.1020706@earthlink.net><4A6753B2.9040109@gmail.com> <4A676115.8060202@earthlink.net><4A6765D7.8080608@gmail.com> <4A6771FF.8030104@earthlink.net><4A677F69.9080006@gmail.com> <4A678BA9.8050408@earthlink.net> <4A6820E3.5070801@gmail.com> <4A68718E.2010700@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 15:21:22 -0000 Dearlove, Christopher (UK) a écrit : > Alexandru >> the draft forbidding link-locals > > Where? Section 6.2: > 6.2. IPv6 Model > > For IPv6, the principles described in Section 4 and Section 5 > translate as such: > > o An IP address configured on this interface should be unique, at > least within the routing domain, and > > o A subnet prefix configured on this interface should be of length > /128. > [end of section] An IPv6 link-local address has prefix length /64, not /128. What do you think? Alex From charles.perkins@earthlink.net Thu Jul 23 10:02:48 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47DB03A6B38 for ; Thu, 23 Jul 2009 10:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsWLFnnxudoV for ; Thu, 23 Jul 2009 10:02:47 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 900F13A6B44 for ; Thu, 23 Jul 2009 10:02:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=YNXJ/k/X8KxEUNjQ6yce7Z57EbZKWbToup65urmiM1eTz6Y9JENLG944Ikw8e5Ui; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.74.16] (helo=[192.168.1.105]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MU1gg-0000u2-13; Thu, 23 Jul 2009 13:02:34 -0400 Message-ID: <4A6897A8.5090109@earthlink.net> Date: Thu, 23 Jul 2009 10:02:32 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Alexandru Petrescu References: <4A6596CD.9040404@gmail.com> <4A673EF1.1020706@earthlink.net> <4A6753B2.9040109@gmail.com> <4A676115.8060202@earthlink.net> <4A6765D7.8080608@gmail.com> <4A6771FF.8030104@earthlink.net> <4A677F69.9080006@gmail.com> <4A678BA9.8050408@earthlink.net> <4A6820E3.5070801@gmail.com> <25c114b90907230711i719750bbr20b2a81dd22dbd05@mail.gmail.com> <4A6871C7.8090802@gmail.com> In-Reply-To: <4A6871C7.8090802@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52395d67279047e7f2e888937c24b42ba3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 17:02:48 -0000 Hello Alex, Alexandru Petrescu wrote: > Ulrich Herberg a écrit : >> I agree with Stan and Chris, that we should move forward with the >> points we have agreed on in the strawman draft and continue the >> discussion about link-local addresses later, as soon as we have >> understood better how to solve the issues with these addresses in >> autoconf. > > The draft forbids the IPv6 link-local addresses - do you agree with that? I don't agree with this. Instead, I understand that the draft does not specify how to use link-locals, but does not prohibit their use. Regards, Charlie P. From alexandru.petrescu@gmail.com Thu Jul 23 10:49:39 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 543373A69C0 for ; Thu, 23 Jul 2009 10:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.567 X-Spam-Level: X-Spam-Status: No, score=-0.567 tagged_above=-999 required=5 tests=[AWL=-0.732, BAYES_40=-0.185, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjI0XNqoSinY for ; Thu, 23 Jul 2009 10:49:38 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id E40CF3A6A11 for ; Thu, 23 Jul 2009 10:48:36 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 390A4D48094; Thu, 23 Jul 2009 19:47:34 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 23B58D48130; Thu, 23 Jul 2009 19:47:31 +0200 (CEST) Message-ID: <4A68A233.9010400@gmail.com> Date: Thu, 23 Jul 2009 19:47:31 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> <4A66E420.8040604@gmail.com> <4A672731.9040009@earthlink.net> <4A672B8A.5000200@gmail.com> <4A673EF1.1020706@earthlink.net> <4A6753B2.9040109@gmail.com> <4A676115.8060202@earthlink.net> <4A6765D7.8080608@gmail.com> <4A6771FF.8030104@earthlink.net> <4A677F69.9080006@gmail.com> <4A678BA9.8050408@earthlink.net> <4A6820E3.5070801@gmail.com> <4A689DB6.6000701@earthlink.net> In-Reply-To: <4A689DB6.6000701@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 090722-0, 22/07/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: [Autoconf] IPv6 ad-hoc network nodes that DON'T self-form any IPv6 link-local address X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 17:49:39 -0000 AUTOCONFers, [...] >>> o An ad-hoc network node self-forms an IPv6 link-local address >>> for each of its interfaces. The procedure is described in the >>> document relevant to the interface type. For example, a WiFi >>> interface should use RFC2464; for a PPP link see RFC5072. For a >>> more exhaustive list of links see RFCXXXX. > > But what about nodes in an ad-hoc network that DON'T self-form any > IPv6 link-local address? I would like to get a sense from the list about ad-hoc network nodes which don't self-form an IPv6 link-local address for themselves. I have my own oppinions about such nodes that I am ready to share on the list, but I would like to see first what people on this list think about ad-hoc network nodes that don't self-form any link-local address? Can such node exist? Would a software knob allow for it? Would other RFCs be influenced by this absence, etc. Any oppinion on this topic? thanks Alex From charles.perkins@earthlink.net Thu Jul 23 10:55:55 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 280C13A6B83 for ; Thu, 23 Jul 2009 10:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxOF8gyRDf5g for ; Thu, 23 Jul 2009 10:55:54 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id DB8663A6B5F for ; Thu, 23 Jul 2009 10:53:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=SQl5t2BADbyDkwLcOzthgbB4YQ82yCODaSgw25qx61fo+USQA33376n8RVBa9vDn; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.74.16] (helo=[192.168.1.105]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MU25g-0002tq-9m; Thu, 23 Jul 2009 13:28:24 -0400 Message-ID: <4A689DB6.6000701@earthlink.net> Date: Thu, 23 Jul 2009 10:28:22 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Alexandru Petrescu References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> <4A66E420.8040604@gmail.com> <4A672731.9040009@earthlink.net> <4A672B8A.5000200@gmail.com> <4A673EF1.1020706@earthlink.net> <4A6753B2.9040109@gmail.com> <4A676115.8060202@earthlink.net> <4A6765D7.8080608@gmail.com> <4A6771FF.8030104@earthlink.net> <4A677F69.9080006@gmail.com> <4A678BA9.8050408@earthlink.net> <4A6820E3.5070801@gmail.com> In-Reply-To: <4A6820E3.5070801@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52d68ce5f12847fd78cacdb9fabc31518b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 17:55:55 -0000 Hello Alex, I don't think you can get consensus on any text that mandates the use of link-locals. You should try to devise some text that makes it clear that they are allowable, but not always mandated. Alexandru Petrescu wrote: >> >> ... perhaps you could take the initiative to craft >> some new text that (a) does make use of the long discussion >> about link-locals and (b) helps us to progress towards a >> resolution and common understanding. > > How about this text which says IPv6 link-local addresses are > recommended when the link layer has determined connectivity properties. > > New: > > 6.2. IPv6 Model > > > > > > For IPv6, the principles described in Section 4 and Section 5 > > translate partially as follows: > > > > o An ad-hoc network node self-forms an IPv6 link-local address for > > each of its interfaces. The procedure is described in the > > document relevant to the interface type. For example, a WiFi > > interface should use RFC2464; for a PPP link see RFC5072. For a > > more exhaustive list of links see RFCXXXX. But what about nodes in an ad-hoc network that DON'T self-form any IPv6 link-local address? > > > > This IPv6 link-local address are recommended when the link-layer > > has determined connectivity properties. That's not going to work. You have to say what the connectivity properties are. "determined" is quite bad for this -- the connectivity properties could be determined to be useless or even harmful. > > > > > o An IP address configured on this interface should be unique, at > > least within the routing domain, and > > > > o A subnet prefix configured on this interface should be of length > > /128 (except, of course, the IPv6 link-local addresses whose > > prefix is /10). This would be O.K. as long as we are clear that there are some MANET interfaces for which link-locals may remain unconfigured. Regards, Charlie P. From charles.perkins@earthlink.net Thu Jul 23 10:55:55 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4FA93A6B83 for ; Thu, 23 Jul 2009 10:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5+EHrjzYEwH for ; Thu, 23 Jul 2009 10:55:55 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 1338A3A6BD3 for ; Thu, 23 Jul 2009 10:54:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=c7nlGDF4t4wR53QZeWvz/xSTcBeblOAbOqlg/s/CyLYVnStGtJUrlbM2x7E1clRI; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.74.16] (helo=[192.168.1.105]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MU1wh-0007LA-Jy; Thu, 23 Jul 2009 13:19:07 -0400 Message-ID: <4A689B8A.5020705@earthlink.net> Date: Thu, 23 Jul 2009 10:19:06 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Alexandru Petrescu References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net><4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net><4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net><4A66E420.8040604@gmail.com> <4A672731.9040009@earthlink.net><4A672B8A.5000200@gmail.com> <4A673EF1.1020706@earthlink.net><4A6753B2.9040109@gmail.com> <4A676115.8060202@earthlink.net><4A6765D7.8080608@gmail.com> <4A6771FF.8030104@earthlink.net><4A677F69.9080006@gmail.com> <4A678BA9.8050408@earthlink.net> <4A6820E3.5070801@gmail.com> <4A68718E.2010700@gmail.com> <4A68732C.2000300@cea.fr> <4A68791E.4020307@gmail .com> In-Reply-To: <4A68791E.4020307@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f522ce531434044b5d94ff6719a4a0d3cc8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 17:55:55 -0000 Hello Alex, Alexandru Petrescu wrote: > By "a subnet prefix configured on an interface" I thought you mean > that number after the slash, near the address. For example, if I say: > > # ifconfig eth0 > adr inet6: fe80::210:b5ff:fe40:b704/64 Scope:Lien > > Then the "subnet prefix configured on an interface" is that /64 > appearing above .... I also think this is what "subnet prefix" means. Regards, Charlie P. From teco@inf-net.nl Thu Jul 23 10:55:56 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EE193A6BA1 for ; Thu, 23 Jul 2009 10:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.805 X-Spam-Level: X-Spam-Status: No, score=-1.805 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkvXkFTmHB2H for ; Thu, 23 Jul 2009 10:55:55 -0700 (PDT) Received: from CPSMTPM-EML103.kpnxchange.com (cpsmtpm-eml103.kpnxchange.com [195.121.3.7]) by core3.amsl.com (Postfix) with ESMTP id 826A73A6BD6 for ; Thu, 23 Jul 2009 10:54:03 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML103.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Thu, 23 Jul 2009 19:53:02 +0200 From: "Teco Boot" To: "'Charles E. Perkins'" , "'Alexandru Petrescu'" References: <4A6596CD.9040404@gmail.com> <4A673EF1.1020706@earthlink.net> <4A6753B2.9040109@gmail.com> <4A676115.8060202@earthlink.net> <4A6765D7.8080608@gmail.com> <4A6771FF.8030104@earthlink.net> <4A677F69.9080006@gmail.com> <4A678BA9.8050408@earthlink.net> <4A6820E3.5070801@gmail.com> <25c114b90907230711i719750bbr20b2a81dd22dbd05@mail.gmail.com> <4A6871C7.8090802@gmail.com> <4A6897A8.5090109@earthlink.net> In-Reply-To: <4A6897A8.5090109@earthlink.net> Date: Thu, 23 Jul 2009 19:52:49 +0200 Message-ID: <000901ca0bbe$6487beb0$2d973c10$@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: AcoLt2vcIYS5sBgvSX6YHAH6WgHPBwABisWw Content-Language: nl X-OriginalArrivalTime: 23 Jul 2009 17:53:02.0862 (UTC) FILETIME=[6CAF9AE0:01CA0BBE] Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 17:55:56 -0000 The draft does not recommend link-locals. I recommend usage of link-locals. Some posting say there are issues with link-locals. But what those are = is vague or not true. For example, I don't see much difference in duplicate avoidance between link-locals and globals. And this is not something to discuss right now, as posted a few times. In DT I felt a bit lonely. Now on ML, I see neutral opinions or recommendations for link-locals. =20 Teco. =20 |-----Oorspronkelijk bericht----- |Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] = Namens |Charles E. Perkins |Verzonden: donderdag 23 juli 2009 19:03 |Aan: Alexandru Petrescu |CC: autoconf@ietf.org |Onderwerp: Re: [Autoconf] Link-locals vis-=E0-vis the new [autoconf] |document | | |Hello Alex, | |Alexandru Petrescu wrote: |> Ulrich Herberg a =E9crit : |>> I agree with Stan and Chris, that we should move forward with the |>> points we have agreed on in the strawman draft and continue the |>> discussion about link-local addresses later, as soon as we have |>> understood better how to solve the issues with these addresses in |>> autoconf. |> |> The draft forbids the IPv6 link-local addresses - do you agree with |that? | |I don't agree with this. Instead, I understand that the |draft does not specify how to use link-locals, but does |not prohibit their use. | |Regards, |Charlie P. | |_______________________________________________ |Autoconf mailing list |Autoconf@ietf.org |https://www.ietf.org/mailman/listinfo/autoconf From alexandru.petrescu@gmail.com Thu Jul 23 11:10:09 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B06A3A688C for ; Thu, 23 Jul 2009 11:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.478 X-Spam-Level: X-Spam-Status: No, score=-1.478 tagged_above=-999 required=5 tests=[AWL=0.471, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwJA8fJmWJc8 for ; Thu, 23 Jul 2009 11:10:08 -0700 (PDT) Received: from smtpfb1-g21.free.fr (smtpfb1-g21.free.fr [212.27.42.9]) by core3.amsl.com (Postfix) with ESMTP id D920D3A69C0 for ; Thu, 23 Jul 2009 11:10:06 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by smtpfb1-g21.free.fr (Postfix) with ESMTP id 5552B2DE78 for ; Thu, 23 Jul 2009 19:42:50 +0200 (CEST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id D7BDDD4812B; Thu, 23 Jul 2009 19:42:17 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 546B0D48167; Thu, 23 Jul 2009 19:42:14 +0200 (CEST) Message-ID: <4A68A0F5.2050806@gmail.com> Date: Thu, 23 Jul 2009 19:42:13 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> <4A66E420.8040604@gmail.com> <4A672731.9040009@earthlink.net> <4A672B8A.5000200@gmail.com> <4A673EF1.1020706@earthlink.net> <4A6753B2.9040109@gmail.com> <4A676115.8060202@earthlink.net> <4A6765D7.8080608@gmail.com> <4A6771FF.8030104@earthlink.net> <4A677F69.9080006@gmail.com> <4A678BA9.8050408@earthlink.net> <4A6820E3.5070801@gmail.com> <4A689DB6.6000701@earthlink.net> In-Reply-To: <4A689DB6.6000701@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090722-0, 22/07/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 18:10:09 -0000 Charles E. Perkins a écrit : > > Hello Alex, > > I don't think you can get consensus on any text that > mandates the use of link-locals. You should try to devise > some text that makes it clear that they are allowable, > but not always mandated. Ok let's see... Alex > > Alexandru Petrescu wrote: >>> >>> ... perhaps you could take the initiative to craft >>> some new text that (a) does make use of the long discussion >>> about link-locals and (b) helps us to progress towards a >>> resolution and common understanding. >> >> How about this text which says IPv6 link-local addresses are >> recommended when the link layer has determined connectivity properties. >> >> New: >> > 6.2. IPv6 Model >> > >> > >> > For IPv6, the principles described in Section 4 and Section 5 >> > translate partially as follows: >> > >> > o An ad-hoc network node self-forms an IPv6 link-local address for >> > each of its interfaces. The procedure is described in the >> > document relevant to the interface type. For example, a WiFi >> > interface should use RFC2464; for a PPP link see RFC5072. For a >> > more exhaustive list of links see RFCXXXX. > > But what about nodes in an ad-hoc network that DON'T self-form > any IPv6 link-local address? >> > >> > This IPv6 link-local address are recommended when the link-layer >> > has determined connectivity properties. > > That's not going to work. You have to say what the > connectivity properties are. "determined" is quite bad > for this -- the connectivity properties could be determined > to be useless or even harmful. >> >> > >> > o An IP address configured on this interface should be unique, at >> > least within the routing domain, and >> > >> > o A subnet prefix configured on this interface should be of length >> > /128 (except, of course, the IPv6 link-local addresses whose >> > prefix is /10). > > This would be O.K. as long as we are clear that there are > some MANET interfaces for which link-locals may remain > unconfigured. > > Regards, > Charlie P. > > > From sratliff@cisco.com Thu Jul 23 11:14:30 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93D7528C15F for ; Thu, 23 Jul 2009 11:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.987 X-Spam-Level: X-Spam-Status: No, score=-5.987 tagged_above=-999 required=5 tests=[AWL=0.612, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60dWdsoo783l for ; Thu, 23 Jul 2009 11:14:29 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id CC25F3A6BC6 for ; Thu, 23 Jul 2009 11:13:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAINFaEpAZnmf/2dsb2JhbAC5WIglkRMFhA2BSA X-IronPort-AV: E=Sophos;i="4.43,256,1246838400"; d="scan'208";a="179115614" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-3.cisco.com with ESMTP; 23 Jul 2009 18:13:28 +0000 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 n6NIDSwl018028; Thu, 23 Jul 2009 14:13:28 -0400 Received: from [10.116.179.218] (rtp-sratliff-8719.cisco.com [10.116.179.218]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6NIDR6S017304; Thu, 23 Jul 2009 18:13:27 GMT Message-ID: <4A68A847.4020500@cisco.com> Date: Thu, 23 Jul 2009 14:13:27 -0400 From: Stan Ratliff User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Alexandru Petrescu References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> <4A66E420.8040604@gmail.com> <4A672731.9040009@earthlink.net> <4A672B8A.5000200@gmail.com> <4A673EF1.1020706@earthlink.net> <4A6753B2.9040109@gmail.com> <4A676115.8060202@earthlink.net> <4A6765D7.8080608@gmail.com> <4A6771FF.8030104@earthlink.net> <4A677F69.9080006@gmail.com> <4A678BA9.8050408@earthlink.net> <4A6820E3.5070801@gmail.com> <4A689DB6.6000701@earthlink.net> <4A68A233.9010400@gmail.com> In-Reply-To: <4A68A233.9010400@gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2295; t=1248372808; x=1249236808; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20Stan=20Ratliff=20 |Subject:=20Re=3A=20[Autoconf]=20IPv6=20ad-hoc=20network=20 nodes=20that=20DON'T=20self-form=20any=0A=20IPv6=20link-loca l=20address |Sender:=20 |To:=20Alexandru=20Petrescu=20; bh=nulKWTBQB8MpGZx8RcQvDHMryvfT4AfmH4NCfzlWV1I=; b=RD5B9blUw9R0XCMmhNneTKNw0MMbwIiAb3t7KpQoLhi7NjJM24s02s+H4V FZ0jhL/wQAYidxpEKwNzJ0E0vUiCiHIrGtf0rhcFS3zBYMWG7Ko/ZY+dX80s 7iLXIpgc9x; Authentication-Results: rtp-dkim-2; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: autoconf@ietf.org Subject: Re: [Autoconf] IPv6 ad-hoc network nodes that DON'T self-form any IPv6 link-local address X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 18:14:30 -0000 Alex, I've deployed MANET networks without IPV6 link local addresses, and they work just fine. Specifically, my deployments have used pre-configured IPV4 addresses. Oh, and by the way, we used /32 prefixes on the "MANET interfaces" as well. :-) In case it matters, the IPV4 deployments I speak of use EIGRP as the routing protocol (I know, it's not an IETF standard, but it works.) I've also deployed MANET networks using V6 link-local addresses. In these cases, we use the "Overlapping Relays" modification to OSPFv3 that was submitted to the OSPF WG (I believe that an experimental RFC number is pending on that draft). As in the V4 case, the V6 link-locals work like a champ. To reiterate, I'm OK with the draft as-written. It does *NOT* preclude the use of V6 link locals. As you rightly mention, it does not discuss V6 link-locals until you get to the appendix. But with it being only a 6 page draft, I don't see the reference in the appendix as a problem -- IMO, if you're going to "skim" a 6 page draft, you deserve whatever trap you fall into because of it. Regards, Stan Alexandru Petrescu wrote: > AUTOCONFers, > > [...] >>>> o An ad-hoc network node self-forms an IPv6 link-local address for >>>> each of its interfaces. The procedure is described in the document >>>> relevant to the interface type. For example, a WiFi interface >>>> should use RFC2464; for a PPP link see RFC5072. For a >>>> more exhaustive list of links see RFCXXXX. >> >> But what about nodes in an ad-hoc network that DON'T self-form any >> IPv6 link-local address? > > I would like to get a sense from the list about ad-hoc network nodes > which don't self-form an IPv6 link-local address for themselves. > > I have my own oppinions about such nodes that I am ready to share on the > list, but I would like to see first what people on this list think about > ad-hoc network nodes that don't self-form any link-local address? Can > such node exist? Would a software knob allow for it? Would other RFCs > be influenced by this absence, etc. > > Any oppinion on this topic? thanks > > Alex > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From alexandru.petrescu@gmail.com Thu Jul 23 11:53:19 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB1AA3A6B32 for ; Thu, 23 Jul 2009 11:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.812 X-Spam-Level: X-Spam-Status: No, score=-0.812 tagged_above=-999 required=5 tests=[AWL=-0.352, BAYES_05=-1.11, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDRDdiFkn2u4 for ; Thu, 23 Jul 2009 11:53:19 -0700 (PDT) Received: from smtpfb2-g21.free.fr (smtpfb2-g21.free.fr [212.27.42.10]) by core3.amsl.com (Postfix) with ESMTP id BF34D3A6AF3 for ; Thu, 23 Jul 2009 11:53:17 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by smtpfb2-g21.free.fr (Postfix) with ESMTP id 34A73CA88AD for ; Thu, 23 Jul 2009 20:40:13 +0200 (CEST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id B8E6CD48169; Thu, 23 Jul 2009 20:39:40 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 7D416D4813D; Thu, 23 Jul 2009 20:39:37 +0200 (CEST) Message-ID: <4A68AE68.2040205@gmail.com> Date: Thu, 23 Jul 2009 20:39:36 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> <4A66E420.8040604@gmail.com> <4A672731.9040009@earthlink.net> <4A672B8A.5000200@gmail.com> <4A673EF1.1020706@earthlink.net> <4A6753B2.9040109@gmail.com> <4A676115.8060202@earthlink.net> <4A6765D7.8080608@gmail.com> <4A6771FF.8030104@earthlink.net> <4A677F69.9080006@gmail.com> <4A678BA9.8050408@earthlink.net> <4A6820E3.5070801@gmail.com> <4A689DB6.6000701@earthlink.net> In-Reply-To: <4A689DB6.6000701@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090722-0, 22/07/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 18:53:19 -0000 Charles E. Perkins a écrit : >>> This IPv6 link-local address are recommended when the link-layer >>> has determined connectivity properties. > > That's not going to work. You have to say what the connectivity > properties are. "determined" is quite bad for this -- the > connectivity properties could be determined to be useless or even > harmful. I will not not turn it saying that undetermined/unplanned connectivity properties (the current formulation of the draft) is not any more useful. I will say what I said in earlier messages that for some particular MANET link layers the determined connectivity properties are when the number of nodes is below a threshold (counted in the tens) and the area covered by the MANET has a range of around 50meters, without obstacles to radio waves and without interference in a certain radio band (counted in GHz). And that the link-layers are specified in agreed documents. There are many such kinds of MANET link layers, counted by the tens. There may be other MANET link layers which don't have such properties, and thus have undetermined connectivity properties. Would this formulation about determined connectivity properties work better? Alex From sratliff@cisco.com Thu Jul 23 11:57:11 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AC6B28C122 for ; Thu, 23 Jul 2009 11:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.11 X-Spam-Level: X-Spam-Status: No, score=-6.11 tagged_above=-999 required=5 tests=[AWL=0.489, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86UhtdFQMNmG for ; Thu, 23 Jul 2009 11:57:10 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 4FF8A3A6767 for ; Thu, 23 Jul 2009 11:57:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAONOaEpAZnme/2dsb2JhbAC5GoglkRgFhA2BSA X-IronPort-AV: E=Sophos;i="4.43,257,1246838400"; d="scan'208";a="51529997" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 23 Jul 2009 18:54:51 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6NIspaL016270; Thu, 23 Jul 2009 14:54:51 -0400 Received: from [10.116.179.218] (rtp-sratliff-8719.cisco.com [10.116.179.218]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6NIsojX023288; Thu, 23 Jul 2009 18:54:51 GMT Message-ID: <4A68B1FA.1050507@cisco.com> Date: Thu, 23 Jul 2009 14:54:50 -0400 From: Stan Ratliff User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Alexandru Petrescu References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> <4A66E420.8040604@gmail.com> <4A672731.9040009@earthlink.net> <4A672B8A.5000200@gmail.com> <4A673EF1.1020706@earthlink.net> <4A6753B2.9040109@gmail.com> <4A676115.8060202@earthlink.net> <4A6765D7.8080608@gmail.com> <4A6771FF.8030104@earthlink.net> <4A677F69.9080006@gmail.com> <4A678BA9.8050408@earthlink.net> <4A6820E3.5070801@gmail.com> <4A689DB6.6000701@earthlink.net> <4A68A233.9010400@gmail.com> <4A68A847.4020500@cisco.com> In-Reply-To: <4A68A847.4020500@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2696; t=1248375291; x=1249239291; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20Stan=20Ratliff=20 |Subject:=20Re=3A=20[Autoconf]=20IPv6=20ad-hoc=20network=20 nodes=20that=20DON'T=20self-form=20any=0A=20IPv6=20link-loca l=20address |Sender:=20 |To:=20Alexandru=20Petrescu=20; bh=6zV2KPZ4HYzsXl2DMOedO2ipCRbbBJAiwy7fVQY0+u8=; b=U9gJ8nCSUbbAhUXiAWhWlNizvTbSMBVB+IP9dnGm5f8kyeRbBKIzN3Tzj1 m8prjhaCmhOMRneAS442jvroQap8ZBrx2RojBZNEVFq1tKyQxQNyrWrAtoOo begJ3pn/8a; Authentication-Results: rtp-dkim-1; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: autoconf@ietf.org Subject: Re: [Autoconf] IPv6 ad-hoc network nodes that DON'T self-form any IPv6 link-local address X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 18:57:11 -0000 Slight correction -- we've deployed with V4 addresses, but haven't used the /32 prefixes on them. Sorry for the mis-information. Regards, Stan Stan Ratliff wrote: > Alex, > > I've deployed MANET networks without IPV6 link local addresses, and > they work just fine. Specifically, my deployments have used > pre-configured IPV4 addresses. Oh, and by the way, we used /32 > prefixes on the "MANET interfaces" as well. :-) In case it matters, > the IPV4 deployments I speak of use EIGRP as the routing protocol (I > know, it's not an IETF standard, but it works.) > > I've also deployed MANET networks using V6 link-local addresses. In > these cases, we use the "Overlapping Relays" modification to OSPFv3 > that was submitted to the OSPF WG (I believe that an experimental RFC > number is pending on that draft). As in the V4 case, the V6 > link-locals work like a champ. > > To reiterate, I'm OK with the draft as-written. It does *NOT* preclude > the use of V6 link locals. As you rightly mention, it does not discuss > V6 link-locals until you get to the appendix. But with it being only a > 6 page draft, I don't see the reference in the appendix as a problem > -- IMO, if you're going to "skim" a 6 page draft, you deserve whatever > trap you fall into because of it. > > Regards, > Stan > > Alexandru Petrescu wrote: >> AUTOCONFers, >> >> [...] >>>>> o An ad-hoc network node self-forms an IPv6 link-local address for >>>>> each of its interfaces. The procedure is described in the document >>>>> relevant to the interface type. For example, a WiFi interface >>>>> should use RFC2464; for a PPP link see RFC5072. For a >>>>> more exhaustive list of links see RFCXXXX. >>> >>> But what about nodes in an ad-hoc network that DON'T self-form any >>> IPv6 link-local address? >> >> I would like to get a sense from the list about ad-hoc network nodes >> which don't self-form an IPv6 link-local address for themselves. >> >> I have my own oppinions about such nodes that I am ready to share on the >> list, but I would like to see first what people on this list think about >> ad-hoc network nodes that don't self-form any link-local address? Can >> such node exist? Would a software knob allow for it? Would other RFCs >> be influenced by this absence, etc. >> >> Any oppinion on this topic? thanks >> >> Alex >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From charles.perkins@earthlink.net Thu Jul 23 11:59:31 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFE033A6B6E for ; Thu, 23 Jul 2009 11:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ro-erKeIQW7v for ; Thu, 23 Jul 2009 11:59:31 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 120B028C147 for ; Thu, 23 Jul 2009 11:59:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=OyJGkQGiTPdtHNSV6ZEHBVuVpkkxiDo0WhtmPBGqr5rHFzstB5b4gEWEw4WMD5fn; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.74.16] (helo=[192.168.1.105]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MU3VJ-0001nz-DM; Thu, 23 Jul 2009 14:58:57 -0400 Message-ID: <4A68B2EF.7060009@earthlink.net> Date: Thu, 23 Jul 2009 11:58:55 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Teco Boot References: <4A6596CD.9040404@gmail.com> <4A673EF1.1020706@earthlink.net> <4A6753B2.9040109@gmail.com> <4A676115.8060202@earthlink.net> <4A6765D7.8080608@gmail.com> <4A6771FF.8030104@earthlink.net> <4A677F69.9080006@gmail.com> <4A678BA9.8050408@earthlink.net> <4A6820E3.5070801@gmail.com> <25c114b90907230711i719750bbr20b2a81dd22dbd05@mail.gmail.com> <4A6871C7.8090802@gmail.com> <4A6897A8.5090109@earthlink.net> <000901ca0bbe$6487beb0$2d973c10$@nl> In-Reply-To: <000901ca0bbe$6487beb0$2d973c10$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52976adae42429a5628b490b5e9e4891c9350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 18:59:31 -0000 Hello Teco, Teco Boot wrote: > The draft does not recommend link-locals. > I recommend usage of link-locals. > Some posting say there are issues with link-locals. But what those are is > vague or not true. For example, I don't see much difference in duplicate > avoidance between link-locals and globals. Well, I don't think we can mandate PPP between every pair of MANET nodes. > And this is not something to > discuss right now, as posted a few times. > I agree with this, except insofar as the discussion may be needed to progress the draft. I think solving the problem of link-local autoconfiguration will not happen within the lifetime of [autoconf], especially if that lifetime is prematurely snuffed out because of insistence on solving the problem of link-local address autoconfiguration. > In DT I felt a bit lonely. Now on ML, I see neutral opinions or > recommendations for link-locals. > I'm still puzzling over whether we are going to mandate PPP between every pair of MANET nodes. Sigh. If that happens, you won't have me to kick around any more. Regards, Charlie P. From teco@inf-net.nl Thu Jul 23 12:30:37 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADC433A67E6 for ; Thu, 23 Jul 2009 12:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.86 X-Spam-Level: X-Spam-Status: No, score=-1.86 tagged_above=-999 required=5 tests=[AWL=0.439, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kK58sp9izDrM for ; Thu, 23 Jul 2009 12:30:36 -0700 (PDT) Received: from CPSMTPM-EML109.kpnxchange.com (Cpsmtpm-eml109.kpnxchange.com [195.121.3.13]) by core3.amsl.com (Postfix) with ESMTP id 808083A676A for ; Thu, 23 Jul 2009 12:30:35 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML109.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Thu, 23 Jul 2009 21:28:45 +0200 From: "Teco Boot" To: "'Charles E. Perkins'" References: <4A6596CD.9040404@gmail.com> <4A673EF1.1020706@earthlink.net> <4A6753B2.9040109@gmail.com> <4A676115.8060202@earthlink.net> <4A6765D7.8080608@gmail.com> <4A6771FF.8030104@earthlink.net> <4A677F69.9080006@gmail.com> <4A678BA9.8050408@earthlink.net> <4A6820E3.5070801@gmail.com> <25c114b90907230711i719750bbr20b2a81dd22dbd05@mail.gmail.com> <4A6871C7.8090802@gmail.com> <4A6897A8.5090109@earthlink.net> <000901ca0bbe$6487beb0$2d973c10$@nl> <4A68B2EF.7060009@earthlink.net> In-Reply-To: <4A68B2EF.7060009@earthlink.net> Date: Thu, 23 Jul 2009 21:28:32 +0200 Message-ID: <000b01ca0bcb$c3b95490$4b2bfdb0$@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: AcoLx6SEBWDkxhsIRYSJIDMd20P/7wAA9n9A Content-Language: nl X-OriginalArrivalTime: 23 Jul 2009 19:28:45.0779 (UTC) FILETIME=[CBBB3230:01CA0BCB] Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 19:30:37 -0000 Hi Charlie, I agree on your opinion on PPP. I'll not enforce anybody to use link-locals. I only recommend it. Teco. |-----Oorspronkelijk bericht----- |Van: Charles E. Perkins [mailto:charles.perkins@earthlink.net] |Verzonden: donderdag 23 juli 2009 20:59 |Aan: Teco Boot |CC: 'Alexandru Petrescu'; autoconf@ietf.org |Onderwerp: Re: [Autoconf] Link-locals vis-=E0-vis the new [autoconf] |document | | |Hello Teco, | |Teco Boot wrote: |> The draft does not recommend link-locals. |> I recommend usage of link-locals. |> Some posting say there are issues with link-locals. But what those = are |is |> vague or not true. For example, I don't see much difference in |duplicate |> avoidance between link-locals and globals. |Well, I don't think we can mandate PPP between every pair of |MANET nodes. | |> And this is not something to |> discuss right now, as posted a few times. |> | |I agree with this, except insofar as the discussion may be |needed to progress the draft. I think solving the problem of |link-local autoconfiguration will not happen within the lifetime |of [autoconf], especially if that lifetime is prematurely snuffed |out because of insistence on solving the problem of link-local |address autoconfiguration. | |> In DT I felt a bit lonely. Now on ML, I see neutral opinions or |> recommendations for link-locals. |> | |I'm still puzzling over whether we are going to mandate PPP |between every pair of MANET nodes. | |Sigh. If that happens, you won't have me to kick around any more. | |Regards, |Charlie P. From alexandru.petrescu@gmail.com Thu Jul 23 12:59:59 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D65D03A6914 for ; Thu, 23 Jul 2009 12:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.576 X-Spam-Level: X-Spam-Status: No, score=-0.576 tagged_above=-999 required=5 tests=[AWL=-0.486, BAYES_20=-0.74, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7mycAV7vzL8 for ; Thu, 23 Jul 2009 12:59:59 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 0E60B3A6818 for ; Thu, 23 Jul 2009 12:59:57 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id E692ED48177; Thu, 23 Jul 2009 21:58:43 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 9F12DD4812B; Thu, 23 Jul 2009 21:58:40 +0200 (CEST) Message-ID: <4A68C0F0.8060805@gmail.com> Date: Thu, 23 Jul 2009 21:58:40 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> <4A66E420.8040604@gmail.com> <4A672731.9040009@earthlink.net> <4A672B8A.5000200@gmail.com> <4A673EF1.1020706@earthlink.net> <4A6753B2.9040109@gmail.com> <4A676115.8060202@earthlink.net> <4A6765D7.8080608@gmail.com> <4A6771FF.8030104@earthlink.net> <4A677F69.9080006@gmail.com> <4A678BA9.8050408@earthlink.net> <4A6820E3.5070801@gmail.com> <4A689DB6.6000701@earthlink.net> In-Reply-To: <4A689DB6.6000701@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090722-0, 22/07/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 19:59:59 -0000 Charles E. Perkins a écrit : >>> o An IP address configured on this interface should be unique, >>> at least within the routing domain, and >>> >>> o A subnet prefix configured on this interface should be of >>> length /128 (except, of course, the IPv6 link-local addresses >>> whose prefix is /10). > > This would be O.K. as long as we are clear that there are some MANET > interfaces for which link-locals may remain unconfigured. So, if you feel this would be O.K., should the editors modify the draft accordingly? Alex From cjbc@it.uc3m.es Sun Jul 26 02:56:17 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82FAC3A6838 for ; Sun, 26 Jul 2009 02:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBE6CM1BOaBP for ; Sun, 26 Jul 2009 02:56:16 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 2BEE83A62C1 for ; Sun, 26 Jul 2009 02:56:15 -0700 (PDT) Received: from [130.129.83.185] (unknown [130.129.83.185]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 07E7565514F for ; Sun, 26 Jul 2009 11:56:14 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: autoconf@ietf.org Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-l7WZ9NL8gkFrqCKe022x" Organization: Universidad Carlos III de Madrid Date: Sun, 26 Jul 2009 11:56:21 +0200 Message-Id: <1248602181.4739.111.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16786.006 Subject: [Autoconf] Comments on draft-baccelli-autoconf-adhoc-addr-model-01.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2009 09:56:17 -0000 --=-l7WZ9NL8gkFrqCKe022x Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi all, Thanks for writing the draft. Although we are still far from reaching our goal, I think this is making progress. I've gone through a first read of the draft and I share some of the opinions that have been already posted in this ML: - I agree that due to the characteristics of MANETs, it might be a good idea to use /32 and /128 on all MANET interfaces (although we don't have yet a clear definition of what a MANET interface is :->). This solve the problem of assuming that one neighbor is on the same link (i.e. reachable within one IP hop). - On the other hand, I also agree that the above (forcing /128) forbids the use of link-local addresses, _in my understanding_. So far I don't have a proposal to solve this contradiction, but I share some of Alex's concerns and I think this is important and it is not enough to say in the appendix that link-locals are not forbidden. - I also share the comment on the terminology issue of saying "undetermined connectivity properties". Again, I don't have a suggestion for a better text now, I'll try to come up with something to be suggested. - Regarding the global/local address uniqueness issue, I also think we should agree on what we need here. In the "non-MANET" world, by ensuring local uniqueness on the link, we could safely assume that global uniqueness would be ensured (for those cases where it's needed, since unique global prefixes would be advertised/used on these links). Depending on the addressing model we finally agree on, this might be different in a MANET. So far, I agree on using the routing domain as the scope for ensuring address uniqueness. Thanks, Carlos --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-l7WZ9NL8gkFrqCKe022x Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkpsKEUACgkQNdy6TdFwT2cC4QCg2E/bulvhOdWZiC+J4sUTt7YZ BbMAnj6yNpr5A7XMasqBBDlLHmiYueBy =vU6R -----END PGP SIGNATURE----- --=-l7WZ9NL8gkFrqCKe022x-- From cjbc@it.uc3m.es Sun Jul 26 02:59:15 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32B963A6838 for ; Sun, 26 Jul 2009 02:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6hf-uIJJhdJ for ; Sun, 26 Jul 2009 02:59:14 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 007853A62C1 for ; Sun, 26 Jul 2009 02:59:13 -0700 (PDT) Received: from [130.129.83.185] (unknown [130.129.83.185]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 27E7F72CDAB; Sun, 26 Jul 2009 11:59:13 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Alexandru Petrescu In-Reply-To: <4A68A233.9010400@gmail.com> References: <4A6596CD.9040404@gmail.com> <4A65B1F1.4030009@gmail.com> <4A65CC37.2080703@gmail.com> <4A65E91C.2080209@earthlink.net> <4A65EEB5.3080500@gmail.com> <4A65F192.3010801@earthlink.net> <4A663B5D.9030107@gmail.com> <4A66437A.2050307@earthlink.net> <4A66E420.8040604@gmail.com> <4A672731.9040009@earthlink.net> <4A672B8A.5000200@gmail.com> <4A673EF1.1020706@earthlink.net> <4A6753B2.9040109@gmail.com> <4A676115.8060202@earthlink.net> <4A6765D7.8080608@gmail.com> <4A6771FF.8030104@earthlink.net> <4A677F69.9080006@gmail.com> <4A678BA9.8050408@earthlink.net> <4A6820E3.5070801@gmail.com> <4A689DB6.6000701@earthlink.net> <4A68A233.9010400@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-n1x/8ATWO/O472g4wCvg" Organization: Universidad Carlos III de Madrid Date: Sun, 26 Jul 2009 11:59:19 +0200 Message-Id: <1248602359.4739.114.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16786.006 Cc: autoconf@ietf.org Subject: Re: [Autoconf] IPv6 ad-hoc network nodes that DON'T self-form any IPv6 link-local address X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2009 09:59:15 -0000 --=-n1x/8ATWO/O472g4wCvg Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Alex, all, On Thu, 2009-07-23 at 19:47 +0200, Alexandru Petrescu wrote: > AUTOCONFers, >=20 > [...] > >>> o An ad-hoc network node self-forms an IPv6 link-local address=20 > >>> for each of its interfaces. The procedure is described in the=20 > >>> document relevant to the interface type. For example, a WiFi=20 > >>> interface should use RFC2464; for a PPP link see RFC5072. For a > >>> more exhaustive list of links see RFCXXXX. > >=20 > > But what about nodes in an ad-hoc network that DON'T self-form any=20 > > IPv6 link-local address? >=20 > I would like to get a sense from the list about ad-hoc network nodes > which don't self-form an IPv6 link-local address for themselves. >=20 > I have my own oppinions about such nodes that I am ready to share on the > list, but I would like to see first what people on this list think about > ad-hoc network nodes that don't self-form any link-local address? Can > such node exist? Would a software knob allow for it? Would other RFCs > be influenced by this absence, etc. >=20 > Any oppinion on this topic? thanks I've just sent an e-mail with comments that I think provides an answer for your (relevant IMHO) questions. Anyway, I'll repeat here myself, just for the sake of keeping them on this thread. I think link-local addresses should be allowed in MANETs, since I think disallowing them may have issues on other protocols that we might not be considering now. However, I also think that only using /32s and /128s would make our life much easier :-D Carlos >=20 > Alex >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-n1x/8ATWO/O472g4wCvg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkpsKPcACgkQNdy6TdFwT2eNCgCgwFvAJtfLpiattrtPJwy9Co5u miEAn0A01kPX+oWuh+//BqQTeXkqAPWE =F6px -----END PGP SIGNATURE----- --=-n1x/8ATWO/O472g4wCvg-- From ryuji.wakikawa@gmail.com Mon Jul 27 02:02:56 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A89D28C27D for ; Mon, 27 Jul 2009 02:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ug5AingQ+Qa for ; Mon, 27 Jul 2009 02:02:55 -0700 (PDT) Received: from mail-px0-f194.google.com (mail-px0-f194.google.com [209.85.216.194]) by core3.amsl.com (Postfix) with ESMTP id 0739128C14F for ; Mon, 27 Jul 2009 02:02:55 -0700 (PDT) Received: by pxi32 with SMTP id 32so1584470pxi.29 for ; Mon, 27 Jul 2009 02:02:54 -0700 (PDT) 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:mime-version:subject:date :x-mailer; bh=Q88uJFTID76Sw9Nsr0f7o/f2u05+cwbGYcjWNbgeo9I=; b=qXSYz2t1+6EoQTVWF0mQbV7i9w0t8WsNmY7pVThqSxozAd7Gzw3trhXR1MZYBASCA8 3GD57yzE7umJlFS0eW98amph9zg913+3pUCRFhMH1br+lV4SrYlup6JAgG1p2tQD714o 7Cm2OmdE5nWBnomAa9c/Dc+4E6IaZogK8ruWA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:x-mailer; b=MBgRKvwikzygRYmUrkXcc8NBhQc7JV0dU0ttzDRud3t0l21nY0E0r5t0wNV77lmQBo jPcItvsQxOG7z7xIvCTZRX6nZQw9gKtsjPNHjfQ9PjXPZPigxepPQSxmqU2GChc/nVx/ YV0gZkU6P47dsNmimUiVuUI03YA93udZVNZXc= Received: by 10.114.53.6 with SMTP id b6mr9568151waa.181.1248685374243; Mon, 27 Jul 2009 02:02:54 -0700 (PDT) Received: from dhcp-52e0.meeting.ietf.org ([130.129.82.224]) by mx.google.com with ESMTPS id j28sm13180396waf.32.2009.07.27.02.02.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 27 Jul 2009 02:02:53 -0700 (PDT) Message-Id: From: Ryuji Wakikawa To: autoconf@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 27 Jul 2009 11:02:48 +0200 X-Mailer: Apple Mail (2.935.3) Subject: [Autoconf] We need volunteer for jabber scribe and note-taker X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 09:02:56 -0000 Hi we will have AUTOCONF meeting this afternoon. We'd need volunteers for taking notes and scribing on Jabber. In addition, please review the DT document before the meeting. http://www.ietf.org/id/draft-baccelli-autoconf-adhoc-addr-model-01.txt Please let me know if you can help us. thanks, ryuji From erik.nordmark@sun.com Mon Jul 27 05:12:47 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08D3028C1F6 for ; Mon, 27 Jul 2009 05:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.896 X-Spam-Level: X-Spam-Status: No, score=-5.896 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XntQZGqbcWvB for ; Mon, 27 Jul 2009 05:12:46 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id 4A00228C1A8 for ; Mon, 27 Jul 2009 05:12:46 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6RCBVC0019113; Mon, 27 Jul 2009 12:11:31 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n6RCBTds565072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Jul 2009 05:11:30 -0700 (PDT) Message-ID: <4A6D9970.8070701@sun.com> Date: Mon, 27 Jul 2009 14:11:28 +0200 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: Teco Boot References: <4A6596CD.9040404@gmail.com> <4A673EF1.1020706@earthlink.net> <4A6753B2.9040109@gmail.com> <4A676115.8060202@earthlink.net> <4A6765D7.8080608@gmail.com> <4A6771FF.8030104@earthlink.net> <4A677F69.9080006@gmail.com> <4A678BA9.8050408@earthlink.net> <4A6820E3.5070801@gmail.com> <25c114b90907230711i719750bbr20b2a81dd22dbd05@mail.gmail.com> <4A6871C7.8090802@gmail.com> <4A6897A8.5090109@earthlink.net> <000901ca0bbe$6487beb0$2d973c10$@nl> <4A68B2EF.7060009@earthlink.net> <000b01ca0bcb$c3b95490$4b2bfdb0$@nl> In-Reply-To: <000b01ca0bcb$c3b95490$4b2bfdb0$@nl> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] =?iso-8859-1?q?Link-locals_vis-=E0-vis_the_new_=5Bauto?= =?iso-8859-1?q?conf=5D_document?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 12:12:47 -0000 I've tried to determine the current state of the IPv6 link-local address discussion, but I might have missed something. From a definitional perspective I think we want to include the IPv6 link-local addresses (as well as the link-scope multicast addresses in this section: 4. IP Subnet Prefix Configuration If the link to which an interface connects enables no assumptions of connectivity to other interfaces, the only addresses which can be assumed "on link", are the address(es) of that interface itself. Note that including it there might not have any operational difference if the MANET routing protocols do not use link-local addresses to communicate with their peers. But it would matter from an operational perspective if there are protocols that want to restrict their communication to a single hop. Such protocols could then use link-local addresses (and link-scope multicasts), while normal applications use global (or ULA) addresses. Erik From erik.nordmark@sun.com Mon Jul 27 07:55:03 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D22473A6942 for ; Mon, 27 Jul 2009 07:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.971 X-Spam-Level: X-Spam-Status: No, score=-5.971 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROpFNGW7C6Aw for ; Mon, 27 Jul 2009 07:55:03 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id E53373A68E8 for ; Mon, 27 Jul 2009 07:55:02 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6REsmLj002310 for ; Mon, 27 Jul 2009 14:54:49 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n6REsksn579675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Jul 2009 07:54:48 -0700 (PDT) Message-ID: <4A6DBFB5.3050305@sun.com> Date: Mon, 27 Jul 2009 16:54:45 +0200 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: "autoconf@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Autoconf] Suggested text on link-locals X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 14:55:03 -0000 Does this make it more clear? In section 4.2 change the sentence If the link to which an interface connects enables no assumptions of connectivity to other interfaces, the only addresses which can be assumed "on link", are the address(es) of that interface itself. to If the link to which an interface connects enables no assumptions of connectivity to other interfaces, the only addresses which can be assumed "on link", are the address(es) of that interface itself. Note that IPv6 link-local addresses are assumed "on link".. However, the utility of IPv6 link-locals is limited as specified in section 6.2. At the end of section 6.2 add this text: A IPv6 link-local addresses must be assigned to each interface according to [RFC 4291]. Due to the connectivity properties of these links with neighbors constantly moving in and out of reachability, the link-local addresses are of very limited utility. The known limitations are: - Even if tested for uniqueness at one moment using Duplicate Address Detection [RFC 4862], a duplicate link-local address might appear as a neighbor the next moment and DAD would not detect that. - There is no mechanism to ensure that IPv6 link-local are unique across multiple links, hence they can not be used to reliably identify routers. - Routers must not forward any packets with Link-Local source or destination addresses to other links [RFC 4921]. And a Manet router that forwards packets by definition forwards from one link to another due to the undefined connectivity properties. (The set of neighbors that heard the packet received by the router might be different than the set of neighbors that hears a packet transmitted by the router even if the same interface on the router is used for the two operations.) Erik From cjbc@it.uc3m.es Mon Jul 27 08:07:47 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFC5D3A6C18 for ; Mon, 27 Jul 2009 08:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uaKksq3MtXj4 for ; Mon, 27 Jul 2009 08:07:46 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 4E1DB3A6C16 for ; Mon, 27 Jul 2009 08:07:45 -0700 (PDT) Received: from [130.129.83.185] (unknown [130.129.83.185]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id F351A659DBD for ; Mon, 27 Jul 2009 17:07:45 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: autoconf@ietf.org Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-GRn0CkHUf50P6U5bN00W" Organization: Universidad Carlos III de Madrid Date: Mon, 27 Jul 2009 17:07:53 +0200 Message-Id: <1248707273.4236.253.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16788.007 Subject: [Autoconf] On the LL issue X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 15:07:47 -0000 --=-GRn0CkHUf50P6U5bN00W Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi all, After (silently) hearing all the discussions on the LL issue during the meeting, here is my understanding (just to check if I got it right): - Ensuring uniqueness of LL addresses in a MANET is hard, because of the dynamic nature of MANET links (i.e. a neighbour now might not be my neighbour anymore 1ms after). - IPv6 specs state that any node MUST have an LL address configured. They don't say this address has to be used. Therefore, one approach is autoconf to propose a way of configure an LL address (maybe as simple as just using EUI64 from MAC addresses), but then warn routing protocols and applications not to use LL in MANETs. - Routing protocols might use ULAs or global addresses to work. However, there seem to be protocols that say that LL MUST be used (some routing protocols, as Teco commented, or just sending RAs, RS). - One of the proposals in the room was to focus autoconf on just working on a practical way of configuring unique ULAs/global addresses (it was also recommended not to make a distinction in the document) and forget about LL. This is my summary, please comment on those things I might have got wrong. Now, my opinion about how to progress (I'm listing the approaches that could be on the table, ordered by my personal preference) is the following (I'm just trying to answer to chairs' request to comment on the ML, since I'm voted against making DT document a WG document): - 1st preference: although it'd be easier to forget about LLs, we should try to do something better. We may try to come up with something that ensures that LL addresses configured in a MANET are not only unique within the link-scope (as required by IPv6 specs), but also within the MANET scope (whatever scope this is, we have to agree on that scope anyway even for ULA uniqueness). This would make the solution harder, but it would not break anything I could think of now. My fear is that by not paying attention to LL, we may end up forgetting about some protocol that is broken (or requires to be revised) in MANETs. - 2st preference: autoconf just focuses on autoconfiguration of ULAs/global addresses, BUT does NOT forget completely about LLs. We may just recommend using EUI64-like SLAAC for LLs and comment that due to the MANET characteristics, 'users' of LL addresses might not assume that LLs are unique within the link (because the link is very dynamic). This would not preclude people from using LLs. - 3rd preference: we forget completely about LLs and just focus on ULAs/globals. I'd personally prefer not going there. Comments? Thanks, Carlos --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-GRn0CkHUf50P6U5bN00W Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkptwskACgkQNdy6TdFwT2dp6wCgwzQZRF0sj6iiQmX81sS8fbTK f48An2SAlBAPu1pNvlf941oV9lpj3Qx5 =KOKa -----END PGP SIGNATURE----- --=-GRn0CkHUf50P6U5bN00W-- From alexandru.petrescu@gmail.com Mon Jul 27 08:34:05 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FD323A6B54 for ; Mon, 27 Jul 2009 08:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bvo6UjsVQ-EL for ; Mon, 27 Jul 2009 08:34:04 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 1CB893A6C37 for ; Mon, 27 Jul 2009 08:33:50 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6RFXmBv027704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Jul 2009 17:33:48 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6RFXled023625; Mon, 27 Jul 2009 17:33:48 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6RFXk7F021893; Mon, 27 Jul 2009 17:33:47 +0200 Message-ID: <4A6DC8DA.5060300@gmail.com> Date: Mon, 27 Jul 2009 17:33:46 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Erik Nordmark References: <4A6DBFB5.3050305@sun.com> In-Reply-To: <4A6DBFB5.3050305@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Suggested text on link-locals X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 15:34:05 -0000 Erik Nordmark a écrit : > > Does this make it more clear? > > In section 4.2 change the sentence > If the link to which an interface connects enables no assumptions of > connectivity to other interfaces, the only addresses which can be > assumed "on link", are the address(es) of that interface itself. > to > If the link to which an interface connects enables no assumptions of > connectivity to other interfaces, the only addresses which can be > assumed "on link", are the address(es) of that interface itself. Note > that IPv6 link-local addresses are assumed "on link".. However, the > utility of IPv6 link-locals is limited as specified in section 6.2. Ok to me. > At the end of section 6.2 add this text: > > A IPv6 link-local addresses must be assigned to each interface according > to [RFC 4291]. Due to the connectivity properties of these links with > neighbors constantly moving in and out of reachability, the link-local > addresses are of very limited utility. The known limitations are: > - Even if tested for uniqueness at one moment using Duplicate Address > Detection [RFC 4862], a duplicate link-local address might appear as a > neighbor the next moment and DAD would not detect that. > - There is no mechanism to ensure that IPv6 link-local are unique > across multiple links, hence they can not be used to reliably identify > routers. ^across links (because it can be used to reliably identify routers on the same link). > - Routers must not forward any packets with Link-Local source or > destination addresses to other links [RFC 4921]. Ok to me. > And a Manet router > that forwards packets by definition forwards from one link to another > due to the undefined connectivity properties. (The set of neighbors that > heard the packet received by the router might be different than the set > of neighbors that hears a packet transmitted by the router even if the > same interface on the router is used for the two operations.) Sounds good too. Alex From alexandru.petrescu@gmail.com Mon Jul 27 09:23:18 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4E0A28C1F6 for ; Mon, 27 Jul 2009 09:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.86 X-Spam-Level: X-Spam-Status: No, score=-1.86 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEg+gKtcDpB0 for ; Mon, 27 Jul 2009 09:23:18 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id A37BA3A6C9E for ; Mon, 27 Jul 2009 09:23:17 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6RGNHNq002548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Jul 2009 18:23:17 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6RGNG43030034; Mon, 27 Jul 2009 18:23:16 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6RGNGII018195; Mon, 27 Jul 2009 18:23:16 +0200 Message-ID: <4A6DD474.80205@gmail.com> Date: Mon, 27 Jul 2009 18:23:16 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <1248707273.4236.253.camel@acorde.it.uc3m.es> In-Reply-To: <1248707273.4236.253.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] On the LL issue X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 16:23:18 -0000 Carlos Jesús Bernardos Cano a écrit : > Hi all, > > After (silently) hearing all the discussions on the LL issue during the > meeting, here is my understanding (just to check if I got it right): > > - Ensuring uniqueness of LL addresses in a MANET is hard, because of > the dynamic nature of MANET links (i.e. a neighbour now might not be my > neighbour anymore 1ms after). > - IPv6 specs state that any node MUST have an LL address configured. > They don't say this address has to be used. Therefore, one approach is > autoconf to propose a way of configure an LL address (maybe as simple as > just using EUI64 from MAC addresses), but then warn routing protocols > and applications not to use LL in MANETs. > - Routing protocols might use ULAs or global addresses to work. > However, there seem to be protocols that say that LL MUST be used (some > routing protocols, as Teco commented, or just sending RAs, RS). > - One of the proposals in the room was to focus autoconf on just > working on a practical way of configuring unique ULAs/global addresses > (it was also recommended not to make a distinction in the document) and > forget about LL. > > This is my summary, please comment on those things I might have got > wrong. > > Now, my opinion about how to progress (I'm listing the approaches that > could be on the table, ordered by my personal preference) is the > following (I'm just trying to answer to chairs' request to comment on > the ML, since I'm voted against making DT document a WG document): > > - 1st preference: although it'd be easier to forget about LLs, we > should try to do something better. We may try to come up with something > that ensures that LL addresses configured in a MANET are not only unique > within the link-scope (as required by IPv6 specs), but also within the > MANET scope (whatever scope this is, we have to agree on that scope > anyway even for ULA uniqueness). This would make the solution harder, > but it would not break anything I could think of now. My fear is that by > not paying attention to LL, we may end up forgetting about some protocol > that is broken (or requires to be revised) in MANETs. > > - 2st preference: autoconf just focuses on autoconfiguration of > ULAs/global addresses, BUT does NOT forget completely about LLs. We may > just recommend using EUI64-like SLAAC for LLs and comment that due to > the MANET characteristics, 'users' of LL addresses might not assume that > LLs are unique within the link (because the link is very dynamic). This > would not preclude people from using LLs. I agree with this approach. An AUTOCONF mechanisms auto-configures ULAs/globals by assuming link-local addresses are already there and ensured existence. AUTOCONF mechanism would not auto-configure link-local addresses, just reuse them. E.g. the src address of the first AUTOCONF packet is a link-local address, pre-defined in earlier RFCs. > - 3rd preference: we forget completely about LLs and just focus on > ULAs/globals. I'd personally prefer not going there. > > Comments? Alex From alexandru.petrescu@gmail.com Mon Jul 27 09:32:29 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C0003A6A06 for ; Mon, 27 Jul 2009 09:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.723 X-Spam-Level: X-Spam-Status: No, score=-0.723 tagged_above=-999 required=5 tests=[AWL=-0.774, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_NAIL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3q1wN4INFhi for ; Mon, 27 Jul 2009 09:32:28 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 838553A6A8B for ; Mon, 27 Jul 2009 09:32:28 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6RGWSLa028480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 27 Jul 2009 18:32:28 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6RGWSVU000406 for ; Mon, 27 Jul 2009 18:32:28 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6RGWRVl003417 for ; Mon, 27 Jul 2009 18:32:28 +0200 Message-ID: <4A6DD69B.40004@gmail.com> Date: Mon, 27 Jul 2009 18:32:27 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "autoconf@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Autoconf] Clarification of the formulation of the /128 recommendation X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 16:32:29 -0000 Current DT draft recommends: > o A subnet prefix configured on this interface should be of length > /128. I am trying to understand this formulation. What does it mean in practice? Does it mean that when I type 'ifconfig' all shown addresses will be suffixed by "/128"? (and not by any other length, like /64, or /48 or such). Does it mean that when I type 'route -n' all entries in the routing table have prefix length 128? (and not /64, nor /48, or similar). There was quick discussion on the jabber room at the end of the meeting, making think that "/128" may be a red herring, and that the "/128" recommendation may not conflict with existing specs. These statements are rather surprising to me. For clarification, I think formulations in terms of practical screen dump of issued commands may help, at least myself, thank you. Or do most people think that this "/128" recommendation is mostly clear and is understood? Alex From teco@inf-net.nl Mon Jul 27 09:37:59 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9B463A6CB9 for ; Mon, 27 Jul 2009 09:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVOctxlMz+bn for ; Mon, 27 Jul 2009 09:37:59 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 7C37E3A6C05 for ; Mon, 27 Jul 2009 09:37:58 -0700 (PDT) Received: (qmail 4900 invoked from network); 27 Jul 2009 18:37:56 +0200 Received: from scandic811.host.songnetworks.se (HELO M90Teco) (212.214.188.26) by server9.hosting2go.nl with SMTP; 27 Jul 2009 18:37:56 +0200 From: "Teco Boot" To: "'Erik Nordmark'" , References: <4A6DBFB5.3050305@sun.com> In-Reply-To: <4A6DBFB5.3050305@sun.com> Date: Mon, 27 Jul 2009 18:37:22 +0200 Message-ID: <000001ca0ed8$98408350$c8c189f0$@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: AcoOyjzRhs0WDbpoR4mS5DAA+vDKNQADBg4A Content-Language: nl Subject: Re: [Autoconf] Suggested text on link-locals X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 16:37:59 -0000 Hi Erik, |-----Oorspronkelijk bericht----- |Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens |Erik Nordmark |Verzonden: maandag 27 juli 2009 16:55 |Aan: autoconf@ietf.org |Onderwerp: [Autoconf] Suggested text on link-locals | | |Does this make it more clear? | |In section 4.2 change the sentence | If the link to which an interface connects enables no assumptions of | connectivity to other interfaces, the only addresses which can be | assumed "on link", are the address(es) of that interface itself. |to | If the link to which an interface connects enables no assumptions of | connectivity to other interfaces, the only addresses which can be | assumed "on link", are the address(es) of that interface itself. |Note | that IPv6 link-local addresses are assumed "on link".. However, the | utility of IPv6 link-locals is limited as specified in section 6.2. We just specify "on-link" not equals "reachable". "on-link" means here we don't send packets with a link-local as destination to a default gateway. | |At the end of section 6.2 add this text: | |A IPv6 link-local addresses must be assigned to each interface according |to [RFC 4291]. Due to the connectivity properties of these links with |neighbors constantly moving in and out of reachability, the link-local |addresses are of very limited utility. Maybe, maybe not. I would not disqualify the characteristics. | The known limitations are: | - Even if tested for uniqueness at one moment using Duplicate Address |Detection [RFC 4862], a duplicate link-local address might appear as a |neighbor the next moment and DAD would not detect that. I do not understand the difference with globals / ULAs. | - There is no mechanism to ensure that IPv6 link-local are unique |across multiple links, hence they can not be used to reliably identify |routers. This is nothing new. And the IETF routing protocol number 1 protocol runs perfect on it. Many others have no problem either. | - Routers must not forward any packets with Link-Local source or | destination addresses to other links [RFC 4921]. And a Manet router |that forwards packets by definition forwards from one link to another |due to the undefined connectivity properties. There are multiple opinions on what a link is. So I cannot agree on the text. But I know what you are saying. |(The set of neighbors that |heard the packet received by the router might be different than the set |of neighbors that hears a packet transmitted by the router even if the |same interface on the router is used for the two operations.) Yes, and this is exactly what makes it very powerful for neighborhood Discovery [NHDP, OSPF, etc.]. Regards, Teco. | | Erik | |_______________________________________________ |Autoconf mailing list |Autoconf@ietf.org |https://www.ietf.org/mailman/listinfo/autoconf From teco@inf-net.nl Mon Jul 27 09:44:41 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B953128C1F6 for ; Mon, 27 Jul 2009 09:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.204 X-Spam-Level: X-Spam-Status: No, score=-1.204 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64Io0njM351W for ; Mon, 27 Jul 2009 09:44:40 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id D58CD28C0EC for ; Mon, 27 Jul 2009 09:44:39 -0700 (PDT) Received: (qmail 4905 invoked from network); 27 Jul 2009 18:37:57 +0200 Received: from scandic811.host.songnetworks.se (HELO M90Teco) (212.214.188.26) by server9.hosting2go.nl with SMTP; 27 Jul 2009 18:37:57 +0200 From: "Teco Boot" To: References: <1248707273.4236.253.camel@acorde.it.uc3m.es> In-Reply-To: <1248707273.4236.253.camel@acorde.it.uc3m.es> Date: Mon, 27 Jul 2009 18:37:22 +0200 Message-ID: <000101ca0ed8$98652250$c92f66f0$@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: AcoOzAQytqEt55ANR0GIWGSwQ/BXlQACMd1A Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] On the LL issue X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 16:44:41 -0000 Hi Carlos, Comments and questions inline. |-----Oorspronkelijk bericht----- |Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] = Namens |Carlos Jes=FAs Bernardos Cano |Verzonden: maandag 27 juli 2009 17:08 |Aan: autoconf@ietf.org |Onderwerp: [Autoconf] On the LL issue | |Hi all, | | After (silently) hearing all the discussions on the LL issue |during the |meeting, here is my understanding (just to check if I got it right): | | - Ensuring uniqueness of LL addresses in a MANET is hard, because |of |the dynamic nature of MANET links (i.e. a neighbour now might not be my |neighbour anymore 1ms after). Do you think it is more easy to come up with unique globals? What makes the difference? | - IPv6 specs state that any node MUST have an LL address |configured. |They don't say this address has to be used. Some protocols clearly specify link-locals MUST be used. ND RA is an example. OSPFv3 (with the MANET extensions) is another. | Therefore, one approach is |autoconf to propose a way of configure an LL address (maybe as simple = as |just using EUI64 from MAC addresses), but then warn routing protocols |and applications not to use LL in MANETs. I do not see any reason that we cannot use link-locals for MANET routing protocols. It provides exactly what is needed: routing protocol packets shall not be forwarded. Using link-locals provides this. We asked for a link-local multicast address (RFC5498). And we got one !!! | - Routing protocols might use ULAs or global addresses to work. |However, there seem to be protocols that say that LL MUST be used (some |routing protocols, as Teco commented, or just sending RAs, RS). RS does not have the link-local requirement. Regards, Teco. | - One of the proposals in the room was to focus autoconf on just |working on a practical way of configuring unique ULAs/global addresses |(it was also recommended not to make a distinction in the document) and |forget about LL. | | This is my summary, please comment on those things I might have |got |wrong. | | Now, my opinion about how to progress (I'm listing the approaches |that |could be on the table, ordered by my personal preference) is the |following (I'm just trying to answer to chairs' request to comment on |the ML, since I'm voted against making DT document a WG document): | | - 1st preference: although it'd be easier to forget about LLs, we |should try to do something better. We may try to come up with something |that ensures that LL addresses configured in a MANET are not only = unique |within the link-scope (as required by IPv6 specs), but also within the |MANET scope (whatever scope this is, we have to agree on that scope |anyway even for ULA uniqueness). This would make the solution harder, |but it would not break anything I could think of now. My fear is that = by |not paying attention to LL, we may end up forgetting about some = protocol |that is broken (or requires to be revised) in MANETs. | | - 2st preference: autoconf just focuses on autoconfiguration of |ULAs/global addresses, BUT does NOT forget completely about LLs. We may |just recommend using EUI64-like SLAAC for LLs and comment that due to |the MANET characteristics, 'users' of LL addresses might not assume = that |LLs are unique within the link (because the link is very dynamic). This |would not preclude people from using LLs. | | - 3rd preference: we forget completely about LLs and just focus on |ULAs/globals. I'd personally prefer not going there. | | Comments? | | Thanks, | | Carlos | |-- |Carlos Jes=FAs Bernardos Cano http://www.netcoms.net |GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 From cjbc@it.uc3m.es Mon Jul 27 09:54:15 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71FD53A6AC0 for ; Mon, 27 Jul 2009 09:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHH+HvCPk-Fa for ; Mon, 27 Jul 2009 09:54:14 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id E45BC28C315 for ; Mon, 27 Jul 2009 09:53:51 -0700 (PDT) Received: from [130.129.85.252] (unknown [130.129.85.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id B3DF76BAD84; Mon, 27 Jul 2009 18:53:51 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Teco Boot In-Reply-To: <000101ca0ed8$98652250$c92f66f0$@nl> References: <1248707273.4236.253.camel@acorde.it.uc3m.es> <000101ca0ed8$98652250$c92f66f0$@nl> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-vwjETGpLCeGDE2W/areI" Organization: Universidad Carlos III de Madrid Date: Mon, 27 Jul 2009 18:53:59 +0200 Message-Id: <1248713639.4236.306.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16788.007 Cc: autoconf@ietf.org Subject: Re: [Autoconf] On the LL issue X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 16:54:15 -0000 --=-vwjETGpLCeGDE2W/areI Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Teco, More inline... On Mon, 2009-07-27 at 18:37 +0200, Teco Boot wrote: > Hi Carlos, >=20 > Comments and questions inline. >=20 > |-----Oorspronkelijk bericht----- > |Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens > |Carlos Jes=FAs Bernardos Cano > |Verzonden: maandag 27 juli 2009 17:08 > |Aan: autoconf@ietf.org > |Onderwerp: [Autoconf] On the LL issue > | > |Hi all, > | > | After (silently) hearing all the discussions on the LL issue > |during the > |meeting, here is my understanding (just to check if I got it right): > | > | - Ensuring uniqueness of LL addresses in a MANET is hard, because > |of > |the dynamic nature of MANET links (i.e. a neighbour now might not be my > |neighbour anymore 1ms after). >=20 > Do you think it is more easy to come up with unique globals? > What makes the difference? Well, depending on the solution (this is solution space) it might be the same, I agree, but from a high level viewpoint, ensuring uniqueness for 64bits is harder than for 128 :-D >=20 >=20 > | - IPv6 specs state that any node MUST have an LL address > |configured. > |They don't say this address has to be used. >=20 > Some protocols clearly specify link-locals MUST be used. > ND RA is an example. OSPFv3 (with the MANET extensions) is another. Agree, I think I mentioned this on my mail. >=20 >=20 > | Therefore, one approach is > |autoconf to propose a way of configure an LL address (maybe as simple as > |just using EUI64 from MAC addresses), but then warn routing protocols > |and applications not to use LL in MANETs. >=20 > I do not see any reason that we cannot use link-locals for MANET routing > protocols. It provides exactly what is needed: routing protocol packets > shall not be forwarded. Using link-locals provides this. We asked for a > link-local multicast address (RFC5498). And we got one !!! Well, using link-local is one approach. Using ULAs/globals with Hop Limit=3D1 would be another. I'd also like to use LLs, but if it makes my life easier to use ULAs/globals, I'd not have a problem using them either. >=20 >=20 > | - Routing protocols might use ULAs or global addresses to work. > |However, there seem to be protocols that say that LL MUST be used (some > |routing protocols, as Teco commented, or just sending RAs, RS). >=20 > RS does not have the link-local requirement. Agree, my mistake. Carlos >=20 > Regards, Teco. >=20 >=20 >=20 >=20 > | - One of the proposals in the room was to focus autoconf on just > |working on a practical way of configuring unique ULAs/global addresses > |(it was also recommended not to make a distinction in the document) and > |forget about LL. > | > | This is my summary, please comment on those things I might have > |got > |wrong. > | > | Now, my opinion about how to progress (I'm listing the approaches > |that > |could be on the table, ordered by my personal preference) is the > |following (I'm just trying to answer to chairs' request to comment on > |the ML, since I'm voted against making DT document a WG document): > | > | - 1st preference: although it'd be easier to forget about LLs, we > |should try to do something better. We may try to come up with something > |that ensures that LL addresses configured in a MANET are not only unique > |within the link-scope (as required by IPv6 specs), but also within the > |MANET scope (whatever scope this is, we have to agree on that scope > |anyway even for ULA uniqueness). This would make the solution harder, > |but it would not break anything I could think of now. My fear is that by > |not paying attention to LL, we may end up forgetting about some protocol > |that is broken (or requires to be revised) in MANETs. > | > | - 2st preference: autoconf just focuses on autoconfiguration of > |ULAs/global addresses, BUT does NOT forget completely about LLs. We may > |just recommend using EUI64-like SLAAC for LLs and comment that due to > |the MANET characteristics, 'users' of LL addresses might not assume that > |LLs are unique within the link (because the link is very dynamic). This > |would not preclude people from using LLs. > | > | - 3rd preference: we forget completely about LLs and just focus on > |ULAs/globals. I'd personally prefer not going there. > | > | Comments? > | > | Thanks, > | > | Carlos > | > |-- > |Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > |GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-vwjETGpLCeGDE2W/areI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkpt26cACgkQNdy6TdFwT2focwCeL7XsdCGLFN4Fgc2f9jiwQZWI iPsAnR+rt5f6K8eA16qqgPr948TPaR6Y =Raq0 -----END PGP SIGNATURE----- --=-vwjETGpLCeGDE2W/areI-- From cjbc@it.uc3m.es Mon Jul 27 10:14:22 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9725E3A6AB2 for ; Mon, 27 Jul 2009 10:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[AWL=-1.848, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MANGLED_NAIL=2.3, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJsW0g0xJOWR for ; Mon, 27 Jul 2009 10:14:21 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id DC81928C17A for ; Mon, 27 Jul 2009 10:14:19 -0700 (PDT) Received: from [130.129.85.252] (unknown [130.129.85.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id A639572C533; Mon, 27 Jul 2009 19:14:19 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Alexandru Petrescu In-Reply-To: <4A6DD69B.40004@gmail.com> References: <4A6DD69B.40004@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-hdbpwbcqAuBg8cbP+xll" Organization: Universidad Carlos III de Madrid Date: Mon, 27 Jul 2009 19:14:27 +0200 Message-Id: <1248714867.4236.311.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16790.000 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Clarification of the formulation of the /128 recommendation X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 17:14:22 -0000 --=-hdbpwbcqAuBg8cbP+xll Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Alex, On Mon, 2009-07-27 at 18:32 +0200, Alexandru Petrescu wrote: > Current DT draft recommends: > > o A subnet prefix configured on this interface should be of length > > /128. I guess next version will say "A Prefix", instead of "A subnet prefix". >=20 > I am trying to understand this formulation. >=20 > What does it mean in practice? >=20 > Does it mean that when I type 'ifconfig' all shown addresses will be=20 > suffixed by "/128"? (and not by any other length, like /64, or /48 or=20 > such). I think so, for all ULAs/global addresses. >=20 > Does it mean that when I type 'route -n' all entries in the routing=20 > table have prefix length 128? (and not /64, nor /48, or similar). I think so, for all routes added to the table because of addresses (ULAs and globals) configured on MANET interfaces. >=20 > There was quick discussion on the jabber room at the end of the meeting,=20 > making think that "/128" may be a red herring, and that the "/128"=20 > recommendation may not conflict with existing specs. These statements=20 > are rather surprising to me. For clarification, I think formulations in=20 > terms of practical screen dump of issued commands may help, at least=20 > myself, thank you. >=20 > Or do most people think that this "/128" recommendation is mostly clear=20 > and is understood? What I understand from that formulation is that that by configuring these addresses, a node will not assume that another address from the same prefix would be directly reachable (within one IP hop) through the interface where the address is configured. Carlos >=20 > Alex >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-hdbpwbcqAuBg8cbP+xll Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkpt4HMACgkQNdy6TdFwT2d0IgCgw6fS63MmhBHtWagAZbJjAQBy xzkAoJRkDNg8qcPtFYib/US7uaE/t5CZ =9RhD -----END PGP SIGNATURE----- --=-hdbpwbcqAuBg8cbP+xll-- From roque.rafael@gmail.com Mon Jul 27 10:17:42 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79A5628C356 for ; Mon, 27 Jul 2009 10:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[AWL=-0.822, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_NAIL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-CCIRT6S1+Z for ; Mon, 27 Jul 2009 10:17:41 -0700 (PDT) Received: from mail-fx0-f217.google.com (mail-fx0-f217.google.com [209.85.220.217]) by core3.amsl.com (Postfix) with ESMTP id 2082E28C33A for ; Mon, 27 Jul 2009 10:17:40 -0700 (PDT) Received: by fxm17 with SMTP id 17so131191fxm.43 for ; Mon, 27 Jul 2009 10:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=pXBJqPWFWlLjcQ2Bx+fxlk4i7nScuim686MLwhIYN9Q=; b=wKLvcB7+OnRj6IadQBTxw9ank1p4O9eUiINmWUCbfHL4ow1gzknq8LMLi9SRD2M0yw uJFRDR5fJ+ouLw/3ESFDEXsC/I1mC2hlu3cgNJn9TVCaEMJLC6WdYaIklhtoWik1UeTs qQQSLOBvtG/12s5uUGGSmJJvIQ6dZ3ucJKNDk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uwggD7LFG7k/frcZUbk+8hGr62QEgZYk7nxfqJU9abPnSjQTlB4YdXaaT95AzdzBQB U09BYcQ58DcmhDsJAqbOTSwXOdbuC76k9zNk3nnjHhAhwQUB4zhkrVTauuoDzC9LK+3Z ZJk3ZwxoSXh0fFUMFeZQahCtOxOp3saX+AMRk= MIME-Version: 1.0 Received: by 10.204.101.80 with SMTP id b16mr3305710bko.73.1248715055352; Mon, 27 Jul 2009 10:17:35 -0700 (PDT) In-Reply-To: <4A6DD69B.40004@gmail.com> References: <4A6DD69B.40004@gmail.com> Date: Mon, 27 Jul 2009 14:17:35 -0300 Message-ID: <1726274c0907271017m651f3e2bm17f43f438483870f@mail.gmail.com> From: Rafael Roque To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=0016e6de15184ccb52046fb321da Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Clarification of the formulation of the /128 recommendation X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 17:17:42 -0000 --0016e6de15184ccb52046fb321da Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Alexandru, i'm still trying to understand all impacts of /32 and /128 fields. I thing that it is not your case, but for those that are a little lost, draft-clausen-manet-autoconf-recommendations-00provides good discussions about the topic. On Mon, Jul 27, 2009 at 1:32 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Current DT draft recommends: > >> o A subnet prefix configured on this interface should be of length >> /128. >> > > I am trying to understand this formulation. > > What does it mean in practice? > > Does it mean that when I type 'ifconfig' all shown addresses will be > suffixed by "/128"? (and not by any other length, like /64, or /48 or > such). > > Does it mean that when I type 'route -n' all entries in the routing table > have prefix length 128? (and not /64, nor /48, or similar). > > There was quick discussion on the jabber room at the end of the meeting, > making think that "/128" may be a red herring, and that the "/128" > recommendation may not conflict with existing specs. These statements are > rather surprising to me. For clarification, I think formulations in terms > of practical screen dump of issued commands may help, at least myself, thank > you. > > Or do most people think that this "/128" recommendation is mostly clear and > is understood? > > Alex > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > -- Rafael Roque Aschoff GPRT/UFPE --0016e6de15184ccb52046fb321da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alexandru,

i'm still trying to understand all impacts of /32 = and /128 fields.
I thing that it is not your case, but for those that ar= e a little lost, draft-clausen-manet-autoconf-recommendations-0= 0 provides good discussions about the topic.

On Mon, Jul 27, 2009 at 1:32 PM, Alexandru P= etrescu <alexandru.petrescu@gmail.com> wrote:
Current DT draft recommends:
=A0 o =A0A subnet prefix configured on this interface should be of length<= br> =A0 =A0 =A0/128.

I am trying to understand this formulation.

What does it mean in practice?

Does it mean that when I type 'ifconfig' all shown addresses will b= e suffixed by "/128"? =A0(and not by any other length, like /64, = or /48 or such).

Does it mean that when I type 'route -n' all entries in the routing= table have prefix length 128? (and not /64, nor /48, or similar).

There was quick discussion on the jabber room at the end of the meeting, ma= king think that "/128" may be a red herring, and that the "/= 128" recommendation may not conflict with existing specs. =A0These sta= tements are rather surprising to me. =A0For clarification, I think formulat= ions in terms of practical screen dump of issued commands may help, at leas= t myself, thank you.

Or do most people think that this "/128" recommendation is mostly= clear and is understood?

Alex

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



--
Rafael Roque AschoffGPRT/UFPE

--0016e6de15184ccb52046fb321da-- From erik.nordmark@sun.com Mon Jul 27 10:46:32 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51D293A6C59 for ; Mon, 27 Jul 2009 10:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.996 X-Spam-Level: X-Spam-Status: No, score=-5.996 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhESKJGAGH-J for ; Mon, 27 Jul 2009 10:46:31 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 477893A6C77 for ; Mon, 27 Jul 2009 10:46:31 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6RHivBG026778; Mon, 27 Jul 2009 17:44:57 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n6RHisWe607765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Jul 2009 10:44:56 -0700 (PDT) Message-ID: <4A6DE796.20901@sun.com> Date: Mon, 27 Jul 2009 19:44:54 +0200 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: Teco Boot References: <4A6DBFB5.3050305@sun.com> <000001ca0ed8$98408350$c8c189f0$@nl> In-Reply-To: <000001ca0ed8$98408350$c8c189f0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Suggested text on link-locals X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 17:46:32 -0000 Teco Boot wrote: > |Note > | that IPv6 link-local addresses are assumed "on link".. However, the > | utility of IPv6 link-locals is limited as specified in section 6.2. > > We just specify "on-link" not equals "reachable". > "on-link" means here we don't send packets with a link-local as destination > to a default gateway. I can't parse your first sentence. Are you suggesting that we say something different in the draft? Or that we are already specifying this? Note that in general (even on an Ethernet) all on-link addresses are not reachable; fe80::/10 (or fe80::/64) is on-link, but you don't get a response from all the addresses in that prefix. > | > |At the end of section 6.2 add this text: > | > |A IPv6 link-local addresses must be assigned to each interface according > |to [RFC 4291]. Due to the connectivity properties of these links with > |neighbors constantly moving in and out of reachability, the link-local > |addresses are of very limited utility. > > Maybe, maybe not. I would not disqualify the characteristics. I explicitly tried to not forbid them - just have appropriate warnings. > > | The known limitations are: > | - Even if tested for uniqueness at one moment using Duplicate Address > |Detection [RFC 4862], a duplicate link-local address might appear as a > |neighbor the next moment and DAD would not detect that. > > I do not understand the difference with globals / ULAs. The autoconf WG would presumably come up with a protocol that has some ways to avoid non-unique addresses being allocated. > | - There is no mechanism to ensure that IPv6 link-local are unique > |across multiple links, hence they can not be used to reliably identify > |routers. > > This is nothing new. > And the IETF routing protocol number 1 protocol runs perfect on it. ICMPv4 doesn't run on IPv6; Perhaps you meant ICMPv6, which I wouldn't call a routing protocol; I could call it an ES-IS protocol. > Many others have no problem either. Duplicate address detection is there to handle unlikely, but very hard to detect failures. Hence it is no surprise that most of the time one can get away with not doing any DAD. > | - Routers must not forward any packets with Link-Local source or > | destination addresses to other links [RFC 4921]. And a Manet router > |that forwards packets by definition forwards from one link to another > |due to the undefined connectivity properties. > > There are multiple opinions on what a link is. > So I cannot agree on the text. But I know what you are saying. Part of the idea with the text in this but a stake in the ground in what a link is for these dynamic environments. I don't know if it makes sense to do that more directly in a separate section in the document, or have it be in this section, but I think it should be in the document. Erik > |(The set of neighbors that > |heard the packet received by the router might be different than the set > |of neighbors that hears a packet transmitted by the router even if the > |same interface on the router is used for the two operations.) > > Yes, and this is exactly what makes it very powerful for neighborhood > Discovery [NHDP, OSPF, etc.]. > > > Regards, Teco. > > > > | > | Erik > | > |_______________________________________________ > |Autoconf mailing list > |Autoconf@ietf.org > |https://www.ietf.org/mailman/listinfo/autoconf > From Fred.L.Templin@boeing.com Mon Jul 27 12:32:38 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A815C3A6CF8 for ; Mon, 27 Jul 2009 12:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAHiD1+NFxmd for ; Mon, 27 Jul 2009 12:32:37 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id D17163A6CEB for ; Mon, 27 Jul 2009 12:32:37 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n6RJWYQC016914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 27 Jul 2009 14:32:34 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n6RJWYIQ004197 for ; Mon, 27 Jul 2009 14:32:34 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n6RJWXHD004154 for ; Mon, 27 Jul 2009 14:32:34 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 12:32:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Jul 2009 12:32:35 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10635BCC1@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <4A6DE796.20901@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VET and link-layer multiplexing Thread-Index: AcoO4jDu4Esj4VJWTHqR90ErkOoeAgADSnGg References: <4A6DBFB5.3050305@sun.com> <000001ca0ed8$98408350$c8c189f0$@nl> <4A6DE796.20901@sun.com> From: "Templin, Fred L" To: X-OriginalArrivalTime: 27 Jul 2009 19:32:32.0120 (UTC) FILETIME=[FC4B1780:01CA0EF0] Subject: [Autoconf] VET and link-layer multiplexing X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 19:32:38 -0000 Hi, I have updated the VET spec to match the proposal briefed to the autoconf working group today. In this proposal, the MANET router configures a virtual interface (i.e., a VET interface) over one or several underlying MANET interfaces that belong to the same MANET. The MANET router then only needs to assign an address to the VET interface and can leave the MANET interfaces with link-local addresses only or with no addresses at all. The specific text is found in section 4.1 and Appendix B. The term "Enterprise Router (ER)" is equivalent to the term "MANET router" as it is normally used in the autoconf terminology. The term "enterprise-interior interface" is equivalent to "MANET interface", and an "Enterprise Border Router (EBR)" is simply a MANET router that also configures a VET interface. Please have a look and send any questions or comments. The draft is here: http://tools.ietf.org/html/draft-templin-intarea-vet Fred fred.l.templin@boeing.com From alexandru.petrescu@gmail.com Mon Jul 27 12:45:17 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB3AA3A6C87 for ; Mon, 27 Jul 2009 12:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.518 X-Spam-Level: X-Spam-Status: No, score=-0.518 tagged_above=-999 required=5 tests=[AWL=-0.569, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_NAIL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KC5P2xIinKI for ; Mon, 27 Jul 2009 12:45:17 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id D68353A6A8B for ; Mon, 27 Jul 2009 12:45:15 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 145EFD4813A; Mon, 27 Jul 2009 21:45:11 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id C2DB6D4818C; Mon, 27 Jul 2009 21:45:08 +0200 (CEST) Message-ID: <4A6E03C2.3050308@gmail.com> Date: Mon, 27 Jul 2009 21:45:06 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <4A6DD69B.40004@gmail.com> <1248714867.4236.311.camel@acorde.it.uc3m.es> In-Reply-To: <1248714867.4236.311.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090726-1, 26/07/2009), Outbound message X-Antivirus-Status: Clean Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Clarification of the formulation of the /128 recommendation X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 19:45:17 -0000 Carlos Jesús Bernardos Cano a écrit : > Hi Alex, > > On Mon, 2009-07-27 at 18:32 +0200, Alexandru Petrescu wrote: >> Current DT draft recommends: >>> o A subnet prefix configured on this interface should be of length >>> /128. > > I guess next version will say "A Prefix", instead of "A subnet prefix". Will it say "for all addresses configured on this interface, the respective prefix will be /128"? Or just for some? >> I am trying to understand this formulation. >> >> What does it mean in practice? >> >> Does it mean that when I type 'ifconfig' all shown addresses will be >> suffixed by "/128"? (and not by any other length, like /64, or /48 or >> such). > > I think so, for all ULAs/global addresses. I hope that instead of "for all" it will be "for some". >> Does it mean that when I type 'route -n' all entries in the routing >> table have prefix length 128? (and not /64, nor /48, or similar). > > I think so, for all routes added to the table because of addresses (ULAs > and globals) configured on MANET interfaces. I think so too. >> There was quick discussion on the jabber room at the end of the meeting, >> making think that "/128" may be a red herring, and that the "/128" >> recommendation may not conflict with existing specs. These statements >> are rather surprising to me. For clarification, I think formulations in >> terms of practical screen dump of issued commands may help, at least >> myself, thank you. >> >> Or do most people think that this "/128" recommendation is mostly clear >> and is understood? > > What I understand from that formulation is that that by configuring > these addresses, a node will not assume that another address from the > same prefix would be directly reachable (within one IP hop) through the > interface where the address is configured. We don't understand the same thing. Would a routing table entry in the node look like this: Destination Gateway Iface 2001:db0:1::1/128 2001:db0:2::2 eth0 Maybe this is what is meant by the "/128" requirement? The Gateway address is directly reachable from the node. Setting a host-based route (/128) can not mean that the Gateway address is not directly reachable. But, if node has the routing table entry like this: Destination Gateway Iface 2001:db0:1::1/128 :: eth0 Then this may mean something different - go through self to reach some outter destination. To clarify this difference, the draft could require that in addition to the /128 host-based route, the routing table entry MUST use an unspecified gateway address - ::. I guess this is what happens in some MANET implementations (guessing). If so, it should be reflected in the draft. [Another thing, if the "/128" requirement is actually the host-based route in the routing table, then it may pose a problem reaching hosts behind a MANET router having 2 interfaces, because the source would have to have a host-based route for each host behind that MANET router, whereas a shorter-than-128 prefix route would suffice.] Alex > > Carlos > >> Alex >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf From alexandru.petrescu@gmail.com Mon Jul 27 13:02:08 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6085A3A6CA6 for ; Mon, 27 Jul 2009 13:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.311 X-Spam-Level: X-Spam-Status: No, score=-0.311 tagged_above=-999 required=5 tests=[AWL=-0.662, BAYES_50=0.001, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYtKCRoSETf5 for ; Mon, 27 Jul 2009 13:02:07 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 6CFDB3A6C80 for ; Mon, 27 Jul 2009 13:02:05 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id BB489D4816A for ; Mon, 27 Jul 2009 22:02:03 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id B6E9AD4810C for ; Mon, 27 Jul 2009 22:02:00 +0200 (CEST) Message-ID: <4A6E07B6.1090007@gmail.com> Date: Mon, 27 Jul 2009 22:01:58 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) 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 090726-1, 26/07/2009), Outbound message X-Antivirus-Status: Clean Subject: [Autoconf] Applications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 20:02:08 -0000 During the meeting there was questioning about which applications are considered in AUTOCONF? The obvious answer "MANET applications" is not sufficient I believe. Two different MANET applications: -------- -------- -------- -------- | Fixed | | Fixed | | Fixed | | Fixed | | Access | | Access | | Access | . . . | Access | | Point | | Point | | Point | | Point | -------- -------- -------- -------- | | | | | | | | o o o o wifi antenna o | o ------ movement | |Mobile| -------> ------ |Host | <----- |Mobile| ------ |Host | ------ ==========================cut here============================== o o | | ------ ------ |Mobile| |Mobile| |Router| ----- |Router| ----- ------ |Fixed| ------ |Fixed| | |Host | | |Host | | --|-- | --|-- --------------| --------------| These applications necessitate different ways of configuring the addresses. I don't think the rule "/128" could fit both. Alex From charles.perkins@earthlink.net Mon Jul 27 14:02:56 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A258F3A6CF8 for ; Mon, 27 Jul 2009 14:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZZkorPFMrbD for ; Mon, 27 Jul 2009 14:02:56 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id CDFB53A6AF4 for ; Mon, 27 Jul 2009 14:02:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=jowDSVa7k4RqJuC47O1VtcBUnOMzsb3Bjm903o++47JgIVnSmfNsHEo75t6s4T2x; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [82.99.29.112] (helo=[10.43.1.4]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MVXLU-00025r-T6; Mon, 27 Jul 2009 17:02:57 -0400 Message-ID: <4A6E15FF.6030207@earthlink.net> Date: Mon, 27 Jul 2009 14:02:55 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Alexandru Petrescu References: <4A6E07B6.1090007@gmail.com> In-Reply-To: <4A6E07B6.1090007@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52f88c8c47877a745a5e5587eeb28a9959350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 82.99.29.112 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Applications X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 21:02:56 -0000 Hello Alex, Are these "usage scenarios"? I thought an application was something that usually communicated through sockets. For your example, I guess that the access points are connected to the Internet and offer various subnet prefixes? Also, I guess that the fixed hosts have wireless interfaces and some way of establishing links at layer 2, but do not offer access to the Internet? Regards, Charlie P. Alexandru Petrescu wrote: > During the meeting there was questioning about which applications are > considered in AUTOCONF? The obvious answer "MANET applications" is > not sufficient I believe. > > Two different MANET applications: > > -------- -------- -------- -------- > | Fixed | | Fixed | | Fixed | | Fixed | > | Access | | Access | | Access | . . . | Access | > | Point | | Point | | Point | | Point | > -------- -------- -------- -------- > | | | | > | | | | > o o o o wifi antenna > > o > | o > ------ movement | > |Mobile| -------> ------ > |Host | <----- |Mobile| > ------ |Host | > ------ > > > > ==========================cut here============================== > > > > o o > | | > ------ ------ > |Mobile| |Mobile| > |Router| ----- |Router| ----- > ------ |Fixed| ------ |Fixed| > | |Host | | |Host | > | --|-- | --|-- > --------------| --------------| > > These applications necessitate different ways of configuring the > addresses. I don't think the rule "/128" could fit both. > > Alex > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > > From alexandru.petrescu@gmail.com Mon Jul 27 14:14:04 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE4893A6CB6 for ; Mon, 27 Jul 2009 14:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Her7ax69Eu7f for ; Mon, 27 Jul 2009 14:14:04 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 32F963A6CB8 for ; Mon, 27 Jul 2009 14:13:51 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 011C5D48098; Mon, 27 Jul 2009 23:13:49 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id C9545D480D9; Mon, 27 Jul 2009 23:13:46 +0200 (CEST) Message-ID: <4A6E1888.6060507@gmail.com> Date: Mon, 27 Jul 2009 23:13:44 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4A6E07B6.1090007@gmail.com> <4A6E15FF.6030207@earthlink.net> In-Reply-To: <4A6E15FF.6030207@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090726-1, 26/07/2009), Outbound message X-Antivirus-Status: Clean Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Usage scenarios (was: Applications) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 21:14:04 -0000 Charles E. Perkins a écrit : > > Hello Alex, > > Are these "usage scenarios"? I thought an application > was something that usually communicated through sockets. Hi Charles, ok, usage scenarios. > For your example, I guess that the access points are > connected to the Internet and offer various subnet > prefixes? No, the first usage scenario has fixed access points disconnected from the Internet, and not connected to each other by some wire, just by their wifi interface, such that the hidden terminal problems are exacerbated. They don't offer various subnet prefixes, there are no /64 prefixes, there are only /128 host-based routes. There is not _one_ single subnet prefix either. (it is not like the usage scenario with Mobile IPv6 and Access Routers connected to Internet and each offering a different and distringuished IPv6 prefix). > Also, I guess that the fixed hosts have wireless > interfaces and some way of establishing links at layer 2, > but do not offer access to the Internet? Yes, the fixed hosts have wireless interfaces. Some other times they have wired interfaces instead. And yes, they don't offer access to the Internet. For these simple usage scenarios it is all disconnected from the Internet. I wanted to express how much different are they in their needs to configure addresses. Alex > > Regards, > Charlie P. > > > Alexandru Petrescu wrote: >> During the meeting there was questioning about which applications are >> considered in AUTOCONF? The obvious answer "MANET applications" is >> not sufficient I believe. >> >> Two different MANET applications: >> >> -------- -------- -------- -------- >> | Fixed | | Fixed | | Fixed | | Fixed | >> | Access | | Access | | Access | . . . | Access | >> | Point | | Point | | Point | | Point | >> -------- -------- -------- -------- >> | | | | >> | | | | >> o o o o wifi antenna >> >> o >> | o >> ------ movement | >> |Mobile| -------> ------ >> |Host | <----- |Mobile| >> ------ |Host | >> ------ >> >> >> >> ==========================cut here============================== >> >> >> >> o o >> | | >> ------ ------ >> |Mobile| |Mobile| >> |Router| ----- |Router| ----- >> ------ |Fixed| ------ |Fixed| >> | |Host | | |Host | >> | --|-- | --|-- >> --------------| --------------| >> >> These applications necessitate different ways of configuring the >> addresses. I don't think the rule "/128" could fit both. >> >> Alex >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >> >> > > From charles.perkins@earthlink.net Mon Jul 27 14:20:56 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 694883A69D5 for ; Mon, 27 Jul 2009 14:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJRJJXNfWt0l for ; Mon, 27 Jul 2009 14:20:55 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id B75603A68DC for ; Mon, 27 Jul 2009 14:20:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=AOGg8bqwgdfGAmGZTC8gs/Xr2lestdw+IYW+wtZHqh4XUki9NHtGqYuNIJnxuPGg; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [82.99.29.112] (helo=[10.43.1.4]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MVXcV-0005dP-3j; Mon, 27 Jul 2009 17:20:31 -0400 Message-ID: <4A6E1A1E.2000502@earthlink.net> Date: Mon, 27 Jul 2009 14:20:30 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Teco Boot References: <1248707273.4236.253.camel@acorde.it.uc3m.es> <000101ca0ed8$98652250$c92f66f0$@nl> In-Reply-To: <000101ca0ed8$98652250$c92f66f0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52e41657f8cc101aca9590aef4b11fe5e5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 82.99.29.112 Cc: autoconf@ietf.org Subject: Re: [Autoconf] On the LL issue X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 21:20:56 -0000 Hello Teco, Teco Boot wrote: > > Do you think it is more easy to come up with unique globals? > What makes the difference? > For global addresses or ULAs, we can use those addresses in packet headers of protocol messages that can be forwarded. Link-local addresses cause packets to not be forwardable. Since global uniqueness is a non-local property, in some situations we do have to forward packets to insure global uniqueness. Regards, Charlie P. From erik.nordmark@sun.com Mon Jul 27 14:22:36 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B2FA3A6CF3 for ; Mon, 27 Jul 2009 14:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.859 X-Spam-Level: X-Spam-Status: No, score=-4.859 tagged_above=-999 required=5 tests=[AWL=-1.113, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MANGLED_NAIL=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9V6iCubgWhR for ; Mon, 27 Jul 2009 14:22:35 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 79AC33A6BEC for ; Mon, 27 Jul 2009 14:22:35 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6RLLwAP002272; Mon, 27 Jul 2009 21:21:58 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n6RLLpe2644622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Jul 2009 14:21:53 -0700 (PDT) Message-ID: <4A6E1A64.2070109@sun.com> Date: Mon, 27 Jul 2009 23:21:40 +0200 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: Alexandru Petrescu References: <4A6DD69B.40004@gmail.com> In-Reply-To: <4A6DD69B.40004@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Clarification of the formulation of the /128 recommendation X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 21:22:36 -0000 Alexandru Petrescu wrote: > Current DT draft recommends: >> o A subnet prefix configured on this interface should be of length >> /128. > > I am trying to understand this formulation. > > What does it mean in practice? > > Does it mean that when I type 'ifconfig' all shown addresses will be > suffixed by "/128"? (and not by any other length, like /64, or /48 or > such). > > Does it mean that when I type 'route -n' all entries in the routing > table have prefix length 128? (and not /64, nor /48, or similar). > > There was quick discussion on the jabber room at the end of the meeting, > making think that "/128" may be a red herring, and that the "/128" > recommendation may not conflict with existing specs. These statements > are rather surprising to me. For clarification, I think formulations in > terms of practical screen dump of issued commands may help, at least > myself, thank you. > > Or do most people think that this "/128" recommendation is mostly clear > and is understood? To me it is merely restating that there are no on-link prefixes (except the link-local prefix), which is clear to me. Erik From teco@inf-net.nl Mon Jul 27 15:31:42 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19FC63A6C92 for ; Mon, 27 Jul 2009 15:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.354 X-Spam-Level: X-Spam-Status: No, score=-1.354 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nxcp4kdndssS for ; Mon, 27 Jul 2009 15:31:41 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id AF0193A6CAF for ; Mon, 27 Jul 2009 15:31:40 -0700 (PDT) Received: (qmail 26190 invoked from network); 28 Jul 2009 00:31:38 +0200 Received: from scandic811.host.songnetworks.se (HELO M90Teco) (212.214.188.26) by server9.hosting2go.nl with SMTP; 28 Jul 2009 00:31:38 +0200 From: "Teco Boot" To: "'Erik Nordmark'" References: <4A6DBFB5.3050305@sun.com> <000001ca0ed8$98408350$c8c189f0$@nl> <4A6DE796.20901@sun.com> In-Reply-To: <4A6DE796.20901@sun.com> Date: Tue, 28 Jul 2009 00:31:04 +0200 Message-ID: <002401ca0f0a$00ce4c50$026ae4f0$@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: AcoO4i6OXRrljN+7TpG/xXSEaH1qNAAJQFIA Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] Suggested text on link-locals X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 22:31:42 -0000 Hi Eric, |Teco Boot wrote: | |> |Note |> | that IPv6 link-local addresses are assumed "on link".. However, |the |> | utility of IPv6 link-locals is limited as specified in section |6.2. |> |> We just specify "on-link" not equals "reachable". |> "on-link" means here we don't send packets with a link-local as |destination |> to a default gateway. | |I can't parse your first sentence. Are you suggesting that we say |something different in the draft? Or that we are already specifying |this? What I intended to say is that the assumption that addresses that are "on-link" are reachable is not always true. In a MANET, interfaces on the same link (= communication facility) can be out of transmission range. Using links with full connectivity, "on-link" would mean "reachable" (see remarks below...). The draft does not specify what a link is, nor what "on-link" means. |Note that in general (even on an Ethernet) all on-link addresses are not |reachable; fe80::/10 (or fe80::/64) is on-link, but you don't get a |response from all the addresses in that prefix. OK, so now we can say MANET links are nothing special. And I am even more convinced there is no problem with link-locals. |> |At the end of section 6.2 add this text: |> | |> |A IPv6 link-local addresses must be assigned to each interface |according |> |to [RFC 4291]. Due to the connectivity properties of these links with |> |neighbors constantly moving in and out of reachability, the link- |local |> |addresses are of very limited utility. |> |> Maybe, maybe not. I would not disqualify the characteristics. | |I explicitly tried to not forbid them - just have appropriate warnings. OK. I agree upper layer protocols (applications) shall use ULA or globals. We need to check address selection rules for this (RFC3484). ULA / globals shall be preferred over link-locals. For routing protocols, this is different. |> | The known limitations are: |> | - Even if tested for uniqueness at one moment using Duplicate |Address |> |Detection [RFC 4862], a duplicate link-local address might appear as |a |> |neighbor the next moment and DAD would not detect that. |> |> I do not understand the difference with globals / ULAs. | |The autoconf WG would presumably come up with a protocol that has some |ways to avoid non-unique addresses being allocated. OK. |> | - There is no mechanism to ensure that IPv6 link-local are unique |> |across multiple links, hence they can not be used to reliably |identify |> |routers. |> |> This is nothing new. |> And the IETF routing protocol number 1 protocol runs perfect on it. | |ICMPv4 doesn't run on IPv6; Perhaps you meant ICMPv6, which I wouldn't |call a routing protocol; I could call it an ES-IS protocol. Sorry, I meant OSPF. And to be specific: OSPFv3. |> Many others have no problem either. | |Duplicate address detection is there to handle unlikely, but very hard |to detect failures. Hence it is no surprise that most of the time one |can get away with not doing any DAD. OK. |> | - Routers must not forward any packets with Link-Local source or |> | destination addresses to other links [RFC 4921]. And a Manet |router |> |that forwards packets by definition forwards from one link to another |> |due to the undefined connectivity properties. |> |> There are multiple opinions on what a link is. |> So I cannot agree on the text. But I know what you are saying. | |Part of the idea with the text in this but a stake in the ground in what |a link is for these dynamic environments. I don't know if it makes sense |to do that more directly in a separate section in the document, or have |it be in this section, but I think it should be in the document. Fully agreed we need such. Teco. | Erik | |> |(The set of neighbors that |> |heard the packet received by the router might be different than the |set |> |of neighbors that hears a packet transmitted by the router even if |the |> |same interface on the router is used for the two operations.) |> |> Yes, and this is exactly what makes it very powerful for neighborhood |> Discovery [NHDP, OSPF, etc.]. |> |> |> Regards, Teco. |> |> |> |> | |> | Erik |> | |> |_______________________________________________ |> |Autoconf mailing list |> |Autoconf@ietf.org |> |https://www.ietf.org/mailman/listinfo/autoconf |> From teco@inf-net.nl Mon Jul 27 22:48:06 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7A6D3A680E for ; Mon, 27 Jul 2009 22:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.404 X-Spam-Level: X-Spam-Status: No, score=-1.404 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaDylNf6aZNd for ; Mon, 27 Jul 2009 22:48:06 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 88BA43A6407 for ; Mon, 27 Jul 2009 22:48:05 -0700 (PDT) Received: (qmail 8946 invoked from network); 28 Jul 2009 07:48:03 +0200 Received: from scandic811.host.songnetworks.se (HELO M90Teco) (212.214.188.26) by server9.hosting2go.nl with SMTP; 28 Jul 2009 07:48:03 +0200 From: "Teco Boot" To: References: <1248707273.4236.253.camel@acorde.it.uc3m.es> <000101ca0ed8$98652250$c92f66f0$@nl> <1248713639.4236.306.camel@acorde.it.uc3m.es> In-Reply-To: <1248713639.4236.306.camel@acorde.it.uc3m.es> Date: Tue, 28 Jul 2009 07:47:30 +0200 Message-ID: <003a01ca0f46$f7fef8d0$e7fcea70$@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: AcoO2tYIlmccOFt4Q02DrKYvVT7gtAAaPttQ Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] On the LL issue X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 05:48:06 -0000 Hi Carlos, More on: |> Do you think it is more easy to come up with unique globals? |> What makes the difference? | |Well, depending on the solution (this is solution space) it might be the |same, I agree, but from a high level viewpoint, ensuring uniqueness for |64bits is harder than for 128 :-D OK, let's go for a /4 for MANET local :-). But then, any idea how we can use the 124 bits for a global? So with my foots on the ground, we have 62 bits for random. If we run DAD on Interface-ID (or skip this for reasons), we are done for link-locals, ULA and globals. The latter for whatever /64 prefix is delegated for usage in the MANET. See Fred's doc App.A for discussion on DAD. Teco. From ulrich@herberg.name Mon Jul 27 23:39:16 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D93E53A69C4 for ; Mon, 27 Jul 2009 23:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.826 X-Spam-Level: X-Spam-Status: No, score=-1.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wz5oX3yfGVu for ; Mon, 27 Jul 2009 23:39:15 -0700 (PDT) Received: from mail-fx0-f216.google.com (mail-fx0-f216.google.com [209.85.220.216]) by core3.amsl.com (Postfix) with ESMTP id 40AEA3A68D1 for ; Mon, 27 Jul 2009 23:39:15 -0700 (PDT) Received: by fxm12 with SMTP id 12so168478fxm.37 for ; Mon, 27 Jul 2009 23:39:12 -0700 (PDT) MIME-Version: 1.0 Sender: ulrich@herberg.name Received: by 10.204.54.65 with SMTP id p1mr3968226bkg.195.1248763152400; Mon, 27 Jul 2009 23:39:12 -0700 (PDT) In-Reply-To: <4A6E1888.6060507@gmail.com> References: <4A6E07B6.1090007@gmail.com> <4A6E15FF.6030207@earthlink.net> <4A6E1888.6060507@gmail.com> Date: Tue, 28 Jul 2009 08:39:12 +0200 X-Google-Sender-Auth: 22c0f8a3e79bf2e9 Message-ID: <25c114b90907272339g17b9fe90ufe02c276eab138ed@mail.gmail.com> From: Ulrich Herberg To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=001636c5b9e81b865a046fbe5405 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Usage scenarios (was: Applications) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 06:39:16 -0000 --001636c5b9e81b865a046fbe5405 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alex, I don't understand what you mean. The second scenario looks for me like "classical" IP, nothing new. Since it is a host, it does not need to be exposed to MANET characteristics and can of course be configured by any prefix short than /128 -- the prefix of the non-MANET interface if that mobile router. The first scenario is ok, even though I would not name them mobile hosts, but mobile routers. Ulrich On Mon, Jul 27, 2009 at 11:13 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Charles E. Perkins a =E9crit : > >> >> Hello Alex, >> >> Are these "usage scenarios"? I thought an application >> was something that usually communicated through sockets. >> > > Hi Charles, ok, usage scenarios. > > For your example, I guess that the access points are >> connected to the Internet and offer various subnet >> prefixes? >> > > No, the first usage scenario has fixed access points disconnected from th= e > Internet, and not connected to each other by some wire, just by their wif= i > interface, such that the hidden terminal problems are exacerbated. > > They don't offer various subnet prefixes, there are no /64 prefixes, ther= e > are only /128 host-based routes. There is not _one_ single subnet prefix > either. > > (it is not like the usage scenario with Mobile IPv6 and Access Routers > connected to Internet and each offering a different and distringuished > IPv6 prefix). > > Also, I guess that the fixed hosts have wireless >> interfaces and some way of establishing links at layer 2, >> but do not offer access to the Internet? >> > > Yes, the fixed hosts have wireless interfaces. Some other times they hav= e > wired interfaces instead. And yes, they don't offer access to the > Internet. > > For these simple usage scenarios it is all disconnected from the Internet= . > > I wanted to express how much different are they in their needs to configu= re > addresses. > > Alex > >> >> Regards, >> Charlie P. >> >> >> Alexandru Petrescu wrote: >> >>> During the meeting there was questioning about which applications are >>> considered in AUTOCONF? The obvious answer "MANET applications" is not >>> sufficient I believe. >>> >>> Two different MANET applications: >>> >>> -------- -------- -------- -------- >>> | Fixed | | Fixed | | Fixed | | Fixed | >>> | Access | | Access | | Access | . . . | Access | >>> | Point | | Point | | Point | | Point | >>> -------- -------- -------- -------- >>> | | | | >>> | | | | >>> o o o o wifi antenna >>> >>> o >>> | o >>> ------ movement | >>> |Mobile| -------> ------ >>> |Host | <----- |Mobile| >>> ------ |Host | >>> ------ >>> >>> >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3Dcut here=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> >>> >>> o o >>> | | >>> ------ ------ >>> |Mobile| |Mobile| >>> |Router| ----- |Router| ----- >>> ------ |Fixed| ------ |Fixed| >>> | |Host | | |Host | >>> | --|-- | --|-- >>> --------------| --------------| >>> >>> These applications necessitate different ways of configuring the >>> addresses. I don't think the rule "/128" could fit both. >>> >>> Alex >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf >>> >>> >>> >> >> > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > --001636c5b9e81b865a046fbe5405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alex,

I don't understand what you mean. The second scenario l= ooks for me like "classical" IP, nothing new. Since it is a host,= it does not need to be exposed to MANET characteristics and can of course = be configured by any prefix short than /128 -- the prefix of the non-MANET = interface if that mobile router. The first scenario is ok, even though I wo= uld not name them mobile hosts, but mobile routers.

Ulrich

On Mon, Jul 27, 2009 at 11:13 = PM, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
Charles E. Perkins a =E9crit :

Hello Alex,

Are these "usage scenarios"? =A0I thought an application
was something that usually communicated through sockets.

Hi Charles, ok, usage scenarios.

For your example, I guess that the access points are
connected to the Internet and offer various subnet
prefixes?

No, the first usage scenario has fixed access points disconnected from the = Internet, and not connected to each other by some wire, just by their wifi = interface, such that the hidden terminal problems are exacerbated.

They don't offer various subnet prefixes, there are no /64 prefixes, th= ere are only /128 host-based routes. =A0There is not _one_ single subnet pr= efix either.

(it is not like the usage scenario with Mobile IPv6 and Access Routers
=A0connected to Internet and each offering a different and distringuished =A0IPv6 prefix).

Also, I guess that the fixed hosts have wireless
interfaces and some way of establishing links at layer 2,
but do not offer access to the Internet?

Yes, the fixed hosts have wireless interfaces. =A0Some other times they hav= e wired interfaces instead. =A0And yes, they =A0don't offer access to t= he Internet.

For these simple usage scenarios it is all disconnected from the Internet.<= br>
I wanted to express how much different are they in their needs to configure= addresses.

Alex

Regards,
Charlie P.


Alexandru Petrescu wrote:
During the meeting there was questioning about which applications are consi= dered in AUTOCONF? =A0The obvious answer "MANET applications" is = not sufficient I believe.

Two different MANET applications:

=A0 =A0-------- =A0 =A0 -------- =A0 =A0 -------- =A0 =A0 =A0 =A0 =A0-----= ---
=A0 | Fixed =A0| =A0 | Fixed =A0| =A0 | Fixed =A0| =A0 =A0 =A0 =A0| Fixed = =A0|
=A0 | Access | =A0 | Access | =A0 | Access | . . . =A0| Access |
=A0 | Point =A0| =A0 | Point =A0| =A0 | Point =A0| =A0 =A0 =A0 =A0| Point = =A0|
=A0 =A0-------- =A0 =A0 -------- =A0 =A0 -------- =A0 =A0 =A0 =A0 --------=
=A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 o =A0 =A0 =A0 =A0 =A0 =A0o =A0 =A0 =A0 =A0 =A0 =A0o =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 o wifi antenna

=A0 =A0 =A0 =A0o
=A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 o
=A0 =A0 =A0------ =A0 =A0 =A0movement =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=
=A0 =A0 |Mobile| =A0 =A0-------> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ------=
=A0 =A0 |Host =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<----- =A0|Mo= bile|
=A0 =A0 =A0------ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = |Host =A0|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0------



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3Dcut here=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D



=A0 =A0 =A0 =A0o =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 o
=A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 |
=A0 =A0 =A0------ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0------
=A0 =A0 |Mobile| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|M= obile|
=A0 =A0 |Router| =A0 =A0 ----- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|Router|= =A0 =A0 -----
=A0 =A0 =A0------ =A0 =A0 |Fixed| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-----= - =A0 =A0 |Fixed|
=A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0|Host | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0| =A0 =A0 =A0 =A0|Host |
=A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 --|-- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | =A0 =A0 =A0 =A0 --|--
=A0 =A0 =A0--------------| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -------= -------|

These applications necessitate different ways of configuring the addresses.= =A0I don't think the rule "/128" could fit both.

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





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

--001636c5b9e81b865a046fbe5405-- From cjbc@it.uc3m.es Tue Jul 28 00:08:18 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 428723A6BD2 for ; Tue, 28 Jul 2009 00:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.481 X-Spam-Level: X-Spam-Status: No, score=-3.481 tagged_above=-999 required=5 tests=[AWL=-1.478, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MANGLED_NAIL=2.3, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kg5gUKcOAsN6 for ; Tue, 28 Jul 2009 00:08:17 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id E48043A6B7A for ; Tue, 28 Jul 2009 00:08:16 -0700 (PDT) Received: from [130.129.85.252] (unknown [130.129.85.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id B317AB484CA; Tue, 28 Jul 2009 09:08:16 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Alexandru Petrescu In-Reply-To: <4A6E03C2.3050308@gmail.com> References: <4A6DD69B.40004@gmail.com> <1248714867.4236.311.camel@acorde.it.uc3m.es> <4A6E03C2.3050308@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-bzx7T4vrv4WGnK7V3WxU" Organization: Universidad Carlos III de Madrid Date: Tue, 28 Jul 2009 09:08:23 +0200 Message-Id: <1248764904.4236.332.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16790.003 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Clarification of the formulation of the /128 recommendation X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 07:08:18 -0000 --=-bzx7T4vrv4WGnK7V3WxU Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable On Mon, 2009-07-27 at 21:45 +0200, Alexandru Petrescu wrote: > Carlos Jes=FAs Bernardos Cano a =E9crit : > > Hi Alex, > >=20 > > On Mon, 2009-07-27 at 18:32 +0200, Alexandru Petrescu wrote: > >> Current DT draft recommends: > >>> o A subnet prefix configured on this interface should be of lengt= h > >>> /128. > >=20 > > I guess next version will say "A Prefix", instead of "A subnet prefix". >=20 > Will it say "for all addresses configured on this interface, the=20 > respective prefix will be /128"? Or just for some? I think it should say for all the addresses configured by autoconf. >=20 > >> I am trying to understand this formulation. > >> > >> What does it mean in practice? > >> > >> Does it mean that when I type 'ifconfig' all shown addresses will be=20 > >> suffixed by "/128"? (and not by any other length, like /64, or /48 or= =20 > >> such). > >=20 > > I think so, for all ULAs/global addresses. >=20 > I hope that instead of "for all" it will be "for some". Agree. >=20 > >> Does it mean that when I type 'route -n' all entries in the routing=20 > >> table have prefix length 128? (and not /64, nor /48, or similar). > >=20 > > I think so, for all routes added to the table because of addresses (ULA= s > > and globals) configured on MANET interfaces. >=20 > I think so too. >=20 > >> There was quick discussion on the jabber room at the end of the meetin= g,=20 > >> making think that "/128" may be a red herring, and that the "/128"=20 > >> recommendation may not conflict with existing specs. These statements= =20 > >> are rather surprising to me. For clarification, I think formulations = in=20 > >> terms of practical screen dump of issued commands may help, at least=20 > >> myself, thank you. > >> > >> Or do most people think that this "/128" recommendation is mostly clea= r=20 > >> and is understood? > >=20 > > What I understand from that formulation is that that by configuring > > these addresses, a node will not assume that another address from the > > same prefix would be directly reachable (within one IP hop) through the > > interface where the address is configured. >=20 > We don't understand the same thing. >=20 > Would a routing table entry in the node look like this: >=20 > Destination Gateway Iface > 2001:db0:1::1/128 2001:db0:2::2 eth0 >=20 > Maybe this is what is meant by the "/128" requirement? The Gateway=20 > address is directly reachable from the node. >=20 > Setting a host-based route (/128) can not mean that the Gateway address=20 > is not directly reachable. >=20 > But, if node has the routing table entry like this: >=20 > Destination Gateway Iface > 2001:db0:1::1/128 :: eth0 >=20 > Then this may mean something different - go through self to reach some=20 > outter destination. To clarify this difference, the draft could require=20 > that in addition to the /128 host-based route, the routing table entry=20 > MUST use an unspecified gateway address - ::. I guess this is what=20 > happens in some MANET implementations (guessing). If so, it should be=20 > reflected in the draft. >=20 > [Another thing, if the "/128" requirement is actually the host-based > route in the routing table, then > it may pose a problem reaching > hosts behind a MANET router having 2 interfaces, because the source > would > have to have a host-based route for each host behind that > MANET router, whereas a shorter-than-128 prefix route would suffice.] >=20 > Alex >=20 >=20 > >=20 > > Carlos > >=20 > >> Alex > >> > >> _______________________________________________ > >> Autoconf mailing list > >> Autoconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/autoconf >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-bzx7T4vrv4WGnK7V3WxU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkpuo+cACgkQNdy6TdFwT2eiywCfdnPydVTpaDxUr9KJUf7FKjmL TGQAoLG7PzcQdObuYwiDxbJFCfoRR9/6 =9q2L -----END PGP SIGNATURE----- --=-bzx7T4vrv4WGnK7V3WxU-- From cjbc@it.uc3m.es Tue Jul 28 00:14:45 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F13B53A6997 for ; Tue, 28 Jul 2009 00:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.083 X-Spam-Level: X-Spam-Status: No, score=-5.083 tagged_above=-999 required=5 tests=[AWL=0.616, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRC2ATXtgjHj for ; Tue, 28 Jul 2009 00:14:44 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id E1E623A67AA for ; Tue, 28 Jul 2009 00:14:43 -0700 (PDT) Received: from [130.129.85.252] (unknown [130.129.85.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id BAAA4659E27; Tue, 28 Jul 2009 09:14:42 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Teco Boot In-Reply-To: <003a01ca0f46$f7fef8d0$e7fcea70$@nl> References: <1248707273.4236.253.camel@acorde.it.uc3m.es> <000101ca0ed8$98652250$c92f66f0$@nl> <1248713639.4236.306.camel@acorde.it.uc3m.es> <003a01ca0f46$f7fef8d0$e7fcea70$@nl> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-BSNzYDz70nrtArW12pJv" Organization: Universidad Carlos III de Madrid Date: Tue, 28 Jul 2009 09:14:50 +0200 Message-Id: <1248765290.4236.338.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16790.003 Cc: autoconf@ietf.org Subject: Re: [Autoconf] On the LL issue X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 07:14:45 -0000 --=-BSNzYDz70nrtArW12pJv Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Teco, On Tue, 2009-07-28 at 07:47 +0200, Teco Boot wrote: > Hi Carlos, >=20 > More on: > |> Do you think it is more easy to come up with unique globals? > |> What makes the difference? > | > |Well, depending on the solution (this is solution space) it might be the > |same, I agree, but from a high level viewpoint, ensuring uniqueness for > |64bits is harder than for 128 :-D >=20 > OK, let's go for a /4 for MANET local :-). > But then, any idea how we can use the 124 bits for a global? >=20 > So with my foots on the ground, we have 62 bits for random. > If we run DAD on Interface-ID (or skip this for reasons),=20 > we are done for link-locals, ULA and globals. The latter for > whatever /64 prefix is delegated for usage in the MANET. > See Fred's doc App.A for discussion on DAD. I know, and I fully agree that it'd be enough to use random IID. You can also check http://tools.ietf.org/html/draft-soto-mobileip-random-iids-00, it is also a good reading. Carlos >=20 > Teco. >=20 >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-BSNzYDz70nrtArW12pJv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkpupWoACgkQNdy6TdFwT2c3lwCfbcXHrfRgY7s/drBnPgKoD+Fy /IYAnjTNX0Ni0cWOBCcelIQ6zcxyS/7N =yY15 -----END PGP SIGNATURE----- --=-BSNzYDz70nrtArW12pJv-- From ulrich@herberg.name Tue Jul 28 00:38:21 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BAE13A67BD for ; Tue, 28 Jul 2009 00:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.876 X-Spam-Level: X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITiWMecjaLuY for ; Tue, 28 Jul 2009 00:38:20 -0700 (PDT) Received: from mail-fx0-f216.google.com (mail-fx0-f216.google.com [209.85.220.216]) by core3.amsl.com (Postfix) with ESMTP id AFBE13A6A01 for ; Tue, 28 Jul 2009 00:38:19 -0700 (PDT) Received: by fxm12 with SMTP id 12so191563fxm.37 for ; Tue, 28 Jul 2009 00:38:18 -0700 (PDT) MIME-Version: 1.0 Sender: ulrich@herberg.name Received: by 10.204.119.71 with SMTP id y7mr4126314bkq.24.1248766698219; Tue, 28 Jul 2009 00:38:18 -0700 (PDT) In-Reply-To: <4A6E03C2.3050308@gmail.com> References: <4A6DD69B.40004@gmail.com> <1248714867.4236.311.camel@acorde.it.uc3m.es> <4A6E03C2.3050308@gmail.com> Date: Tue, 28 Jul 2009 09:38:18 +0200 X-Google-Sender-Auth: 0a5adc286af4e744 Message-ID: <25c114b90907280038u4a82c57ax38c68fbf75064d0c@mail.gmail.com> From: Ulrich Herberg To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=0016e6d59e1f746bab046fbf2795 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Clarification of the formulation of the /128 recommendation X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 07:38:21 -0000 --0016e6d59e1f746bab046fbf2795 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Alex, On Mon, Jul 27, 2009 at 9:45 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > [...] > Will it say "for all addresses configured on this interface, the respective > prefix will be /128"? Or just for some? > For all addresses that we configure in autoconf. > > [...] >>> Does it mean that when I type 'ifconfig' all shown addresses will be >>> suffixed by "/128"? (and not by any other length, like /64, or /48 or >>> such). >>> >> >> I think so, for all ULAs/global addresses. >> > > I hope that instead of "for all" it will be "for some". Why? > We don't understand the same thing. > [...] > > Would a routing table entry in the node look like this: > > Destination Gateway Iface > 2001:db0:1::1/128 2001:db0:2::2 eth0 > > Maybe this is what is meant by the "/128" requirement? The Gateway address > is directly reachable from the node. Yes, that looks valid for me. > > > Setting a host-based route (/128) can not mean that the Gateway address is > not directly reachable. Why should it? > > > But, if node has the routing table entry like this: > > Destination Gateway Iface > 2001:db0:1::1/128 :: eth0 > > Then this may mean something different - go through self to reach some > outter destination. To clarify this difference, the draft could require > that in addition to the /128 host-based route, the routing table entry MUST > use an unspecified gateway address - ::. I guess this is what happens in > some MANET implementations (guessing). If so, it should be reflected in the > draft. No, I don't think that's a necessity. > > > [Another thing, if the "/128" requirement is actually the host-based > route in the routing table, then > it may pose a problem reaching > hosts behind a MANET router having 2 interfaces, because the source > would > have to have a host-based route for each host behind that > MANET router, whereas a shorter-than-128 prefix route would suffice.] > Keep in mind that we are talking about MANET interfaces on a MANET router only. If there is other stuff (e.g. hosts) behind the MANET router (so, on a non-MANET interface of that MANET router), they are configured as usual. We are not talking about how to configure these hosts behind the MANET router. Ulrich --0016e6d59e1f746bab046fbf2795 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alex,

On Mon, Jul 27, 2009 at 9:45 PM, Al= exandru Petrescu <alexandru.petrescu@gmail.com> wrote:
[...]
Will it say "for all addresses configured on this interface, = the respective prefix will be /128"? =A0Or just for some?


For all addresses that we configure in autoconf.
=A0

[...]
Does it mean that when I type 'ifconfig' all shown addresses will b= e suffixed by "/128"? =A0(and not by any other length, like /64, = or /48 or such).

I think so, for all ULAs/global addresses.

I hope that instead of "for all" it will be "for some".=

Why?
=A0
We don't understand the same thing.
[...]

Would a routing table entry in the node look like this:

Destination =A0 =A0 =A0 =A0 =A0 Gateway =A0 =A0 =A0 =A0 =A0 =A0 =A0Iface 2001:db0:1::1/128 =A0 =A0 2001:db0:2::2 =A0 =A0 =A0 =A0eth0

Maybe this is what is meant by the "/128" requirement? =A0The Gat= eway address is directly reachable from the node.


= Yes, that looks valid for me.

=A0


Setting a host-based route (/128) can not mean that the Gateway address is = not directly reachable.

Why should it?
=A0


But, if node has the routing table entry like this:

Destination =A0 =A0 =A0 =A0 =A0 Gateway =A0 =A0 =A0 =A0 =A0 =A0 =A0Iface 2001:db0:1::1/128 =A0 =A0 :: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 eth0

Then this may mean something different - go through self to reach some outt= er destination. =A0To clarify this difference, the draft could require that= in addition to the /128 host-based route, the routing table entry MUST use= an unspecified gateway address - ::. =A0I guess this is what happens in so= me MANET implementations (guessing). =A0If so, it should be reflected in th= e draft.

No, I don't think that's a necessity.
=A0


[Another thing, if the "/128" requirement is actually the host-ba= sed
=A0route in the routing table, then
=A0it may pose a problem reaching
=A0hosts behind a MANET router having 2 interfaces, because the source
=A0would
=A0have to have a host-based route for each host behind that
=A0MANET router, whereas a shorter-than-128 prefix route would suffice.]

Keep in mind that we are talking about MANET interfa= ces on a MANET router only. If there is other stuff (e.g. hosts) behind the= MANET router (so, on a non-MANET interface of that MANET router), they are= configured as usual. We are not talking about how to configure these hosts= behind the MANET router.

Ulrich
=A0
--0016e6d59e1f746bab046fbf2795-- From erik.nordmark@sun.com Tue Jul 28 00:39:02 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF7E33A691A for ; Tue, 28 Jul 2009 00:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.786 X-Spam-Level: X-Spam-Status: No, score=-5.786 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93iZyrcivSYe for ; Tue, 28 Jul 2009 00:39:02 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id BF5093A6997 for ; Tue, 28 Jul 2009 00:38:59 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6S7ctMA002141; Tue, 28 Jul 2009 07:38:55 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n6S7cr5x729602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 00:38:55 -0700 (PDT) Message-ID: <4A6EAB0C.8020008@sun.com> Date: Tue, 28 Jul 2009 00:38:52 -0700 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: Teco Boot References: <4A6DBFB5.3050305@sun.com> <000001ca0ed8$98408350$c8c189f0$@nl> <4A6DE796.20901@sun.com> <002401ca0f0a$00ce4c50$026ae4f0$@nl> In-Reply-To: <002401ca0f0a$00ce4c50$026ae4f0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Suggested text on link-locals X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 07:39:03 -0000 Teco Boot wrote: > What I intended to say is that the assumption that addresses that > are "on-link" are reachable is not always true. In a MANET, interfaces > on the same link (= communication facility) can be out of transmission > range. Using links with full connectivity, "on-link" would mean > "reachable" (see remarks below...). OK > The draft does not specify what a link is, nor what "on-link" means. It does so implicitly. If you want it to be more explicit, then you should direct that comment to the authors/DT. I tried to have this thread be about the suggested clarifications for IPv6 link-local addresses. > |Note that in general (even on an Ethernet) all on-link addresses are not > |reachable; fe80::/10 (or fe80::/64) is on-link, but you don't get a > |response from all the addresses in that prefix. > > OK, so now we can say MANET links are nothing special. > And I am even more convinced there is no problem with link-locals. The largest issue with link-locals is that they are not guaranteed to have the uniqueness properties you might assume. Hence I think the utility of IPv6 link-locals is very limited. > |> This is nothing new. > |> And the IETF routing protocol number 1 protocol runs perfect on it. > | > |ICMPv4 doesn't run on IPv6; Perhaps you meant ICMPv6, which I wouldn't > |call a routing protocol; I could call it an ES-IS protocol. > > Sorry, I meant OSPF. And to be specific: OSPFv3. I don't think you can assert that OSPFv3 works correctly by a simple test, since your EUI-64 derived link-locals are not likely to conflict in your test. To show that OSPFv3 works you would actually have to run it with routers that (at least temporarily) have the same IPv6 link-local addresses yet are on the same link. That would help verify that such routers temporarily being within reach doesn't cause any confusion. > |Part of the idea with the text in this but a stake in the ground in what > |a link is for these dynamic environments. I don't know if it makes sense > |to do that more directly in a separate section in the document, or have > |it be in this section, but I think it should be in the document. > > Fully agreed we need such. Care to propose text to the WG? Erik From ulrich@herberg.name Tue Jul 28 00:55:37 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A01A63A67BD for ; Tue, 28 Jul 2009 00:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lJMaZhFLj8n for ; Tue, 28 Jul 2009 00:55:36 -0700 (PDT) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by core3.amsl.com (Postfix) with ESMTP id 510793A691A for ; Tue, 28 Jul 2009 00:55:36 -0700 (PDT) Received: by bwz21 with SMTP id 21so718543bwz.37 for ; Tue, 28 Jul 2009 00:55:07 -0700 (PDT) MIME-Version: 1.0 Sender: ulrich@herberg.name Received: by 10.204.119.71 with SMTP id y7mr4133739bkq.24.1248767211896; Tue, 28 Jul 2009 00:46:51 -0700 (PDT) In-Reply-To: <4A6DBFB5.3050305@sun.com> References: <4A6DBFB5.3050305@sun.com> Date: Tue, 28 Jul 2009 09:46:51 +0200 X-Google-Sender-Auth: 3a0ac8f9070f7dfc Message-ID: <25c114b90907280046m540d2698xf67d6d9d02a7cf10@mail.gmail.com> From: Ulrich Herberg To: Erik Nordmark Content-Type: multipart/alternative; boundary=0016e6d59e1f12805a046fbf465c Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Suggested text on link-locals X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 07:55:37 -0000 --0016e6d59e1f12805a046fbf465c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Erik, thanks for the text. It is ok for me. Ulrich On Mon, Jul 27, 2009 at 4:54 PM, Erik Nordmark wrote: > > Does this make it more clear? > > In section 4.2 change the sentence > If the link to which an interface connects enables no assumptions of > connectivity to other interfaces, the only addresses which can be > assumed "on link", are the address(es) of that interface itself. > to > If the link to which an interface connects enables no assumptions of > connectivity to other interfaces, the only addresses which can be > assumed "on link", are the address(es) of that interface itself. Note > that IPv6 link-local addresses are assumed "on link".. However, the > utility of IPv6 link-locals is limited as specified in section 6.2. > > At the end of section 6.2 add this text: > > A IPv6 link-local addresses must be assigned to each interface according to > [RFC 4291]. Due to the connectivity properties of these links with neighbors > constantly moving in and out of reachability, the link-local addresses are > of very limited utility. The known limitations are: > - Even if tested for uniqueness at one moment using Duplicate Address > Detection [RFC 4862], a duplicate link-local address might appear as a > neighbor the next moment and DAD would not detect that. > - There is no mechanism to ensure that IPv6 link-local are unique across > multiple links, hence they can not be used to reliably identify routers. > - Routers must not forward any packets with Link-Local source or > destination addresses to other links [RFC 4921]. And a Manet router that > forwards packets by definition forwards from one link to another due to the > undefined connectivity properties. (The set of neighbors that heard the > packet received by the router might be different than the set of neighbors > that hears a packet transmitted by the router even if the same interface on > the router is used for the two operations.) > > Erik > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > --0016e6d59e1f12805a046fbf465c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Erik,

thanks for the text. It is ok for me.

Ulrich

=
On Mon, Jul 27, 2009 at 4:54 PM, Erik Nordmark <= span dir=3D"ltr"><erik.nordmark= @sun.com> wrote:

Does this make it more clear?

In section 4.2 change the sentence
=A0 If the link to which an interface connects enables no assumptions of =A0 connectivity to other interfaces, the only addresses which can be
=A0 assumed "on link", are the address(es) of that interface its= elf.
to
=A0 If the link to which an interface connects enables no assumptions of =A0 connectivity to other interfaces, the only addresses which can be
=A0 assumed "on link", are the address(es) of that interface its= elf. Note
=A0 that IPv6 link-local addresses are assumed "on link".. Howev= er, the
=A0 utility of IPv6 link-locals is limited as specified in section 6.2.
At the end of section 6.2 add this text:

A IPv6 link-local addresses must be assigned to each interface according to= [RFC 4291]. Due to the connectivity properties of these links with neighbo= rs constantly moving in and out of reachability, the link-local addresses a= re of very limited utility. The known limitations are:
=A0- Even if tested for uniqueness at one moment using Duplicate Address De= tection [RFC 4862], a duplicate link-local address might appear as a neighb= or the next moment and DAD would not detect that.
=A0- There is no mechanism to ensure that IPv6 link-local are unique across= multiple links, hence they can not be used to reliably identify routers. =A0- Routers must not forward any packets with Link-Local source or
=A0 destination addresses to other links [RFC 4921]. And a Manet router th= at forwards packets by definition forwards from one link to another due to = the undefined connectivity properties. (The set of neighbors that heard the= packet received by the router might be different than the set of neighbors= that hears a packet transmitted by the router even if the same interface o= n the router is used for the two operations.)

=A0Erik

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

--0016e6d59e1f12805a046fbf465c-- From alexandru.petrescu@gmail.com Tue Jul 28 01:50:26 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0098F3A6CEB for ; Tue, 28 Jul 2009 01:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmhWwb6+7xRQ for ; Tue, 28 Jul 2009 01:50:25 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id E027C3A6D08 for ; Tue, 28 Jul 2009 01:50:24 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6S8oOMU021062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Jul 2009 10:50:24 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6S8oOjk021193; Tue, 28 Jul 2009 10:50:24 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6S8oMhY015588; Tue, 28 Jul 2009 10:50:24 +0200 Message-ID: <4A6EBBCE.9090302@gmail.com> Date: Tue, 28 Jul 2009 10:50:22 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Erik Nordmark References: <4A6DBFB5.3050305@sun.com> <000001ca0ed8$98408350$c8c189f0$@nl> <4A6DE796.20901@sun.com> <002401ca0f0a$00ce4c50$026ae4f0$@nl> <4A6EAB0C.8020008@sun.com> In-Reply-To: <4A6EAB0C.8020008@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Suggested text on link-locals X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 08:50:26 -0000 Erik Nordmark a écrit : [...] > The largest issue with link-locals is that they are not guaranteed to > have the uniqueness properties you might assume. That is because the 'subnet' and the 'link' are not defined (DAD on something undefined is undefined too). IMHO, and I will stop talking about this right after: we can't work IP over something that we insist to not know what is (link-layers with unknown properties, unpredictable and numerous movements and disconnections, etc.) Alex > Hence I think the utility of IPv6 link-locals is very limited. > >> |> This is nothing new. |> And the IETF routing protocol number 1 >> protocol runs perfect on it. | |ICMPv4 doesn't run on IPv6; Perhaps >> you meant ICMPv6, which I wouldn't |call a routing protocol; I >> could call it an ES-IS protocol. >> >> Sorry, I meant OSPF. And to be specific: OSPFv3. > > I don't think you can assert that OSPFv3 works correctly by a simple > test, since your EUI-64 derived link-locals are not likely to > conflict in your test. > > To show that OSPFv3 works you would actually have to run it with > routers that (at least temporarily) have the same IPv6 link-local > addresses yet are on the same link. That would help verify that such > routers temporarily being within reach doesn't cause any confusion. > >> |Part of the idea with the text in this but a stake in the ground >> in what |a link is for these dynamic environments. I don't know if >> it makes sense |to do that more directly in a separate section in >> the document, or have |it be in this section, but I think it should >> be in the document. >> >> Fully agreed we need such. > > Care to propose text to the WG? > > Erik > > _______________________________________________ Autoconf mailing list > Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf > From charles.perkins@earthlink.net Tue Jul 28 01:58:29 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28ACA3A6DF3 for ; Tue, 28 Jul 2009 01:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KknxaaRcsuS for ; Tue, 28 Jul 2009 01:58:28 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 5FF9F3A69C8 for ; Tue, 28 Jul 2009 01:58:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=JirbToeDv6OOIWwlRoVTVGH1odWU0+iZRrbceqo/cYx8no1BQXwIB/8wfesmOMlL; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [130.129.20.182] by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MViVx-00039B-C2; Tue, 28 Jul 2009 04:58:29 -0400 Message-ID: <4A6EBDB4.3020101@earthlink.net> Date: Tue, 28 Jul 2009 01:58:28 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Alexandru Petrescu References: <4A6DBFB5.3050305@sun.com> <000001ca0ed8$98408350$c8c189f0$@nl> <4A6DE796.20901@sun.com> <002401ca0f0a$00ce4c50$026ae4f0$@nl> <4A6EAB0C.8020008@sun.com> <4A6EBBCE.9090302@gmail.com> In-Reply-To: <4A6EBBCE.9090302@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5223a3f10cb80272d172ac4e4ba91a9b45350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.20.182 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Suggested text on link-locals X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 08:58:29 -0000 Hello Alex, Alexandru Petrescu wrote: > >> The largest issue with link-locals is that they are not guaranteed to >> have the uniqueness properties you might assume. > > That is because the 'subnet' and the 'link' are not defined (DAD on > something undefined is undefined too). > > IMHO, and I will stop talking about this right after: we can't work IP > over something that we insist to not know what is (link-layers with > unknown properties, unpredictable and numerous movements and > disconnections, etc.) Well, a lot of people have done it. So, there must be something wrong with your assumptions. I'm serious! In particular, IP can operate _without_ subnets entirely. And, without multicast. And, without DNS. And... Regards, Charlie P. From teco@inf-net.nl Tue Jul 28 02:00:08 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 923113A6E14 for ; Tue, 28 Jul 2009 02:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bvlh5-roAx2q for ; Tue, 28 Jul 2009 02:00:07 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id B5B863A6D9B for ; Tue, 28 Jul 2009 02:00:06 -0700 (PDT) Received: (qmail 21613 invoked from network); 28 Jul 2009 11:00:05 +0200 Received: from dhcp-15cb.meeting.ietf.org (HELO M90Teco) (130.129.21.203) by server9.hosting2go.nl with SMTP; 28 Jul 2009 11:00:05 +0200 From: "Teco Boot" To: "'Erik Nordmark'" References: <4A6DBFB5.3050305@sun.com> <000001ca0ed8$98408350$c8c189f0$@nl> <4A6DE796.20901@sun.com> <002401ca0f0a$00ce4c50$026ae4f0$@nl> <4A6EAB0C.8020008@sun.com> In-Reply-To: <4A6EAB0C.8020008@sun.com> Date: Tue, 28 Jul 2009 10:59:32 +0200 Message-ID: <006c01ca0f61$cb802de0$628089a0$@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: AcoPVnxFOAuagvOYTea2I71rO+Lg6QAAN83w Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] Suggested text on link-locals X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 09:00:08 -0000 Hi Eric, |The largest issue with link-locals is that they are not guaranteed to |have the uniqueness properties you might assume. |Hence I think the utility of IPv6 link-locals is very limited. In another thread, we concluded link-locals do not differ from globals that much on this subject. |> Sorry, I meant OSPF. And to be specific: OSPFv3. | |I don't think you can assert that OSPFv3 works correctly by a simple |test, since your EUI-64 derived link-locals are not likely to conflict |in your test. I tested and I read the spec. There is no problem in OSPFv3. Information is maintained using RouterID and RouterID-InterfaceID. These are 32-bit and 64-bit IDs and have nothing to do with addresses. There would be a problem with next-hop addresses when there are duplicates. No-one said we can accept duplicates on a link. We say the problem preventing them would be equal for link-locals and globals / ULA. |> |Part of the idea with the text in this but a stake in the ground in |what |> |a link is for these dynamic environments. I don't know if it makes |sense |> |to do that more directly in a separate section in the document, or |have |> |it be in this section, but I think it should be in the document. |> |> Fully agreed we need such. | |Care to propose text to the WG? I did. Recent posting (July 21): =========== link - a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP. (out of RFC4861) MANET link - 1-hop connectivity between two MANET interfaces. Called edge in graph theory. MANET interface - MANET router interface with a MANET protocol enabled. Radio link - a link with undetermined connectivity properties, such as asymmetry, non-transitivity and time-variation as described in [draft-baccelli-multi-hop-wireless-communication]. Wireless links have often undetermined connectivity properties. Radio interface - MANET router interface to a Radio link. The term "MANET link" needs another thought. The word "link" in "MANET link" would be associated with term "link", this is confusing. I am OK on any better term, but I still can't come up with something. "MANET edge" ?? No, this wouldn't work. ========== Later on, Charlie P. and I discussed what "on-link" really means. We have to choose between "on same communication facility" and "in range". We concluded we better not use "on-link", as on a Radio link, we use MANET protocols for handling the more difficult connectivity characteristics. We need for example Link Quality and Symmetry [NHDP] and Link Metrics / costs [dearlove-olsrv2-metrics], [OSPF-MANET]. This leaves open using link-locals for MANET protocols. It exactly provides what is needed: 1-hop connectivity. Regards, Teco. From alexandru.petrescu@gmail.com Tue Jul 28 02:02:49 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D10B63A6DFC for ; Tue, 28 Jul 2009 02:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.86 X-Spam-Level: X-Spam-Status: No, score=-1.86 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMfF0tgezzir for ; Tue, 28 Jul 2009 02:02:49 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 4ACE13A6D3F for ; Tue, 28 Jul 2009 02:02:48 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6S92l7L002927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Jul 2009 11:02:47 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6S92lV0024332; Tue, 28 Jul 2009 11:02:47 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6S92kFa019647; Tue, 28 Jul 2009 11:02:47 +0200 Message-ID: <4A6EBEB6.2020001@gmail.com> Date: Tue, 28 Jul 2009 11:02:46 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Ulrich Herberg References: <4A6DD69B.40004@gmail.com> <1248714867.4236.311.camel@acorde.it.uc3m.es> <4A6E03C2.3050308@gmail.com> <25c114b90907280038u4a82c57ax38c68fbf75064d0c@mail.gmail.com> In-Reply-To: <25c114b90907280038u4a82c57ax38c68fbf75064d0c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Clarification of the formulation of the /128 recommendation X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 09:02:49 -0000 Ulrich Herberg a écrit : > Alex, > > On Mon, Jul 27, 2009 at 9:45 PM, Alexandru Petrescu > > wrote: > > [...] > Will it say "for all addresses configured on this interface, the > respective prefix will be /128"? Or just for some? > > > > For all addresses that we configure in autoconf. Ok. > [...] > Does it mean that when I type 'ifconfig' all shown addresses > will be suffixed by "/128"? (and not by any other length, > like /64, or /48 or such). > > > I think so, for all ULAs/global addresses. > > > I hope that instead of "for all" it will be "for some". > > > Why? I think it would be good if it were only for all addresses AUTOCONFed, not for the ones manually configured. > Would a routing table entry in the node look like this: > > Destination Gateway Iface > 2001:db0:1::1/128 2001:db0:2::2 eth0 > > Maybe this is what is meant by the "/128" requirement? The Gateway > address is directly reachable from the node. > > > Yes, that looks valid for me. > > Setting a host-based route (/128) can not mean that the Gateway > address is not directly reachable. > > > Why should it? So you mean that the Gateway address is _not_ directly reachable? If so, then the packet to that Destination will be dropped, because NS/NA for Gateway address will timeout. > [Another thing, if the "/128" requirement is actually the host-based > route in the routing table, then > it may pose a problem reaching > hosts behind a MANET router having 2 interfaces, because the source > would > have to have a host-based route for each host behind that > MANET router, whereas a shorter-than-128 prefix route would suffice.] > > > Keep in mind that we are talking about MANET interfaces on a MANET > router only. If there is other stuff (e.g. hosts) behind the MANET > router (so, on a non-MANET interface of that MANET router), they are > configured as usual. We are not talking about how to configure these > hosts behind the MANET router. ------ ------------ ---------- |Source|------|MANET Router|----+---|Otherhost1| ------ ------------ | ---------- | ---------- +---|Otherhost2| ---------- Does Source have two host based /128 entries in its routing table for each Otherhost? Or does it have a single /64 entry covering all Otherhosts behind MANET Router? Alex From alexandru.petrescu@gmail.com Tue Jul 28 02:09:28 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDC293A6D24 for ; Tue, 28 Jul 2009 02:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMeywcepHe3Z for ; Tue, 28 Jul 2009 02:09:27 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 47F303A6DD6 for ; Tue, 28 Jul 2009 02:09:17 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6S98txs018661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Jul 2009 11:08:55 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6S98tZY026195; Tue, 28 Jul 2009 11:08:55 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6S98sCJ006375; Tue, 28 Jul 2009 11:08:54 +0200 Message-ID: <4A6EC026.2030607@gmail.com> Date: Tue, 28 Jul 2009 11:08:54 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Ulrich Herberg References: <4A6E07B6.1090007@gmail.com> <4A6E15FF.6030207@earthlink.net> <4A6E1888.6060507@gmail.com> <25c114b90907272339g17b9fe90ufe02c276eab138ed@mail.gmail.com> In-Reply-To: <25c114b90907272339g17b9fe90ufe02c276eab138ed@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Usage scenarios X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 09:09:28 -0000 Ulrich Herberg a écrit : > Hi Alex, > > I don't understand what you mean. The second scenario looks for me like > "classical" IP, nothing new. There should be something new in the way the mobile routers talk on their wifi interfaces otherwise the FixedHosts can't talk to each other. > Since it is a host, it does not need to be > exposed to MANET characteristics and can of course be configured by any > prefix short than /128 -- the prefix of the non-MANET interface if that > mobile router. In that figure, the wifi interfaces of the Mobile Routers behave as if they were in a MANET, or so I have been told by many people. > The first scenario is ok, even though I would not name > them mobile hosts, but mobile routers. Well, a Mobile Router with a single physical interface looks more like a host to me, more than a router. IMHO. I also called them hosts because they seem to be the two ends of a communicating application and the problem is how to route packets between them. In the second usage scenario the FixedHosts are the two ends of the communicating application. Alex > > Ulrich > > On Mon, Jul 27, 2009 at 11:13 PM, Alexandru Petrescu > > wrote: > > Charles E. Perkins a écrit : > > > Hello Alex, > > Are these "usage scenarios"? I thought an application > was something that usually communicated through sockets. > > > Hi Charles, ok, usage scenarios. > > For your example, I guess that the access points are > connected to the Internet and offer various subnet > prefixes? > > > No, the first usage scenario has fixed access points disconnected > from the Internet, and not connected to each other by some wire, > just by their wifi interface, such that the hidden terminal problems > are exacerbated. > > They don't offer various subnet prefixes, there are no /64 prefixes, > there are only /128 host-based routes. There is not _one_ single > subnet prefix either. > > (it is not like the usage scenario with Mobile IPv6 and Access Routers > connected to Internet and each offering a different and distringuished > IPv6 prefix). > > Also, I guess that the fixed hosts have wireless > interfaces and some way of establishing links at layer 2, > but do not offer access to the Internet? > > > Yes, the fixed hosts have wireless interfaces. Some other times > they have wired interfaces instead. And yes, they don't offer > access to the Internet. > > For these simple usage scenarios it is all disconnected from the > Internet. > > I wanted to express how much different are they in their needs to > configure addresses. > > Alex > > > Regards, > Charlie P. > > > Alexandru Petrescu wrote: > > During the meeting there was questioning about which > applications are considered in AUTOCONF? The obvious answer > "MANET applications" is not sufficient I believe. > > Two different MANET applications: > > -------- -------- -------- -------- > | Fixed | | Fixed | | Fixed | | Fixed | > | Access | | Access | | Access | . . . | Access | > | Point | | Point | | Point | | Point | > -------- -------- -------- -------- > | | | | > | | | | > o o o o wifi antenna > > o > | o > ------ movement | > |Mobile| -------> ------ > |Host | <----- |Mobile| > ------ |Host | > ------ > > > > ==========================cut here============================== > > > > o o > | | > ------ ------ > |Mobile| |Mobile| > |Router| ----- |Router| ----- > ------ |Fixed| ------ |Fixed| > | |Host | | |Host | > | --|-- | --|-- > --------------| --------------| > > These applications necessitate different ways of configuring > the addresses. I don't think the rule "/128" could fit both. > > Alex > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > > > > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > > From alexandru.petrescu@gmail.com Tue Jul 28 02:14:41 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D78133A685A for ; Tue, 28 Jul 2009 02:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.884 X-Spam-Level: X-Spam-Status: No, score=-1.884 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8cITaYRu5QO for ; Tue, 28 Jul 2009 02:14:41 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 82E933A69C8 for ; Tue, 28 Jul 2009 02:14:40 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6S9EdUa001243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Jul 2009 11:14:39 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6S9Ed2F027946; Tue, 28 Jul 2009 11:14:39 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6S9EdMl024123; Tue, 28 Jul 2009 11:14:39 +0200 Message-ID: <4A6EC17F.1050707@gmail.com> Date: Tue, 28 Jul 2009 11:14:39 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4A6DBFB5.3050305@sun.com> <000001ca0ed8$98408350$c8c189f0$@nl> <4A6DE796.20901@sun.com> <002401ca0f0a$00ce4c50$026ae4f0$@nl> <4A6EAB0C.8020008@sun.com> <4A6EBBCE.9090302@gmail.com> <4A6EBDB4.3020101@earthlink.net> In-Reply-To: <4A6EBDB4.3020101@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Suggested text on link-locals X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 09:14:41 -0000 Charles E. Perkins a écrit : > Hello Alex, > > Alexandru Petrescu wrote: >> >>> The largest issue with link-locals is that they are not guaranteed to >>> have the uniqueness properties you might assume. >> >> That is because the 'subnet' and the 'link' are not defined (DAD on >> something undefined is undefined too). >> >> IMHO, and I will stop talking about this right after: we can't work IP >> over something that we insist to not know what is (link-layers with >> unknown properties, unpredictable and numerous movements and >> disconnections, etc.) > > Well, a lot of people have done it. So, there must be > something wrong with your assumptions. > > I'm serious! I'm fine, I've been also told yesteerday than I'm 4 (four) years behind the state of the art :-) > In particular, IP can operate _without_ subnets entirely. > And, without multicast. And, without DNS. And... Charlie the IPv6 over non-subnet non-multicast is wishful thinking. YEs, it is that little behaviour that could. :-) Alex From erik.nordmark@sun.com Tue Jul 28 02:30:23 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A07423A6E8E for ; Tue, 28 Jul 2009 02:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.902 X-Spam-Level: X-Spam-Status: No, score=-5.902 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5ZqNEU0ISXt for ; Tue, 28 Jul 2009 02:30:21 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 810953A6E8D for ; Tue, 28 Jul 2009 02:30:19 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6S9Tr7b027643; Tue, 28 Jul 2009 09:29:53 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n6S9TovK739556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 02:29:51 -0700 (PDT) Message-ID: <4A6EC50D.2080406@sun.com> Date: Tue, 28 Jul 2009 02:29:49 -0700 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: Alexandru Petrescu References: <4A6DBFB5.3050305@sun.com> <000001ca0ed8$98408350$c8c189f0$@nl> <4A6DE796.20901@sun.com> <002401ca0f0a$00ce4c50$026ae4f0$@nl> <4A6EAB0C.8020008@sun.com> <4A6EBBCE.9090302@gmail.com> In-Reply-To: <4A6EBBCE.9090302@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Suggested text on link-locals X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 09:30:23 -0000 Alexandru Petrescu wrote: > Erik Nordmark a écrit : > [...] >> The largest issue with link-locals is that they are not guaranteed to >> have the uniqueness properties you might assume. > > That is because the 'subnet' and the 'link' are not defined (DAD on > something undefined is undefined too). Link is defined in RFC 2460 and I don't see any need to change that. "Subnet", "subnet ID" and "subnet prefix" are defined in RFC 4291; FWIW I think you mean "subnet prefix" and not unspecific "subnet". What is wrong with those definitions? I think the struggle is with describing the practical implications of the time-variant, non-transitive and asymmetric reachability, and also some historical assumption that subnet prefix mapping to one link. > IMHO, and I will stop talking about this right after: we can't work IP > over something that we insist to not know what is (link-layers with > unknown properties, unpredictable and numerous movements and > disconnections, etc.) Why do you mean by "unknown properties"? FWIW I use the unpredictable and numerous movements and disconnections technology know as 802.11 at the moment; seems to be usable for IP in practice ;-) Erik > Alex > > >> Hence I think the utility of IPv6 link-locals is very limited. >> >>> |> This is nothing new. |> And the IETF routing protocol number 1 >>> protocol runs perfect on it. | |ICMPv4 doesn't run on IPv6; Perhaps >>> you meant ICMPv6, which I wouldn't |call a routing protocol; I >>> could call it an ES-IS protocol. >>> >>> Sorry, I meant OSPF. And to be specific: OSPFv3. >> >> I don't think you can assert that OSPFv3 works correctly by a simple >> test, since your EUI-64 derived link-locals are not likely to >> conflict in your test. >> >> To show that OSPFv3 works you would actually have to run it with >> routers that (at least temporarily) have the same IPv6 link-local >> addresses yet are on the same link. That would help verify that such >> routers temporarily being within reach doesn't cause any confusion. >> >>> |Part of the idea with the text in this but a stake in the ground >>> in what |a link is for these dynamic environments. I don't know if >>> it makes sense |to do that more directly in a separate section in >>> the document, or have |it be in this section, but I think it should >>> be in the document. >>> >>> Fully agreed we need such. >> >> Care to propose text to the WG? >> >> Erik >> >> _______________________________________________ Autoconf mailing list >> Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf >> > > From alexandru.petrescu@gmail.com Tue Jul 28 03:00:19 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90B2D3A6D3A for ; Tue, 28 Jul 2009 03:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[AWL=1.354, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bizh+z94aNvM for ; Tue, 28 Jul 2009 03:00:15 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 3D9E43A6CFD for ; Tue, 28 Jul 2009 03:00:15 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6SA06H7030714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Jul 2009 12:00:06 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6SA05wM006485; Tue, 28 Jul 2009 12:00:06 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6SA05Cr006179; Tue, 28 Jul 2009 12:00:05 +0200 Message-ID: <4A6ECC25.1020201@gmail.com> Date: Tue, 28 Jul 2009 12:00:05 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Erik Nordmark References: <4A6DBFB5.3050305@sun.com> <000001ca0ed8$98408350$c8c189f0$@nl> <4A6DE796.20901@sun.com> <002401ca0f0a$00ce4c50$026ae4f0$@nl> <4A6EAB0C.8020008@sun.com> <4A6EBBCE.9090302@gmail.com> <4A6EC50D.2080406@sun.com> In-Reply-To: <4A6EC50D.2080406@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Suggested text on link-locals X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 10:00:19 -0000 Erik Nordmark a écrit : > Alexandru Petrescu wrote: >> Erik Nordmark a écrit : [...] >>> The largest issue with link-locals is that they are not >>> guaranteed to have the uniqueness properties you might assume. >> >> That is because the 'subnet' and the 'link' are not defined (DAD on >> something undefined is undefined too). > > Link is defined in RFC 2460 and I don't see any need to change that. It has a big problem in that it doesn't mention "wireless" in the examples. Were it to say "wireless" too, in addition Ethernets, ATM, PPP then it would no longer be an invitation to consider wireless links to not be the rfc2460 links. > "Subnet", "subnet ID" and "subnet prefix" are defined in RFC 4291; > FWIW I think you mean "subnet prefix" and not unspecific "subnet". > > What is wrong with those definitions? I meant to say that in a wireless topology B A-|-C where A can't hear C because too far, the link and subnet are undefined. People consider this topology (1) to not have any subnet prefix (the "/128" recommendation, equally the "not on-link subnet"), sometimes I consider it to (2) have two different subnets: one from A to B one from B to C, or (3) one single subnet for all three and B is a repeater, not router. I think the existing subnet definitions don't cover these three cases I mentioned just above. > I think the struggle is with describing the practical implications of > the time-variant, non-transitive and asymmetric reachability, and > also some historical assumption that subnet prefix mapping to one > link. I think the historical assumption a subnet prefix mapped on one link is ok and is widely implemented. I doubt it can be changed just like that. (ok several prefixes and subnets on one link, but not ok no subnet on a link). >> IMHO, and I will stop talking about this right after: we can't work >> IP over something that we insist to not know what is (link-layers >> with unknown properties, unpredictable and numerous movements and >> disconnections, etc.) > > Why do you mean by "unknown properties"? I meant "undetermined connectivitiy properties", a term used in the draft to mean the links considered by AUTOCONF. It was explained as "unplanned connectivity properties" too. > FWIW I use the unpredictable and numerous movements and > disconnections technology know as 802.11 at the moment; seems to be > usable for IP in practice ;-) :-) Alex From ulrich@herberg.name Tue Jul 28 04:02:57 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E16503A6D1E for ; Tue, 28 Jul 2009 04:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.616 X-Spam-Level: X-Spam-Status: No, score=-1.616 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_82=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RR+qpM8ORLRr for ; Tue, 28 Jul 2009 04:02:56 -0700 (PDT) Received: from mail-fx0-f216.google.com (mail-fx0-f216.google.com [209.85.220.216]) by core3.amsl.com (Postfix) with ESMTP id 51C553A6A70 for ; Tue, 28 Jul 2009 04:02:55 -0700 (PDT) Received: by fxm12 with SMTP id 12so38935fxm.37 for ; Tue, 28 Jul 2009 04:02:54 -0700 (PDT) MIME-Version: 1.0 Sender: ulrich@herberg.name Received: by 10.204.116.212 with SMTP id n20mr4010067bkq.138.1248778974342; Tue, 28 Jul 2009 04:02:54 -0700 (PDT) In-Reply-To: <4A6EBEB6.2020001@gmail.com> References: <4A6DD69B.40004@gmail.com> <1248714867.4236.311.camel@acorde.it.uc3m.es> <4A6E03C2.3050308@gmail.com> <25c114b90907280038u4a82c57ax38c68fbf75064d0c@mail.gmail.com> <4A6EBEB6.2020001@gmail.com> Date: Tue, 28 Jul 2009 13:02:54 +0200 X-Google-Sender-Auth: 8af7d972c534c2db Message-ID: <25c114b90907280402s79b56bb1xa4427b999dac7ba7@mail.gmail.com> From: Ulrich Herberg To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=0016e6d999da2b2dfb046fc20376 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Clarification of the formulation of the /128 recommendation X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 11:02:58 -0000 --0016e6d999da2b2dfb046fc20376 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Alex, On Tue, Jul 28, 2009 at 11:02 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > [..] > > [...] >> Does it mean that when I type 'ifconfig' all shown addresses >> will be suffixed by "/128"? (and not by any other length, >> like /64, or /48 or such). >> >> >> I think so, for all ULAs/global addresses. >> >> >> I hope that instead of "for all" it will be "for some". >> >> >> Why? >> > > I think it would be good if it were only for all addresses AUTOCONFed, not > for the ones manually configured. What is the difference? It does not matter how to configure these addresses. And again, the draft says: "A subnet prefix configured on this interface *should* be of length /128" and "When more specific assumptions can be made regarding the connectivity to other interfaces on the link, these SHOULD be considered when configuring subnet prefixes." So, if you know better, you *can* configure another address (possibly with a shorter prefix) on the interface (manually or autoconf'ed, doesn't matter) > > > Would a routing table entry in the node look like this: >> >> Destination Gateway Iface >> 2001:db0:1::1/128 2001:db0:2::2 eth0 >> >> Maybe this is what is meant by the "/128" requirement? The Gateway >> address is directly reachable from the node. >> > > > >> >> Yes, that looks valid for me. >> >> Setting a host-based route (/128) can not mean that the Gateway >> address is not directly reachable. >> >> >> Why should it? >> > > So you mean that the Gateway address is _not_ directly reachable? If so, > then the packet to that Destination will be dropped, because NS/NA for > Gateway address will timeout. That's not what I meant. Maybe I misunderstood the two "not"s in your sentence :-) Can you rephrase the sentence, please? > > > [Another thing, if the "/128" requirement is actually the host-based >> route in the routing table, then >> it may pose a problem reaching >> hosts behind a MANET router having 2 interfaces, because the source >> would >> have to have a host-based route for each host behind that >> MANET router, whereas a shorter-than-128 prefix route would suffice.] >> >> >> Keep in mind that we are talking about MANET interfaces on a MANET router >> only. If there is other stuff (e.g. hosts) behind the MANET router (so, on a >> non-MANET interface of that MANET router), they are configured as usual. We >> are not talking about how to configure these hosts behind the MANET router. >> > > ------ ------------ ---------- > |Source|------|MANET Router|----+---|Otherhost1| > ------ ------------ | ---------- > | ---------- > +---|Otherhost2| > ---------- > > Does Source have two host based /128 entries in its routing table for each > Otherhost? Or does it have a single /64 entry covering all Otherhosts > behind MANET Router? Since these hosts are behind the MANET router (i.e. on a non-MANET interface), routing can be done as usual. In the draft, we do not talk about how these hosts are configured (not necessarily with a /128 prefix!), we only talk about the interface of the router. So, depending how these hosts are configured, aggregation could be used for avoiding having two entries in the routing tables. Ulrich --0016e6d999da2b2dfb046fc20376 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alex,

On Tue, Jul 28, 2009 at 11:02 AM, A= lexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
[..]


=A0 =A0 =A0 =A0 =A0 =A0[...]
=A0 =A0 =A0 =A0 =A0 =A0Does it mean that when I type 'ifconfig' al= l shown addresses
=A0 =A0 =A0 =A0 =A0 =A0will be suffixed by "/128"? =A0(and not b= y any other length,
=A0 =A0 =A0 =A0 =A0 =A0like /64, or /48 or such).


=A0 =A0 =A0 =A0I think so, for all ULAs/global addresses.


=A0 =A0I hope that instead of "for all" it will be "for som= e".


Why?

I think it would be good if it were only for all addresses AUTOCONFed, not = for the ones manually configured.


What is the diff= erence? It does not matter how to configure these addresses. And again, the= draft says: "A subnet prefix configured on this interface *should* be= of length /128" and "When more specific assumptions can be made = regarding the connectivity to other interfaces on the link, these SHOULD be= considered when configuring subnet prefixes." So, if you know better,= you *can* configure another address (possibly with a shorter prefix) on th= e interface (manually or autoconf'ed, doesn't matter)


=A0 =A0Would a routing table entry in the node look like this:

=A0 =A0Destination =A0 =A0 =A0 =A0 =A0 Gateway =A0 =A0 =A0 =A0 =A0 =A0 =A0= Iface
=A0 =A02001:db0:1::1/128 =A0 =A0 2001:db0:2::2 =A0 =A0 =A0 =A0eth0

=A0 =A0Maybe this is what is meant by the "/128" requirement? = =A0The Gateway
=A0 =A0address is directly reachable from the node.
>

Yes, that looks valid for me.

=A0 =A0Setting a host-based route (/128) can not mean that the Gateway
=A0 =A0address is not directly reachable.


Why should it?

So you mean that the Gateway address is _not_ directly reachable? =A0If so,= then the packet to that Destination will be dropped, because NS/NA for Gat= eway address will timeout.

That's not what I meant= . Maybe I misunderstood the two "not"s in your sentence :-) Can y= ou rephrase the sentence, please?
=A0


=A0 =A0[Another thing, if the "/128" requirement is actually the= host-based
=A0 =A0 route in the routing table, then
=A0 =A0 it may pose a problem reaching
=A0 =A0 hosts behind a MANET router having 2 interfaces, because the sourc= e
=A0 =A0 would
=A0 =A0 have to have a host-based route for each host behind that
=A0 =A0 MANET router, whereas a shorter-than-128 prefix route would suffic= e.]


Keep in mind that we are talking about MANET interfaces on a MANET router o= nly. If there is other stuff (e.g. hosts) behind the MANET router (so, on a= non-MANET interface of that MANET router), they are configured as usual. W= e are not talking about how to configure these hosts behind the MANET route= r.

=A0 ------ =A0 =A0 =A0 =A0------------ =A0 =A0 =A0 =A0 =A0----------
=A0|Source|------|MANET Router|----+---|Otherhost1|
=A0 ------ =A0 =A0 =A0 =A0------------ =A0 =A0 | =A0 =A0----------
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 = =A0----------
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+---|Ot= herhost2|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 ----------

Does Source have two host based /128 entries in its routing table for each = Otherhost? =A0Or does it have a single /64 entry covering all Otherhosts be= hind MANET Router?
=A0

Since these hosts are= behind the MANET router (i.e. on a non-MANET interface), routing can be do= ne as usual. In the draft, we do not talk about how these hosts are configu= red (not necessarily with a /128 prefix!), we only talk about the interface= of the router. So, depending how these hosts are configured, aggregation c= ould be used for avoiding having two entries in the routing tables.

Ulrich
=A0
--0016e6d999da2b2dfb046fc20376-- From erik.nordmark@sun.com Tue Jul 28 04:10:46 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3D123A6BFB for ; Tue, 28 Jul 2009 04:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.916 X-Spam-Level: X-Spam-Status: No, score=-5.916 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0d5S-eEZ+wOh for ; Tue, 28 Jul 2009 04:10:45 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 646EB3A6A70 for ; Tue, 28 Jul 2009 04:10:45 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6SBAjRC000188; Tue, 28 Jul 2009 11:10:46 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n6SBAhTc758330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 04:10:44 -0700 (PDT) Message-ID: <4A6EDCB2.9090507@sun.com> Date: Tue, 28 Jul 2009 04:10:42 -0700 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: Teco Boot References: <4A6DBFB5.3050305@sun.com> <000001ca0ed8$98408350$c8c189f0$@nl> <4A6DE796.20901@sun.com> <002401ca0f0a$00ce4c50$026ae4f0$@nl> <4A6EAB0C.8020008@sun.com> <006c01ca0f61$cb802de0$628089a0$@nl> In-Reply-To: <006c01ca0f61$cb802de0$628089a0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Suggested text on link-locals X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 11:10:46 -0000 Teco Boot wrote: > Hi Eric, FWIW spelling is Erik. > |The largest issue with link-locals is that they are not guaranteed to > |have the uniqueness properties you might assume. > |Hence I think the utility of IPv6 link-locals is very limited. > > In another thread, we concluded link-locals do not differ from globals > that much on this subject. For what value of "we"? Where is the thread? > |> Sorry, I meant OSPF. And to be specific: OSPFv3. > | > |I don't think you can assert that OSPFv3 works correctly by a simple > |test, since your EUI-64 derived link-locals are not likely to conflict > |in your test. > > I tested and I read the spec. There is no problem in OSPFv3. Information > is maintained using RouterID and RouterID-InterfaceID. These are 32-bit > and 64-bit IDs and have nothing to do with addresses. > > There would be a problem with next-hop addresses when there are duplicates. > No-one said we can accept duplicates on a link. We say the problem > preventing them would be equal for link-locals and globals / ULA. If you neither have guaranteed to be unique interface IDs to form the IPv6-link locals, nor a robust protocol to test and detect duplicate addresses, then how can you claim that OSPFv3 would work reliably? > I did. Recent posting (July 21): > =========== > link - a communication facility or medium over which nodes can > communicate at the link layer, i.e., the layer > immediately below IP. (out of RFC4861) Perhaps I should have been more explicit - text which clarifies the term more than that is in RFC 2460. It we all agree that we just need the definition from 2460 then we are done. > > MANET link - 1-hop connectivity between two MANET interfaces. Called > edge in graph theory. Why is that term needed? Isn't it the same as "link"? It not, what is the difference? > MANET interface > - MANET router interface with a MANET protocol enabled. Why do you need a specific term and not use use the RFC 2460 "interface" term? > Radio link - a link with undetermined connectivity properties, such > as asymmetry, non-transitivity and time-variation as > described in > [draft-baccelli-multi-hop-wireless-communication]. > Wireless links have often undetermined connectivity > properties. > > Radio interface > - MANET router interface to a Radio link. Why do you need to define those? The reason I'm asking is that "radio" is rather generic, and would seem to include WiFi, 3G and other stuff where the L2 might ensure that there is transient and symmetric reachability. Erik From erik.nordmark@sun.com Tue Jul 28 04:23:03 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 924103A6E3D for ; Tue, 28 Jul 2009 04:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.928 X-Spam-Level: X-Spam-Status: No, score=-6.928 tagged_above=-999 required=5 tests=[AWL=1.118, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEl7UyQHr+rj for ; Tue, 28 Jul 2009 04:23:02 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id B5D4A3A6E3B for ; Tue, 28 Jul 2009 04:23:02 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6SBMwFt005006; Tue, 28 Jul 2009 11:22:58 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n6SBMtA5759289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 04:22:57 -0700 (PDT) Message-ID: <4A6EDF8F.3090304@sun.com> Date: Tue, 28 Jul 2009 04:22:55 -0700 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: Alexandru Petrescu References: <4A6DBFB5.3050305@sun.com> <000001ca0ed8$98408350$c8c189f0$@nl> <4A6DE796.20901@sun.com> <002401ca0f0a$00ce4c50$026ae4f0$@nl> <4A6EAB0C.8020008@sun.com> <4A6EBBCE.9090302@gmail.com> <4A6EC50D.2080406@sun.com> <4A6ECC25.1020201@gmail.com> In-Reply-To: <4A6ECC25.1020201@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Suggested text on link-locals X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 11:23:03 -0000 Alexandru Petrescu wrote: > Erik Nordmark a écrit : >> Alexandru Petrescu wrote: >>> Erik Nordmark a écrit : [...] >>>> The largest issue with link-locals is that they are not >>>> guaranteed to have the uniqueness properties you might assume. >>> >>> That is because the 'subnet' and the 'link' are not defined (DAD on >>> something undefined is undefined too). >> >> Link is defined in RFC 2460 and I don't see any need to change that. > > It has a big problem in that it doesn't mention "wireless" in the > examples. Were it to say "wireless" too, in addition Ethernets, ATM, > PPP then it would no longer be an invitation to consider wireless links > to not be the rfc2460 links. Can you define what the term "example" means? This is getting silly. Do we also need to list avian carriers in the examples? Satelite links? Software emulated virtual links inside a hypervisor? >> "Subnet", "subnet ID" and "subnet prefix" are defined in RFC 4291; >> FWIW I think you mean "subnet prefix" and not unspecific "subnet". >> >> What is wrong with those definitions? > > I meant to say that in a wireless topology > > B > A-|-C > > where A can't hear C because too far, the link and subnet are undefined. No, the definition of link and subnet prefix still hold. > People consider this topology (1) to not have any subnet prefix (the > "/128" recommendation, equally the "not on-link subnet"), sometimes I > consider it to (2) have two different subnets: one from A to B > one from B to C, or (3) one single subnet for all three and B is a > repeater, not router. Again, please don't use the term "subnet". Are you talking about a "subnet ID" or "subnet prefix"? Note that those are definitions about the address format, and not about reachability. > I think the existing subnet definitions don't cover these three cases I > mentioned just above. There is no definition of "subnet". There is a definition about "subnet prefix", which looks fine to me. >> I think the struggle is with describing the practical implications of >> the time-variant, non-transitive and asymmetric reachability, and >> also some historical assumption that subnet prefix mapping to one >> link. > > I think the historical assumption a subnet prefix mapped on one link is > ok and is widely implemented. I doubt it can be changed just like that. > > (ok several prefixes and subnets on one link, but not ok no subnet on a > link). Back when RFC 1970 was published we introduced the notion that a link might not have any global prefixes that are on link. Sorry to spring this on you with only 13 years of warning ;-) I think IPv4 operational practice for pt-pt links that have no subnet prefix associated with them dates a bit further back. Erik From alexandru.petrescu@gmail.com Tue Jul 28 05:06:19 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D06C3A6EFA for ; Tue, 28 Jul 2009 05:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.933 X-Spam-Level: X-Spam-Status: No, score=-2.933 tagged_above=-999 required=5 tests=[AWL=1.316, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7mcKIqK6FvB for ; Tue, 28 Jul 2009 05:06:18 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 0D8FF3A67B3 for ; Tue, 28 Jul 2009 05:06:17 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6SC6HfY006903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Jul 2009 14:06:17 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6SC6HCi028600; Tue, 28 Jul 2009 14:06:17 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6SC6GRi019281; Tue, 28 Jul 2009 14:06:17 +0200 Message-ID: <4A6EE9B8.3040508@gmail.com> Date: Tue, 28 Jul 2009 14:06:16 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Erik Nordmark References: <4A6DBFB5.3050305@sun.com> <000001ca0ed8$98408350$c8c189f0$@nl> <4A6DE796.20901@sun.com> <002401ca0f0a$00ce4c50$026ae4f0$@nl> <4A6EAB0C.8020008@sun.com> <4A6EBBCE.9090302@gmail.com> <4A6EC50D.2080406@sun.com> <4A6ECC25.1020201@gmail.com> <4A6EDF8F.3090304@sun.com> In-Reply-To: <4A6EDF8F.3090304@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Suggested text on link-locals X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 12:06:19 -0000 Erik, But if you say that the link definition and the subnet prefix definitions still hold in the B case then I don't understand A-|-C why we need the "/128" and the "not on-link subnet prefix" recommendations. Anyways, just to try to converge, let me remind that my only interest is to avoid prohibiting the use of link-local addresses and that the text you provided for the draft seems ok to me. Alex Erik Nordmark a écrit : > Alexandru Petrescu wrote: >> Erik Nordmark a écrit : >>> Alexandru Petrescu wrote: >>>> Erik Nordmark a écrit : [...] >>>>> The largest issue with link-locals is that they are not >>>>> guaranteed to have the uniqueness properties you might assume. >>>> >>>> That is because the 'subnet' and the 'link' are not defined (DAD on >>>> something undefined is undefined too). >>> >>> Link is defined in RFC 2460 and I don't see any need to change that. >> >> It has a big problem in that it doesn't mention "wireless" in the >> examples. Were it to say "wireless" too, in addition Ethernets, ATM, >> PPP then it would no longer be an invitation to consider wireless links >> to not be the rfc2460 links. > > Can you define what the term "example" means? > This is getting silly. > Do we also need to list avian carriers in the examples? Satelite links? > Software emulated virtual links inside a hypervisor? > >>> "Subnet", "subnet ID" and "subnet prefix" are defined in RFC 4291; >>> FWIW I think you mean "subnet prefix" and not unspecific "subnet". >>> >>> What is wrong with those definitions? >> >> I meant to say that in a wireless topology >> >> B >> A-|-C >> >> where A can't hear C because too far, the link and subnet are undefined. > > No, the definition of link and subnet prefix still hold. > >> People consider this topology (1) to not have any subnet prefix (the >> "/128" recommendation, equally the "not on-link subnet"), sometimes I >> consider it to (2) have two different subnets: one from A to B >> one from B to C, or (3) one single subnet for all three and B is a >> repeater, not router. > > Again, please don't use the term "subnet". Are you talking about a > "subnet ID" or "subnet prefix"? Note that those are definitions about > the address format, and not about reachability. > >> I think the existing subnet definitions don't cover these three cases I >> mentioned just above. > > There is no definition of "subnet". There is a definition about "subnet > prefix", which looks fine to me. > >>> I think the struggle is with describing the practical implications of >>> the time-variant, non-transitive and asymmetric reachability, and >>> also some historical assumption that subnet prefix mapping to one >>> link. >> >> I think the historical assumption a subnet prefix mapped on one link is >> ok and is widely implemented. I doubt it can be changed just like that. >> >> (ok several prefixes and subnets on one link, but not ok no subnet on a >> link). > > Back when RFC 1970 was published we introduced the notion that a link > might not have any global prefixes that are on link. Sorry to spring > this on you with only 13 years of warning ;-) > > I think IPv4 operational practice for pt-pt links that have no subnet > prefix associated with them dates a bit further back. > > Erik > > > From alexandru.petrescu@gmail.com Tue Jul 28 05:13:28 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AA823A6EF5 for ; Tue, 28 Jul 2009 05:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_82=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gA6eX6yzE7EV for ; Tue, 28 Jul 2009 05:13:27 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 59F583A68EA for ; Tue, 28 Jul 2009 05:13:27 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n6SCDREd008760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Jul 2009 14:13:27 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n6SCDQCF030341; Tue, 28 Jul 2009 14:13:27 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n6SCDQZu021420; Tue, 28 Jul 2009 14:13:26 +0200 Message-ID: <4A6EEB66.3050103@gmail.com> Date: Tue, 28 Jul 2009 14:13:26 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Ulrich Herberg References: <4A6DD69B.40004@gmail.com> <1248714867.4236.311.camel@acorde.it.uc3m.es> <4A6E03C2.3050308@gmail.com> <25c114b90907280038u4a82c57ax38c68fbf75064d0c@mail.gmail.com> <4A6EBEB6.2020001@gmail.com> <25c114b90907280402s79b56bb1xa4427b999dac7ba7@mail.gmail.com> In-Reply-To: <25c114b90907280402s79b56bb1xa4427b999dac7ba7@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Clarification of the formulation of the /128 recommendation X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 12:13:28 -0000 Ulrich, Sorry, my fault. I think I am inconsciously diverging the discussion away from the topic of the draft under discussion. You are right about the questions you raise below and the normal routing. I will wait to see other's comments, the new DT draft when it comes out, and remark on it then. Thanks, Alex Ulrich Herberg a écrit : > Alex, > > On Tue, Jul 28, 2009 at 11:02 AM, Alexandru Petrescu > > wrote: > > [..] > > > [...] > Does it mean that when I type 'ifconfig' all shown > addresses > will be suffixed by "/128"? (and not by any other > length, > like /64, or /48 or such). > > > I think so, for all ULAs/global addresses. > > > I hope that instead of "for all" it will be "for some". > > > Why? > > > I think it would be good if it were only for all addresses > AUTOCONFed, not for the ones manually configured. > > > > What is the difference? It does not matter how to configure these > addresses. And again, the draft says: "A subnet prefix configured on > this interface *should* be of length /128" and "When more specific > assumptions can be made regarding the connectivity to other interfaces > on the link, these SHOULD be considered when configuring subnet > prefixes." So, if you know better, you *can* configure another address > (possibly with a shorter prefix) on the interface (manually or > autoconf'ed, doesn't matter) > > > > Would a routing table entry in the node look like this: > > Destination Gateway Iface > 2001:db0:1::1/128 2001:db0:2::2 eth0 > > Maybe this is what is meant by the "/128" requirement? The > Gateway > address is directly reachable from the node. > > > > > > Yes, that looks valid for me. > > Setting a host-based route (/128) can not mean that the Gateway > address is not directly reachable. > > > Why should it? > > > So you mean that the Gateway address is _not_ directly reachable? > If so, then the packet to that Destination will be dropped, because > NS/NA for Gateway address will timeout. > > > That's not what I meant. Maybe I misunderstood the two "not"s in your > sentence :-) Can you rephrase the sentence, please? > > > > > [Another thing, if the "/128" requirement is actually the > host-based > route in the routing table, then > it may pose a problem reaching > hosts behind a MANET router having 2 interfaces, because the > source > would > have to have a host-based route for each host behind that > MANET router, whereas a shorter-than-128 prefix route would > suffice.] > > > Keep in mind that we are talking about MANET interfaces on a > MANET router only. If there is other stuff (e.g. hosts) behind > the MANET router (so, on a non-MANET interface of that MANET > router), they are configured as usual. We are not talking about > how to configure these hosts behind the MANET router. > > > ------ ------------ ---------- > |Source|------|MANET Router|----+---|Otherhost1| > ------ ------------ | ---------- > | ---------- > +---|Otherhost2| > ---------- > > Does Source have two host based /128 entries in its routing table > for each Otherhost? Or does it have a single /64 entry covering all > Otherhosts behind MANET Router? > > > > Since these hosts are behind the MANET router (i.e. on a non-MANET > interface), routing can be done as usual. In the draft, we do not talk > about how these hosts are configured (not necessarily with a /128 > prefix!), we only talk about the interface of the router. So, depending > how these hosts are configured, aggregation could be used for avoiding > having two entries in the routing tables. > > Ulrich > From teco@inf-net.nl Tue Jul 28 07:18:26 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F6473A6FB1 for ; Tue, 28 Jul 2009 07:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40YiEU2xpCZ7 for ; Tue, 28 Jul 2009 07:18:25 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 538DA3A6FB4 for ; Tue, 28 Jul 2009 07:18:25 -0700 (PDT) Received: (qmail 10597 invoked from network); 28 Jul 2009 16:18:22 +0200 Received: from dhcp-15cb.meeting.ietf.org (HELO M90Teco) (130.129.21.203) by server9.hosting2go.nl with SMTP; 28 Jul 2009 16:18:22 +0200 From: "Teco Boot" To: "'Erik Nordmark'" References: <4A6DBFB5.3050305@sun.com> <000001ca0ed8$98408350$c8c189f0$@nl> <4A6DE796.20901@sun.com> <002401ca0f0a$00ce4c50$026ae4f0$@nl> <4A6EAB0C.8020008@sun.com> <006c01ca0f61$cb802de0$628089a0$@nl> <4A6EDCB2.9090507@sun.com> In-Reply-To: <4A6EDCB2.9090507@sun.com> Date: Tue, 28 Jul 2009 16:17:50 +0200 Message-ID: <00e101ca0f8e$4310fd40$c932f7c0$@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: AcoPdA/ZOTm5L/+URg6x+XDLNS4FtAAEvOAQ Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] Suggested text on link-locals X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 14:18:26 -0000 Hi Erik, |> In another thread, we concluded link-locals do not differ from globals |> that much on this subject. | |For what value of "we"? Where is the thread? http://www.ietf.org/mail-archive/web/autoconf/current/msg01701.html We have 62 bits random or unique EUI-64. We might need DAD, for those who need further guarantee for uniqueness. I don't have any indication that DAD for globals is more easy than for link-locals. But this is solution space. |> |> Sorry, I meant OSPF. And to be specific: OSPFv3. |> | |> |I don't think you can assert that OSPFv3 works correctly by a simple |> |test, since your EUI-64 derived link-locals are not likely to |conflict |> |in your test. |> |> I tested and I read the spec. There is no problem in OSPFv3. |Information |> is maintained using RouterID and RouterID-InterfaceID. These are 32- |bit |> and 64-bit IDs and have nothing to do with addresses. |> |> There would be a problem with next-hop addresses when there are |duplicates. |> No-one said we can accept duplicates on a link. We say the problem |> preventing them would be equal for link-locals and globals / ULA. | |If you neither have guaranteed to be unique interface IDs to form the |IPv6-link locals, nor a robust protocol to test and detect duplicate |addresses, then how can you claim that OSPFv3 would work reliably? Because OSPFv3 don't use addresses for the routing topology. |> I did. Recent posting (July 21): |> =========== |> link - a communication facility or medium over which nodes can |> communicate at the link layer, i.e., the layer |> immediately below IP. (out of RFC4861) | |Perhaps I should have been more explicit - text which clarifies the term | more than that is in RFC 2460. It we all agree that we just need the |definition from 2460 then we are done. Agreed on a link may not be "full connected"? 2460 / 4861 doesn't mandate this. A link is "just a communication facility". I worked with ATM, FR etc. that were not full connected, and MANETs does not differ here. Routing protocols hide this for hosts. |> MANET link - 1-hop connectivity between two MANET interfaces. Called |> edge in graph theory. | |Why is that term needed? Isn't it the same as "link"? It not, what is |the difference? A "link" could be partial connected. The "MANET link" is the elementary object in for example [olsrv2]. It is a "link between two nodes", or "edge". I need another term, as --* link-- is confusing. But then, we need to rename OLSR...... |> MANET interface |> - MANET router interface with a MANET protocol enabled. | |Why do you need a specific term and not use use the RFC 2460 "interface" |term? There may be interfaces not running the protocols. For example, the interface with fixed connected hosts (like NEMO mobile network). Sometimes, posting says "MANET interface MUST xxxx". Then I'm lost, because I have no clue what is meant. |> Radio link - a link with undetermined connectivity properties, such |> as asymmetry, non-transitivity and time-variation as |> described in |> [draft-baccelli-multi-hop-wireless-communication]. |> Wireless links have often undetermined connectivity |> properties. |> |> Radio interface |> - MANET router interface to a Radio link. | |Why do you need to define those? |The reason I'm asking is that "radio" is rather generic, and would seem |to include WiFi, 3G and other stuff where the L2 might ensure that there |is transient and symmetric reachability. Yes, I understand you comment. But I find "link with undetermined connectivity properties" rather clumsy. We could introduce "lwucp" or "elwucpie". Regards, Teco From charles.perkins@earthlink.net Tue Jul 28 07:22:18 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE69C3A6FEA for ; Tue, 28 Jul 2009 07:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIu+g5AVtc7w for ; Tue, 28 Jul 2009 07:22:18 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 065343A6FE9 for ; Tue, 28 Jul 2009 07:22:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=cS+3Et+Pb4iHvoY/cqgUqZ+mhnwsvpzp9ipDzbKjQ+EnYqCdbHGIv695wy/lptSF; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [130.129.20.182] by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MVnZK-0004dq-R0; Tue, 28 Jul 2009 10:22:19 -0400 Message-ID: <4A6F099A.80600@earthlink.net> Date: Tue, 28 Jul 2009 07:22:18 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Teco Boot References: <4A6DBFB5.3050305@sun.com> <000001ca0ed8$98408350$c8c189f0$@nl> <4A6DE796.20901@sun.com> <002401ca0f0a$00ce4c50$026ae4f0$@nl> <4A6EAB0C.8020008@sun.com> <006c01ca0f61$cb802de0$628089a0$@nl> <4A6EDCB2.9090507@sun.com> <00e101ca0f8e$4310fd40$c932f7c0$@nl> In-Reply-To: <00e101ca0f8e$4310fd40$c932f7c0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52b2e0f846fa1a6b296a0a622f695dd1c0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.20.182 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Suggested text on link-locals X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 14:22:18 -0000 Hello Teco, Teco Boot wrote: > We might need DAD, for those who need further guarantee for uniqueness. > I don't have any indication that DAD for globals is more easy than > for link-locals. But this is solution space. > DAD for globals is easier, because packets using global IP addresses can be forwarded. Forwarding may be necessary to guarantee uniqueness across non-local regions of the network. This should count as an "indication". Regards, Charlie P. From erik.nordmark@sun.com Tue Jul 28 08:11:44 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 088043A703D for ; Tue, 28 Jul 2009 08:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.011 X-Spam-Level: X-Spam-Status: No, score=-6.011 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPCJA7ftj9Jk for ; Tue, 28 Jul 2009 08:11:42 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id B3D393A7030 for ; Tue, 28 Jul 2009 08:11:42 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6SFBbbh006839; Tue, 28 Jul 2009 15:11:37 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n6SFBY42783170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 08:11:35 -0700 (PDT) Message-ID: <4A6F1526.4050104@sun.com> Date: Tue, 28 Jul 2009 08:11:34 -0700 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: Teco Boot References: <4A6DBFB5.3050305@sun.com> <000001ca0ed8$98408350$c8c189f0$@nl> <4A6DE796.20901@sun.com> <002401ca0f0a$00ce4c50$026ae4f0$@nl> <4A6EAB0C.8020008@sun.com> <006c01ca0f61$cb802de0$628089a0$@nl> <4A6EDCB2.9090507@sun.com> <00e101ca0f8e$4310fd40$c932f7c0$@nl> In-Reply-To: <00e101ca0f8e$4310fd40$c932f7c0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Suggested text on link-locals X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 15:11:44 -0000 Teco Boot wrote: > Hi Erik, > > > |> In another thread, we concluded link-locals do not differ from globals > |> that much on this subject. > | > |For what value of "we"? Where is the thread? > > http://www.ietf.org/mail-archive/web/autoconf/current/msg01701.html Did the WG chairs declare some form of consensus on this subject? The thread seems to say that *if* we've solved DAD for link-locals *then* that can be used to solve DAD for globals. But that doesn't mean that the inverse is true. Hence I don't see how you can say that they are the same or similar. > We have 62 bits random or unique EUI-64. > We might need DAD, for those who need further guarantee for uniqueness. > I don't have any indication that DAD for globals is more easy than > for link-locals. But this is solution space. I do have an example. For Ethernets DHCPv6 is an example of a way to make DAD simpler; a logically single location of the state of which addresses are allocated to whom avoids duplicates. (I'm in no way advocating DHCPv6 as a solution; it is merely an example that global address allocation can avoid the DAD we need for link-locals.) > |If you neither have guaranteed to be unique interface IDs to form the > |IPv6-link locals, nor a robust protocol to test and detect duplicate > |addresses, then how can you claim that OSPFv3 would work reliably? > > Because OSPFv3 don't use addresses for the routing topology. If the routing topology is perfect, but data packets get misdelivered or duplicated (due to duplicate link-locals), does that mean than routing is working? > |> MANET link - 1-hop connectivity between two MANET interfaces. Called > |> edge in graph theory. > | > |Why is that term needed? Isn't it the same as "link"? It not, what is > |the difference? > > A "link" could be partial connected. > The "MANET link" is the elementary object in for example > [olsrv2]. It is a "link between two nodes", or "edge". > I need another term, as --* link-- is confusing. > But then, we need to rename OLSR...... Do you mean that the connectivity has been checked to be symmetric, or something else? > > |> MANET interface > |> - MANET router interface with a MANET protocol enabled. > | > |Why do you need a specific term and not use use the RFC 2460 "interface" > |term? > > There may be interfaces not running the protocols. For example, the > interface > with fixed connected hosts (like NEMO mobile network). > Sometimes, posting says "MANET interface MUST xxxx". Then I'm lost, > because I have no clue what is meant. Yes, but we don't seem to need terms like "OSPF interface" or "BGP interface" to describe how those protocols work. (They might use different terms like adjacencies to describe how the protocol works.) > |> Radio link - a link with undetermined connectivity properties, such > |> as asymmetry, non-transitivity and time-variation as > |> described in > |> [draft-baccelli-multi-hop-wireless-communication]. > |> Wireless links have often undetermined connectivity > |> properties. > |> > |> Radio interface > |> - MANET router interface to a Radio link. > | > |Why do you need to define those? > |The reason I'm asking is that "radio" is rather generic, and would seem > |to include WiFi, 3G and other stuff where the L2 might ensure that there > |is transient and symmetric reachability. > > Yes, I understand you comment. > But I find "link with undetermined connectivity properties" rather > clumsy. We could introduce "lwucp" or "elwucpie". But that isn't specific to radio. I've had Ethernet links with asymmetric connectivity, and a broken Ethernet switch can create non-transitive connectivity. The difference is in probability. Thus a link with high loss probability, asymmetric and non-transitive connectivity is just the most general form of a link. Trying to pick separate names for such a thing based on probabilities isn't very helpful, nor is tying the name to a current technology used to construct links with those properties. Erik From teco@inf-net.nl Tue Jul 28 08:23:26 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EC353A6FC7 for ; Tue, 28 Jul 2009 08:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7f1tRXcT8eS for ; Tue, 28 Jul 2009 08:23:25 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 614E33A706D for ; Tue, 28 Jul 2009 08:23:25 -0700 (PDT) Received: (qmail 29369 invoked from network); 28 Jul 2009 17:23:21 +0200 Received: from dhcp-15cb.meeting.ietf.org (HELO M90Teco) (130.129.21.203) by server9.hosting2go.nl with SMTP; 28 Jul 2009 17:23:21 +0200 From: "Teco Boot" To: "'Charles E. Perkins'" References: <4A6DBFB5.3050305@sun.com> <000001ca0ed8$98408350$c8c189f0$@nl> <4A6DE796.20901@sun.com> <002401ca0f0a$00ce4c50$026ae4f0$@nl> <4A6EAB0C.8020008@sun.com> <006c01ca0f61$cb802de0$628089a0$@nl> <4A6EDCB2.9090507@sun.com> <00e101ca0f8e$4310fd40$c932f7c0$@nl> <4A6F099A.80600@earthlink.net> In-Reply-To: <4A6F099A.80600@earthlink.net> Date: Tue, 28 Jul 2009 17:22:49 +0200 Message-ID: <010601ca0f97$56ed6fc0$04c84f40$@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: AcoPjtSYqlmy5p+/RTagAZE9rickpQAB1nMw Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] Suggested text on link-locals X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 15:23:26 -0000 Hi Charlie, |> We might need DAD, for those who need further guarantee for |uniqueness. |> I don't have any indication that DAD for globals is more easy than |> for link-locals. But this is solution space. |> | |DAD for globals is easier, because packets using global IP |addresses can be forwarded. Forwarding may be necessary |to guarantee uniqueness across non-local regions of the |network. | |This should count as an "indication". We run DAD before sending a packet with this address. Or am I missing something? When we worked out a mechanism, it could easily support both. Maybe link-local is simpler. So I have an opposite indication also:-) Regards, Teco From teco@inf-net.nl Tue Jul 28 09:13:20 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 551B83A6E31 for ; Tue, 28 Jul 2009 09:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGoMhvhZFOYd for ; Tue, 28 Jul 2009 09:13:19 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id F05133A6E25 for ; Tue, 28 Jul 2009 09:13:18 -0700 (PDT) Received: (qmail 5535 invoked from network); 28 Jul 2009 18:13:18 +0200 Received: from dhcp-15cb.meeting.ietf.org (HELO M90Teco) (130.129.21.203) by server9.hosting2go.nl with SMTP; 28 Jul 2009 18:13:18 +0200 From: "Teco Boot" To: "'Erik Nordmark'" References: <4A6DBFB5.3050305@sun.com> <000001ca0ed8$98408350$c8c189f0$@nl> <4A6DE796.20901@sun.com> <002401ca0f0a$00ce4c50$026ae4f0$@nl> <4A6EAB0C.8020008@sun.com> <006c01ca0f61$cb802de0$628089a0$@nl> <4A6EDCB2.9090507@sun.com> <00e101ca0f8e$4310fd40$c932f7c0$@nl> <4A6F1526.4050104@sun.com> In-Reply-To: <4A6F1526.4050104@sun.com> Date: Tue, 28 Jul 2009 18:12:44 +0200 Message-ID: <010701ca0f9e$50d13de0$f273b9a0$@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: AcoPlbquIM2nnqNoTuGdEjiCXZHulgAAcgGA Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] Suggested text on link-locals X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 16:13:20 -0000 Hi Erik, |> http://www.ietf.org/mail-archive/web/autoconf/current/msg01701.html | |Did the WG chairs declare some form of consensus on this subject? No. |The thread seems to say that *if* we've solved DAD for link-locals |*then* that can be used to solve DAD for globals. But that doesn't mean |that the inverse is true. Hence I don't see how you can say that they |are the same or similar. This is evaluation of multi-hop DAD solutions. I'll postpone answering. Still, I do not see much difference. |> We have 62 bits random or unique EUI-64. |> We might need DAD, for those who need further guarantee for |uniqueness. |> I don't have any indication that DAD for globals is more easy than |> for link-locals. But this is solution space. | |I do have an example. |For Ethernets DHCPv6 is an example of a way to make DAD simpler; a |logically single location of the state of which addresses are allocated |to whom avoids duplicates. |(I'm in no way advocating DHCPv6 as a solution; it is merely an example |that global address allocation can avoid the DAD we need for link- |locals.) I think DHCP depends on another token (IA, DUID). So I say duplicate avoidance is distributed. How is DAD on IA/DUID implemented? What makes link-locals based on EUI-64 different from globals based on DUID-LL? |> |If you neither have guaranteed to be unique interface IDs to form the |> |IPv6-link locals, nor a robust protocol to test and detect duplicate |> |addresses, then how can you claim that OSPFv3 would work reliably? |> |> Because OSPFv3 don't use addresses for the routing topology. | |If the routing topology is perfect, but data packets get misdelivered or |duplicated (due to duplicate link-locals), does that mean than routing |is working? This depends on the layer-2 technology used. With only P2P links, using only a single link-local address, I do not expect a problem. Using duplicate link-locals on multi-access links would introduce L2 problems, and DAD would help little or not at all. |> |> MANET link - 1-hop connectivity between two MANET interfaces. |Called |> |> edge in graph theory. |> | |> |Why is that term needed? Isn't it the same as "link"? It not, what is |> |the difference? |> |> A "link" could be partial connected. |> The "MANET link" is the elementary object in for example |> [olsrv2]. It is a "link between two nodes", or "edge". |> I need another term, as --* link-- is confusing. |> But then, we need to rename OLSR...... | |Do you mean that the connectivity has been checked to be symmetric, or |something else? Yes, the "MANET links" status needs to be checked. State can also be asymmetric, bad (do_not_use) or lost. Or have a cost value. |> |> Radio link - a link with undetermined connectivity properties, such |> |> as asymmetry, non-transitivity and time-variation as |> |> described in |> |> [draft-baccelli-multi-hop-wireless-communication]. |> |> Wireless links have often undetermined connectivity |> |> properties. |> |> |> |> Radio interface |> |> - MANET router interface to a Radio link. |> | |> |Why do you need to define those? |> |The reason I'm asking is that "radio" is rather generic, and would |seem |> |to include WiFi, 3G and other stuff where the L2 might ensure that |there |> |is transient and symmetric reachability. |> |> Yes, I understand you comment. |> But I find "link with undetermined connectivity properties" rather |> clumsy. We could introduce "lwucp" or "elwucpie". | |But that isn't specific to radio. I've had Ethernet links with |asymmetric connectivity, and a broken Ethernet switch can create |non-transitive connectivity. |The difference is in probability. | |Thus a link with high loss probability, asymmetric and non-transitive |connectivity is just the most general form of a link. Trying to pick |separate names for such a thing based on probabilities isn't very |helpful, nor is tying the name to a current technology used to construct |links with those properties. OK, let's go for elwucpie. I'm in for any better suggestion. Regards, Teco. From Thomas@ThomasClausen.org Tue Jul 28 09:19:07 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCD2F3A6919 for ; Tue, 28 Jul 2009 09:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ty-XHENxEZvc for ; Tue, 28 Jul 2009 09:19:07 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 449883A7052 for ; Tue, 28 Jul 2009 09:18:46 -0700 (PDT) Received: from dhcp-1294.meeting.ietf.org ([130.129.18.148]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1MVpNi-0004Hl-6J; Tue, 28 Jul 2009 16:18:26 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 130.129.18.148 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18yrgyu5huqQuan0gQdNvil In-Reply-To: <4A6F1526.4050104@sun.com> References: <4A6DBFB5.3050305@sun.com> <000001ca0ed8$98408350$c8c189f0$@nl> <4A6DE796.20901@sun.com> <002401ca0f0a$00ce4c50$026ae4f0$@nl> <4A6EAB0C.8020008@sun.com> <006c01ca0f61$cb802de0$628089a0$@nl> <4A6EDCB2.9090507@sun.com> <00e101ca0f8e$4310fd40$c932f7c0$@nl> <4A6F1526.4050104@sun.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Thomas Heide Clausen Date: Tue, 28 Jul 2009 18:19:00 +0200 To: Erik Nordmark X-Mailer: Apple Mail (2.753.1) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Suggested text on link-locals X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 16:19:08 -0000 On Jul 28, 2009, at 17:11 PM, Erik Nordmark wrote: > > Did the WG chairs declare some form of consensus on this subject? > The chairs are currently, with the minute takers, compiling the meeting minutes for posting on-line. Once that's done, and the minutes are available for the list to see, we'll summarize the perceived consensus in the room in Stockholm, and call for consensus on the list. Sincerely, Thomas From teco@inf-net.nl Tue Jul 28 23:44:26 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD1623A682D for ; Tue, 28 Jul 2009 23:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.429 X-Spam-Level: X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eINCGuzRQIkt for ; Tue, 28 Jul 2009 23:44:25 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 729573A680D for ; Tue, 28 Jul 2009 23:44:24 -0700 (PDT) Received: (qmail 9426 invoked from network); 29 Jul 2009 08:44:23 +0200 Received: from scandic811.host.songnetworks.se (HELO M90Teco) (212.214.188.26) by server9.hosting2go.nl with SMTP; 29 Jul 2009 08:44:23 +0200 From: "Teco Boot" To: "'Erik Nordmark'" , References: <4A6DBFB5.3050305@sun.com> In-Reply-To: <4A6DBFB5.3050305@sun.com> Date: Wed, 29 Jul 2009 08:43:51 +0200 Message-ID: <012001ca1018$015de270$0419a750$@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: AcoOyjzRhs0WDbpoR4mS5DAA+vDKNQBSpn/Q Content-Language: nl Subject: Re: [Autoconf] Suggested text on link-locals X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 06:44:26 -0000 Hi Eric, Back to your proposed text. I worked on refinements, so I can agree on it. |In section 4.2 change the sentence | If the link to which an interface connects enables no assumptions of | connectivity to other interfaces, the only addresses which can be | assumed "on link", are the address(es) of that interface itself. |to | If the link to which an interface connects enables no assumptions of | connectivity to other interfaces, the only addresses which can be | assumed "on link", are the address(es) of that interface itself. | Note | that IPv6 link-local addresses are assumed "on link".. However, the | utility of IPv6 link-locals is limited as specified in section 6.2. If we add reachable to "on-link", it would be much clearer. New text: If the link to which an interface connects enables no assumptions of connectivity to other interfaces, the only addresses which can be assumed "on-link" or reachable, are the address(es) of that interface itself. Note that IPv6 link-local addresses are assumed "on-link", either reachable or not. This makes the utility of IPv6 link-locals limited as specified in section 6.2. On the second part, I agree upper layer protocols that do not understand the details of connectivity in a MANET better not use link-locals. And we can leave open if MANET protocols use link-locals or not. I removed some text, that is in my opinion unneeded or lead to discussions on for example what is a link?, what is a MANET link? etc. Old text: |At the end of section 6.2 add this text: | |A IPv6 link-local addresses must be assigned to each interface according |to [RFC 4291]. Due to the connectivity properties of these links with |neighbors constantly moving in and out of reachability, the link-local |addresses are of very limited utility. The known limitations are: | - Even if tested for uniqueness at one moment using Duplicate Address |Detection [RFC 4862], a duplicate link-local address might appear as a |neighbor the next moment and DAD would not detect that. | - There is no mechanism to ensure that IPv6 link-local are unique |across multiple links, hence they can not be used to reliably identify |routers. | - Routers must not forward any packets with Link-Local source or | destination addresses to other links [RFC 4921]. And a Manet router |that forwards packets by definition forwards from one link to another |due to the undefined connectivity properties. (The set of neighbors that |heard the packet received by the router might be different than the set |of neighbors that hears a packet transmitted by the router even if the |same interface on the router is used for the two operations.) New text: A IPv6 link-local addresses must be assigned to each interface according to [RFC 4291]. Due to the connectivity properties of these links with neighbors constantly moving in and out of reachability, the link-local addresses are of very limited utility for applications that are not aware. The known limitations are: - Even if tested for uniqueness at one moment using Duplicate Address Detection [RFC 4862], a duplicate link-local address might appear as a neighbor the next moment and DAD would not detect that. - Routers must not forward any packets with Link-Local source or destination addresses to other links [RFC 4921]. In practice, IPv6 routers do not forward these packets, even on the same link. Now I and many others can keep protocols using link-locals, when dealt with the limitations. And we are free on not using link-locals. OK with this? Regards, Teco. From arjen.holtzer@tno.nl Thu Jul 30 05:09:56 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 294953A659B for ; Thu, 30 Jul 2009 05:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6c0lTToHpTei for ; Thu, 30 Jul 2009 05:09:55 -0700 (PDT) Received: from mailoutb.tno.nl (mailoutb.tno.nl [134.221.1.17]) by core3.amsl.com (Postfix) with ESMTP id E10433A686D for ; Thu, 30 Jul 2009 05:09:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,295,1246831200"; d="scan'208";a="5443909" Received: from ms-dt01thalia.tno.nl (HELO ms-dt01thalia.tsn.tno.nl) ([134.221.225.157]) by mailhost1b.tno.nl with ESMTP; 30 Jul 2009 14:09:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 30 Jul 2009 14:09:55 +0200 Message-ID: In-Reply-To: <4A6DBFB5.3050305@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Suggested text on link-locals Thread-Index: AcoOyj2Lk9hVOxEgRdOF9nC1wW0p8wCPvsog References: <4A6DBFB5.3050305@sun.com> From: "Holtzer, A.C.G. (Arjen)" To: "Erik Nordmark" , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: [Autoconf] Suggested text on link-locals X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 12:09:56 -0000 Hi all, I agree on not prohibiting the use of LLs. And I agree the text should also reflect the possible limitations of their usage. I'm not sure if the text was meant to prohibit the use of LLs, but following the discussion I feel the limitation seems to be formulated relatively strong. See comments inline.=20 > -----Original Message----- > From: autoconf-bounces@ietf.org=20 > [mailto:autoconf-bounces@ietf.org] On Behalf Of Erik Nordmark > Sent: maandag 27 juli 2009 16:55 > To: autoconf@ietf.org > Subject: [Autoconf] Suggested text on link-locals >=20 >=20 > Does this make it more clear? >=20 > In section 4.2 change the sentence > If the link to which an interface connects enables no=20 > assumptions of > connectivity to other interfaces, the only addresses which can be > assumed "on link", are the address(es) of that interface itself. > to > If the link to which an interface connects enables no=20 > assumptions of > connectivity to other interfaces, the only addresses which can be > assumed "on link", are the address(es) of that interface=20 > itself. Note > that IPv6 link-local addresses are assumed "on link"..=20 > However, the > utility of IPv6 link-locals is limited as specified in=20 > section 6.2. >=20 > At the end of section 6.2 add this text: >=20 > A IPv6 link-local addresses must be assigned to each=20 > interface according to [RFC 4291]. Due to the connectivity=20 > properties of these links with neighbors constantly moving in=20 > and out of reachability, the link-local addresses are of very=20 > limited utility. The known limitations are: > - Even if tested for uniqueness at one moment using=20 > Duplicate Address Detection [RFC 4862], a duplicate=20 > link-local address might appear as a neighbor the next moment=20 > and DAD would not detect that. Ok. > - There is no mechanism to ensure that IPv6 link-local are=20 > unique across multiple links, hence they can not be used to=20 > reliably identify routers. >From the discussion: there's agreement that DAD cannot always guarantee address uniqueness in mobile scenarios, but on the other hand using random interface ID's for address generation seems to have a very low probability of generating duplicates (see the draft Carlos referred to: http://tools.ietf.org/html/draft-soto-mobileip-random-iids-00). So in many cases this can be reliable enough. So maybe the text should say: "IPv6 link-local addresses can not be entirely ensured to be unique across multiple links using existing mechanisms in all situations, in which they can not be used to reliably identify routers."=20 People requiring it in their scenario can then still use link local addresses and the Autoconf WG can decide if they feel the need to create a mechanism that does ensure address uniqueness in all cases for LLs or not. Of course, one may ask: what are the situations/scenarios mentioned here? Regards, Arjen > - Routers must not forward any packets with Link-Local source or > destination addresses to other links [RFC 4921]. And a=20 > Manet router that forwards packets by definition forwards=20 > from one link to another due to the undefined connectivity=20 > properties. (The set of neighbors that heard the packet=20 > received by the router might be different than the set of=20 > neighbors that hears a packet transmitted by the router even=20 > if the same interface on the router is used for the two operations.) >=20 > Erik >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf >=20 This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/disclaimer/email.html