From teco@inf-net.nl Tue Jan 5 10:32:10 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49FC528C192 for ; Tue, 5 Jan 2010 10:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpD+fq53cbZu for ; Tue, 5 Jan 2010 10:32:09 -0800 (PST) Received: from CPSMTPM-EML101.kpnxchange.com (cpsmtpm-eml101.kpnxchange.com [195.121.3.5]) by core3.amsl.com (Postfix) with ESMTP id AF1B228C12D for ; Tue, 5 Jan 2010 10:32:07 -0800 (PST) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML101.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Tue, 5 Jan 2010 19:32:06 +0100 From: "Teco Boot" To: "'Thomas Heide Clausen'" References: <3A8500A3-A75A-49A8-B48C-EED53A17E722@computer.org> <009d01ca7a5a$1c301940$54904bc0$@nl> <007f01ca846b$42a42060$c7ec6120$@nl> <493AD5DF-102A-4CC4-9ED0-C1B3618A7891@thomasclausen.org> In-Reply-To: Date: Tue, 5 Jan 2010 19:31:49 +0100 Message-ID: <000901ca8e35$585951e0$090bf5a0$@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: AcqGrYCwDWLp9KNRTtWZK20Duy+AywGhd/8QAEByfsA= Content-Language: nl X-OriginalArrivalTime: 05 Jan 2010 18:32:06.0574 (UTC) FILETIME=[62382CE0:01CA8E35] 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, 05 Jan 2010 18:32:10 -0000 Did this mail reach any destination? Teco. >-----Oorspronkelijk bericht----- >Van: Teco Boot [mailto:teco@inf-net.nl] >Verzonden: maandag 4 januari 2010 20:08 >Aan: 'Thomas Heide Clausen' >CC: '' >Onderwerp: RE: [Autoconf] Working Group Last Call for draft-ietf- >autoconf-addr-model-01 > >Hi Thomas, > >To begin with: happy new year. > >And on your question, I expect the doc editors carefully check >WGLC comments and update the doc. > >On this particular issue on 1-hop connectivity, the doc has the >following text: >> 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 exactly my requirement. But for IP packet exchange, there >is a need for a routing table entry or neighbor cache entry for the >destination. I dislike an addressing model where 1-hop connectivity >dependents on a routing protocol. Meanwhile, it is perfectly right >that a routing protocol overrides a routing table entry for a directly >connected interface with a longer match entry, even when it is a >multi-hop path. > >The mechanism I use decouples configured prefixes on the MANET >interfaces and the advertised prefixes. With a default configuration, >only the MANET interface address is advertised (e.g. a /32 prefix), >even if a shorter subnet mask is configured on that interface. Today, >it is not an autoconfigured configuration. > >The question is: do we want to support such functionality in Autoconf? >This requires providing and configuring a subnet mask. For IPv6, this is >not a big deal, we can use /64 and define a well known ULA or whatever. >This is also proposed by others, e.g. draft-perkins-manet-autoconf: >> In case the node does not know any suitable prefix, it uses the >> MANET_PREFIX, with prefix length 64, reserved for this purpose. >For IPv4, this draft suggests the 169.254/16, which was zero-config at >that time. Now, it is clearly defined as link-local. Try to >allocate 240/8? Or leave IPv4 for what it is? Other options? > >I hope this helps. Did it? > >Regards, Teco > > >>-----Oorspronkelijk bericht----- >>Van: Thomas Heide Clausen [mailto:ietf@thomasclausen.org] >>Verzonden: zondag 27 december 2009 5:33 >>Aan: Teco Boot >>CC: >>Onderwerp: Re: [Autoconf] Working Group Last Call for draft-ietf- >>autoconf-addr-model-01 >> >>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 From narten@us.ibm.com Tue Jan 5 11:58:22 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EF4E3A68DA for ; Tue, 5 Jan 2010 11:58:22 -0800 (PST) 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 ZlJuF5wDmWdG for ; Tue, 5 Jan 2010 11:58:21 -0800 (PST) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by core3.amsl.com (Postfix) with ESMTP id 50A383A694A for ; Tue, 5 Jan 2010 11:58:21 -0800 (PST) Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by e3.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o05JmSoU029229 for ; Tue, 5 Jan 2010 14:48:28 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o05Jw5AR1429622 for ; Tue, 5 Jan 2010 14:58:05 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o05Jw4wS006862 for ; Tue, 5 Jan 2010 14:58:04 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-239-33.mts.ibm.com [9.65.239.33]) by d01av04.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o05Jw3Cr006837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 5 Jan 2010 14:58:04 -0500 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.3/8.12.5) with ESMTP id o05Jw3vF025489 for ; Tue, 5 Jan 2010 14:58:03 -0500 Message-Id: <201001051958.o05Jw3vF025489@cichlid.raleigh.ibm.com> To: autoconf@ietf.org In-reply-to: <3A8500A3-A75A-49A8-B48C-EED53A17E722@computer.org> References: <3A8500A3-A75A-49A8-B48C-EED53A17E722@computer.org> Comments: In-reply-to Thomas Heide Clausen message dated "Thu, 10 Dec 2009 02:37:03 +0100." Date: Tue, 05 Jan 2010 14:58:03 -0500 From: Thomas Narten 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, 05 Jan 2010 19:58:22 -0000 Two comments on this document. The document uses but does not really define the term "routing domain". It should define and/or explain what this term means and why the term is important (in the context of this document). > 6.1. IPv6 Model > > For IPv6, the principles described in Section 4 and Section 5 suggest > the following rules: > ... > o No on-link subnet prefix is configured on this interface. > But: > 6.2. IPv4 Model > > For IPv4, the principles described in Section 4 and Section 5 suggest > rules similar to those mentioned for IPv6 in Section 6.1, that are: > ... > o Any subnet prefix configured on this interface should be of length > /32. I don't see a lot of difference between an IPv6 "on-link" prefix and an IPv4 subnet prefix. It doesn't make sense to me that IPv6 and IPv4 are treated differently. Thomas From ietf@thomasclausen.org Thu Jan 7 04:47:03 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 442883A6835 for ; Thu, 7 Jan 2010 04:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 eXedR+P0rlw4 for ; Thu, 7 Jan 2010 04:47:02 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 913A93A67AA for ; Thu, 7 Jan 2010 04:47:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4D0074300A3; Thu, 7 Jan 2010 04:47:01 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.216.22.248] (unknown [80.10.46.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 9B6374300A0; Thu, 7 Jan 2010 04:47:00 -0800 (PST) References: <3A8500A3-A75A-49A8-B48C-EED53A17E722@computer.org> <201001051958.o05Jw3vF025489@cichlid.raleigh.ibm.com> Message-Id: From: Thomas Heide Clausen To: Thomas Narten In-Reply-To: <201001051958.o05Jw3vF025489@cichlid.raleigh.ibm.com> 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: Thu, 7 Jan 2010 13:47:46 +0100 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: Thu, 07 Jan 2010 12:47:03 -0000 Hi Thomas, Thanks for your review. Happy new year. I will comment on one thing in your email, leaving the "routing domain" discussion for elsewhere. On 5 Jan 2010, at 20:58, Thomas Narten wrote: > > >> 6.1. IPv6 Model >> >> For IPv6, the principles described in Section 4 and Section 5 >> suggest >> the following rules: >> > ... >> o No on-link subnet prefix is configured on this interface. >> > > But: > >> 6.2. IPv4 Model >> >> For IPv4, the principles described in Section 4 and Section 5 >> suggest >> rules similar to those mentioned for IPv6 in Section 6.1, that are: >> > ... >> o Any subnet prefix configured on this interface should be of >> length >> /32. > > I don't see a lot of difference between an IPv6 "on-link" prefix and > an IPv4 subnet prefix. It doesn't make sense to me that IPv6 and IPv4 > are treated differently. > I believe that Dave Thaler mentioned that there in no definition of an "on link prefix" for IPv4, and that this is the reason for the text being thus different for v4 and v6. Thomas > Thomas > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From narten@us.ibm.com Thu Jan 7 05:32:08 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E17D43A6853 for ; Thu, 7 Jan 2010 05:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.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 jvpTR7IulDpn for ; Thu, 7 Jan 2010 05:32:06 -0800 (PST) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by core3.amsl.com (Postfix) with ESMTP id D26FE3A6846 for ; Thu, 7 Jan 2010 05:32:05 -0800 (PST) Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e7.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o07DQ03N008442 for ; Thu, 7 Jan 2010 08:26:00 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o07DVtmF112562 for ; Thu, 7 Jan 2010 08:31:55 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o07DVtaO017441 for ; Thu, 7 Jan 2010 11:31:55 -0200 Received: from cichlid.raleigh.ibm.com (sig-9-65-244-248.mts.ibm.com [9.65.244.248]) by d01av03.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o07DVsFR017399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2010 11:31:55 -0200 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.3/8.12.5) with ESMTP id o07DVrk1017562; Thu, 7 Jan 2010 08:31:54 -0500 Message-Id: <201001071331.o07DVrk1017562@cichlid.raleigh.ibm.com> To: Thomas Heide Clausen In-reply-to: References: <3A8500A3-A75A-49A8-B48C-EED53A17E722@computer.org> <201001051958.o05Jw3vF025489@cichlid.raleigh.ibm.com> Comments: In-reply-to Thomas Heide Clausen message dated "Thu, 07 Jan 2010 13:47:46 +0100." Date: Thu, 07 Jan 2010 08:31:53 -0500 From: Thomas Narten 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: Thu, 07 Jan 2010 13:32:08 -0000 > > I don't see a lot of difference between an IPv6 "on-link" prefix and > > an IPv4 subnet prefix. It doesn't make sense to me that IPv6 and IPv4 > > are treated differently. > > > I believe that Dave Thaler mentioned that there in no definition of an > "on link prefix" for IPv4, and that this is the reason for the text > being thus different for v4 and v6. It is more than the text being different. If the recommendation is that in IPv4 you assign a /32 subnet prefix, than in IPv6 the equivalent would be to set a /128 to the on-link prefix set. Whether you call it a subnet prefix or on-link isn't the issue. What I think doesn't make sense is to assign a prefix in IPv4 but say not to do so for IPv6. If that is in fact the intention, what is the technical justification? Thomas From townsley@cisco.com Wed Jan 20 03:26:08 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE6093A68E4 for ; Wed, 20 Jan 2010 03:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.532 X-Spam-Level: X-Spam-Status: No, score=-10.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnL8dSIkrC0g for ; Wed, 20 Jan 2010 03:26:06 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 01E833A6A3E for ; Wed, 20 Jan 2010 03:25:50 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAFN3VkurR7Hu/2dsb2JhbACBRsBTlUGENgQ X-IronPort-AV: E=Sophos;i="4.49,309,1262563200"; d="scan'208";a="76786016" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 20 Jan 2010 11:25:46 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o0KBPkPD016361; Wed, 20 Jan 2010 11:25:46 GMT Received: from Saturn.local (dhcp-10-55-80-146.cisco.com [10.55.80.146]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o0KBPiW26428; Wed, 20 Jan 2010 03:25:45 -0800 (PST) Message-ID: <4B56E834.4060800@cisco.com> Date: Wed, 20 Jan 2010 12:25:40 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Thomas Narten References: <3A8500A3-A75A-49A8-B48C-EED53A17E722@computer.org> <201001051958.o05Jw3vF025489@cichlid.raleigh.ibm.com> In-Reply-To: <201001051958.o05Jw3vF025489@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Wed, 20 Jan 2010 11:26:08 -0000 On 1/5/10 8:58 PM, Thomas Narten wrote: > Two comments on this document. > > The document uses but does not really define the term "routing > domain". It should define and/or explain what this term means and why > the term is important (in the context of this document). > We can reference RFC 1136 for this (but I'd hate to have to use the ISO "routeing" spelling, it just hurts my eyes). > >> 6.1. IPv6 Model >> >> For IPv6, the principles described in Section 4 and Section 5 suggest >> the following rules: >> >> > ... > >> o No on-link subnet prefix is configured on this interface. >> >> > But: > > >> 6.2. IPv4 Model >> >> For IPv4, the principles described in Section 4 and Section 5 suggest >> rules similar to those mentioned for IPv6 in Section 6.1, that are: >> >> > ... > >> o Any subnet prefix configured on this interface should be of length >> /32. >> > I don't see a lot of difference between an IPv6 "on-link" prefix and > an IPv4 subnet prefix. It doesn't make sense to me that IPv6 and IPv4 > are treated differently. > I think I was the one who actively supported treating IPv6 and IPv4 differently in the document. IPv6 has a ULA range, IPv4 doesn't. IPv4 has a Private range, IPv6 doesn't. IPv4 global space is constrained, IPv6 isn't. IPv4 stacks remove IPv4 link-local addresses from an interface when a global or private is assigned, IPv6 stacks do not... etc... etc... So, while there certainly are commonalities in the models, there are enough differences that describing each model separately seems to reduce the chance of misunderstanding the differences that do exist between one version vs. the other. - Mark > Thomas > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > > From narten@us.ibm.com Wed Jan 20 05:51:20 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A5FB3A6938 for ; Wed, 20 Jan 2010 05:51:20 -0800 (PST) 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 IwbTtI5J9HTI for ; Wed, 20 Jan 2010 05:51:19 -0800 (PST) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by core3.amsl.com (Postfix) with ESMTP id 3C6983A6823 for ; Wed, 20 Jan 2010 05:51:19 -0800 (PST) Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e8.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o0K9iuMx026407 for ; Wed, 20 Jan 2010 04:44:56 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o0KDpE9Q150736 for ; Wed, 20 Jan 2010 08:51:14 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o0KDpElV011158 for ; Wed, 20 Jan 2010 08:51:14 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-49-158-184.mts.ibm.com [9.49.158.184]) by d01av01.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o0KDpDsx011143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jan 2010 08:51:14 -0500 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.3/8.12.5) with ESMTP id o0KDpCnG015304; Wed, 20 Jan 2010 08:51:12 -0500 Message-Id: <201001201351.o0KDpCnG015304@cichlid.raleigh.ibm.com> To: Mark Townsley In-reply-to: <4B56E834.4060800@cisco.com> References: <3A8500A3-A75A-49A8-B48C-EED53A17E722@computer.org> <201001051958.o05Jw3vF025489@cichlid.raleigh.ibm.com> <4B56E834.4060800@cisco.com> Comments: In-reply-to Mark Townsley message dated "Wed, 20 Jan 2010 12:25:40 +0100." Date: Wed, 20 Jan 2010 08:51:12 -0500 From: Thomas Narten 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: Wed, 20 Jan 2010 13:51:20 -0000 Mark, > > I don't see a lot of difference between an IPv6 "on-link" prefix and > > an IPv4 subnet prefix. It doesn't make sense to me that IPv6 and IPv4 > > are treated differently. > I think I was the one who actively supported treating IPv6 and IPv4 > differently in the document. IPv6 has a ULA range, IPv4 doesn't. IPv4 > has a Private range, IPv6 doesn't. This isn't a real difference. Net 10 is "private" in IPv4 and spans multiple links/subnets. That is no different than a ULA in IPv6. Yes, there are some important differences between ULAs and net 10 addresses (namely global uniqueness), but that doesn't change how prefixes out of those networks are assigned to individual links, and whether they are to be treated as being on-link (or not), which is what is at issue. > IPv4 global space is constrained, IPv6 isn't. IPv4 stacks remove > IPv4 link-local addresses from an interface when a global or private > is assigned, IPv6 stacks do not... etc... etc... So, while there > certainly are commonalities in the models, there are enough > differences that describing each model separately seems to reduce > the chance of misunderstanding the differences that do exist between > one version vs. the other. This doesn't really answer my core question. There is no real difference between a /32 in IPv4 and a /128 in IPv6. What is the justification for saying /32 should be used in IPv4 but no on-link prefix is used in IPv6? BTW, I'd be fine with having the IPv6 section say on-link with a /128. That is what I would have expected for consistency. I don't think doing this is a big deal, unless you have IPv4 and IPv6 be different, with no good technical justification, which is how I see things at the moment. Thomas From townsley@cisco.com Wed Jan 20 10:22:25 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16EF83A6895 for ; Wed, 20 Jan 2010 10:22:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdoyESPKMmog for ; Wed, 20 Jan 2010 10:22:24 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 48BD83A6867 for ; Wed, 20 Jan 2010 10:22:23 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcEAFvYVkurR7Ht/2dsb2JhbACBRsM3lVuENgQ X-IronPort-AV: E=Sophos;i="4.49,311,1262563200"; d="scan'208";a="234152577" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 20 Jan 2010 18:22:19 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0KIMJiq012116; Wed, 20 Jan 2010 18:22:19 GMT Received: from Saturn.local (ams3-vpn-dhcp455.cisco.com [10.61.65.199]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o0KIMHW26559; Wed, 20 Jan 2010 10:22:17 -0800 (PST) Message-ID: <4B5749D8.40503@cisco.com> Date: Wed, 20 Jan 2010 19:22:16 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Thomas Narten References: <3A8500A3-A75A-49A8-B48C-EED53A17E722@computer.org> <201001051958.o05Jw3vF025489@cichlid.raleigh.ibm.com> <4B56E834.4060800@cisco.com> <201001201351.o0KDpCnG015304@cichlid.raleigh.ibm.com> In-Reply-To: <201001201351.o0KDpCnG015304@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org, Dave Thaler 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: Wed, 20 Jan 2010 18:22:25 -0000 cc'ing Dave Thaler directly, I need his advice here. Please see inline... On 1/20/10 2:51 PM, Thomas Narten wrote: > Mark, > > > >>> I don't see a lot of difference between an IPv6 "on-link" prefix and >>> an IPv4 subnet prefix. It doesn't make sense to me that IPv6 and IPv4 >>> are treated differently. >>> > >> I think I was the one who actively supported treating IPv6 and IPv4 >> differently in the document. IPv6 has a ULA range, IPv4 doesn't. IPv4 >> has a Private range, IPv6 doesn't. >> > This isn't a real difference. Net 10 is "private" in IPv4 and spans > multiple links/subnets. That is no different than a ULA in IPv6. > > Yes, there are some important differences between ULAs and net 10 > addresses (namely global uniqueness), but that doesn't change how > prefixes out of those networks are assigned to individual links, and > whether they are to be treated as being on-link (or not), which is > what is at issue. > > >> IPv4 global space is constrained, IPv6 isn't. IPv4 stacks remove >> IPv4 link-local addresses from an interface when a global or private >> is assigned, IPv6 stacks do not... etc... etc... So, while there >> certainly are commonalities in the models, there are enough >> differences that describing each model separately seems to reduce >> the chance of misunderstanding the differences that do exist between >> one version vs. the other. >> > This doesn't really answer my core question. There is no real > difference between a /32 in IPv4 and a /128 in IPv6. What is the > justification for saying /32 should be used in IPv4 but no on-link > prefix is used in IPv6? > Indeed, in the previous draft we had this text: > o (An IPv6) subnet prefix configured on this interface should be > of length > /128. > and > > o Any (IPv4) subnet prefix configured on this interface should be > of length > /32. However, Dave convinced us at the last IETF that the better way in IPv6 to describe what we really want to say is that on-link subnet prefixes should simply not be configured at all. Practically speaking, I don't think we have this same luxury in IPv4. - Mark > BTW, I'd be fine with having the IPv6 section say on-link with a > /128. That is what I would have expected for consistency. > > I don't think doing this is a big deal, unless you have IPv4 and IPv6 > be different, with no good technical justification, which is how I see > things at the moment. > > Thomas > > From emmanuel.baccelli@gmail.com Thu Jan 21 07:03:43 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7D4A3A69F3 for ; Thu, 21 Jan 2010 07:03:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szofyMOuUn3X for ; Thu, 21 Jan 2010 07:03:42 -0800 (PST) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by core3.amsl.com (Postfix) with ESMTP id 350AF3A697E for ; Thu, 21 Jan 2010 07:03:41 -0800 (PST) Received: by ewy3 with SMTP id 3so65856ewy.13 for ; Thu, 21 Jan 2010 07:03:35 -0800 (PST) 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=q6nWQkzIxxtZ3v0xSymYahN0DFeOoMUPytlDY0olXyI=; b=Lydh0MXnJsJ9wpUZGjQHUlUOUL0p3fLjiq3LhAep8J3KNxM0NJL8r4tNvC69td4ssB N3HDJRw4DhO513alwbf4RL/G/NdluALqe/RYL5OmkkCRUtBERFOpffB+Xi90Zs2zDkSA QLlQ9eg9KaZd8r8vJl7jSptD3ezfz41JPDisQ= 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=qagirdopOXsyar7xpbrGT1GTlEawF8i8IhEBCMW2I2SgxH6eF+FQ6xyTZiH5GOvPv0 8qhXf8izKPBzlrCWL3y4TfkdwMsONvsZxav6w1QXkaFez1lfTxkPjGZdGO7fehGRcU/l FBoo0AnRRQmXfxHD5Q95+MMLoF2LnPBxyjoyA= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.213.44.18 with SMTP id y18mr2430274ebe.69.1264086215150; Thu, 21 Jan 2010 07:03:35 -0800 (PST) In-Reply-To: <7877C5C0B5CC894AB26113CF06CF886301238DBA@ms-dt01thalia.tsn.tno.nl> References: <3A8500A3-A75A-49A8-B48C-EED53A17E722@computer.org> <7877C5C0B5CC894AB26113CF06CF886301238DBA@ms-dt01thalia.tsn.tno.nl> From: Emmanuel Baccelli Date: Thu, 21 Jan 2010 16:03:15 +0100 X-Google-Sender-Auth: 34a4b06682b52cce Message-ID: To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=0014852f78e9d1d2e8047dae01a9 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: Thu, 21 Jan 2010 15:03:44 -0000 --0014852f78e9d1d2e8047dae01a9 Content-Type: text/plain; charset=ISO-8859-1 Hi Ronald, On Wed, Dec 23, 2009 at 11:19 PM, Velt, R. (Ronald) in 't < Ronald.intVelt@tno.nl> wrote: > All, > > Please find my comments below: > > 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 agree, this is more precise. > I-D> > 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." > > > Here too ;) > I-D> > I-D> > I-D> 3. Applicability Statement > I-D> > 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. > > We're just to describe what addresses/prefixes are to be configured, on a router's interface which does not have determined connectivity. How, and to what the routers connect over such interfaces is out of scope for this document, as far as I understand it. > > > I-D> 8. Security Considerations > I-D> > I-D> This document does not describe any security considerations. > > That's a tautology, as Charles P. already pointed out. > This is corrected ;) Regards, and happy new year. Emmanuel --0014852f78e9d1d2e8047dae01a9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ronald,=A0


On Wed, Dec 23, 2009 a= t 11:19 PM, Velt, R. (Ronald) in 't <Ronald.intVelt@tno.nl> wrote:
=
All,

Please find my comments below:

<snip>=A0
I-D> =A0 =A0Link-level connectivity is generally qualified as undetermin= ed
when
I-D> =A0 =A0it is unplanned and/or time-varying in character. =A0Ad hoc<= br> networks
I-D> =A0 =A0are typical examples of networks with undetermined link-leve= l
I-D> =A0 =A0connectivity. =A0Routing protocols for ad hoc networks have = as
purpose
I-D> =A0 =A0to detect and maintain paths across the network, even when f= aced
with
I-D> =A0 =A0links with undetermined connectivity, assuming that routers&= #39;
I-D> =A0 =A0interfaces are configured with IP addresses. =A0This documen= t thus
I-D> =A0 =A0proposes a model for configuration of IP addresses and subne= t
I-D> =A0 =A0prefixes on router interfaces to links with undetermined
connectivity
I-D> =A0 =A0properties, 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 progre= ss, 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 agree, this is more p= recise.

=A0
I-D>
I-D> =A0 =A0Note that routers may ultimately need additional IP prefixes= for
the
I-D> =A0 =A0diverse applications that could run directly on the routers<= br> I-D> =A0 =A0themselves, or for assignment to attached hosts or networks.=
For
I-D> =A0 =A0IPv6, these addresses may be global [RFC3587], Unique-Local<= br> [RFC4193]
I-D> =A0 =A0or Link-Local [RFC4291]. =A0For IPv4, the addresses may be g= lobal
(i.e.
I-D> =A0 =A0public) or private [RFC1918]. =A0In general, global scope is=
desired
I-D> =A0 =A0over local scope, though it is understood that this may not<= br> always be
I-D> =A0 =A0achievable via automatic configuration mechanisms. =A0In thi= s
document
I-D> =A0 =A0however, automatic configuration of the prefixes used for general
I-D> =A0 =A0applications is considered as a problem that is separable fr= om
that
I-D> =A0 =A0of automatic configuration of addresses and prefixes necessa= ry
for
I-D> =A0 =A0routing protocols to function. =A0This document thus focuses= on
the
I-D> =A0 =A0latter: the type of IP address and subnet mask configuration=
I-D> =A0 =A0necessary 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."




Here too ;)

=A0
I-D>
I-D>
I-D> 3. =A0Applicability Statement
I-D>
I-D> =A0 =A0The configuration proposed by this model is applicable to an= y
I-D> =A0 =A0router's IP interface. =A0It specifies IP addresses and = IP subnet
I-D> =A0 =A0prefixes 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 applicab= le
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<= br> 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<= br> 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 's= atellite
hosts' initially) would have to share a common prefix with the router.<= br>


We're just to descr= ibe what addresses/prefixes are to be configured, on a router's interfa= ce which does not have determined connectivity. How, and to what the router= s connect over such interfaces is out of scope for this document, as far as= I understand it.


=A0
<snip>

I-D> 8. =A0Security Considerations
I-D>
I-D> =A0 =A0This document does not describe any security considerations.=

That's a tautology, as Charles P. already pointed out.
=


This is corrected ;)
=A0
=

Regards, and happy new year.

Emmanuel

--0014852f78e9d1d2e8047dae01a9-- From emmanuel.baccelli@gmail.com Tue Jan 26 04:09:49 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9E663A6915 for ; Tue, 26 Jan 2010 04:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfKz7hUswIlC for ; Tue, 26 Jan 2010 04:09:49 -0800 (PST) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id E005E3A6923 for ; Tue, 26 Jan 2010 04:09:48 -0800 (PST) Received: by ewy8 with SMTP id 8so5368181ewy.29 for ; Tue, 26 Jan 2010 04:09:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=HY5ta3I6qj7uFW5mp/L0xfYr1WUl51cAKzrA1D7UlOU=; b=Ho/xfdPB638C9OS8b8NXFvHlI8++KjOr4jfw2ETbA67nqu25Xd5XFfO5HVqydt7sUQ Ndr8gtjOUtmAxiB2iEXeLEmVOdl/2RUwxtOBaID8IsfV+wXROxw6t5CuG5Y5BcIwTy4u kKfdWDPm2+8qD0EBEfG8RjeQPR8W72lHrHdE0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; b=g07cEQAG3rPK5nwG3pue+pPADxmBJ921W5AgBiqrj+CPXJrZt/JR2iwQFUaiwWyflJ 33wgr7PnxdFjkYhVWeI6V6xJvM0wSqDDfOKrLWEWfS2tj1p9MGV3SqMwUvCk6N/9dW15 7pDGrJq6Ab0fwAkgJO3ACDHmZkQVDwx4/yo1s= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.213.49.143 with SMTP id v15mr7938177ebf.17.1264507795564; Tue, 26 Jan 2010 04:09:55 -0800 (PST) From: Emmanuel Baccelli Date: Tue, 26 Jan 2010 13:09:35 +0100 X-Google-Sender-Auth: d86a5d64b1bfaf88 Message-ID: To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=00148531acb8f86bce047e102923 Subject: [Autoconf] Updated ad hoc addressing model 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, 26 Jan 2010 12:09:49 -0000 --00148531acb8f86bce047e102923 Content-Type: text/plain; charset=ISO-8859-1 Folks, here's an updated version of the ad hoc addressing model document, following the comments gathered during working group last call. We took as much as possible on board, as discussed on the mailing list. Please review this revision, and let us know if you have further comments. http://www.ietf.org/id/draft-ietf-autoconf-adhoc-addr-model-02.txt Regards, Emmanuel --00148531acb8f86bce047e102923 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Folks,

here's an updated version of the ad hoc addre= ssing model document, following the comments gathered during working group = last call. We took as much as possible on board, as discussed on the mailin= g list. Please review this revision, and let us know if you have further co= mments.


Regards,

Emmanuel


--00148531acb8f86bce047e102923-- From root@core3.amsl.com Tue Jan 26 04:15:02 2010 Return-Path: X-Original-To: autoconf@ietf.org Delivered-To: autoconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0D5493A6949; Tue, 26 Jan 2010 04:15: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: <20100126121502.0D5493A6949@core3.amsl.com> Date: Tue, 26 Jan 2010 04:15:01 -0800 (PST) Cc: autoconf@ietf.org Subject: [Autoconf] I-D Action:draft-ietf-autoconf-adhoc-addr-model-02.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, 26 Jan 2010 12:15: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-02.txt Pages : 8 Date : 2010-01-26 This document describes a model for configuring IP addresses and subnet prefixes on the interfaces of routers which connect to links with undetermined connectivity properties. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-autoconf-adhoc-addr-model-02.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-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-26040332.I-D@ietf.org> --NextPart-- From zach@sensinode.com Tue Jan 26 23:54:12 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 117893A6A1F for ; Tue, 26 Jan 2010 23:54:12 -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=[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 FEhihjmhQFlQ for ; Tue, 26 Jan 2010 23:54:11 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id F0F7E3A6820 for ; Tue, 26 Jan 2010 23:54:10 -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 o0R7sKDW003957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jan 2010 09:54:20 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Wed, 27 Jan 2010 09:54:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8D3BEBF5-A1DC-431A-8C26-767F6A06ED5E@sensinode.com> References: To: Emmanuel Baccelli X-Mailer: Apple Mail (2.1077) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Updated ad hoc addressing model 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, 27 Jan 2010 07:54:12 -0000 I took a read through -02, and the changes look fine to me. Zach=20 On Jan 26, 2010, at 14:09 , Emmanuel Baccelli wrote: > Folks, >=20 > here's an updated version of the ad hoc addressing model document, = following the comments gathered during working group last call. We took = as much as possible on board, as discussed on the mailing list. Please = review this revision, and let us know if you have further comments. >=20 > http://www.ietf.org/id/draft-ietf-autoconf-adhoc-addr-model-02.txt >=20 > Regards, >=20 > Emmanuel >=20 >=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 thomas@thomasclausen.org Tue Jan 26 23:59:59 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C51D03A67E1 for ; Tue, 26 Jan 2010 23:59:59 -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=[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 HkXji48ldp86 for ; Tue, 26 Jan 2010 23:59:58 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id D58863A67D8 for ; Tue, 26 Jan 2010 23:59:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6190543B311; Wed, 27 Jan 2010 00:00:12 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.0.2.6] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 614CE43B310; Wed, 27 Jan 2010 00:00:11 -0800 (PST) Message-Id: <8BFA5B0D-C5DB-4388-9291-5766E579201E@thomasclausen.org> From: Thomas Heide Clausen To: Zach Shelby In-Reply-To: <8D3BEBF5-A1DC-431A-8C26-767F6A06ED5E@sensinode.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 27 Jan 2010 09:00:09 +0100 References: <8D3BEBF5-A1DC-431A-8C26-767F6A06ED5E@sensinode.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Updated ad hoc addressing model 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, 27 Jan 2010 07:59:59 -0000 Thanks, Zach, for your review. I'll add my 2 cents and exclaim satisfaction with -02 as well. I'd be happy to see this iteration go to the AD/IESG..... Thomas On Jan 27, 2010, at 8:54 AM, Zach Shelby wrote: > I took a read through -02, and the changes look fine to me. > > Zach > > On Jan 26, 2010, at 14:09 , Emmanuel Baccelli wrote: > >> Folks, >> >> here's an updated version of the ad hoc addressing model document, >> following the comments gathered during working group last call. We >> took as much as possible on board, as discussed on the mailing >> list. Please review this revision, and let us know if you have >> further comments. >> >> http://www.ietf.org/id/draft-ietf-autoconf-adhoc-addr-model-02.txt >> >> Regards, >> >> Emmanuel >> >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > -- > 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. > > > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From ryuji.wakikawa@gmail.com Wed Jan 27 00:00:06 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44AFE3A6A22 for ; Wed, 27 Jan 2010 00:00:06 -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 7Oua-rR55G4n for ; Wed, 27 Jan 2010 00:00:05 -0800 (PST) Received: from mail-yx0-f174.google.com (mail-yx0-f174.google.com [209.85.210.174]) by core3.amsl.com (Postfix) with ESMTP id 658CC3A6A1A for ; Wed, 27 Jan 2010 00:00:05 -0800 (PST) Received: by yxe4 with SMTP id 4so4156707yxe.32 for ; Wed, 27 Jan 2010 00:00:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=cOGZtvFhed3eKrfIgIFAAzxOQ9PPCId+NEWno/KoDeA=; b=YrxPTziRsOhHT9haHglMlqojgxF7GtjoSLYrc551XExVmt7MAUL8lE4vfCfngwhxmM pw3tRnpGQyEQK1rDPLQNE6snbdduX2IkB/rOc+DkWr96jTzaMVelk74BEICB/Vn/f0oO htewlvhiRAmcASjWRjFZN9UwXsA2fzB00TjH8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=ntRmo1ZBAmuRDUIXPBXA85q3ogZhiaFvTBIGzfZGT8PI+CoJIGPfx1hUFUjWvr1alW 8O8p5VW9xA23L8EzffcCfQbA0lbfIZ3GQOL2ahdnTldq4ypiwvJNxKleizeTJhl0lTeT zLnryVAfdv9eCPYAzi2YRAsP8Ha/zOsLR7oDg= Received: by 10.101.40.1 with SMTP id s1mr2093302anj.222.1264579210509; Wed, 27 Jan 2010 00:00:10 -0800 (PST) Received: from ?10.0.1.3? (c-98-248-44-75.hsd1.ca.comcast.net [98.248.44.75]) by mx.google.com with ESMTPS id 6sm2334200yxg.30.2010.01.27.00.00.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 27 Jan 2010 00:00:09 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ryuji Wakikawa In-Reply-To: Date: Wed, 27 Jan 2010 00:00:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> References: To: Emmanuel Baccelli X-Mailer: Apple Mail (2.1077) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Updated ad hoc addressing model 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, 27 Jan 2010 08:00:06 -0000 Hi all, Emmanuel updated the document according to the WG last call.=20 Please confirm the changes specially if you sent comments during WGLC. We will pass this document to Jari for the next stage soon. thanks, ryuji On 2010/01/26, at 4:09, Emmanuel Baccelli wrote: > Folks, >=20 > here's an updated version of the ad hoc addressing model document, = following the comments gathered during working group last call. We took = as much as possible on board, as discussed on the mailing list. Please = review this revision, and let us know if you have further comments. >=20 > http://www.ietf.org/id/draft-ietf-autoconf-adhoc-addr-model-02.txt >=20 > Regards, >=20 > Emmanuel >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From ryuji.wakikawa@gmail.com Wed Jan 27 00:01:03 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EA9B3A6A2D for ; Wed, 27 Jan 2010 00:01:03 -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 9-HLgwSLsQq4 for ; Wed, 27 Jan 2010 00:01:02 -0800 (PST) Received: from mail-yx0-f174.google.com (mail-yx0-f174.google.com [209.85.210.174]) by core3.amsl.com (Postfix) with ESMTP id 803FD3A67D8 for ; Wed, 27 Jan 2010 00:01:02 -0800 (PST) Received: by yxe4 with SMTP id 4so4157184yxe.32 for ; Wed, 27 Jan 2010 00:01:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=M2tUGGUhpr6sInY1V/jrOeGUHRFZQGDYWrBlPyZskKY=; b=UHo+UfVgfzGcOXA6+0KFCH30zywORtS/xhU7TXpSJ5fheae4zJ2EjwcstdhJJMy5uz naYUWukhasvE4a95gv/RPM0PA3BHKtgy+Fi+k43XwtOjWpWxxz9+1JmeY7J2dshmeoGy VN3DfH4AEyCBixtSr+v8xsb8+bKXM4evG0ewg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=QlSdCUIFTPMuDGglNH+jt31nolqGa21jqe9cwB7mq70gJ8g2NCXQnhd7TAPuBuFkIc LObf8Mx5aBqRloV84uLtHrC0FGvvCdwvuZd1jkvbyZczkDYnu6qFJpa+yxYHKJ7LUE1O FLjIZwibUL3wcHNO2y2QI0JNHLscoYODwuMkI= Received: by 10.150.103.19 with SMTP id a19mr34445ybc.177.1264579272074; Wed, 27 Jan 2010 00:01:12 -0800 (PST) Received: from ?10.0.1.3? (c-98-248-44-75.hsd1.ca.comcast.net [98.248.44.75]) by mx.google.com with ESMTPS id 6sm2334200yxg.30.2010.01.27.00.01.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 27 Jan 2010 00:01:11 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ryuji Wakikawa In-Reply-To: <8D3BEBF5-A1DC-431A-8C26-767F6A06ED5E@sensinode.com> Date: Wed, 27 Jan 2010 00:01:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9D9EC8FF-4FF0-48C2-B6D4-62381053C4A0@gmail.com> References: <8D3BEBF5-A1DC-431A-8C26-767F6A06ED5E@sensinode.com> To: Zach Shelby X-Mailer: Apple Mail (2.1077) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Updated ad hoc addressing model 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, 27 Jan 2010 08:01:03 -0000 Hi Zach, Thanks for quick review and ack to the changes. thanks, ryuji On 2010/01/26, at 23:54, Zach Shelby wrote: > I took a read through -02, and the changes look fine to me. >=20 > Zach=20 >=20 > On Jan 26, 2010, at 14:09 , Emmanuel Baccelli wrote: >=20 >> Folks, >>=20 >> here's an updated version of the ad hoc addressing model document, = following the comments gathered during working group last call. We took = as much as possible on board, as discussed on the mailing list. Please = review this revision, and let us know if you have further comments. >>=20 >> http://www.ietf.org/id/draft-ietf-autoconf-adhoc-addr-model-02.txt >>=20 >> Regards, >>=20 >> Emmanuel >>=20 >>=20 >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >=20 > --=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 >=20 > Zach Shelby > Head of Research > Sensinode Ltd. > Kidekuja 2 > 88610 Vuokatti, FINLAND >=20 > 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 >=20 >=20 >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From ulrich@herberg.name Wed Jan 27 00:43:37 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B37FF3A687F for ; Wed, 27 Jan 2010 00:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mud7vUYDOwzR for ; Wed, 27 Jan 2010 00:43:36 -0800 (PST) Received: from mail-bw0-f224.google.com (mail-bw0-f224.google.com [209.85.218.224]) by core3.amsl.com (Postfix) with ESMTP id 41B9C3A6891 for ; Wed, 27 Jan 2010 00:43:35 -0800 (PST) Received: by bwz24 with SMTP id 24so1723422bwz.29 for ; Wed, 27 Jan 2010 00:43:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.25.209 with SMTP id a17mr1936768bkc.104.1264581825472; Wed, 27 Jan 2010 00:43:45 -0800 (PST) In-Reply-To: <8D3BEBF5-A1DC-431A-8C26-767F6A06ED5E@sensinode.com> References: <8D3BEBF5-A1DC-431A-8C26-767F6A06ED5E@sensinode.com> Date: Wed, 27 Jan 2010 09:43:43 +0100 Message-ID: <25c114b91001270043r64d20dbbj722cdb1202a3eae8@mail.gmail.com> From: Ulrich Herberg To: Zach Shelby Content-Type: multipart/alternative; boundary=000325557e1e7f4849047e216633 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Updated ad hoc addressing model 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, 27 Jan 2010 08:43:37 -0000 --000325557e1e7f4849047e216633 Content-Type: text/plain; charset=ISO-8859-1 Same for me, I agree with the text. Ulrich On Wed, Jan 27, 2010 at 8:54 AM, Zach Shelby wrote: > I took a read through -02, and the changes look fine to me. > > Zach > > On Jan 26, 2010, at 14:09 , Emmanuel Baccelli wrote: > > > Folks, > > > > here's an updated version of the ad hoc addressing model document, > following the comments gathered during working group last call. We took as > much as possible on board, as discussed on the mailing list. Please review > this revision, and let us know if you have further comments. > > > > http://www.ietf.org/id/draft-ietf-autoconf-adhoc-addr-model-02.txt > > > > Regards, > > > > Emmanuel > > > > > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www.ietf.org/mailman/listinfo/autoconf > > -- > 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. > > > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > --000325557e1e7f4849047e216633 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Same for me, I agree with the text.

Ulrich

On Wed, Jan 27, 2010 at 8:54 AM, Zach Shelby <= ;zach@sensinode.com> wr= ote:
I took a read thr= ough -02, and the changes look fine to me.

Zach

On Jan 26, 2010, at 14:09 , Emmanuel Baccelli wrote:

> Folks,
>
> here's an updated version of the ad hoc addressing model document,= following the comments gathered during working group last call. We took as= much as possible on board, as discussed on the mailing list. Please review= this revision, and let us know if you have further comments.
>
> http://www.ietf.org/id/draft-ietf-autoconf-adhoc= -addr-model-02.txt
>
> Regards,
>
> Emmanuel
>
>
> _______________________________________________
> Autoconf mailing list
> Autoconf@ietf.org
> https://www.ietf.org/mailman/listinfo/autoconf

--
http://www.sensinode= .com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - N= ew 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 lega= lly privileged information. If you are not the intended recipient, please c= ontact the sender and delete the e-mail from your system without producing,= distributing or retaining copies thereof.




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

--000325557e1e7f4849047e216633-- From teco@inf-net.nl Fri Jan 29 08:13:38 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A15D3A6A0D for ; Fri, 29 Jan 2010 08:13:38 -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 TAIAqp73GSCN for ; Fri, 29 Jan 2010 08:13:37 -0800 (PST) Received: from CPSMTPM-EML103.kpnxchange.com (cpsmtpm-eml103.kpnxchange.com [195.121.3.7]) by core3.amsl.com (Postfix) with ESMTP id ABAA33A67EB for ; Fri, 29 Jan 2010 08:13:36 -0800 (PST) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML103.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Fri, 29 Jan 2010 17:13:57 +0100 From: "Teco Boot" To: "'Ryuji Wakikawa'" , "'Thomas Heide Clausen'" References: <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> In-Reply-To: <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> Date: Fri, 29 Jan 2010 17:13:56 +0100 Message-ID: <008c01caa0fe$0eee3530$2cca9f90$@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: AcqfJsecKWOYyKMoT7m7h/CJlr9R0wB09LDg Content-Language: nl X-OriginalArrivalTime: 29 Jan 2010 16:13:57.0156 (UTC) FILETIME=[0F415E40:01CAA0FE] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Updated ad hoc addressing model 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: Fri, 29 Jan 2010 16:13:38 -0000 Ryuji, Thomas, I commented on the document. I don't see any reflection in the document, nor received questions for clarification. I am quite uncomfortable with a large drawback of the proposed addressing model, which makes it unacceptable for the deployed MANETs I am involved in. My requirement is that L3 communication between nodes, that have L2 connectivity, must be possible in all conditions, including conditions with a non-operational MANET protocol. Maybe this drawback is overlooked or underestimated. And the text on link locals does not describe how IPv6 works. LLs are used in MANETs for multiple purposes. We can't without. My other comments are textual or on incompleteness. Especially, the document doesn't describe anything useful for assigning globals. Regards, Teco >-----Oorspronkelijk bericht----- >Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens >Ryuji Wakikawa >Verzonden: woensdag 27 januari 2010 9:00 >Aan: Emmanuel Baccelli >CC: autoconf@ietf.org >Onderwerp: Re: [Autoconf] Updated ad hoc addressing model document > >Hi all, > >Emmanuel updated the document according to the WG last call. >Please confirm the changes specially if you sent comments during WGLC. > >We will pass this document to Jari for the next stage soon. > >thanks, >ryuji > > >On 2010/01/26, at 4:09, Emmanuel Baccelli wrote: > >> Folks, >> >> here's an updated version of the ad hoc addressing model document, >following the comments gathered during working group last call. We took >as much as possible on board, as discussed on the mailing list. Please >review this revision, and let us know if you have further comments. >> >> http://www.ietf.org/id/draft-ietf-autoconf-adhoc-addr-model-02.txt >> >> Regards, >> >> Emmanuel >> >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > >_______________________________________________ >Autoconf mailing list >Autoconf@ietf.org >https://www.ietf.org/mailman/listinfo/autoconf From charles.perkins@earthlink.net Fri Jan 29 09:10:33 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64D043A6A55 for ; Fri, 29 Jan 2010 09:10:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PA8QqTo7J+z for ; Fri, 29 Jan 2010 09:10:32 -0800 (PST) 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 239EA3A6A4F for ; Fri, 29 Jan 2010 09:10:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=HpLrE2wTqFY3IS8CDMfK3gj3JoTv7lNl6BJwDRrYgogIhJ4g943uhUbuZ1jOtj9r; 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 1NauMu-00011O-G1; Fri, 29 Jan 2010 12:10:52 -0500 Message-ID: <4B631699.7040504@earthlink.net> Date: Fri, 29 Jan 2010 09:10:49 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Teco Boot References: <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> <008c01caa0fe$0eee3530$2cca9f90$@nl> In-Reply-To: <008c01caa0fe$0eee3530$2cca9f90$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52ebb43ebc1bfe3012062c88a9b2d2eb4c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org, 'Thomas Heide Clausen' Subject: Re: [Autoconf] Updated ad hoc addressing model 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: Fri, 29 Jan 2010 17:10:34 -0000 Hello Teco, On 1/29/2010 8:13 AM, Teco Boot wrote: > I am quite uncomfortable with a large drawback of the proposed > addressing model, which makes it unacceptable for the deployed MANETs > I am involved in. > My requirement is that L3 communication between nodes, that have L2 > connectivity, must be possible in all conditions, including conditions > with a non-operational MANET protocol. > I don't see that the addressing model prevents any such L3 communication. > Maybe this drawback is overlooked or underestimated. > It doesn't even seem to be a drawback at all as far as I can tell. > And the text on link locals does not describe how IPv6 works. LLs are > used in MANETs for multiple purposes. We can't without. > This isn't true. You can build MANETs without using link-local at all in any fashion. I'm not saying you have to ignore link-local. > My other comments are textual or on incompleteness. Especially, the > document doesn't describe anything useful for assigning globals. > Yeah, it would be nice if we could get to the point of doing address autoconfiguration in this group. Regards, Charlie P. From teco@inf-net.nl Fri Jan 29 10:04:25 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 319E23A659C for ; Fri, 29 Jan 2010 10:04:25 -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 7IjKCOJs+O1B for ; Fri, 29 Jan 2010 10:04:24 -0800 (PST) Received: from CPSMTPM-EML107.kpnxchange.com (Cpsmtpm-eml107.kpnxchange.com [195.121.3.11]) by core3.amsl.com (Postfix) with ESMTP id 208733A6452 for ; Fri, 29 Jan 2010 10:04:23 -0800 (PST) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML107.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Fri, 29 Jan 2010 19:04:41 +0100 From: "Teco Boot" To: "'Charles E. Perkins'" References: <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> <008c01caa0fe$0eee3530$2cca9f90$@nl> <4B631699.7040504@earthlink.net> In-Reply-To: <4B631699.7040504@earthlink.net> Date: Fri, 29 Jan 2010 19:04:40 +0100 Message-ID: <009001caa10d$8729a2a0$957ce7e0$@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: AcqhBgPaM7j/smATS+eTIrDKEVYMWwABoifw Content-Language: nl X-OriginalArrivalTime: 29 Jan 2010 18:04:41.0432 (UTC) FILETIME=[878D6D80:01CAA10D] Cc: autoconf@ietf.org, 'Thomas Heide Clausen' Subject: Re: [Autoconf] Updated ad hoc addressing model 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: Fri, 29 Jan 2010 18:04:25 -0000 Hi Charlie, >> I am quite uncomfortable with a large drawback of the proposed >> addressing model, which makes it unacceptable for the deployed MANETs >> I am involved in. >> My requirement is that L3 communication between nodes, that have L2 >> connectivity, must be possible in all conditions, including conditions >> with a non-operational MANET protocol. >> > >I don't see that the addressing model prevents any such L3 >communication. How are packets forwarded? The destination address (which is direct L2 neighbor in this case) needs to be found in a forwarding table, normally the routing table. Neighbor cache could be used also. How to get this info in such a table? >> And the text on link locals does not describe how IPv6 works. LLs are >> used in MANETs for multiple purposes. We can't without. >> > >This isn't true. You can build MANETs without using link-local at all >in any fashion. > >I'm not saying you have to ignore link-local. If LLs are configured, they are used for L2 address resolving. Also for MANET protocols, if destination address is LL mcast. One can think of updating the IPv6 RFCs. I'll stay on current practice. Regards, Teco From Fred.L.Templin@boeing.com Fri Jan 29 10:10:15 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0B033A67E5 for ; Fri, 29 Jan 2010 10:10:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 1j3zC-ouuzZc for ; Fri, 29 Jan 2010 10:10:13 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id DD0893A67B6 for ; Fri, 29 Jan 2010 10:10:12 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id o0TIAUvT009564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 29 Jan 2010 10:10:31 -0800 (PST) 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 o0TIAUaP017631; Fri, 29 Jan 2010 12:10:30 -0600 (CST) Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id o0TIATml017584 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 29 Jan 2010 12:10:29 -0600 (CST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Fri, 29 Jan 2010 10:10:29 -0800 From: "Templin, Fred L" To: Teco Boot , "'Charles E. Perkins'" Date: Fri, 29 Jan 2010 10:10:28 -0800 Thread-Topic: [Autoconf] Updated ad hoc addressing model document Thread-Index: AcqhBgPaM7j/smATS+eTIrDKEVYMWwABoifwAABbvoA= Message-ID: References: <8DC BF4A4-7879-4148-A8FE-9A73219536B9@gmail.com><008c01caa0fe$0eee3530$2cca9f90$@nl><4B631699.7040504@earthlink.net> <009001caa10d$8729a2a0$957ce7e0$@nl> In-Reply-To: <009001caa10d$8729a2a0$957ce7e0$@nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "autoconf@ietf.org" , 'Thomas Heide Clausen' Subject: Re: [Autoconf] Updated ad hoc addressing model 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: Fri, 29 Jan 2010 18:10:15 -0000 > -----Original Message----- > From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On Beh= alf Of Teco Boot > Sent: Friday, January 29, 2010 10:05 AM > To: 'Charles E. Perkins' > Cc: autoconf@ietf.org; 'Thomas Heide Clausen' > Subject: Re: [Autoconf] Updated ad hoc addressing model document >=20 > Hi Charlie, >=20 > >> I am quite uncomfortable with a large drawback of the proposed > >> addressing model, which makes it unacceptable for the deployed MANETs > >> I am involved in. > >> My requirement is that L3 communication between nodes, that have L2 > >> connectivity, must be possible in all conditions, including conditions > >> with a non-operational MANET protocol. > >> > > > >I don't see that the addressing model prevents any such L3 > >communication. >=20 > How are packets forwarded? > The destination address (which is direct L2 neighbor in this case) > needs to be found in a forwarding table, normally the routing table. > Neighbor cache could be used also. > How to get this info in such a table? >=20 >=20 > >> And the text on link locals does not describe how IPv6 works. LLs are > >> used in MANETs for multiple purposes. We can't without. > >> > > > >This isn't true. You can build MANETs without using link-local at all > >in any fashion. > > > >I'm not saying you have to ignore link-local. >=20 > If LLs are configured, they are used for L2 address resolving. > Also for MANET protocols, if destination address is LL mcast. > One can think of updating the IPv6 RFCs. I'll stay on current > practice. I believe OSPFv3 for one is going to need link-locals when it is used as a MANET routing protocol. (That is not to say that OSPFv3 can only carry IPv6 routes; it can also use Address Family extensions to carry IPv4 routes.) Fred fred.l.templin@boeing.com =20 > Regards, Teco >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From charles.perkins@earthlink.net Fri Jan 29 12:40:40 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2AB63A68D3 for ; Fri, 29 Jan 2010 12:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7RVrU+TlHDO for ; Fri, 29 Jan 2010 12:40:40 -0800 (PST) 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 12D0E3A688B for ; Fri, 29 Jan 2010 12:40:39 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=tcNx1kEJUdgU5uRIulFAId5amMFL00wH9ATmJtP0HFW08Fl+gp3bbXCducgMsMM3; 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 1NaxeG-00030B-OQ; Fri, 29 Jan 2010 15:41:00 -0500 Message-ID: <4B6347DA.1040004@earthlink.net> Date: Fri, 29 Jan 2010 12:40:58 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Teco Boot References: <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> <008c01caa0fe$0eee3530$2cca9f90$@nl> <4B631699.7040504@earthlink.net> <009001caa10d$8729a2a0$957ce7e0$@nl> In-Reply-To: <009001caa10d$8729a2a0$957ce7e0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f525627e5f2a4b2b772ffdcaa4e35839966350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org, 'Thomas Heide Clausen' Subject: Re: [Autoconf] Updated ad hoc addressing model 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: Fri, 29 Jan 2010 20:40:41 -0000 Hello Teco, On 1/29/2010 10:04 AM, Teco Boot wrote: > >>> My requirement is that L3 communication between nodes, that have L2 >>> connectivity, must be possible in all conditions, including conditions >>> with a non-operational MANET protocol. >>> >>> >> I don't see that the addressing model prevents any such L3 >> communication. >> > How are packets forwarded? > The destination address (which is direct L2 neighbor in this case) > needs to be found in a forwarding table, normally the routing table. > Neighbor cache could be used also. > How to get this info in such a table? > Node A broadcasts a "Hello" message. Node B hears it, and puts node A in its forwarding table. The nodes may take subsequent actions to verify bidirectionality, exchange other table entries, etc. > >>> And the text on link locals does not describe how IPv6 works. LLs are >>> used in MANETs for multiple purposes. We can't without. >>> >>> >> This isn't true. You can build MANETs without using link-local at all >> in any fashion. >> >> I'm not saying you have to ignore link-local. >> > If LLs are configured, they are used for L2 address resolving. > Also for MANET protocols, if destination address is LL mcast. > O.K. > One can think of updating the IPv6 RFCs. I'll stay on current > practice. > Me, too. Current practice includes running AODV and OLSR and DYMO. One should think of updating the IPv6 RFCs, since the link-local constructions contained therein were written _explicitly_ in disregard of the needs for wireless links of the sort familiar to practitioners in this group. I was there. I remember very well the meeting in Boston where this happened. Regards, Charlie P. From charles.perkins@earthlink.net Fri Jan 29 12:46:35 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4E753A683C for ; Fri, 29 Jan 2010 12:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LfdFMezBSEI for ; Fri, 29 Jan 2010 12:46:33 -0800 (PST) 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 C5D133A659A for ; Fri, 29 Jan 2010 12:46:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=VEoWTrXqvLRnJOFL4s7RaWxJNSriwvv7Kt7Ii0hGgWmhzHroYKZV/AE4NWF9DdrJ; 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 1Naxjz-0007fL-TO; Fri, 29 Jan 2010 15:46:56 -0500 Message-ID: <4B63493E.7050705@earthlink.net> Date: Fri, 29 Jan 2010 12:46:54 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: "Templin, Fred L" References: <8DC BF4A4-7879-4148-A8FE-9A73219536B9@gmail.com><008c01caa0fe$0eee3530$2cca9f90$@nl><4B631699.7040504@earthlink.net> <009001caa10d$8729a2a0$957ce7e0$@nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f523a193a17d99e199047eef23d00da9079350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: "autoconf@ietf.org" , 'Thomas Heide Clausen' Subject: Re: [Autoconf] Updated ad hoc addressing model 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: Fri, 29 Jan 2010 20:46:36 -0000 Hello Fred, On 1/29/2010 10:10 AM, Templin, Fred L wrote: > > I believe OSPFv3 for one is going to need link-locals > when it is used as a MANET routing protocol. (That is > not to say that OSPFv3 can only carry IPv6 routes; it > can also use Address Family extensions to carry IPv4 > routes.) > I'd like to see how they are going to do it. For all the discussion about how some people really really need link-locals, I somehow missed the part about how they were really going to be able to do it -- except under highly restrictive circumstances (e.g., single hop from backbone, ...). But, full disclosure here, I didn't follow the OSPF effort very well. At one point, when I was paying attention, it seemed to me that they were trying to do the right thing. Regards, Charlie P. From charles.perkins@earthlink.net Fri Jan 29 13:02:46 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2B7B3A6889 for ; Fri, 29 Jan 2010 13:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gw7jXtp9pQj8 for ; Fri, 29 Jan 2010 13:02:45 -0800 (PST) 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 2149B3A659A for ; Fri, 29 Jan 2010 13:02:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=kfZtpCOFjrX60n26fPWhEehB3RFZFq8/cjrEKcmlnltAkX/tHy5zZSG67uXWHQU2; 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 1Naxzf-0004mS-VO; Fri, 29 Jan 2010 16:03:08 -0500 Message-ID: <4B634D09.4090201@earthlink.net> Date: Fri, 29 Jan 2010 13:03:05 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: "Templin, Fred L" References: <8DC BF4A4-7879-4148-A8FE-9A73219536B9@gmail.com><008c01caa0fe$0eee3530$2cca9f90$@nl><4B631699.7040504@earthlink.net> <009001caa10d$8729a2a0$957ce7e0$@nl> <4B63493E.7050705@earthlink.net> In-Reply-To: <4B63493E.7050705@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52d751f736a17f551853fcb8f82c3a39ae350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: "autoconf@ietf.org" , 'Thomas Heide Clausen' Subject: Re: [Autoconf] Updated ad hoc addressing model 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: Fri, 29 Jan 2010 21:02:46 -0000 Hello again folks, I should have mentioned that, of course, link-locals work great with almost no effort, if one can assume unique L2 addresses. Mea culpa! And, as I mentioned before, I think it would be a really good idea for link-local proponents to write up a document (perhaps only one paragraph) saying pretty much exactly that. Regards, Charlie P. On 1/29/2010 12:46 PM, Charles E. Perkins wrote: > > Hello Fred, > > On 1/29/2010 10:10 AM, Templin, Fred L wrote: >> >> I believe OSPFv3 for one is going to need link-locals >> when it is used as a MANET routing protocol. (That is >> not to say that OSPFv3 can only carry IPv6 routes; it >> can also use Address Family extensions to carry IPv4 >> routes.) > > I'd like to see how they are going to do it. > > For all the discussion about how some people really > really need link-locals, I somehow missed the part > about how they were really going to be able to do > it -- except under highly restrictive circumstances > (e.g., single hop from backbone, ...). But, full disclosure > here, I didn't follow the OSPF effort very well. At one > point, when I was paying attention, it seemed to me that > they were trying to do the right thing. > > Regards, > Charlie P. > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From teco@inf-net.nl Sat Jan 30 03:21:41 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1016B3A67F6 for ; Sat, 30 Jan 2010 03:21:41 -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 O8iirRlHCkGn for ; Sat, 30 Jan 2010 03:21:40 -0800 (PST) Received: from CPSMTPM-EML102.kpnxchange.com (cpsmtpm-eml102.kpnxchange.com [195.121.3.6]) by core3.amsl.com (Postfix) with ESMTP id 9C8D93A67AB for ; Sat, 30 Jan 2010 03:21:38 -0800 (PST) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML102.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Sat, 30 Jan 2010 12:22:03 +0100 From: "Teco Boot" To: "'Charles E. Perkins'" References: <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> <008c01caa0fe$0eee3530$2cca9f90$@nl> <4B631699.7040504@earthlink.net> <009001caa10d$8729a2a0$957ce7e0$@nl> <4B6347DA.1040004@earthlink.net> In-Reply-To: <4B6347DA.1040004@earthlink.net> Date: Sat, 30 Jan 2010 12:22:00 +0100 Message-ID: <00a601caa19e$7122c810$53685830$@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: AcqhI2CYrfC3lkyqSIm4UUM5KirB6AAegQTA Content-Language: nl X-OriginalArrivalTime: 30 Jan 2010 11:22:03.0481 (UTC) FILETIME=[72B46490:01CAA19E] Cc: autoconf@ietf.org, 'Thomas Heide Clausen' Subject: Re: [Autoconf] Updated ad hoc addressing model 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: Sat, 30 Jan 2010 11:21:41 -0000 Charlie, >>>> My requirement is that L3 communication between nodes, that have L2 >>>> connectivity, must be possible in all conditions, including >conditions >>>> with a non-operational MANET protocol. >>>> >>>> >>> I don't see that the addressing model prevents any such L3 >>> communication. >>> >> How are packets forwarded? >> The destination address (which is direct L2 neighbor in this case) >> needs to be found in a forwarding table, normally the routing table. >> Neighbor cache could be used also. >> How to get this info in such a table? >> > >Node A broadcasts a "Hello" message. >Node B hears it, and puts node A in its forwarding table. > >The nodes may take subsequent actions to verify >bidirectionality, exchange other table entries, etc. My point is that L3 communication becomes dependent on a L3 routing protocol. We didn't have this in the IP stack before. >>>> And the text on link locals does not describe how IPv6 works. LLs >are >>>> used in MANETs for multiple purposes. We can't without. >>>> >>>> >>> This isn't true. You can build MANETs without using link-local at >all >>> in any fashion. >>> >>> I'm not saying you have to ignore link-local. >>> >> If LLs are configured, they are used for L2 address resolving. >> Also for MANET protocols, if destination address is LL mcast. >> > >O.K. > >> One can think of updating the IPv6 RFCs. I'll stay on current >> practice. >> > >Me, too. > >Current practice includes running AODV and OLSR and DYMO. These protocols use link-locals, when RFC5498 and RFC3484 are implemented. >One should think of updating the IPv6 RFCs, since the link-local >constructions contained therein were written _explicitly_ in >disregard of the needs for wireless links of the sort familiar to >practitioners in this group. I use link-locals on wireless links, and it works great. What is your point? Regards, Teco. From teco@inf-net.nl Sat Jan 30 03:26:51 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8C6F3A67AB for ; Sat, 30 Jan 2010 03:26:51 -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=[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 A9iuGCDz17ZP for ; Sat, 30 Jan 2010 03:26:51 -0800 (PST) Received: from CPSMTPM-EML104.kpnxchange.com (cpsmtpm-eml104.kpnxchange.com [195.121.3.8]) by core3.amsl.com (Postfix) with ESMTP id 7F9F63A67F8 for ; Sat, 30 Jan 2010 03:26:50 -0800 (PST) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML104.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Sat, 30 Jan 2010 12:27:15 +0100 From: "Teco Boot" To: "'Charles E. Perkins'" References: <8DC BF4A4-7879-4148-A8FE-9A73219536B9@gmail.com><008c01caa0fe$0eee3530$2cca9f90$@nl><4B631699.7040504@earthlink.net> <009001caa10d$8729a2a0$957ce7e0$@nl> <4B63493E.7050705@earthlink.net> <4B634D09.4090201@earthlink.net> In-Reply-To: <4B634D09.4090201@earthlink.net> Date: Sat, 30 Jan 2010 12:27:12 +0100 Message-ID: <00a701caa19f$2ae7b260$80b71720$@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: AcqhJnu4yJUYdduiQRqgywM6+QwV7AAeCG6A Content-Language: nl X-OriginalArrivalTime: 30 Jan 2010 11:27:15.0245 (UTC) FILETIME=[2C87CDD0:01CAA19F] Cc: autoconf@ietf.org, 'Thomas Heide Clausen' Subject: Re: [Autoconf] Updated ad hoc addressing model 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: Sat, 30 Jan 2010 11:26:51 -0000 Hi Charlie, I think you overlook something. Getting unique addresses applies to any address that should be unique :-). Why could we assume that non-link-local addresses work great with almost no effort? Regards, Teco >-----Oorspronkelijk bericht----- >Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens >Charles E. Perkins >Verzonden: vrijdag 29 januari 2010 22:03 >Aan: Templin, Fred L >CC: autoconf@ietf.org; 'Thomas Heide Clausen' >Onderwerp: Re: [Autoconf] Updated ad hoc addressing model document > > >Hello again folks, > >I should have mentioned that, of course, link-locals >work great with almost no effort, if one can assume >unique L2 addresses. Mea culpa! > >And, as I mentioned before, I think it would be a >really good idea for link-local proponents to write >up a document (perhaps only one paragraph) >saying pretty much exactly that. > >Regards, >Charlie P. > > >On 1/29/2010 12:46 PM, Charles E. Perkins wrote: >> >> Hello Fred, >> >> On 1/29/2010 10:10 AM, Templin, Fred L wrote: >>> >>> I believe OSPFv3 for one is going to need link-locals >>> when it is used as a MANET routing protocol. (That is >>> not to say that OSPFv3 can only carry IPv6 routes; it >>> can also use Address Family extensions to carry IPv4 >>> routes.) >> >> I'd like to see how they are going to do it. >> >> For all the discussion about how some people really >> really need link-locals, I somehow missed the part >> about how they were really going to be able to do >> it -- except under highly restrictive circumstances >> (e.g., single hop from backbone, ...). But, full disclosure >> here, I didn't follow the OSPF effort very well. At one >> point, when I was paying attention, it seemed to me that >> they were trying to do the right thing. >> >> 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