From root@core3.amsl.com Mon Dec 7 16:30:01 2009 Return-Path: X-Original-To: autoconf@ietf.org Delivered-To: autoconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DD2803A69C2; Mon, 7 Dec 2009 16:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091208003001.DD2803A69C2@core3.amsl.com> Date: Mon, 7 Dec 2009 16:30:01 -0800 (PST) Cc: autoconf@ietf.org Subject: [Autoconf] I-D Action:draft-ietf-autoconf-adhoc-addr-model-01.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 00:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Ad-Hoc Network Autoconfiguration Working Group of the IETF. Title : IP Addressing Model in Ad Hoc Networks Author(s) : E. Baccelli, M. Townsley Filename : draft-ietf-autoconf-adhoc-addr-model-01.txt Pages : 8 Date : 2009-12-07 This document describes a model for configuring IP addresses and subnet prefixes on the interfaces of routers which connect to links with undetermined connectivity properties. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 10, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-autoconf-adhoc-addr-model-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-autoconf-adhoc-addr-model-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-07162951.I-D@ietf.org> --NextPart-- From teco@inf-net.nl Tue Dec 8 06:41:36 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC87F3A6860 for ; Tue, 8 Dec 2009 06:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.755 X-Spam-Level: X-Spam-Status: No, score=-0.755 tagged_above=-999 required=5 tests=[AWL=-0.756, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXgIv13vRGlx for ; Tue, 8 Dec 2009 06:41:36 -0800 (PST) Received: from CPSMTPM-EML107.kpnxchange.com (Cpsmtpm-eml107.kpnxchange.com [195.121.3.11]) by core3.amsl.com (Postfix) with ESMTP id D5A4C3A67E3 for ; Tue, 8 Dec 2009 06:41:34 -0800 (PST) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML107.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Tue, 8 Dec 2009 15:41:22 +0100 From: "Teco Boot" To: Date: Tue, 8 Dec 2009 15:41:21 +0100 Message-ID: <013201ca7814$82282af0$867880d0$@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: Acp4FH5J1mYfogA3RGu8QPCZnqwGTA== Content-Language: nl x-cr-hashedpuzzle: AZWf A8SE BKWN Cfli C2x0 C3yW FyEg IJxN IUc0 IYjW KAVY KEO/ KUiz KZhc KpZ8 K3QH; 1; YQB1AHQAbwBjAG8AbgBmAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {545A6BA2-B853-4C92-A249-D3C9D893380F}; dABlAGMAbwBAAGkAbgBmAC0AbgBlAHQALgBuAGwA; Tue, 08 Dec 2009 14:41:14 GMT; MQAtAGgAbwBwACAAcgBlAGEAYwBoAGEAYgBpAGwAaQB0AHkAIABkAGUAcABlAG4AZABpAG4AZwAgAG8AbgAgAE0AQQBOAEUAVAAgAHAAcgBvAHQAbwBjAG8AbAA= x-cr-puzzleid: {545A6BA2-B853-4C92-A249-D3C9D893380F} X-OriginalArrivalTime: 08 Dec 2009 14:41:22.0824 (UTC) FILETIME=[83229080:01CA7814] Subject: [Autoconf] 1-hop reachability depending on MANET protocol X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 08 Dec 2009 14:41:36 -0000 When using the proposed addressing model, I faced a reachability problem between 1-hop neighbors, when the MANET routing protocol was stopped. I couldn't start via the network, because the problem. Luckily, there are link-locals. Teco. From Matthew.Anderson@us.elster.com Tue Dec 8 12:08: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 B2F7D3A690A for ; Tue, 8 Dec 2009 12:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVZYg499NEy3 for ; Tue, 8 Dec 2009 12:08:55 -0800 (PST) Received: from mail53.messagelabs.com (mail53.messagelabs.com [216.82.249.211]) by core3.amsl.com (Postfix) with SMTP id 766A73A6403 for ; Tue, 8 Dec 2009 12:08:54 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: Matthew.Anderson@us.elster.com X-Msg-Ref: server-8.tower-53.messagelabs.com!1260302923!47660401!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [206.182.155.20] Received: (qmail 24805 invoked from network); 8 Dec 2009 20:08:43 -0000 Received: from unknown (HELO us-smtp01.smtp.elster.com) (206.182.155.20) by server-8.tower-53.messagelabs.com with SMTP; 8 Dec 2009 20:08:43 -0000 Auto-Submitted: auto-generated From: Matthew.Anderson@us.elster.com To: autoconf@ietf.org Message-ID: Date: Tue, 8 Dec 2009 15:09:14 -0500 X-MIMETrack: Serialize by Router on US-SMTP01.domino.elster-group.com/RIM-TEMP(Release 8.5.1|September 28, 2009) at 12/08/2009 03:06:02 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [Autoconf] AUTO: Matthew Anderson is out of the office (returning 12/14/2009) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 08 Dec 2009 20:08:55 -0000 I am out of the office until 12/14/2009. I am out of the office on vacation. I will occasionally check emails at night, but any critical matters should be sent to Gerald Paprocki. Also - please make sure you have the correct Matt Anderson on this email if you are surprised by this out of office. Note: This is an automated response to your message "Autoconf Digest, Vol 45, Issue 2" sent on 12/8/2009 3:00:03 PM. This is the only notification you will receive while this person is away. From t.clausen@computer.org Wed Dec 9 17:37: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 DF1263A69A2 for ; Wed, 9 Dec 2009 17:37:24 -0800 (PST) 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 xAIaw5B-CxXx for ; Wed, 9 Dec 2009 17:37:24 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 0C82E3A6877 for ; Wed, 9 Dec 2009 17:37:22 -0800 (PST) Received: from adsl-99-49-9-50.dsl.pltn13.sbcglobal.net ([99.49.9.50] helo=[192.168.18.109]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1NIXxu-0003zX-Nh for autoconf@ietf.org; Thu, 10 Dec 2009 01:37:11 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 99.49.9.50 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18uGnzty7kaiHGNREV61zV9 Message-Id: <3A8500A3-A75A-49A8-B48C-EED53A17E722@computer.org> From: Thomas Heide Clausen 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 v936) Date: Thu, 10 Dec 2009 02:37:03 +0100 X-Mailer: Apple Mail (2.936) Subject: [Autoconf] Working Group Last Call for draft-ietf-autoconf-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: Thu, 10 Dec 2009 01:37:25 -0000 All, In Hiroshima, we discussed draft-ietf-autoconf-addr-model-00. The editors have updated the document and issued draft-ietf-autoconf-addr- model-01 to reflect these discussions. The WG chairs have reviewed the document, and believe that this new version capture the discussion to our satisfaction. In order to not drag out the WG process unnecessarily, we therefore hereby issue a Working Group Last Call on draft-ietf-autocon-addr-model: http://tools.ietf.org/wg/autoconf/draft-ietf-autoconf-adhoc-addr-model/ This Working Group Last Call runs until 09/12/23. Please review the document carefully, and post your comments to autoconf@ietf.org as soon as possible and before that deadline. When you review the document, please pay specific attention to the changes which were included following the discussions in Hiroshima, and which were summarized in Appendix A (http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model-01#appendix-A - reproduced below): Appendix A. Changes since -00 This section logs the main changes of this document since its last version. These are: Facts on the needs of applications other than routing - At the end of the intro, added a disclaimer on the fact that apps other than routing may need additional addresses (potentially plus prefixes, and such, better global than local, but that the doc focuses only on what is necessary for the routing protocols to be functional. Modified list of issues pertaining to the use of LLs - Removed DAD issue as argument for why link-local addresses are not recommended for use. Other issues, that remain listed in this document, are still sufficient to reach the same conclusion. More precise expression of the model for IPv6 - Reworded the "/128 IPv6 prefixes" recommendation into "there is no on-link prefix" recommendation. More precise expression of the applicability of the model - Better expression of recommendation that "if you know something about reachability o addresses or interfaces" then you may leverage this to configure an on-link prefix in the last paragraphs of section 3 and 4. Sincerely, Ryuji and Thomas From teco@inf-net.nl Fri Dec 11 04:04: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 989353A67EC for ; Fri, 11 Dec 2009 04:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[AWL=0.638, 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 dZodC6OF+1C3 for ; Fri, 11 Dec 2009 04:04:58 -0800 (PST) Received: from CPSMTPM-EML104.kpnxchange.com (cpsmtpm-eml104.kpnxchange.com [195.121.3.8]) by core3.amsl.com (Postfix) with ESMTP id 95D793A6781 for ; Fri, 11 Dec 2009 04:04:56 -0800 (PST) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML104.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Fri, 11 Dec 2009 13:04:43 +0100 From: "Teco Boot" To: References: <3A8500A3-A75A-49A8-B48C-EED53A17E722@computer.org> In-Reply-To: <3A8500A3-A75A-49A8-B48C-EED53A17E722@computer.org> Date: Fri, 11 Dec 2009 13:04:37 +0100 Message-ID: <009d01ca7a5a$1c301940$54904bc0$@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: Acp5ON03M0rvCn6DTACl8TmznAKSoABDjr1w Content-Language: nl X-OriginalArrivalTime: 11 Dec 2009 12:04:43.0700 (UTC) FILETIME=[200F4F40:01CA7A5A] Subject: Re: [Autoconf] Working Group Last Call for draft-ietf-autoconf-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: Fri, 11 Dec 2009 12:04:59 -0000 Here my thoughts on the document in its current state. I think the document describes a practical addressing model for ad hoc networks. I say _a_ practical addressing model, because I think there are other practical models, e.g. a model that use link-locals or a model that use a common subnet prefix for each MANET segment. All such models have their pro's and con's. I think the document is restrictive in scope, it focuses solely on addresses for the MANET protocol and leaves open what to do for normal end-user applications. Do we need an additional document? It does not say anything on the address types, e.g. use ULA of request something else. The document leaves also open what address model applies to those parts of the ad hoc network that have some determined connectivity properties. It also does not address multi-homed scenarios. Detailed comments: Page 3: In general, global scope is desired over local scope, though it is understood that this may not always be achievable via automatic configuration mechanisms. I don't understand why automatic configuration of globals is not achievable, specifically when the network is attached to The Internet. Page 4: The configuration proposed by this model is applicable to any router's IP interface. It specifies IP addresses and IP subnet prefixes to be configured on network interfaces. This is not in line with the scope of the document. The next sentence in the document also argues against this statement. Page 4: If L2 communication is enabled between a pair of interfaces, IP packet exchange is enabled regardless of the IP subnet configuration on each of these interfaces. This is only possible if the IP stack is aware of the L2 link between the pair of interfaces. One way of establishing this is configure an on-link subnet prefix. Now we choose not to configure so, and instead run a MANET protocol. But this makes IP communication dependent on the MANET protocol, which can have a negative effect on managing the network. Think of remote management and updates on the MANET protocol. Page 4: If on the contrary, assumptions can be made regarding the connectivity between interfaces, or regarding the persistent reachability of some addresses, these SHOULD be considered when configuring IP subnet prefixes, and the corresponding interface(s) MAY in such case be configured with an on-link subnet prefix. There are scenarios where some tethered hosts do always have connectivity with a router, and connectivity to other nodes is undetermined. In such cases, there should be used an off-link subnet prefix. The text says "should" and "may", so yes, the document is not incorrect. But it leaves open many scenarios. Page 5: link-local addresses are of limited utility on links with undetermined connectivity There were debates on protocols that more or less require or depend on link-locals. Mentioned protocols are OSPF-MANET, ND and MLD. On ND: RAs are sent with link-local source address. This is also the case for NS to Solicited-Node Address (FF02:0:0:0:0:1:FFXX: XXXX), using default source address selection. And also, the default source address selection uses link-locals for MANET Packets with LL-MANET-Routers destination address. Page 5: o There is no mechanism to ensure that IPv6 link-local addresses are unique across multiple links, hence they can not be used to reliably identify routers. This argument is not specific to ad hoc networks at all. So I do not see a reason to come up with it in this document. There is no such standardized mechanism for non-link-locals either, so with the same argument those address types cannot be used also !!! However, there are proposals for ensuring unique InterfaceIDs, for example for generating unique ULAs, and as a consequence such mechanism also ensures unique link-locals. So link-locals can be used to reliably identify routers. Link-locals have a limitation on reachability, and one may need reachable router identifiers. In that case, link-locals cannot be used. Page 5: o Routers cannot forward any packets with link-local source or destination addresses to other links (as per [RFC4291]) while most of the time, routers need to be able to forward packets to/from different links. I agree on this. But the scope of the document is an addressing model used by MANET protocols. MANET protocols use hop-by-hop information transfer, and thus do not need more than link-locals provide. Page 6: Note that the use of IPv4 link-local addresses [RFC3927] in this context should be discouraged for most applications, as the limitations outlined in Section 6.1 for IPv6 link-local addresses also concern IPv4 link-local addresses. These limitations are further exacerbated by the smaller pool of IPv4 link-local addresses to choose from and thus increased reliance on DAD. I think the main difference with IPv6 is that an IPv4 interface would not have configured a link-local _and_ a routable address. Also, what other, larger, pool of addresses is available? Regards, Teco. >-----Oorspronkelijk bericht----- >Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens >Thomas Heide Clausen >Verzonden: donderdag 10 december 2009 2:37 >Aan: autoconf@ietf.org >Onderwerp: [Autoconf] Working Group Last Call for draft-ietf-autoconf- >addr-model-01 > >All, > >In Hiroshima, we discussed draft-ietf-autoconf-addr-model-00. The >editors have updated the document and issued draft-ietf-autoconf-addr- >model-01 to reflect these discussions. The WG chairs have reviewed the >document, and believe that this new version capture the discussion to >our satisfaction. > >In order to not drag out the WG process unnecessarily, we therefore >hereby issue a Working Group Last Call on draft-ietf-autocon-addr-model: > > http://tools.ietf.org/wg/autoconf/draft-ietf-autoconf-adhoc-addr- >model/ > >This Working Group Last Call runs until 09/12/23. > >Please review the document carefully, and post your comments to >autoconf@ietf.org > as soon as possible and before that deadline. > >When you review the document, please pay specific attention to the >changes which were included following the discussions in Hiroshima, >and which were summarized in Appendix A >(http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model- >01#appendix-A > - reproduced below): > > > Appendix A. Changes since -00 > > This section logs the main changes of this document since its >last > version. These are: > > Facts on the needs of applications other than routing - At the >end > of the intro, added a disclaimer on the fact that apps other >than > routing may need additional addresses (potentially plus >prefixes, > and such, better global than local, but that the doc focuses >only > on what is necessary for the routing protocols to be >functional. > > Modified list of issues pertaining to the use of LLs - Removed >DAD > issue as argument for why link-local addresses are not >recommended > for use. Other issues, that remain listed in this document, >are > still sufficient to reach the same conclusion. > > More precise expression of the model for IPv6 - Reworded the >"/128 > IPv6 prefixes" recommendation into "there is no on-link >prefix" > recommendation. > > More precise expression of the applicability of the model - >Better > expression of recommendation that "if you know something >about > reachability o addresses or interfaces" then you may >leverage >this > to configure an on-link prefix in the last paragraphs of >section 3 > and 4. > >Sincerely, > >Ryuji and Thomas > >_______________________________________________ >Autoconf mailing list >Autoconf@ietf.org >https://www.ietf.org/mailman/listinfo/autoconf From ulrich@herberg.name Mon Dec 21 06:15: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 2658428C0E7 for ; Mon, 21 Dec 2009 06:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bA7M-aR9tZxH for ; Mon, 21 Dec 2009 06:15:06 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id A7CBF3A6A05 for ; Mon, 21 Dec 2009 06:15:03 -0800 (PST) Received: by bwz23 with SMTP id 23so3580076bwz.29 for ; Mon, 21 Dec 2009 06:14:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.143.153 with SMTP id v25mr4598445bku.116.1261404883266; Mon, 21 Dec 2009 06:14:43 -0800 (PST) In-Reply-To: <3A8500A3-A75A-49A8-B48C-EED53A17E722@computer.org> References: <3A8500A3-A75A-49A8-B48C-EED53A17E722@computer.org> Date: Mon, 21 Dec 2009 15:14:43 +0100 Message-ID: <25c114b90912210614t337744p9b03622bd7aa02dc@mail.gmail.com> From: Ulrich Herberg To: autoconf@ietf.org, Thomas Heide Clausen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Autoconf] Working Group Last Call for draft-ietf-autoconf-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: Mon, 21 Dec 2009 14:15:15 -0000 Hi, here is my review on the draft. I think that the document defines a good start into further work of AUTOCONF, and I am all in favor for going ahead with the publication of it. Some more detailed comments: * The document represents *a* practical addressing model, that works for interfaces (such as used in MANETs) without planned topology, and as such without any assumptions about connectivity between routers. The document makes clear -- and this has been a major point of discussion -- that when more assumptions about connectivity can be made, other subnet prefixes can be configured on the interfaces. * The modified introduction, that includes a disclaimer about other applications on the router or attached hosts, sets clear limits of the scope of the document. Therefore, I think it was a useful addition to the document. Once we agree on an addressing model and recharter AUTOCONF, we should decide where to treat these addresses and prefixes that are used by applications on the router or attached hosts. * Concerning the reworded /128 assumption, I think the new formulation (proposed by Dave Thaler IIRC) is useful. Maybe, however, the authors should add an explanation what that means in practice or give an example how that can be achieved. * I agree with the modified part about link-local addresses. * The "Security Considerations" section is empty. Will the authors add something in there? Merry Christmas Ulrich On Thu, Dec 10, 2009 at 2:37 AM, Thomas Heide Clausen wrote: > All, > > In Hiroshima, we discussed draft-ietf-autoconf-addr-model-00. The editors > have updated the document and issued draft-ietf-autoconf-addr-model-01 to > reflect these discussions. The WG chairs have reviewed the document, and > believe that this new version capture the discussion to our satisfaction. > > In order to not drag out the WG process unnecessarily, we therefore hereb= y > issue a Working Group Last Call on draft-ietf-autocon-addr-model: > > > =A0http://tools.ietf.org/wg/autoconf/draft-ietf-autoconf-adhoc-addr-model= / > > This Working Group Last Call runs until 09/12/23. > > Please review the document carefully, and post your comments to > autoconf@ietf.org=A0as soon as possible and before that deadline. > > When you review the document, please pay specific attention to the change= s > which were included following the discussions in Hiroshima, and which wer= e > summarized in Appendix A > (http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model-01#appen= dix-A=A0- > reproduced below): > > > =A0 =A0 =A0 =A0Appendix A. =A0Changes since -00 > > =A0 =A0 =A0 =A0 =A0 This section logs the main changes of this document s= ince its last > =A0 =A0 =A0 =A0 =A0 version. =A0These are: > > =A0 =A0 =A0 =A0 =A0 Facts on the needs of applications other than routing= - =A0At the > end > =A0 =A0 =A0 =A0 =A0 =A0 =A0of the intro, added a disclaimer on the fact t= hat apps other > than > =A0 =A0 =A0 =A0 =A0 =A0 =A0routing may need additional addresses (potenti= ally plus > prefixes, > =A0 =A0 =A0 =A0 =A0 =A0 =A0and such, better global than local, but that t= he doc focuses > only > =A0 =A0 =A0 =A0 =A0 =A0 =A0on what is necessary for the routing protocols= to be > functional. > > =A0 =A0 =A0 =A0 =A0 Modified list of issues pertaining to the use of LLs = - =A0Removed > DAD > =A0 =A0 =A0 =A0 =A0 =A0 =A0issue as argument for why link-local addresses= are not > recommended > =A0 =A0 =A0 =A0 =A0 =A0 =A0for use. =A0Other issues, that remain listed i= n this document, > are > =A0 =A0 =A0 =A0 =A0 =A0 =A0still sufficient to reach the same conclusion. > > =A0 =A0 =A0 =A0 =A0 More precise expression of the model for IPv6 - =A0Re= worded the > "/128 > =A0 =A0 =A0 =A0 =A0 =A0 =A0IPv6 prefixes" recommendation into "there is n= o on-link prefix" > =A0 =A0 =A0 =A0 =A0 =A0 =A0recommendation. > > =A0 =A0 =A0 =A0 =A0 More precise expression of the applicability of the m= odel - > =A0Better > =A0 =A0 =A0 =A0 =A0 =A0 =A0expression of recommendation that "if you know= something about > =A0 =A0 =A0 =A0 =A0 =A0 =A0reachability o addresses or interfaces" then y= ou may leverage > this > =A0 =A0 =A0 =A0 =A0 =A0 =A0to configure an on-link prefix in the last par= agraphs of > section 3 > =A0 =A0 =A0 =A0 =A0 =A0 =A0and 4. > > Sincerely, > > Ryuji and Thomas > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From zach@sensinode.com Tue Dec 22 03:00: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 7B14C3A6956 for ; Tue, 22 Dec 2009 03:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 7HD09ewLB9T2 for ; Tue, 22 Dec 2009 03:00:08 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 0D34C3A6831 for ; Tue, 22 Dec 2009 03:00:07 -0800 (PST) Received: from [62.145.172.51] ([62.145.172.51]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id nBMAxdvo006889 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Dec 2009 12:59:40 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <3A8500A3-A75A-49A8-B48C-EED53A17E722@computer.org> Date: Tue, 22 Dec 2009 12:59:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <12179C23-1AE4-400E-A025-CF4C4FBF7A02@sensinode.com> References: <3A8500A3-A75A-49A8-B48C-EED53A17E722@computer.org> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1077) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Working Group Last Call for draft-ietf-autoconf-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, 22 Dec 2009 11:00:09 -0000 Hi, I read through addr-model-01 and am happy with the changes. As with = Ulrich, I am in favor of going ahead with publication. - The text on the needs of applications other than routing and = assignment to hosts is very useful and puts this draft into perspective, = explaining exactly the kinds of things we are defining over in 6lowpan = using this model as a reference. Thanks.=20 - The change from /128 to "there is no on-link prefix" recommendation = works well in my opinion. This is compatible with our use in 6lowpan.=20 - I don't think that security section content is required for this = document. =20 Happy Holidays! Zach On Dec 10, 2009, at 3:37 , Thomas Heide Clausen wrote: > All, >=20 > In Hiroshima, we discussed draft-ietf-autoconf-addr-model-00. The = editors have updated the document and issued = draft-ietf-autoconf-addr-model-01 to reflect these discussions. The WG = chairs have reviewed the document, and believe that this new version = capture the discussion to our satisfaction. >=20 > In order to not drag out the WG process unnecessarily, we therefore = hereby issue a Working Group Last Call on draft-ietf-autocon-addr-model: >=20 > = http://tools.ietf.org/wg/autoconf/draft-ietf-autoconf-adhoc-addr-model/ >=20 > This Working Group Last Call runs until 09/12/23. >=20 > Please review the document carefully, and post your comments to = autoconf@ietf.org as soon as possible and before that deadline. >=20 > When you review the document, please pay specific attention to the = changes which were included following the discussions in Hiroshima, and = which were summarized in Appendix A = (http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model-01#append= ix-A - reproduced below): >=20 >=20 > Appendix A. Changes since -00 >=20 > This section logs the main changes of this document since its = last > version. These are: >=20 > Facts on the needs of applications other than routing - At = the end > of the intro, added a disclaimer on the fact that apps = other than > routing may need additional addresses (potentially plus = prefixes, > and such, better global than local, but that the doc = focuses only > on what is necessary for the routing protocols to be = functional. >=20 > Modified list of issues pertaining to the use of LLs - = Removed DAD > issue as argument for why link-local addresses are not = recommended > for use. Other issues, that remain listed in this = document, are > still sufficient to reach the same conclusion. >=20 > More precise expression of the model for IPv6 - Reworded the = "/128 > IPv6 prefixes" recommendation into "there is no on-link = prefix" > recommendation. >=20 > More precise expression of the applicability of the model - = Better > expression of recommendation that "if you know something = about > reachability o addresses or interfaces" then you may = leverage this > to configure an on-link prefix in the last paragraphs of = section 3 > and 4. >=20 > Sincerely, >=20 > Ryuji and Thomas >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf --=20 http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain = legally privileged information. If you are not the intended recipient, = please contact the sender and delete the e-mail from your system without = producing, distributing or retaining copies thereof.=20 From Ronald.intVelt@tno.nl Wed Dec 23 14:20: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 0B5DF3A6820 for ; Wed, 23 Dec 2009 14:20:03 -0800 (PST) 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 S0Z0n8jKcP03 for ; Wed, 23 Dec 2009 14:20:00 -0800 (PST) Received: from mailouta.tno.nl (mailouta.tno.nl [134.221.1.16]) by core3.amsl.com (Postfix) with ESMTP id 43D613A69DB for ; Wed, 23 Dec 2009 14:20:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.47,445,1257116400"; d="scan'208";a="28849924" Received: from ms-dt01thalia.tno.nl (HELO ms-dt01thalia.tsn.tno.nl) ([134.221.225.157]) by mailhost1a.tno.nl with ESMTP; 23 Dec 2009 23:19:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Dec 2009 23:19:39 +0100 Message-ID: <7877C5C0B5CC894AB26113CF06CF886301238DBA@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <3A8500A3-A75A-49A8-B48C-EED53A17E722@computer.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Working Group Last Call fordraft-ietf-autoconf-addr-model-01 Thread-Index: Acp5OVAVAMM8asykRv2EoPBMaSCFvAKsJj4g References: <3A8500A3-A75A-49A8-B48C-EED53A17E722@computer.org> From: "Velt, R. (Ronald) in 't" To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: [Autoconf] Working Group Last Call fordraft-ietf-autoconf-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: Wed, 23 Dec 2009 22:21:12 -0000 All, Please find my comments below: I-D> Abstract I-D>=20 I-D> This document describes a model for configuring IP addresses and I-D> subnet prefixes on the interfaces of routers which connect to links I-D> with undetermined connectivity properties. The scope of this document appears to be limited to router interfaces used for talking to other routers, so maybe change to: "... on the interfaces of routers which connect to other routers over links with undetermined connectivity properties." (See also comment on section 3). I-D>=20 I-D> 1. Introduction I-D>=20 I-D> The appropriate configuration of IP addresses and subnet masks for I-D> router network interfaces is generally a prerequisite to the correct I-D> functioning of routing protocols. Consideration of various items, I-D> including underlying link capabilities and connectivity, geographical I-D> topology, available address blocks, assumed traffic patterns, I-D> etc. are used when determining the appropriate network topology and I-D> the associated IP interface configuration. I-D>=20 I-D> When the capabilities and connectivity of the links that connect I-D> routers are well-known and stable, logical network topology design I-D> and corresponding IP interface configuration are straightforward. I-D> Absent any assumption about link-level connectivity, however, there I-D> is no canonical method for determining a given IP interface I-D> configuration. I-D>=20 I-D> Link-level connectivity is generally qualified as undetermined when I-D> it is unplanned and/or time-varying in character. Ad hoc networks I-D> are typical examples of networks with undetermined link-level I-D> connectivity. Routing protocols for ad hoc networks have as purpose I-D> to detect and maintain paths across the network, even when faced with I-D> links with undetermined connectivity, assuming that routers' I-D> interfaces are configured with IP addresses. This document thus I-D> proposes a model for configuration of IP addresses and subnet I-D> prefixes on router interfaces to links with undetermined connectivity I-D> properties, to allow routing protocols to function. As soon as these routing protocols have completed an initial round of "detecting" and the "maintaining" of paths is in progress, said paths may be put to use for the actual forwarding of user traffic. At each intermediate router, this involves looking up next-hop addresses in the FIB, retrieving the corresponding L2 destination addresses and sticking the latter on the packets (frames, actually) to be forwarded. It stands to reason that these next-hop addresses are the same ones as those for routing protocol operation. (The alternative would be to use LL's as next-hops!) Suggest to change the last sentence of the paragraph above to: "... , to allow routing protocols and data packet forwarding to function". I-D>=20 I-D> Note that routers may ultimately need additional IP prefixes for the I-D> diverse applications that could run directly on the routers I-D> themselves, or for assignment to attached hosts or networks. For I-D> IPv6, these addresses may be global [RFC3587], Unique-Local [RFC4193] I-D> or Link-Local [RFC4291]. For IPv4, the addresses may be global (i.e. I-D> public) or private [RFC1918]. In general, global scope is desired I-D> over local scope, though it is understood that this may not always be I-D> achievable via automatic configuration mechanisms. In this document I-D> however, automatic configuration of the prefixes used for general I-D> applications is considered as a problem that is separable from that I-D> of automatic configuration of addresses and prefixes necessary for I-D> routing protocols to function. This document thus focuses on the I-D> latter: the type of IP address and subnet mask configuration I-D> necessary for routing protocols to function. While the configuration of prefixes for general applications may be separable from the configuration of prefixes and addresses necessary for the operation of routing protocols, in my view the configuration of addresses to be used as next-hops for data packet forwarding is not. So again: "... necessary for routing protocols and data packet forwarding to function." I-D>=20 I-D>=20 I-D> 3. Applicability Statement I-D>=20 I-D> The configuration proposed by this model is applicable to any I-D> router's IP interface. It specifies IP addresses and IP subnet I-D> prefixes to be configured on network interfaces. It seems to me, that the applicability of the model is restricted to those IP interfaces that are used to connect to other routers. If this is the case, the first sentence could be reworded as: "... is applicable to any router's IP interface over which a routing protocol is run". In general, both other routers and hosts could be reachable over some IP interface of a router. See e.g. the first slide of Teco's presentation in the Autoconf session at IETF-74 (San Francisco). Does the model presented here rule out that possibility? If so, this should be stated. Or is this still supportable, provided a different, additional IP address is configured on the router's IP interface, for the purpose of router-host communication? Can we always assume that a different IP interface will be used for router-host communication? During the long discussion on the ML about the usability of link-locals, mention was made several times of devices that are so resource-starved that they have neither a globally unique MAC addresses nor a (pseudo)-random number generator. What if some poor underprivileged router device has just a single radio interface as its sole means of communication with both hosts and other routers? The 'tethered' hosts (term coined by Fred Templin; I called them 'satellite hosts' initially) would have to share a common prefix with the router. I-D>=20 I-D> When more specific assumptions can be made regarding the connectivity I-D> between interfaces, or the (persistent) reachability of some I-D> addresses, these SHOULD be considered when configuring subnet I-D> prefixes. I-D>=20 I-D>=20 I-D> 4. IP Subnet Prefix Configuration I-D>=20 I-D> If the link to which an interface connects enables no assumptions of s/enables/warrants/ ? I-D> connectivity to other interfaces, the only addresses which can be I-D> assumed "on link", are the address(es) of that interface itself. I-D> Note that while link-local addresses are assumed to be "on link", the I-D> utility of link-local addresses is limited as described in Section 6. I-D>=20 I-D> Subnet prefix configuration on such interfaces must thus not make any I-D> promises in terms of direct (one hop) IP connectivity to IP addresses I-D> other than that of the interface itself. This suggests the following I-D> principle: I-D>=20 I-D> o no on-link subnet prefix should be configured on such an I-D> interface. I-D>=20 I-D> If L2 communication is enabled between a pair of interfaces, IP I-D> packet exchange is enabled regardless of the IP subnet configuration I-D> on each of these interfaces. I-D>=20 I-D> If on the contrary, assumptions can be made regarding the I-D> connectivity between interfaces, or regarding the persistent I-D> reachability of some addresses, these SHOULD be considered when I-D> configuring IP subnet prefixes, and the corresponding interface(s) I-D> MAY in such case be configured with an on-link subnet prefix. I-D>=20 I-D>=20 I-D> 5. IP Address Configuration I-D>=20 I-D> Routing protocols running on a router may exhibit different I-D>=20 I-D>=20 I-D>=20 I-D> requirements for uniqueness of interface addresses; some have no such I-D> requirements, others have requirements ranging from local uniqueness I-D> only, to uniqueness within, at least, the routing domain. I-D>=20 I-D> Configuring an IP address that is unique within the routing domain I-D> satisfies the less stringent uniqueness requirements of local I-D> uniqueness, while also enabling protocols which have the most I-D> stringent requirements of uniqueness within the routing domain. This I-D> suggests the following principle: I-D>=20 I-D> o an IP address assigned to an interface that connects to a link I-D> with undetermined connectivity properties should be unique, at I-D> least within the routing domain. I-D>=20 I-D>=20 I-D> 6. Addressing Model I-D>=20 I-D> Section 4 and Section 5 describe principles for IP address and subnet I-D> prefix configuration on an interface of a router, when that interface I-D> connects to a link with undetermined connectivity properties. The I-D> following describes guidelines that follow from these principles, I-D> respectively for IPv6 and IPv4. I-D>=20 I-D> 6.1. IPv6 Model I-D>=20 I-D> For IPv6, the principles described in Section 4 and Section 5 suggest I-D> the following rules: I-D>=20 I-D> o An IP address configured on this interface should be unique, at I-D> least within the routing domain, and I-D>=20 I-D> o No on-link subnet prefix is configured on this interface. Or: Within the routing domain, the IP address configured on this interface is only one out of its prefix that is configured on any interface. I-D>=20 I-D> Note that while an IPv6 link-local address is assigned to each I-D> interface as per [RFC4291], in general link-local addresses are of I-D> limited utility on links with undetermined connectivity, as And yet the LL-MANET-Router multicast address given by RFC5498 has link-local scope. If the routing protcol instance (which in many cases could be a 'daemon' running in user space) does not explicitly specify the source address to be used when sending protocol packets to this multicast address, chances are that the Operating System will pick a link-local source address. Furthermore, I agree with Teco's comment here on Neighbor Sollicitations (which will be sent over router-to-router interfaces as part of user data forwarding). These are sent to the Solicited-Node multicast address, which has link-local scope. If RFC3484, Source Address Selection, Rule #2 is followed, a link-local source address will be picked for these NS. I-D> connectivity to neighbors may be constantly changing. The known I-D> limitations are: I-D>=20 I-D> o There is no mechanism to ensure that IPv6 link-local addresses are I-D> unique across multiple links, hence they can not be used to I-D> reliably identify routers. I-D>=20 I-D> o Routers cannot forward any packets with link-local source or I-D> destination addresses to other links (as per [RFC4291]) while most I-D> of the time, routers need to be able to forward packets to/from I-D> different links. I completely agree with Teco's comment on this bullet. Routing protocol messages / packets travel hop-by-hop. I-D>=20 I-D>=20 I-D>=20 I-D>=20 I-D> Therefore, autoconfiguration solutions should be encouraged to I-D> primarily focus on configuring IP addresses that are not IPv6 link- I-D> local. While I don't think the "therefore" is entirely justified, I do agree with the advice! I-D>=20 I-D> 6.2. IPv4 Model I-D>=20 I-D> For IPv4, the principles described in Section 4 and Section 5 suggest I-D> rules similar to those mentioned for IPv6 in Section 6.1, that are: I-D>=20 I-D> o An IP address configured on this interface should be unique, at I-D> least within the routing domain, and I-D>=20 I-D> o Any subnet prefix configured on this interface should be of length I-D> /32. I-D>=20 I-D> Note that the use of IPv4 link-local addresses [RFC3927] in this I-D> context should be discouraged for most applications, as the I-D> limitations outlined in Section 6.1 for IPv6 link-local addresses I-D> also concern IPv4 link-local addresses. These limitations are I-D> further exacerbated by the smaller pool of IPv4 link-local addresses I-D> to choose from and thus increased reliance on DAD. I-D>=20 I-D>=20 I-D> 7. IANA Considerations I-D>=20 I-D> This document has no actions for IANA. I-D>=20 I-D>=20 I-D> 8. Security Considerations I-D>=20 I-D> This document does not describe any security considerations. That's a tautology, as Charles P. already pointed out. I-D>=20 I-D>=20 I-D> 9. Normative References I-D> =20 I-D>=20 I-D>=20 I-D> Appendix A. Changes since -00 I-D>=20 I-D> This section logs the main changes of this document since its last I-D> version. These are: I-D>=20 I-D> Facts on the needs of applications other than routing - At the end I-D> of the intro, added a disclaimer on the fact that apps other than I-D> routing may need additional addresses (potentially plus prefixes, I-D> and such, better global than local, but that the doc focuses only I-D> on what is necessary for the routing protocols to be functional. But user data packet forwarding is still overlooked. I-D>=20 I-D> Modified list of issues pertaining to the use of LLs - Removed DAD I-D> issue as argument for why link-local addresses are not recommended I-D> for use. Other issues, that remain listed in this document, are I-D> still sufficient to reach the same conclusion. I-D>=20 I-D> More precise expression of the model for IPv6 - Reworded the "/128 I-D> IPv6 prefixes" recommendation into "there is no on-link prefix" I-D> recommendation. I-D>=20 I-D> More precise expression of the applicability of the model - Better I-D> expression of recommendation that "if you know something about I-D> reachability o addresses or interfaces" then you may leverage this typo: reachability of addresses I-D> to configure an on-link prefix in the last paragraphs of section 3 I-D> and 4. I-D>=20 I-D>=20 I-D> Appendix B. Contributors I-D>=20 I-D> This document reflects discussions and contributions from several I-D> individuals including (in alphabetical order): Teco Boot, Ulrich I-D> Herberg, Thomas Narten, Erik Nordmark, Charles Perkins and Zach I-D> Shelby. Perhaps add Dave Thaler? I-D>=20 I-D> That's all. I can only hope that my comments will not all be dismissed right away. Season's greetings, Ronald in 't Velt =20 >-----Original Message----- >From: autoconf-bounces@ietf.org=20 >[mailto:autoconf-bounces@ietf.org] On Behalf Of Thomas Heide Clausen >Sent: donderdag 10 december 2009 2:37 >To: autoconf@ietf.org >Subject: [Autoconf] Working Group Last Call=20 >fordraft-ietf-autoconf-addr-model-01 > >All, > >In Hiroshima, we discussed draft-ietf-autoconf-addr-model-00.=20 >The editors have updated the document and issued=20 >draft-ietf-autoconf-addr- >model-01 to reflect these discussions. The WG chairs have=20 >reviewed the document, and believe that this new version=20 >capture the discussion to our satisfaction. > >In order to not drag out the WG process unnecessarily, we=20 >therefore hereby issue a Working Group Last Call on=20 >draft-ietf-autocon-addr-model: > >=09 >http://tools.ietf.org/wg/autoconf/draft-ietf-autoconf-adhoc-addr-model/ > >This Working Group Last Call runs until 09/12/23. > >Please review the document carefully, and post your comments=20 >to autoconf@ietf.org > as soon as possible and before that deadline. > >When you review the document, please pay specific attention to=20 >the changes which were included following the discussions in=20 >Hiroshima, and which were summarized in Appendix A=20 >(http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-mode >l-01#appendix-A > - reproduced below): > > > Appendix A. Changes since -00 > > This section logs the main changes of this document=20 >since its last > version. These are: > > Facts on the needs of applications other than=20 >routing - At the end > of the intro, added a disclaimer on the fact that=20 >apps other than > routing may need additional addresses=20 >(potentially plus prefixes, > and such, better global than local, but that the=20 >doc focuses only > on what is necessary for the routing protocols to=20 >be functional. > > Modified list of issues pertaining to the use of LLs=20 >- Removed DAD > issue as argument for why link-local addresses=20 >are not recommended > for use. Other issues, that remain listed in=20 >this document, are > still sufficient to reach the same conclusion. > > More precise expression of the model for IPv6 - =20 >Reworded the "/128 > IPv6 prefixes" recommendation into "there is no=20 >on-link prefix" > recommendation. > > More precise expression of the applicability of the=20 >model - Better > expression of recommendation that "if you know=20 >something about > reachability o addresses or interfaces" then you=20 >may leverage this > to configure an on-link prefix in the last=20 >paragraphs of section 3 > and 4. > >Sincerely, > >Ryuji and Thomas > >_______________________________________________ >Autoconf mailing list >Autoconf@ietf.org >https://www.ietf.org/mailman/listinfo/autoconf > This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/disclaimer/email.html From teco@inf-net.nl Wed Dec 23 23:32: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 764CC3A6898 for ; Wed, 23 Dec 2009 23:32:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.102 X-Spam-Level: X-Spam-Status: No, score=-1.102 tagged_above=-999 required=5 tests=[AWL=-0.362, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttiBYKvWYeiw for ; Wed, 23 Dec 2009 23:32:55 -0800 (PST) Received: from CPSMTPM-EML110.kpnxchange.com (cpsmtpm-eml110.kpnxchange.com [195.121.3.14]) by core3.amsl.com (Postfix) with ESMTP id 551283A6805 for ; Wed, 23 Dec 2009 23:32:54 -0800 (PST) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML110.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Thu, 24 Dec 2009 08:32:36 +0100 From: "Teco Boot" To: References: <3A8500A3-A75A-49A8-B48C-EED53A17E722@computer.org> <009d01ca7a5a$1c301940$54904bc0$@nl> In-Reply-To: <009d01ca7a5a$1c301940$54904bc0$@nl> Date: Thu, 24 Dec 2009 08:32:34 +0100 Message-ID: <007f01ca846b$42a42060$c7ec6120$@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: Acp5ON03M0rvCn6DTACl8TmznAKSoABDjr1wAog8XTA= Content-Language: nl X-OriginalArrivalTime: 24 Dec 2009 07:32:36.0609 (UTC) FILETIME=[43B9AF10:01CA846B] Subject: Re: [Autoconf] Working Group Last Call for draft-ietf-autoconf-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: Thu, 24 Dec 2009 08:03:37 -0000 I have to add the issue on network operations (see my mail below). For IPv6, a solution is using LLs. Not easy to handle, but it works. But for IPv4, I can't find something working. And I did not receive any response on my mail. Because I work on MANETs that are actually deployed, and those need remote management, including a fall-back reachability option in cases the MANET routing protocol is not running, I swapped back to the addressing model I used before, that is using a common prefix for all interfaces to a MANET segment. I did not detect any problems with it. I had problems with the /32: some of the boxes I use simply do not support this, and when configured, I miss the fallback reachability. No misunderstanding: I keep supporting the advertised /32 prefix, advertised prefixes shall not overlap. This needs a function in the MANET routing protocol, that is does not advertise the configured prefix, but instead the /32 route (or a configured shorter prefix). All MANET Routing protocol implementations I use support this function. Write down a standard, for what is widely deployed? Regards, Teco PS. I think Autoconf should work on IPv6. And the addressing model should work well for multi-homed MANETs. The current draft attempts to define the model for both IPv4 and IPv6 and does not address the multi-homed scenario at all. -----Oorspronkelijk bericht----- Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens Teco Boot Verzonden: dinsdag 8 december 2009 15:41 Aan: autoconf@ietf.org Onderwerp: [Autoconf] 1-hop reachability depending on MANET protocol When using the proposed addressing model, I faced a reachability problem between 1-hop neighbors, when the MANET routing protocol was stopped. I couldn't start via the network, because the problem. Luckily, there are link-locals. Teco. From ietf@thomasclausen.org Sat Dec 26 20:32: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 BDD323A67DB for ; Sat, 26 Dec 2009 20:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.02 X-Spam-Level: X-Spam-Status: No, score=-1.02 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, 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 A1q2cXvqna9v for ; Sat, 26 Dec 2009 20:32:35 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 126B83A67D9 for ; Sat, 26 Dec 2009 20:32:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0CCAD430616; Sat, 26 Dec 2009 20:32:17 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.201.7.84] (unknown [80.10.46.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id DAF7443060D; Sat, 26 Dec 2009 20:32:15 -0800 (PST) References: <3A8500A3-A75A-49A8-B48C-EED53A17E722@computer.org> <009d01ca7a5a$1c301940$54904bc0$@nl> <007f01ca846b$42a42060$c7ec6120$@nl> Message-Id: <493AD5DF-102A-4CC4-9ED0-C1B3618A7891@thomasclausen.org> From: Thomas Heide Clausen To: Teco Boot In-Reply-To: <007f01ca846b$42a42060$c7ec6120$@nl> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Sun, 27 Dec 2009 05:32:49 +0100 Cc: "" Subject: Re: [Autoconf] Working Group Last Call for draft-ietf-autoconf-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: Sun, 27 Dec 2009 04:32:35 -0000 Teco, What are you, concretely, suggesting to do to the doc? Seasonal greetings, Thomas On 24 Dec 2009, at 08:32, "Teco Boot" wrote: > I have to add the issue on network operations (see my mail below). > For IPv6, a solution is using LLs. Not easy to handle, but it works. > But for IPv4, I can't find something working. And I did not receive > any response on my mail. > > Because I work on MANETs that are actually deployed, and those need > remote management, including a fall-back reachability option in cases > the MANET routing protocol is not running, I swapped back to the > addressing model I used before, that is using a common prefix for all > interfaces to a MANET segment. I did not detect any problems with it. > I had problems with the /32: some of the boxes I use simply do not > support this, and when configured, I miss the fallback reachability. > > No misunderstanding: I keep supporting the advertised /32 prefix, > advertised prefixes shall not overlap. This needs a function in the > MANET routing protocol, that is does not advertise the configured > prefix, but instead the /32 route (or a configured shorter prefix). > All MANET Routing protocol implementations I use support this > function. > Write down a standard, for what is widely deployed? > > Regards, Teco > > > PS. I think Autoconf should work on IPv6. And the addressing model > should work well for multi-homed MANETs. The current draft attempts > to define the model for both IPv4 and IPv6 and does not address the > multi-homed scenario at all. > > > -----Oorspronkelijk bericht----- > Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] > Namens > Teco Boot > Verzonden: dinsdag 8 december 2009 15:41 > Aan: autoconf@ietf.org > Onderwerp: [Autoconf] 1-hop reachability depending on MANET protocol > > When using the proposed addressing model, I faced a reachability > problem between 1-hop neighbors, when the MANET routing protocol > was stopped. I couldn't start via the network, because the problem. > > Luckily, there are link-locals. > > Teco. > > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf