From autoconf-bounces@ietf.org Sun Nov 2 00:27:50 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7835D3A6872; Sun, 2 Nov 2008 00:27:50 -0700 (PDT) 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 AA5AF3A6936; Sun, 2 Nov 2008 00:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.703 X-Spam-Level: X-Spam-Status: No, score=-1.703 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 twwj5796CBDW; Sun, 2 Nov 2008 00:27:49 -0700 (PDT) Received: from hpsmtp-eml19.kpnxchange.com (hpsmtp-eml19.KPNXCHANGE.COM [213.75.38.84]) by core3.amsl.com (Postfix) with ESMTP id AEAF73A6872; Sun, 2 Nov 2008 00:27:48 -0700 (PDT) Received: from cpsmtpi-eml06.kpnxchange.com ([213.75.38.136]) by hpsmtp-eml19.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 2 Nov 2008 08:27:43 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtpi-eml06.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 2 Nov 2008 08:27:43 +0100 From: "Teco Boot" To: "'manet'" , Date: Sun, 2 Nov 2008 08:27:33 +0100 Message-ID: <00f601c93cbc$7a4fad10$6eef0730$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ack8vHjvy2ALVhmIQDaA3XeRBwNxxQ== Content-Language: nl X-OriginalArrivalTime: 02 Nov 2008 07:27:43.0881 (UTC) FILETIME=[7EFD2F90:01C93CBC] Subject: [Autoconf] New BRDP drafts 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org All, A new version of I-D.boot-autoconf-brdp-01.txt is posted: http://tools.ietf.org/id/draft-boot-autoconf-brdp-01.txt I've still some problems posting the BRDP Based Routing I-D. It can be accessed on: http://www.inf-net.nl/draft-boot-brdp-based-routing-00.txt Draft presentation on BRDP Based Routing: http://www.inf-net.nl/BRDP%20based%20routing%20-%20RRG.pdf Comments welcome, especially on the BRDP Based Routing idea. Cheers, Teco ------------ Abstract draft-boot-autoconf-brdp-01.txt: Mobile Ad hoc Networks (MANET) may be attached to a fixed infrastructure network, like the Internet. This document specifies a mechanism for Border Router discovery and utilization in such a subordinate, possibly multi-homed, MANET. It provides facilities for choosing preferred Border Router(s) and configuring IP address(es) needed for communication between MANET nodes and nodes on the Internet via the selected Border Router. Autonomous MANETs do not have Border Routers; an self-sufficient Address Autoconfiguration is defined as well. Abstract draft-boot-brdp-based-routing-00.txt: This document specifies a mechanism for routing in multi-homed access networks. The default gateway routing mechanism is replaced with routing to Border Routers that correspond with the source address of the packets. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 3 15:43:11 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCF8828C39D; Mon, 3 Nov 2008 15:43:11 -0800 (PST) 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 E3E0428C39D for ; Mon, 3 Nov 2008 15:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPe0PM3CNgV6 for ; Mon, 3 Nov 2008 15:43:10 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 0159F28C2FB for ; Mon, 3 Nov 2008 15:43:09 -0800 (PST) Received: from [192.168.0.10] (82.159.25.132.dyn.user.ono.com [82.159.25.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id D1EC85CA0E5 for ; Tue, 4 Nov 2008 00:34:59 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: autoconf@ietf.org Organization: Universidad Carlos III de Madrid Date: Tue, 04 Nov 2008 00:34:56 +0100 Message-Id: <1225755296.4976.15.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: [Autoconf] Is autoconf meeting in Minneapolis? X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1756575963==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============1756575963== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-7+L2pPchHDhufEWvQXf4" --=-7+L2pPchHDhufEWvQXf4 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi, Is autoconf meeting this time? have been any progress since Dublin in the manetarch issue? Thanks! Carlos --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2009: 2nd Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-7+L2pPchHDhufEWvQXf4 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkkPiqAACgkQNdy6TdFwT2cBwwCeN6BIBNAP5IDfBcwB55M/J5w0 VDcAn37NWvmp4Sl0NketKnuUAm87Yoxx =22jQ -----END PGP SIGNATURE----- --=-7+L2pPchHDhufEWvQXf4-- --===============1756575963== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf --===============1756575963==-- From autoconf-bounces@ietf.org Tue Nov 4 01:51:05 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4F163A693C; Tue, 4 Nov 2008 01:51:05 -0800 (PST) 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 D62673A693C for ; Tue, 4 Nov 2008 01:51:04 -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 jclKPuCAWbmc for ; Tue, 4 Nov 2008 01:51:04 -0800 (PST) Received: from mho-02-bos.mailhop.org (mho-02-bos.mailhop.org [63.208.196.179]) by core3.amsl.com (Postfix) with ESMTP id 00A053A6912 for ; Tue, 4 Nov 2008 01:51:03 -0800 (PST) Received: from aste-genev-bois-153-1-97-110.w86-218.abo.wanadoo.fr ([86.218.123.110] helo=[192.168.147.109]) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1KxIYu-000Osc-JP for autoconf@ietf.org; Tue, 04 Nov 2008 09:51:00 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 86.218.123.110 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+ke/Tm8UiS5DZvEaypgdON Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: To: autoconf@ietf.org From: Thomas Heide Clausen Date: Tue, 4 Nov 2008 10:51:09 +0100 X-Mailer: Apple Mail (2.753.1) Subject: [Autoconf] draft-clausen-manet-linktype 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Folks, As you know, we need to make progress on the architectural issues, before we can hope to make progress on other matters within this WG. One of the requests that have been made to us has been to "describe the MANET Link Type", and so I have written together a strawman text to this effect: http://www.ietf.org/internet-drafts/draft-clausen-manet-linktype-00.txt Feedback is, obviously, welcome -- preferably on the list such that we could be prepared spend time on this also in MN. Note, however, that this is an individual I-D. I'd also like to draw your collective attention to: http://www.ietf.org/internet-drafts/draft-iab-ip-model-evolution-01.txt Which has served as a source of inspiration for the linktype text. Thanks, Thomas _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 5 23:51:13 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FE313A697B; Wed, 5 Nov 2008 23:51:13 -0800 (PST) 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 EE3203A697B for ; Wed, 5 Nov 2008 23:51:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7tzMpr8DuhE for ; Wed, 5 Nov 2008 23:51:11 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id EE0B23A682C for ; Wed, 5 Nov 2008 23:51:10 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so525090wfd.31 for ; Wed, 05 Nov 2008 23:51:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=BXhJ54/M1ndDRL/WR1gRB5uOyd75XUQPj/wxLgF+EPA=; b=ptQZwoArJ1YLU1DMOP7qFIzKObwAFFtW8RTH0T5fDPhd6PYWjGmU3Zt+Fs62rkhtcV z5ixnpYYZ7zUegoMQqzIJRCyDItBshr9vSp38Aw1C3/r4U8GaU1Sh2gYdaHp0+tjDBXv z38F8QZ1WLhARul2Lwxz10gjScbR3Iva15FOo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ZyWN0A+PxvSdgaXV74Ew2KR2tVfwIXOAg+6T+1ojp/D0yziLKVRN0bFgcs5KsfEMLJ vF8s3QYeeH7oUNa4J+wViP7Qi/tNOSoWSC18x+Z+dzpJfy5eZf4rtfRXoNmCM85XhY+3 YJ6w7sukDH5tK1Y8yOwrxxnliQ2xspGYDouIg= Received: by 10.143.19.16 with SMTP id w16mr305187wfi.200.1225957867753; Wed, 05 Nov 2008 23:51:07 -0800 (PST) Received: by 10.142.88.7 with HTTP; Wed, 5 Nov 2008 23:51:07 -0800 (PST) Message-ID: Date: Thu, 6 Nov 2008 13:21:07 +0530 From: Shubhranshu To: cjbc@it.uc3m.es In-Reply-To: <1225755296.4976.15.camel@localhost> MIME-Version: 1.0 Content-Disposition: inline References: <1225755296.4976.15.camel@localhost> Cc: autoconf@ietf.org Subject: Re: [Autoconf] Is autoconf meeting in Minneapolis? 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello Carlos, All, Autoconf WG has been scheduled on Tuesday, November 18, 2008 1520-1700 Afternoon Session II, Salon G. Refer to https://datatracker.ietf.org/meeting/73/agenda.html We'd like to spend considerable amount of the meeting time on architectural discussions, please refer to draft-clausen-manet-linktype and draft-ietf-autoconf-manetarch-07 Also, let us know if you have any related agenda item that you would like to discuss during the meeting. - Shubhranshu 2008/11/4 Carlos Jes=FAs Bernardos Cano : > Hi, > > Is autoconf meeting this time? have been any progress since Dublin= in > the manetarch issue? > > Thanks! > > Carlos > > -- > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > WEEDEV 2009: 2nd Workshop on Experimental Evaluation and > Deployment Experiences on Vehicular networks > http://www.weedev.org/ > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > _______________________________________________ > 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 autoconf-bounces@ietf.org Mon Nov 10 10:55:16 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DF9B28C11A; Mon, 10 Nov 2008 10:55:16 -0800 (PST) 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 DF78928C11A for ; Mon, 10 Nov 2008 10:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.395 X-Spam-Level: X-Spam-Status: No, score=-3.395 tagged_above=-999 required=5 tests=[AWL=2.304, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCrF0EfJr7vy for ; Mon, 10 Nov 2008 10:55:13 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 7F3F43A6A73 for ; Mon, 10 Nov 2008 10:55:13 -0800 (PST) Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id D72C2ACAC97; Mon, 10 Nov 2008 19:55:08 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Shubhranshu In-Reply-To: References: <1225755296.4976.15.camel@localhost> Organization: Universidad Carlos III de Madrid Date: Mon, 10 Nov 2008 19:55:08 +0100 Message-Id: <1226343308.4806.78.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Is autoconf meeting in Minneapolis? X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0098107736==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============0098107736== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-NUdHjqEbXAVzAgslR5Wg" --=-NUdHjqEbXAVzAgslR5Wg Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Shubranshu, all, El jue, 06-11-2008 a las 13:21 +0530, Shubhranshu escribi=F3: > Hello Carlos, All, >=20 > Autoconf WG has been scheduled on Tuesday, November 18, 2008 1520-1700 > Afternoon Session II, Salon G. Refer to > https://datatracker.ietf.org/meeting/73/agenda.html >=20 > We'd like to spend considerable amount of the meeting time on > architectural discussions, please refer to > draft-clausen-manet-linktype and draft-ietf-autoconf-manetarch-07 >=20 > Also, let us know if you have any related agenda item that you would > like to discuss during the meeting. I agree we should focus on the architectural discussions. Unless we move forward on that direction, nothing else can happen. Kind Regards, Carlos >=20 > - Shubhranshu >=20 >=20 > 2008/11/4 Carlos Jes=FAs Bernardos Cano : > > Hi, > > > > Is autoconf meeting this time? have been any progress since Dubl= in in > > the manetarch issue? > > > > Thanks! > > > > Carlos > > > > -- > > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > WEEDEV 2009: 2nd Workshop on Experimental Evaluation and > > Deployment Experiences on Vehicular networks > > http://www.weedev.org/ > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www.ietf.org/mailman/listinfo/autoconf > > > > --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2009: 2nd Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-NUdHjqEbXAVzAgslR5Wg Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkkYg4wACgkQNdy6TdFwT2fMbgCdGZuUgPEdzdxCJ14R/w5umS+E Z6UAn2j8++b/KETQA5fV5/0LxegIJUdD =NDXL -----END PGP SIGNATURE----- --=-NUdHjqEbXAVzAgslR5Wg-- --===============0098107736== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf --===============0098107736==-- From autoconf-bounces@ietf.org Mon Nov 10 23:54:59 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26B3D3A6AF3; Mon, 10 Nov 2008 23:54:59 -0800 (PST) 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 935F03A6AF3 for ; Mon, 10 Nov 2008 23:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.368 X-Spam-Level: X-Spam-Status: No, score=0.368 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_MISMATCH_COM=0.553] 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 bb6qI7smzC68 for ; Mon, 10 Nov 2008 23:54:58 -0800 (PST) Received: from hpsmtp-eml12.kpnxchange.com (hpsmtp-eml12.KPNXCHANGE.COM [213.75.38.112]) by core3.amsl.com (Postfix) with ESMTP id AF97C3A689D for ; Mon, 10 Nov 2008 23:54:54 -0800 (PST) Received: from cpsmtpi-eml04.kpnxchange.com ([213.75.38.134]) by hpsmtp-eml12.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Nov 2008 08:54:53 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtpi-eml04.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Nov 2008 08:54:53 +0100 From: "Teco Boot" To: , "'Shubhranshu'" References: <1225755296.4976.15.camel@localhost> <1226343308.4806.78.camel@localhost> In-Reply-To: <1226343308.4806.78.camel@localhost> Date: Tue, 11 Nov 2008 08:54:52 +0100 Message-ID: <003001c943d2$c7af2ff0$570d8fd0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclDZeDb5j+0qgMkRwOeEnFnGP+llgAacOGA Content-Language: nl X-OriginalArrivalTime: 11 Nov 2008 07:54:53.0660 (UTC) FILETIME=[C82179C0:01C943D2] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Is autoconf meeting in Minneapolis? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > > I agree we should focus on the architectural discussions. Unless we > move forward on that direction, nothing else can happen. IMHO we should finish the architectural discussions and manetarch & PS documents as soon as possible. We don't help improve the Internet by just discussions. We have to solve some problems. Maybe the "old" document from Fred Templin is helpful: draft-templin-manet-autoconf-link-00.txt Personally, I prefer a mathematical model for MANET links and stay away from terms like "fuzzy". My attempt on defining a "MANET Link" model: --- A MANET Interface has a single non-reflexive P2MP link to a set of neighbors, a set of reflexive P2P link to a set of neighbors and a set of non-reflexive P2P link to a set of neighbors. The sets of neighbors and the link qualities vary over time. A characteristic of MANET Links is interference, i.e. a transmission from a MANET Interface could influence other MANET Links. --- BTW, why are the two WG I-Ds expired? Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 11 01:55:40 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFAC73A6AFE; Tue, 11 Nov 2008 01:55:40 -0800 (PST) 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 1673A3A6AFE for ; Tue, 11 Nov 2008 01:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdRD6z85Y2Ot for ; Tue, 11 Nov 2008 01:55:38 -0800 (PST) Received: from smtp2.bae.co.uk (unknown [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id E52193A6AFD for ; Tue, 11 Nov 2008 01:55:37 -0800 (PST) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id mAB9tQNY008289 for ; Tue, 11 Nov 2008 09:55:26 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id mAB9tQuJ030201 for ; Tue, 11 Nov 2008 09:55:26 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 11 Nov 2008 09:55:26 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Tue, 11 Nov 2008 09:55:24 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 11 Nov 2008 09:55:20 -0000 Message-ID: In-Reply-To: <003001c943d2$c7af2ff0$570d8fd0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Is autoconf meeting in Minneapolis? Thread-Index: AclDZeDb5j+0qgMkRwOeEnFnGP+llgAacOGAAARnC7A= References: <1225755296.4976.15.camel@localhost> <1226343308.4806.78.camel@localhost> <003001c943d2$c7af2ff0$570d8fd0$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , , "Shubhranshu" X-OriginalArrivalTime: 11 Nov 2008 09:55:24.0691 (UTC) FILETIME=[9E293E30:01C943E3] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Is autoconf meeting in Minneapolis? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > A MANET Interface has a single non-reflexive P2MP link to a set of > neighbors, "Non-reflexive" has become misused, not for the first time here. I think the term intended is non-transitive. Of a relationship R: Reflexive is that for all x, xRx Symmetric is that for all x, y, xRy => yRx Transitive is that for all x, y, z, xRy and yRz => xRz MANET links are neither symmetric, not transitive. It's the lack of transitivity - and that there's nothing you can do about it directly - that makes it most problematic. (Lack of symmetry, in the sense of whether there simply is a link, can be handled using some sort of acknowledgement process. Of course that may still leave asymmetry in terms of data rates etc.) Whether a link is reflexive (whether a node has a link to itself) is really a matter of definition, and not very important. > A characteristic of MANET Links is > interference, i.e. a transmission from a MANET Interface could influence > other MANET Links. There needs to be quite a bit more said here. I think Thomas's draft does. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 11 02:43:48 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3478528C15E; Tue, 11 Nov 2008 02:43:48 -0800 (PST) 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 64C4228C14F for ; Tue, 11 Nov 2008 02:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.839 X-Spam-Level: X-Spam-Status: No, score=-0.839 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 50e3hHWdiGkC for ; Tue, 11 Nov 2008 02:43:45 -0800 (PST) Received: from cpsmtpo-eml02.kpnxchange.com (cpsmtpo-eml02.KPNXCHANGE.COM [213.75.38.151]) by core3.amsl.com (Postfix) with ESMTP id 6676728C15E for ; Tue, 11 Nov 2008 02:43:44 -0800 (PST) Received: from hpsmtp-eml10.kpnxchange.com ([213.75.38.110]) by cpsmtpo-eml02.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Nov 2008 11:43:45 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml10.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Nov 2008 11:43:44 +0100 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" References: <1225755296.4976.15.camel@localhost> <1226343308.4806.78.camel@localhost> <003001c943d2$c7af2ff0$570d8fd0$@nl> In-Reply-To: Date: Tue, 11 Nov 2008 11:43:44 +0100 Message-ID: <003601c943ea$5e6c3d90$1b44b8b0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclDZeDb5j+0qgMkRwOeEnFnGP+llgAacOGAAARnC7AAAd7sQA== Content-Language: nl X-OriginalArrivalTime: 11 Nov 2008 10:43:44.0730 (UTC) FILETIME=[5EB813A0:01C943EA] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Is autoconf meeting in Minneapolis? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > "Non-reflexive" has become misused, not for the first time here. > I think the term intended is non-transitive. I meant non-reflexive, as defined in RFC4861: ### Non-reflexive reachability means packets from A reach B, ### but packets from B don't reach A. For myself, I would use the term uni-directional. I'm fine with symmetric, but link metrics would not need to be symmetric. My ADSL provides bidirectional communication but has different data rates for up- and downlink. We need text on clarification / correction of RFC4861. > Of course that may still leave asymmetry in > terms of data rates etc.) Yes! > > A characteristic of MANET Links is > > interference, i.e. a transmission from a MANET Interface could > influence > > other MANET Links. > > There needs to be quite a bit more said here. I think Thomas's > draft does. I am OK with having a document that describes the MANET model in detail. I suggested to include a more mathematical model for the MANET links. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 11 02:57:47 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A4273A680A; Tue, 11 Nov 2008 02:57:47 -0800 (PST) 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 6D98A3A680A for ; Tue, 11 Nov 2008 02:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2GjXvHW6mmc for ; Tue, 11 Nov 2008 02:57:44 -0800 (PST) Received: from smtp2.bae.co.uk (unknown [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id 035C13A67C0 for ; Tue, 11 Nov 2008 02:57:43 -0800 (PST) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id mABAvHXV007145 for ; Tue, 11 Nov 2008 10:57:17 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id mABAvHhc006352 for ; Tue, 11 Nov 2008 10:57:17 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 11 Nov 2008 10:57:17 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Tue, 11 Nov 2008 10:57:16 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 11 Nov 2008 10:57:15 -0000 Message-ID: In-Reply-To: <003601c943ea$5e6c3d90$1b44b8b0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Is autoconf meeting in Minneapolis? Thread-Index: AclDZeDb5j+0qgMkRwOeEnFnGP+llgAacOGAAARnC7AAAd7sQAAA3PAg References: <1225755296.4976.15.camel@localhost> <1226343308.4806.78.camel@localhost> <003001c943d2$c7af2ff0$570d8fd0$@nl> <003601c943ea$5e6c3d90$1b44b8b0$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" X-OriginalArrivalTime: 11 Nov 2008 10:57:16.0839 (UTC) FILETIME=[42C61370:01C943EC] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Is autoconf meeting in Minneapolis? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > I meant non-reflexive, as defined in RFC4861: > Non-reflexive reachability means packets from A reach B, > but packets from B don't reach A. That is unfortunate, a bad usage enshrined in an RFC, and an important RFC at that. But, the RFC notwithstanding, that's contrary to long established mathematical usage - see for example http://mathworld.wolfram.com/Reflexive.html and to normal English, see for example http://dictionary.reference.com/browse/reflexive While changing RFC4861 isn't practical, I don't see any reason to perpetuate the error. > I'm fine with symmetric, but link metrics would not need to be symmetric. > My ADSL provides bidirectional communication but has different data rates > for up- and downlink. This is where two uses of symmetric come into conflict. The relationship "has a link with" mayt be symmetric, while the properties of the link may not be. But replacing by reflexive (which has another meaning) is not the answer. But actually, as I noted, I think it's the non-transitivity, not the non-symmetry (for either usage of symmetry, and as you say, uni/bi-directional is a good usage) that's the killer as to why ND doesn't work (though non-symmetry doesn't help of course). ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 11 04:21:44 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB4BF28C139; Tue, 11 Nov 2008 04:21:44 -0800 (PST) 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 8EBB328C1BA for ; Tue, 11 Nov 2008 04:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.443 X-Spam-Level: X-Spam-Status: No, score=-1.443 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 r+3E2YqMdbZR for ; Tue, 11 Nov 2008 04:21:43 -0800 (PST) Received: from hpsmtp-eml16.kpnxchange.com (hpsmtp-eml16.KPNXCHANGE.COM [213.75.38.116]) by core3.amsl.com (Postfix) with ESMTP id 7CC9F28C139 for ; Tue, 11 Nov 2008 04:21:42 -0800 (PST) Received: from cpsmtpi-eml07.kpnxchange.com ([213.75.38.137]) by hpsmtp-eml16.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Nov 2008 13:21:42 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtpi-eml07.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Nov 2008 13:21:43 +0100 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" References: <1225755296.4976.15.camel@localhost> <1226343308.4806.78.camel@localhost> <003001c943d2$c7af2ff0$570d8fd0$@nl> <003601c943ea$5e6c3d90$1b44b8b0$@nl> In-Reply-To: Date: Tue, 11 Nov 2008 13:21:41 +0100 Message-ID: <003701c943f8$0de93ef0$29bbbcd0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclDZeDb5j+0qgMkRwOeEnFnGP+llgAacOGAAARnC7AAAd7sQAAA3PAgAAHP1AA= Content-Language: nl X-OriginalArrivalTime: 11 Nov 2008 12:21:43.0221 (UTC) FILETIME=[0E929E50:01C943F8] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Is autoconf meeting in Minneapolis? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > > I meant non-reflexive, as defined in RFC4861: > > Non-reflexive reachability means packets from A reach B, > > but packets from B don't reach A. > > That is unfortunate, a bad usage enshrined in an RFC, and an > important RFC at that. OK, let's go for an errata for RFC4861: === Old text: asymmetric reachability - a link where non-reflexive and/or non-transitive reachability is part of normal operation. (Non- reflexive reachability means packets from A reach B, but packets from B don't reach A. Non-transitive reachability means packets from A reach B, and packets from B reach C, but packets from A don't reach C.) Many radio links exhibit these properties. === New text: asymmetric reachability - a link where non-symmetric and/or non-transitive reachability is part of normal operation. (Non- symmetric reachability means packets from A reach B, but packets from B don't reach A. Non-transitive reachability means packets from A reach B, and packets from B reach C, but packets from A don't reach C.) Many radio links exhibit these properties. === OK with this? And an adjusted attempt on defining a "MANET Link" model: --- A MANET Interface has a single non-symmetric P2MP link to a set of neighbors, a set of symmetric P2P links to a set of neighbors and a set of non-symmetric P2P links to a set of neighbors. The sets of neighbors and the link qualities vary over time. A characteristic of MANET Links is interference, i.e. a transmission from a MANET Interface could influence other MANET Links. --- I am not satisfied with the "set of symmetric P2P links", because the link metrics may be asymmetric. And non-transitivity could be included. And the P2MP link can be refined. The MANET interface has two roles here, as a hub for sending and as spokes for receiving. Another shot: === A MANET Interface has a single outbound uni-directional P2MP link to a set of neighbors, a set of inbound uni-directional P2MP links from a set of neighbors, a set of bi-directional P2P links with a set of neighbors and a set of uni-directional P2P links from a set of neighbors. The sets of neighbors and the link qualities vary over time and link metrics may be asymmetric. Furthermore, links between the MANET Interfaces could be non-transitive. A characteristic of MANET Links is interference, i.e. a transmission from a MANET Interface could influence other MANET Links. === > But actually, as I noted, I think it's the non-transitivity, > not the non-symmetry (for either usage of symmetry, and as > you say, uni/bi-directional is a good usage) that's the > killer as to why ND doesn't work (though non-symmetry doesn't > help of course). Maybe parts of ND doesn't work. Duplicate Address Detection doesn't work because both non-symmetry and non-transitivity. Neighbor Unreachability Detection should work. If parts of ND doesn't work, I think it is important to specify which parts. This should be included in the PS. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 11 04:30:23 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73EA928C1B7; Tue, 11 Nov 2008 04:30:23 -0800 (PST) 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 8F50F28C1B7 for ; Tue, 11 Nov 2008 04:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PNI0cAoZct7 for ; Tue, 11 Nov 2008 04:30:21 -0800 (PST) Received: from smtp2.bae.co.uk (unknown [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id DBC5228C17F for ; Tue, 11 Nov 2008 04:30:19 -0800 (PST) Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id mABCU6fF019588 for ; Tue, 11 Nov 2008 12:30:06 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id mABCU6m3018264 for ; Tue, 11 Nov 2008 12:30:06 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 11 Nov 2008 12:30:06 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Tue, 11 Nov 2008 12:30:06 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 11 Nov 2008 12:30:04 -0000 Message-ID: In-Reply-To: <003701c943f8$0de93ef0$29bbbcd0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Is autoconf meeting in Minneapolis? Thread-Index: AclDZeDb5j+0qgMkRwOeEnFnGP+llgAacOGAAARnC7AAAd7sQAAA3PAgAAHP1AAAATbK4A== References: <1225755296.4976.15.camel@localhost> <1226343308.4806.78.camel@localhost> <003001c943d2$c7af2ff0$570d8fd0$@nl> <003601c943ea$5e6c3d90$1b44b8b0$@nl> <003701c943f8$0de93ef0$29bbbcd0$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" X-OriginalArrivalTime: 11 Nov 2008 12:30:06.0116 (UTC) FILETIME=[3A524E40:01C943F9] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Is autoconf meeting in Minneapolis? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > OK, let's go for an errata for RFC4861: > === Old text: > asymmetric reachability > - a link where non-reflexive and/or non-transitive > reachability is part of normal operation. (Non- > reflexive reachability means packets from A reach B, > but packets from B don't reach A. Non-transitive > reachability means packets from A reach B, and > packets from B reach C, but packets from A don't > reach C.) Many radio links exhibit these properties. > === New text: > asymmetric reachability > - a link where non-symmetric and/or non-transitive > reachability is part of normal operation. (Non- > symmetric reachability means packets from A reach B, > but packets from B don't reach A. Non-transitive > reachability means packets from A reach B, and > packets from B reach C, but packets from A don't > reach C.) Many radio links exhibit these > properties. > === > OK with this? Personally, yes. But even if it is accepted (as I think it should be) that reflexive is wrong, I can see arguments over symmetric, which as we've noted has alternative meanings. In addition I'd rather not get into the administrative process of errataing (if that's a word) a well-supported RFC right at the moment without good support from the powers that be. (I'm not familiar with the RFC errata process details.) ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 11 05:47:28 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 265CC3A6945; Tue, 11 Nov 2008 05:47:28 -0800 (PST) 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 7E56B3A6AF2 for ; Tue, 11 Nov 2008 05:47:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.644 X-Spam-Level: X-Spam-Status: No, score=-1.644 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 O-d0lk+p6sDZ for ; Tue, 11 Nov 2008 05:47:25 -0800 (PST) Received: from cpsmtpo-eml06.kpnxchange.com (cpsmtpo-eml06.KPNXCHANGE.COM [213.75.38.155]) by core3.amsl.com (Postfix) with ESMTP id 9FACE3A6945 for ; Tue, 11 Nov 2008 05:47:24 -0800 (PST) Received: from hpsmtp-eml10.kpnxchange.com ([213.75.38.110]) by cpsmtpo-eml06.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Nov 2008 14:47:22 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml10.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Nov 2008 14:47:21 +0100 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" References: <1225755296.4976.15.camel@localhost> <1226343308.4806.78.camel@localhost> <003001c943d2$c7af2ff0$570d8fd0$@nl> <003601c943ea$5e6c3d90$1b44b8b0$@nl> <003701c943f8$0de93ef0$29bbbcd0$@nl> In-Reply-To: Date: Tue, 11 Nov 2008 14:47:21 +0100 Message-ID: <003b01c94404$0573e890$105bb9b0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclDZeDb5j+0qgMkRwOeEnFnGP+llgAacOGAAARnC7AAAd7sQAAA3PAgAAHP1AAAATbK4AAC0nRg Content-Language: nl X-OriginalArrivalTime: 11 Nov 2008 13:47:22.0033 (UTC) FILETIME=[058B1A10:01C94404] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Is autoconf meeting in Minneapolis? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > > OK, let's go for an errata for RFC4861: > In addition I'd rather not get > into the administrative process of errataing (if that's a word) a > well-supported RFC right at the moment without good support from the > powers that be. I posted the issue: http://www.rfc-editor.org/errata_search.php?rfc=4861 Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sat Nov 15 04:23:59 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18FDB3A68B0; Sat, 15 Nov 2008 04:23:59 -0800 (PST) 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 307C63A68B0 for ; Sat, 15 Nov 2008 04:23:58 -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 DxqeUii7Sa12 for ; Sat, 15 Nov 2008 04:23:57 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id 7E7DC3A67ED for ; Sat, 15 Nov 2008 04:23:57 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so1959336wfd.31 for ; Sat, 15 Nov 2008 04:23:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=sLaFTl286EIZhr/bomMWK08ApOqgMJkHlNM95GpeStg=; b=u9b2wJABDLSPNSLA6nkgbCmslILJAuemtgEs5ZV7LnfoDw2eYIbxk/+tRj1FQqvpwB hAWD3/AUMOXKKxF1gjdqH+Gxw8RmAIevhWztwaAUB2cgvzl9BpBswO6MHfGND3tl01D9 AnP/EnGpHaQEIaJFA4P8EJbsol7EapyPzsiqk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=sPLVLJPmWMyVIfz6SFwY6dfrPpXi5Tf3mwrN95MfIbBdB43aQV/s8vKh7hErVmtlrH gW62Y926Sw/4NgxoIMzi7gYT0IV6ogcgLESCIyvM4nPHJ02ZF5bSwuhp1ziymDgwRzQB 6Y5tEqb0GzvOpRJb8h81/ahvDFi/o4v+Pr/II= Received: by 10.142.86.7 with SMTP id j7mr896974wfb.122.1226751837106; Sat, 15 Nov 2008 04:23:57 -0800 (PST) Received: by 10.142.88.7 with HTTP; Sat, 15 Nov 2008 04:23:57 -0800 (PST) Message-ID: Date: Sat, 15 Nov 2008 17:53:57 +0530 From: Shubhranshu To: autoconf@ietf.org MIME-Version: 1.0 Content-Disposition: inline Subject: [Autoconf] Presentation Slides 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org The usual place to look for the WG presentation slides and agenda is https://datatracker.ietf.org/meeting/73/materials.html . I'll upload the presentation slides as soon as I receive them. The meeting agenda is also available at http://www.ietf.org/proceedings/08nov/agenda/autoconf.txt - Shubhranshu _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sat Nov 15 18:13:58 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47BD23A6999; Sat, 15 Nov 2008 18:13:58 -0800 (PST) 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 4EFA23A6999 for ; Sat, 15 Nov 2008 18:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 Qfyf1hc5mgkJ for ; Sat, 15 Nov 2008 18:13:55 -0800 (PST) Received: from mxav01.cc.niigata-u.ac.jp (mxav01.cc.niigata-u.ac.jp [133.35.17.129]) by core3.amsl.com (Postfix) with ESMTP id 53C883A6951 for ; Sat, 15 Nov 2008 18:13:54 -0800 (PST) Received: from mxav01.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 36B9E4F4242 for ; Sun, 16 Nov 2008 11:13:44 +0900 (JST) Received: from chamame.ie.niigata-u.ac.jp (chamame.ie.niigata-u.ac.jp [133.35.169.34]) by mxav01.cc.niigata-u.ac.jp (Postfix) with SMTP id 2C1D64F41EC for ; Sun, 16 Nov 2008 11:13:44 +0900 (JST) Received: (qmail 16026 invoked from network); 16 Nov 2008 11:13:44 +0900 Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 16 Nov 2008 11:13:44 +0900 Message-Id: <7.0.0.16.2.20081116103354.086b0bc8@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Sun, 16 Nov 2008 11:13:48 +0900 To: Thomas Heide Clausen ,autoconf@ietf.org From: mase In-Reply-To: References: Mime-Version: 1.0 Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Dear Thomas, I think that your document is very useful to deepen understanding about what is MANETs. I have some commnets. I think that Sec. 4 MANET Interface discusses more than MANET interface, that is, MANET link type. This section may present essences of the MANET link type. I almost agree what are written here, but hope that we could a little bit clearer the essence of MANET link type. I would propose the following remark to be included in the texts. The set of neighbors of each MANET interface may be position (attachment to a link)- and time-dependent. The nature of position-dependency in MANETs is clearly described in Sec. 4. Time-dependency occurs for example due to interference in wireless environment. This is different from things discussed in Sec. 5. Note that , in the Ethernet-like link, the set of neighbors of each MANET interface is position- and time-independent in principle. The word "position" is used in Sec. 5. So, the remark above also contributes to improves consistency. I also would propose that Sec. 6 is entitled "The MANET link Type Characteristics". It should be noted in Sec. 6 that the most of characteristics of MANET link type, listed here, occur as the result of the nature of MANET link type proposed above. Thanks, Kenichi At 18:51 08/11/04, Thomas Heide Clausen wrote: >Folks, > >As you know, we need to make progress on the architectural issues, >before we can hope to make progress on other matters within this WG. >One of the requests that have been made to us has been to "describe >the MANET Link Type", and so I have written together a strawman text >to this effect: > > http://www.ietf.org/internet-drafts/draft-clausen-manet-linktype-00.txt > >Feedback is, obviously, welcome -- preferably on the list such that >we could be prepared spend time on this also in MN. > >Note, however, that this is an individual I-D. > >I'd also like to draw your collective attention to: > > http://www.ietf.org/internet-drafts/draft-iab-ip-model-evolution-01.txt > >Which has served as a source of inspiration for the linktype text. > >Thanks, > >Thomas >_______________________________________________ >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 autoconf-bounces@ietf.org Mon Nov 17 03:25:05 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FC213A6801; Mon, 17 Nov 2008 03:25:05 -0800 (PST) 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 B70863A6801 for ; Mon, 17 Nov 2008 03:25:04 -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 72TVXlSlTLNs for ; Mon, 17 Nov 2008 03:25:03 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 790863A677E for ; Mon, 17 Nov 2008 03:25:03 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-128.messagelabs.com!1226921101!4057502!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 12175 invoked from network); 17 Nov 2008 11:25:01 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-128.messagelabs.com with SMTP; 17 Nov 2008 11:25:01 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mAHBOxvh007952; Mon, 17 Nov 2008 04:24:59 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id mAHBOxUL021134; Mon, 17 Nov 2008 05:24:59 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id mAHBOvm4021123; Mon, 17 Nov 2008 05:24:58 -0600 (CST) Message-ID: <49215489.9090903@gmail.com> Date: Mon, 17 Nov 2008 12:24:57 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Thomas Heide Clausen References: In-Reply-To: X-Antivirus: avast! (VPS 081116-0, 16/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Thomas Heide Clausen wrote: > Folks, > > As you know, we need to make progress on the architectural issues, > before we can hope to make progress on other matters within this WG. > One of the requests that have been made to us has been to "describe > the MANET Link Type", and so I have written together a strawman text > to this effect: > > http://www.ietf.org/internet-drafts/draft-clausen-manet-linktype-00.txt > > > > Feedback is, obviously, welcome -- preferably on the list such that > we could be prepared spend time on this also in MN. Hi ThomasC, I went quickly through the draft, thank you for posting it. I also think gathering a good description on the link types addressed by MANETs is helpful towards profiling AUTOCONF goals. I have one minor feedback, in general - could we list, perhaps in a separate section, the names of the link layer technologies considered as MANET, and targeted by AUTOCONF and IPv6 goals. I could start with: IEEE 802.11 IEEE 802.15 IEEE 802.15.4-2006 Bluetooth SIG BLUETOOTH SPECIFICATION Version 2.1 + EDR Wireless USB WirelessHD ANT W.I.N.D. Other? What do you think? Otherwise, just some suggestions of clarifications of some possible nits: > IPv6 Link Local Multicast (FFx2::) are specified to not be forwarded That's right, but for better readability probably saying "IPv6 multicast address with link-local scope (prefixed by FF02:: or FF12::)" would be better because, for example, there's no IPv6 multicast address with link-local scope prefixed by FF22:: - only FF02:: and FF12:: could exist, as of RFC3513. > While the MANET interfaces of nodes B and C in Figure 5 may not be > configured with addresses from within the same subnet, these may > still communicate e.g. as point-to-point links where the two > endpoints have addresses from unrelated address spaces. Let me try to understand the last part: two endpoints on a point-to-point link have addresses from unrelated address spaces? For example on a ptp link node A has address 1::1/64 and node B has address 2::1/64? I think that's not possible, because the ptp link has a common subnet prefix and the ends need to have addresses like 1::1/64 and 1::2/64 (same 'address space' 1::/64 subnet address); ptp links often have same subnet address, eg IPv6 over PPP stateless autoconfiguration. Or maybe I don't understand well the 'address space' in this context here. Nit, Figure 3: > -------+------- ---+------- Transmission > ------+------- -------+------- -------+------- Ranges > > \|/ \|/ \|/ \|/ \|/ > | | | | | > +-+-+ +-+-+ +-+-+ +-+-+ +-+-+ > | A | | B | | C | | D | | E | > +---+ +---+ +---+ +---+ +---+ > > In this simple network, a transmission by the node C reaches only > nodes B and D on the MANET link, due to the limited transmission > range of the wireless broadcast interface. Similarly, a transmission > from node B reaches only nodes A and C and a transmission by node D > reaches only node E- the latter might be due to environmental > interference or obstacles, transmission power levels or antenna > properties of node C or D (e.g. directional antennas on either or > both of C and D). The picture makes think there's a directional antenna only on D, not on C, and oriented towards E. Also I wanted to ask whether this picture depicts an on-off kind of behaviour (no packet sent by D reaches C, whereas all from C reach D) or is it more like an uneven bandwidth (D-to-C 1Mbit/s whereas C-to-D 10Mbit/s). This uneven behaviour is typical in wifi... but not sure which link-layer technology is thought of in the Figure 3's example? Just some notes... Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 17 03:40:42 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D8963A67E6; Mon, 17 Nov 2008 03:40:42 -0800 (PST) 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 7CA603A67E6 for ; Mon, 17 Nov 2008 03:40: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 tjYn2Fy4YrBz for ; Mon, 17 Nov 2008 03:40:40 -0800 (PST) Received: from mho-02-bos.mailhop.org (mho-02-bos.mailhop.org [63.208.196.179]) by core3.amsl.com (Postfix) with ESMTP id 709363A6403 for ; Mon, 17 Nov 2008 03:40:40 -0800 (PST) Received: from [130.129.78.103] by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1L22T9-000KPQ-EP; Mon, 17 Nov 2008 11:40:39 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 130.129.78.103 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/R5HxwiAbml1EAj4agP6uj In-Reply-To: <49215489.9090903@gmail.com> References: <49215489.9090903@gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Thomas Heide Clausen Date: Mon, 17 Nov 2008 12:41:07 +0100 To: Alexandru Petrescu X-Mailer: Apple Mail (2.753.1) Cc: autoconf@ietf.org Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Alex, Thanks for your comments. See below. On Nov 17, 2008, at 12:24 PM, Alexandru Petrescu wrote: > Thomas Heide Clausen wrote: >> Folks, >> As you know, we need to make progress on the architectural issues, >> before we can hope to make progress on other matters within this >> WG. One of the requests that have been made to us has been to >> "describe the MANET Link Type", and so I have written together a >> strawman text to this effect: >> http://www.ietf.org/internet-drafts/draft-clausen-manet- >> linktype-00.txt >> Feedback is, obviously, welcome -- preferably on the list such >> that we could be prepared spend time on this also in MN. > > Hi ThomasC, > > I went quickly through the draft, thank you for posting it. I also > think gathering a good description on the link types addressed by > MANETs > is helpful towards profiling AUTOCONF goals. > > I have one minor feedback, in general - could we list, perhaps in a > separate section, the names of the link layer technologies > considered as > MANET, and targeted by AUTOCONF and IPv6 goals. > > I could start with: > > IEEE 802.11 > IEEE 802.15 IEEE 802.15.4-2006 > Bluetooth SIG BLUETOOTH SPECIFICATION Version 2.1 + EDR > Wireless USB > WirelessHD > ANT > W.I.N.D. > Other? > > What do you think? I am actually not a fan of listing explicitly such. In part, because I do not think that this list necessarily complete neither now nor "in the immediate future", and in part because I think that we are trying at a more generic description than a specific L2. > Otherwise, just some suggestions of clarifications of some possible > nits: >> IPv6 Link Local Multicast (FFx2::) are specified to not be forwarded > > That's right, but for better readability probably saying "IPv6 > multicast > address with link-local scope (prefixed by FF02:: or FF12::)" > would be > better because, for example, there's no IPv6 multicast address with > link-local scope prefixed by FF22:: - only FF02:: and FF12:: could > exist, as of RFC3513. Good point, I'll do that in an update. > >> While the MANET interfaces of nodes B and C in Figure 5 may not be >> configured with addresses from within the same subnet, these may >> still communicate e.g. as point-to-point links where the two >> endpoints have addresses from unrelated address spaces. > > Let me try to understand the last part: two endpoints on a > point-to-point link have addresses from unrelated address spaces? For > example on a ptp link node A has address 1::1/64 and node B has > address > 2::1/64? I think that's not possible, because the ptp link has a > common > subnet prefix and the ends need to have addresses like 1::1/64 and > 1::2/64 (same 'address space' 1::/64 subnet address); ptp links often > have same subnet address, eg IPv6 over PPP stateless > autoconfiguration. > > Or maybe I don't understand well the 'address space' in this > context here. No, you understand it quite well. It is quite possible to run links between routers in this way (and, I know of at least one case in the IETF wherein the link between a router and hosts is also run in that way). > Nit, Figure 3: >> -------+------- ---+------- Transmission >> ------+------- -------+------- -------+------- Ranges >> \|/ \|/ \|/ \|/ \|/ >> | | | | | >> +-+-+ +-+-+ +-+-+ +-+-+ +-+-+ >> | A | | B | | C | | D | | E | >> +---+ +---+ +---+ +---+ +---+ >> >> In this simple network, a transmission by the node C reaches only >> nodes B and D on the MANET link, due to the limited transmission >> range of the wireless broadcast interface. Similarly, a >> transmission from node B reaches only nodes A and C and a >> transmission by node D reaches only node E- the latter might be >> due to environmental >> interference or obstacles, transmission power levels or antenna >> properties of node C or D (e.g. directional antennas on either or >> both of C and D). > > The picture makes think there's a directional antenna only on D, > not on C, and oriented towards E. That could be the case, yes. > > Also I wanted to ask whether this picture depicts an on-off kind of > behaviour (no packet sent by D reaches C, whereas all from C reach D) I'd say "yes" > or is it more like an uneven bandwidth (D-to-C 1Mbit/s whereas C-to- > D 10Mbit/s). I'd say "yes" again. > This uneven behaviour is typical in wifi... but not sure which link- > layer technology is thought of in the Figure 3's example? No specific L2, fig. 3 is trying to describe a "general type of behavior, which a MANET protocol must be designed to accommodate". Thomas _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 17 05:47:48 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F4873A67FA; Mon, 17 Nov 2008 05:47:48 -0800 (PST) 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 ECAAA3A67FA for ; Mon, 17 Nov 2008 05:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYliK2h3pIe3 for ; Mon, 17 Nov 2008 05:47:47 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id AD5173A63D3 for ; Mon, 17 Nov 2008 05:47:46 -0800 (PST) Received: (qmail 10784 invoked from network); 17 Nov 2008 14:47:37 +0100 Received: from unknown (HELO M90Teco) (12.104.246.2) by server9.hosting2go.nl with SMTP; 17 Nov 2008 14:47:37 +0100 From: "Teco Boot" To: "'Thomas Heide Clausen'" , "'Alexandru Petrescu'" References: <49215489.9090903@gmail.com> In-Reply-To: Date: Mon, 17 Nov 2008 14:47:36 +0100 Message-ID: <002401c948bb$0dfd7b50$29f871f0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclIqVUHRAETtd+QQhGFx0U1POi0JQAEJwHg Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > > Nit, Figure 3: > >> -------+------- ---+------- Transmission > >> ------+------- -------+------- -------+------- Ranges > >> \|/ \|/ \|/ \|/ \|/ > >> | | | | | > >> +-+-+ +-+-+ +-+-+ +-+-+ +-+-+ > >> | A | | B | | C | | D | | E | > >> +---+ +---+ +---+ +---+ +---+ > >> > >> In this simple network, a transmission by the node C reaches only > >> nodes B and D on the MANET link, due to the limited transmission > >> range of the wireless broadcast interface. Similarly, a > >> transmission from node B reaches only nodes A and C and a > >> transmission by node D reaches only node E- the latter might be > >> due to environmental > >> interference or obstacles, transmission power levels or antenna > >> properties of node C or D (e.g. directional antennas on either or > >> both of C and D). > > > > The picture makes think there's a directional antenna only on D, > > not on C, and oriented towards E. > > That could be the case, yes. Directional antennas provide beam forming for transmit and receive. It could be the case that there is a directional antenna, but directional antennas do NOT introduce unidirectional reachability. Or physical laws are updated recently... Perhaps D sends with lower power than C, or there is noise or interference on C. Or C has low sensitive receiver. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 17 05:50:19 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 835CA3A6962; Mon, 17 Nov 2008 05:50:19 -0800 (PST) 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 DA5AE3A6962 for ; Mon, 17 Nov 2008 05:50:17 -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 bOT2cViUWH7u for ; Mon, 17 Nov 2008 05:50:16 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id C62223A63D3 for ; Mon, 17 Nov 2008 05:50:16 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-153.messagelabs.com!1226929815!12241479!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 29053 invoked from network); 17 Nov 2008 13:50:15 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-153.messagelabs.com with SMTP; 17 Nov 2008 13:50:15 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mAHDoE0W005553; Mon, 17 Nov 2008 06:50:14 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id mAHDoElD001152; Mon, 17 Nov 2008 07:50:14 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id mAHDoD61001132; Mon, 17 Nov 2008 07:50:13 -0600 (CST) Message-ID: <49217694.4040205@gmail.com> Date: Mon, 17 Nov 2008 14:50:12 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Thomas Heide Clausen References: <49215489.9090903@gmail.com> In-Reply-To: X-Antivirus: avast! (VPS 081116-0, 16/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Thomas Heide Clausen wrote: [listing specific link-layer types] > > I am actually not a fan of listing explicitly such. In part, because I > do not think that this list necessarily complete neither now nor "in the > immediate future", and in part because I think that we are trying at a > more generic description than a specific L2. It was not the intention to make it complete, but to have a start list of such things. To make it more complete one would simply add more items. Which link you think is not and needs to be present on that list? [...] >>> While the MANET interfaces of nodes B and C in Figure 5 may not be >>> configured with addresses from within the same subnet, these may >>> still communicate e.g. as point-to-point links where the two >>> endpoints have addresses from unrelated address spaces. >> >> Let me try to understand the last part: two endpoints on a >> point-to-point link have addresses from unrelated address spaces? For >> example on a ptp link node A has address 1::1/64 and node B has address >> 2::1/64? I think that's not possible, because the ptp link has a common >> subnet prefix and the ends need to have addresses like 1::1/64 and >> 1::2/64 (same 'address space' 1::/64 subnet address); ptp links often >> have same subnet address, eg IPv6 over PPP stateless autoconfiguration. >> >> Or maybe I don't understand well the 'address space' in this context >> here. > > No, you understand it quite well. It is quite possible to run links > between routers in this way (and, I know of at least one case in the > IETF wherein the link between a router and hosts is also run in that way). I think a point-to-point link between routers still has a common subnet address, or otherwise one should disable DAD and other ND parameters. It could be advantageous to say so, because it also brings in an opportunity to talk about ND, otherwise absent from the draft. >> Nit, Figure 3: >>> -------+------- ---+------- Transmission >>> ------+------- -------+------- -------+------- Ranges >>> \|/ \|/ \|/ \|/ \|/ >>> | | | | | >>> +-+-+ +-+-+ +-+-+ +-+-+ +-+-+ >>> | A | | B | | C | | D | | E | >>> +---+ +---+ +---+ +---+ +---+ >>> >>> In this simple network, a transmission by the node C reaches only >>> nodes B and D on the MANET link, due to the limited transmission >>> range of the wireless broadcast interface. Similarly, a transmission >>> from node B reaches only nodes A and C and a transmission by node D >>> reaches only node E- the latter might be due to environmental >>> interference or obstacles, transmission power levels or antenna >>> properties of node C or D (e.g. directional antennas on either or >>> both of C and D). >> >> The picture makes think there's a directional antenna only on D, not >> on C, and oriented towards E. > > That could be the case, yes. In that case one wouldn't say 'either or both of C and D', just 'on D'. >> Also I wanted to ask whether this picture depicts an on-off kind of >> behaviour (no packet sent by D reaches C, whereas all from C reach D) > > I'd say "yes" Well I think that's a UDLR link, and in this case it should be qualified as such. UDLR may be useful to cite here, there are RFCs about it, mostly from the satellite links worlds. >> or is it more like an uneven bandwidth (D-to-C 1Mbit/s whereas C-to-D >> 10Mbit/s). > > I'd say "yes" again. Sorry, can't be both. A link is either UDLR (like satellite) or asymmetric (like ADSL). There don't exist links which are both UDLR and ADSL at the same time. >> This uneven behaviour is typical in wifi... but not sure which >> link-layer technology is thought of in the Figure 3's example? > > No specific L2, fig. 3 is trying to describe a "general type of > behavior, which a MANET protocol must be designed to accommodate". I do subscribe to the generic aspect, and the intention to have IP run over all types of links pertinent to MANET. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 17 05:58:15 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1834C3A696E; Mon, 17 Nov 2008 05:58:15 -0800 (PST) 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 D856B3A696E for ; Mon, 17 Nov 2008 05:58:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[AWL=1.238, 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 o4CvibqeZmEU for ; Mon, 17 Nov 2008 05:58:13 -0800 (PST) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id CB9923A63D3 for ; Mon, 17 Nov 2008 05:58:12 -0800 (PST) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id mAHDwAIm002155 for ; Mon, 17 Nov 2008 13:58:10 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id mAHDwAMn008689 for ; Mon, 17 Nov 2008 13:58:10 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 17 Nov 2008 13:58:09 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 17 Nov 2008 13:58:09 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 17 Nov 2008 13:58:07 -0000 Message-ID: In-Reply-To: <49217694.4040205@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] draft-clausen-manet-linktype Thread-Index: AclIu3RnonkqkmKaQMOR84zDBq+HogAABNfA References: <49215489.9090903@gmail.com> <49217694.4040205@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" , "Thomas Heide Clausen" X-OriginalArrivalTime: 17 Nov 2008 13:58:09.0051 (UTC) FILETIME=[85ACB6B0:01C948BC] Cc: autoconf@ietf.org Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > It was not the intention to make it complete, but to have a start list > of such things. To make it more complete one would simply add more > items. I agree with Thomas, attempting to list possible systems is not a good idea. Quoting one or two examples (e.g. 802.11) to give an example of the problems is useful. But any attempt to provide anything comprehensive is doomed to double failure. Failure to catch everything, and failure in that it might suggest things that aren't listed aren't included. That does mean that when quoting an example, it is important to make clear it is just that and no more. > Which link you think is not and needs to be present on that list? I can think of some. But I don't intend to list them. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 17 06:02:58 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D8993A682E; Mon, 17 Nov 2008 06:02:58 -0800 (PST) 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 3B2A53A682E for ; Mon, 17 Nov 2008 06:02:57 -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 CJtzfA8odut9 for ; Mon, 17 Nov 2008 06:02:56 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 638493A63D3 for ; Mon, 17 Nov 2008 06:02:56 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-128.messagelabs.com!1226930574!18770568!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 7859 invoked from network); 17 Nov 2008 14:02:54 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-128.messagelabs.com with SMTP; 17 Nov 2008 14:02:54 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mAHE2sAH008942; Mon, 17 Nov 2008 07:02:54 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id mAHE2sxJ006077; Mon, 17 Nov 2008 08:02:54 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id mAHE2qg2006066; Mon, 17 Nov 2008 08:02:53 -0600 (CST) Message-ID: <4921798C.2010301@gmail.com> Date: Mon, 17 Nov 2008 15:02:52 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <49215489.9090903@gmail.com> <49217694.4040205@gmail.com> In-Reply-To: X-Antivirus: avast! (VPS 081116-0, 16/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Dearlove, Christopher (UK) wrote: >> It was not the intention to make it complete, but to have a start list > >> of such things. To make it more complete one would simply add more >> items. > > I agree with Thomas, attempting to list possible systems is not a > good idea. Quoting one or two examples (e.g. 802.11) to give an > example of the problems is useful. But any attempt to provide anything > comprehensive is doomed to double failure. Failure to catch everything, > and failure in that it might suggest things that aren't listed aren't > included. That does mean that when quoting an example, it is important > to make clear it is just that and no more. I wouldnt go as far as trying to make it comprehensive list, of course. But doing my best - yes. I really would list the links which concerns us. E.g. I'm concerned by WiFi and Bluetooth in my work - none is UDLR, thus no need to mention the on-off kind of behaviour. I'm not concerned by satellite. You'd be concerned by other links, welcome to add it. Hiding my head in the sand about which link layer I'm using, in a document about link layer types... risks me being taken not seriously. >> Which link you think is not and needs to be present on that list? > > I can think of some. But I don't intend to list them. Why? Is it because the confidentiality of the type of work? Alex > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 17 06:13:48 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BA6B3A688B; Mon, 17 Nov 2008 06:13:48 -0800 (PST) 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 8D6E33A688B for ; Mon, 17 Nov 2008 06:13:46 -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 dB7uRR8rqd+b for ; Mon, 17 Nov 2008 06:13:45 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id B12D23A6814 for ; Mon, 17 Nov 2008 06:13:45 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-128.messagelabs.com!1226931224!4065212!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [136.182.1.14] Received: (qmail 19860 invoked from network); 17 Nov 2008 14:13:44 -0000 Received: from unknown (HELO motgate4.mot.com) (136.182.1.14) by server-7.tower-128.messagelabs.com with SMTP; 17 Nov 2008 14:13:44 -0000 Received: from il27exr04.cig.mot.com (il27exr04.mot.com [10.17.196.73]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id mAHEDdoV010795; Mon, 17 Nov 2008 07:13:44 -0700 (MST) Received: from az10vts04.mot.com (il27vts04.cig.mot.com [10.17.196.88]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id mAHEDcpY020771; Mon, 17 Nov 2008 08:13:38 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id mAHEDbsi020705; Mon, 17 Nov 2008 08:13:37 -0600 (CST) Message-ID: <49217C0C.80202@gmail.com> Date: Mon, 17 Nov 2008 15:13:32 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Teco Boot References: <49215489.9090903@gmail.com> <002401c948bb$0dfd7b50$29f871f0$@nl> In-Reply-To: <002401c948bb$0dfd7b50$29f871f0$@nl> X-Antivirus: avast! (VPS 081116-0, 16/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Teco Boot wrote: >>> Nit, Figure 3: >>>> -------+------- ---+------- Transmission >>>> ------+------- -------+------- -------+------- Ranges >>>> \|/ \|/ \|/ \|/ \|/ >>>> | | | | | >>>> +-+-+ +-+-+ +-+-+ +-+-+ +-+-+ >>>> | A | | B | | C | | D | | E | >>>> +---+ +---+ +---+ +---+ +---+ >>>> >>>> In this simple network, a transmission by the node C reaches only >>>> nodes B and D on the MANET link, due to the limited transmission >>>> range of the wireless broadcast interface. Similarly, a >>>> transmission from node B reaches only nodes A and C and a >>>> transmission by node D reaches only node E- the latter might be >>>> due to environmental >>>> interference or obstacles, transmission power levels or antenna >>>> properties of node C or D (e.g. directional antennas on either or >>>> both of C and D). >>> The picture makes think there's a directional antenna only on D, >>> not on C, and oriented towards E. >> That could be the case, yes. > > Directional antennas provide beam forming for transmit and receive. > It could be the case that there is a directional antenna, but directional > antennas do NOT introduce unidirectional reachability. Or physical laws are > updated recently... > > Perhaps D sends with lower power than C, or there is noise or interference > on C. Or C has low sensitive receiver. I kind of agree Teco. My issue is just to have a coherent description with a particular case with the particular whys, coherent, non-contradictory. For example, we could say: for equally distanced B-C-D, a packet sent by C arrives faster to B than to D; this is so because of noise interference on D. An ND implication is that DAD timers on C and D may need to reflect this difference (be different). But I'm not keen on saying: packets from C to B may sometimes arrive whereas from D to B may not, because some interference may happen or because D's or C's antennas may be more directional than others. This description _is_ generic, but is it helpful enough to setting AUTOCONF goals? This would also give an opportunity to mention DAD, otherwise not mentioned in the draft. Just some thoughts... Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 17 06:17:03 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA10A3A69E4; Mon, 17 Nov 2008 06:17:03 -0800 (PST) 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 0FB8A28C10B for ; Mon, 17 Nov 2008 06:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.609 X-Spam-Level: X-Spam-Status: No, score=-5.609 tagged_above=-999 required=5 tests=[AWL=0.990, 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 WzKxsJ4cW4YY for ; Mon, 17 Nov 2008 06:17:01 -0800 (PST) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id 0338A28C0E4 for ; Mon, 17 Nov 2008 06:17:00 -0800 (PST) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id mAHEGwqg009515 for ; Mon, 17 Nov 2008 14:16:58 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id mAHEGwDf020199 for ; Mon, 17 Nov 2008 14:16:58 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 17 Nov 2008 14:16:57 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 17 Nov 2008 14:16:57 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 17 Nov 2008 14:16:55 -0000 Message-ID: In-Reply-To: <4921798C.2010301@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] draft-clausen-manet-linktype Thread-Index: AclIvTKojZe8CM7dR2mtJKuDLu/+uwAAG1MQ References: <49215489.9090903@gmail.com> <49217694.4040205@gmail.com> <4921798C.2010301@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 17 Nov 2008 14:16:57.0568 (UTC) FILETIME=[2652BE00:01C948BF] Cc: autoconf@ietf.org Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > Hiding my head in the sand about which link layer I'm using, in a > document about link layer types It's not a document about link layer types. It's a document about the broad characteristics of wireless links, and how they differ from typical wired links. What's important is that there are some widely use links (and just 802.11 would be sufficient for this to be true) that do not behave like an Ethernet. And, despite that IP was originally intended to be a network layer running over a link layer without knowing what that link layer is, protocols have developed assuming that all the world is like an Ethernet. But (and it's pretty elementary stuff to anyone who works with radio systems) all the world is not like an Ethernet. However it is clear that this has to be said, and spelled out. And as I (not an author of this document of course) see it, that's the job of this document. Then (the architecture document) if links are not all like Ethernets, what are the consequences? Precisely what long list of wireless systems have those consequences isn't the point. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 17 07:16:14 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F4173A6848; Mon, 17 Nov 2008 07:16:14 -0800 (PST) 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 3DE063A6848 for ; Mon, 17 Nov 2008 07:16:12 -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 66B8E8VfUJpD for ; Mon, 17 Nov 2008 07:16:11 -0800 (PST) Received: from mho-02-bos.mailhop.org (mho-02-bos.mailhop.org [63.208.196.179]) by core3.amsl.com (Postfix) with ESMTP id BDBB03A6898 for ; Mon, 17 Nov 2008 07:15:44 -0800 (PST) Received: from [130.129.29.141] by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1L25pG-000Njm-T8; Mon, 17 Nov 2008 15:15:43 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 130.129.29.141 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+5gVc7O7157NEYAO2aW3wR In-Reply-To: <4921798C.2010301@gmail.com> References: <49215489.9090903@gmail.com> <49217694.4040205@gmail.com> <4921798C.2010301@gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <457BAFB4-F3C9-4DBA-89F3-23E6F2665195@thomasclausen.org> From: Thomas Heide Clausen Date: Mon, 17 Nov 2008 16:16:10 +0100 To: Alexandru Petrescu X-Mailer: Apple Mail (2.753.1) Cc: autoconf@ietf.org Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org On Nov 17, 2008, at 15:02 PM, Alexandru Petrescu wrote: > Dearlove, Christopher (UK) wrote: >>> It was not the intention to make it complete, but to have a start >>> list >>> of such things. To make it more complete one would simply add >>> more items. >> I agree with Thomas, attempting to list possible systems is not a >> good idea. Quoting one or two examples (e.g. 802.11) to give an >> example of the problems is useful. But any attempt to provide >> anything >> comprehensive is doomed to double failure. Failure to catch >> everything, >> and failure in that it might suggest things that aren't listed aren't >> included. That does mean that when quoting an example, it is >> important >> to make clear it is just that and no more. > > I wouldnt go as far as trying to make it comprehensive list, of > course. But doing my best - yes. I really would list the links > which concerns us. E.g. I'm concerned by WiFi and Bluetooth in my > work - none is UDLR, thus no need to mention the on-off kind of > behaviour. I'm not concerned by satellite. > > You'd be concerned by other links, welcome to add it. > > Hiding my head in the sand about which link layer I'm using, in a > document about link layer types... risks me being taken not seriously. > I think that this is not a matter of "hiding ones heads" anywhere, Alex. The intent is to say that "Here's the abstract set of L2 properties that we're designing MANET protocols to. Any link-layer providing this (or better), will work." I'm on board with Chris on the "cite one or two examples", however I do not believe that we can do a reasonable job of enumerating all possible L2s that exist, has existed and will exist. I think that we're better served by being a notch more abstract. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 17 07:17:18 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C0F23A6814; Mon, 17 Nov 2008 07:17:18 -0800 (PST) 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 BEE353A682E for ; Mon, 17 Nov 2008 07:17:16 -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 kIOvvZfz3JTJ for ; Mon, 17 Nov 2008 07:17:16 -0800 (PST) Received: from mho-02-bos.mailhop.org (mho-02-bos.mailhop.org [63.208.196.179]) by core3.amsl.com (Postfix) with ESMTP id 009AE3A67A6 for ; Mon, 17 Nov 2008 07:17:16 -0800 (PST) Received: from [130.129.29.141] by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1L25qk-000O88-Ql; Mon, 17 Nov 2008 15:17:14 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 130.129.29.141 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19xq3Urcl/J51f7bW+S7S9K In-Reply-To: References: <49215489.9090903@gmail.com> <49217694.4040205@gmail.com> <4921798C.2010301@gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <7C14CF83-E5A5-41D0-8E3A-9824EF78339E@thomasclausen.org> From: Thomas Heide Clausen Date: Mon, 17 Nov 2008 16:17:41 +0100 To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.753.1) Cc: autoconf@ietf.org Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org On Nov 17, 2008, at 15:16 PM, Dearlove, Christopher (UK) wrote: > >> Hiding my head in the sand about which link layer I'm using, in a >> document about link layer types > > It's not a document about link layer types. It's a document about > the broad characteristics of wireless links, and how they differ > from typical wired links. What's important is that there are some > widely use links (and just 802.11 would be sufficient for this to > be true) that do not behave like an Ethernet. And, despite that IP > was originally intended to be a network layer running over a link > layer without knowing what that link layer is, protocols have > developed assuming that all the world is like an Ethernet. But > (and it's pretty elementary stuff to anyone who works with radio > systems) all the world is not like an Ethernet. However it is > clear that this has to be said, and spelled out. And as I (not > an author of this document of course) see it, that's the job of > this document. Then (the architecture document) if links are not > all like Ethernets, what are the consequences? Precisely what > long list of wireless systems have those consequences isn't the > point. Chris is right on the spot with these remarks, at least as far as the intent of the author of the document. Thomas _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 17 07:20:09 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A95428C115; Mon, 17 Nov 2008 07:20:09 -0800 (PST) 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 84BA83A6814 for ; Mon, 17 Nov 2008 07:20:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.774 X-Spam-Level: X-Spam-Status: No, score=-5.774 tagged_above=-999 required=5 tests=[AWL=0.825, 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 nRME00w583hI for ; Mon, 17 Nov 2008 07:20:06 -0800 (PST) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id 1D6283A67B5 for ; Mon, 17 Nov 2008 07:20:05 -0800 (PST) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id mAHFK1Ff003282 for ; Mon, 17 Nov 2008 15:20:01 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id mAHFK1a0023724 for ; Mon, 17 Nov 2008 15:20:01 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 17 Nov 2008 15:20:00 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 17 Nov 2008 15:20:00 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 17 Nov 2008 15:20:00 -0000 Message-ID: In-Reply-To: <457BAFB4-F3C9-4DBA-89F3-23E6F2665195@thomasclausen.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] draft-clausen-manet-linktype Thread-Index: AclIx18Up4/wQzrCRJSQzaTdgHIhXAAADbfw References: <49215489.9090903@gmail.com> <49217694.4040205@gmail.com> <4921798C.2010301@gmail.com> <457BAFB4-F3C9-4DBA-89F3-23E6F2665195@thomasclausen.org> From: "Dearlove, Christopher (UK)" To: "Thomas Heide Clausen" , "Alexandru Petrescu" X-OriginalArrivalTime: 17 Nov 2008 15:20:00.0339 (UTC) FILETIME=[F507CA30:01C948C7] Cc: autoconf@ietf.org Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > I'm on board with Chris on the "cite one or two examples" What I didn't say however, was that, while 802.11 is the most obvious example, a second example that's significantly different, while still being clearly appropriate, would have the advantage of making it clear that this is not just about 802.11. 802.15.4 might serve, or possibly a non-IEEE example. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 17 08:20:43 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E22F3A6A22; Mon, 17 Nov 2008 08:20:43 -0800 (PST) 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 EEAB83A69C5 for ; Mon, 17 Nov 2008 08:20: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 qGifqhL32daz for ; Mon, 17 Nov 2008 08:20:40 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id AD39A3A69BA for ; Mon, 17 Nov 2008 08:20:39 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=df68qxLVd23nxfJ+ZTP+mHoPI21tivI7b1p7IQsaL9gdw92olx4YFlTZ5tQW2qJa; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [130.129.78.128] by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L26q7-0000Bg-6T for autoconf@ietf.org; Mon, 17 Nov 2008 11:20:39 -0500 Message-ID: <492199D7.2020108@earthlink.net> Date: Mon, 17 Nov 2008 08:20:39 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: autoconf@ietf.org References: <49215489.9090903@gmail.com> <49217694.4040205@gmail.com> <4921798C.2010301@gmail.com> <457BAFB4-F3C9-4DBA-89F3-23E6F2665195@thomasclausen.org> In-Reply-To: X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52d5040a2e30639b8cd9adac04c5dba881350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.78.128 Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello folks, I also agree that it would be a mistake to try to list those wireless media for which would apply. In fact, the problem is really quite difficult, if not intractable. Are 802.11a and 802.11b two different physical media? For the purposes of such a list, do different frequency bands present two different media? Two different codes? I remember a previous discussion about horizontal versus vertical handovers. That discussion was terminated by fiat without being able to provide a normative description about whether such media were similar enough to have horizontal handovers. Rough consensus seemed to be that it was time to publish the document anyway :-) We shouldn't go there with this document. Regards, Charlie P. Dearlove, Christopher (UK) wrote: >> I'm on board with Chris on the "cite one or two examples" >> > > What I didn't say however, was that, while 802.11 is the > most obvious example, a second example that's significantly > different, while still being clearly appropriate, would have > the advantage of making it clear that this is not just about > 802.11. 802.15.4 might serve, or possibly a non-IEEE example. > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > > > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 17 09:04:59 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 628723A6A01; Mon, 17 Nov 2008 09:04:59 -0800 (PST) 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 E751E3A6928 for ; Mon, 17 Nov 2008 09:04:57 -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 xMI-Pigm+Xz1 for ; Mon, 17 Nov 2008 09:04:57 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id EF5553A68B9 for ; Mon, 17 Nov 2008 09:04:56 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-153.messagelabs.com!1226941495!7865645!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 3408 invoked from network); 17 Nov 2008 17:04:56 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-153.messagelabs.com with SMTP; 17 Nov 2008 17:04:56 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mAHH4tjo002331; Mon, 17 Nov 2008 10:04:55 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id mAHH4trt021110; Mon, 17 Nov 2008 11:04:55 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id mAHH4sJF021103; Mon, 17 Nov 2008 11:04:54 -0600 (CST) Message-ID: <4921A435.3030104@gmail.com> Date: Mon, 17 Nov 2008 18:04:53 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Charles E. Perkins" References: <49215489.9090903@gmail.com> <49217694.4040205@gmail.com> <4921798C.2010301@gmail.com> <457BAFB4-F3C9-4DBA-89F3-23E6F2665195@thomasclausen.org> <492199D7.2020108@earthlink.net> In-Reply-To: <492199D7.2020108@earthlink.net> X-Antivirus: avast! (VPS 081116-0, 16/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Charles E. Perkins wrote: > > Hello folks, > > I also agree that it would be a mistake to try to list those > wireless media for which > would apply. > > In fact, the problem is really quite difficult, if not intractable. > Are 802.11a and 802.11b two different physical media? > For the purposes of such a list, do different frequency bands > present two different media? Two different codes? If the a/b difference is a problem then the solution is at their level and not above. I.e. IP can't fix the differences in coding or frequency. IP can't solve Figure3 B-C-D MANET Interface problems related to antenna directionality, radio interference and transmission range samedistance-differentdelays problems. I may be way off the common thought here... Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 17 09:22:44 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F7133A688F; Mon, 17 Nov 2008 09:22:44 -0800 (PST) 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 B6B6F3A68B9 for ; Mon, 17 Nov 2008 09:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.892 X-Spam-Level: X-Spam-Status: No, score=-5.892 tagged_above=-999 required=5 tests=[AWL=0.707, 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 O9h2a3LGYyKJ for ; Mon, 17 Nov 2008 09:22:41 -0800 (PST) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id BFE8F3A67A6 for ; Mon, 17 Nov 2008 09:22:40 -0800 (PST) Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id mAHHMYOM016057 for ; Mon, 17 Nov 2008 17:22:34 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id mAHHMYde012245 for ; Mon, 17 Nov 2008 17:22:34 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 17 Nov 2008 17:22:34 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 17 Nov 2008 17:22:33 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 17 Nov 2008 17:22:33 -0000 Message-ID: In-Reply-To: <4921A435.3030104@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] draft-clausen-manet-linktype Thread-Index: AclI1u/oppq30yTNQ/aUr20tlmdungAAD4Ow References: <49215489.9090903@gmail.com> <49217694.4040205@gmail.com> <4921798C.2010301@gmail.com> <457BAFB4-F3C9-4DBA-89F3-23E6F2665195@thomasclausen.org> <492199D7.2020108@earthlink.net> <4921A435.3030104@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" , "Charles E. Perkins" X-OriginalArrivalTime: 17 Nov 2008 17:22:33.0945 (UTC) FILETIME=[141F0490:01C948D9] Cc: autoconf@ietf.org Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Alexander Petrescu wrote: > Charles E. Perkins wrote: >> In fact, the problem is really quite difficult, if not intractable. >> Are 802.11a and 802.11b two different physical media? >> For the purposes of such a list, do different frequency bands >> present two different media? Two different codes? > If the a/b difference is a problem then the solution is at their level > and not above. I.e. IP can't fix the differences in coding or frequency. I think you've missed Charlie's point, which isn't that 802.11a/b is a problem as a link layer, it's that whether 802.11a and 802.11b are one standard or two (or more) is not clear, in fact it's not even a well-defined question. According to http://www.theregister.co.uk/2008/11/13/wimax_again/ the FDD and TDD modes of IEEE 802.16e-2005 are being considered as separate standards by the ITU for IMT-2000 inclusion. This is not directly relevant to this document, but illustrates that "how many standards" is not just a technical question. However please note that, of my knowledge, this report may or may not be accurate, I have no personal knowledge of the issue. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 17 10:12:18 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9764D3A6A03; Mon, 17 Nov 2008 10:12:18 -0800 (PST) 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 83E9C3A6948 for ; Mon, 17 Nov 2008 10:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rC7mlpsVrGdX for ; Mon, 17 Nov 2008 10:12:15 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 689A23A68AD for ; Mon, 17 Nov 2008 10:12:15 -0800 (PST) Received: (qmail 25128 invoked from network); 17 Nov 2008 19:12:11 +0100 Received: from unknown (HELO M90Teco) (12.104.246.2) by server9.hosting2go.nl with SMTP; 17 Nov 2008 19:12:11 +0100 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" , "'Alexandru Petrescu'" , "'Charles E. Perkins'" References: <49215489.9090903@gmail.com> <49217694.4040205@gmail.com> <4921798C.2010301@gmail.com> <457BAFB4-F3C9-4DBA-89F3-23E6F2665195@thomasclausen.org> <492199D7.2020108@earthlink.net> <4921A435.3030104@gmail.com> In-Reply-To: Date: Mon, 17 Nov 2008 19:12:07 +0100 Message-ID: <005501c948e0$0367d3a0$0a377ae0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclI1u/oppq30yTNQ/aUr20tlmdungAAD4OwAAFyacA= Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > I think you've missed Charlie's point, which isn't that > 802.11a/b is a problem as a link layer, it's that whether > 802.11a and 802.11b are one standard or two (or more) is > not clear, in fact it's not even a well-defined question. [Teco:] Agreed. By the way, the 11a / 11b are "retired" amendments, both are "rolled into" in IEEE 802.11-2007. Terms "retired" and "rolled into" are out of 802.11-2007. Far more important is the two modes 802.11 can operate in: IBSS and BSS. The MANET link would only apply to IBSS: >>> IEEE 802.11-2007: 3.5 ad hoc network: Often used as a venacular term for an independent basic service set (IBSS). <<< An IBSS is NOT equivalent with a MANET: >>> IEEE 802.11-2007: An IBSS consists of STAs that are directly connected. <<< The target of MANET routing is repairing connectivity problems when STAs are out of reach from each other. But this implies that the topology is not in line with the service definition for IBSS. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 17 10:14:53 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A04C13A692D; Mon, 17 Nov 2008 10:14:53 -0800 (PST) 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 ABE7D3A692D for ; Mon, 17 Nov 2008 10:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjBzV0rbtMAf for ; Mon, 17 Nov 2008 10:14:52 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 9DCCA3A6835 for ; Mon, 17 Nov 2008 10:14:51 -0800 (PST) Received: (qmail 26547 invoked from network); 17 Nov 2008 19:14:48 +0100 Received: from unknown (HELO M90Teco) (12.104.246.2) by server9.hosting2go.nl with SMTP; 17 Nov 2008 19:14:48 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <49215489.9090903@gmail.com> <49217694.4040205@gmail.com> <4921798C.2010301@gmail.com> <457BAFB4-F3C9-4DBA-89F3-23E6F2665195@thomasclausen.org> <492199D7.2020108@earthlink.net> <4921A435.3030104@gmail.com> In-Reply-To: <4921A435.3030104@gmail.com> Date: Mon, 17 Nov 2008 19:14:47 +0100 Message-ID: <005601c948e0$60eb5740$22c205c0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclI1u4AhgbXquOmR0OjNrWrPQrbewACR3cA Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > IP can't solve Figure3 B-C-D MANET Interface problems related to > antenna > directionality, radio interference and transmission range > samedistance-differentdelays problems. Again: the unidirectional problem CANNOT be caused by directional antennas. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 17 10:32:38 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CC123A68AC; Mon, 17 Nov 2008 10:32:38 -0800 (PST) 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 78CDD3A68AC for ; Mon, 17 Nov 2008 10:32:37 -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 q7W6G3Bjpgnw for ; Mon, 17 Nov 2008 10:32:36 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 46E3C3A6835 for ; Mon, 17 Nov 2008 10:32:36 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-128.messagelabs.com!1226946755!11069970!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 22924 invoked from network); 17 Nov 2008 18:32:35 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-128.messagelabs.com with SMTP; 17 Nov 2008 18:32:35 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mAHIWYiI022840; Mon, 17 Nov 2008 11:32:34 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id mAHIWYac017423; Mon, 17 Nov 2008 12:32:34 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id mAHIWXTX017398; Mon, 17 Nov 2008 12:32:33 -0600 (CST) Message-ID: <4921B8C0.2000103@gmail.com> Date: Mon, 17 Nov 2008 19:32:32 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <49215489.9090903@gmail.com> <49217694.4040205@gmail.com> <4921798C.2010301@gmail.com> <457BAFB4-F3C9-4DBA-89F3-23E6F2665195@thomasclausen.org> <492199D7.2020108@earthlink.net> <4921A435.3030104@gmail.com> In-Reply-To: X-Antivirus: avast! (VPS 081116-0, 16/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Christopher, please allow me top-posting in this case. I do not agree with this document. Although I may have seen in practice some of the problems mentioned in this document (e.g. the B-C-D asymetricity in Figure 2) the solutions were not at IP level but below (e.g. MAC repeater, antenna range extender). IPv6 works ok over WiFi. Alex Dearlove, Christopher (UK) wrote: > Alexander Petrescu wrote: >> Charles E. Perkins wrote: >>> In fact, the problem is really quite difficult, if not intractable. >>> Are 802.11a and 802.11b two different physical media? >>> For the purposes of such a list, do different frequency bands >>> present two different media? Two different codes? > >> If the a/b difference is a problem then the solution is at their level > >> and not above. I.e. IP can't fix the differences in coding or > frequency. > > I think you've missed Charlie's point, which isn't that > 802.11a/b is a problem as a link layer, it's that whether > 802.11a and 802.11b are one standard or two (or more) is > not clear, in fact it's not even a well-defined question. > > According to http://www.theregister.co.uk/2008/11/13/wimax_again/ > the FDD and TDD modes of IEEE 802.16e-2005 are being considered > as separate standards by the ITU for IMT-2000 inclusion. This > is not directly relevant to this document, but illustrates that > "how many standards" is not just a technical question. > > However please note that, of my knowledge, this report may or may > not be accurate, I have no personal knowledge of the issue. > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 17 10:40:28 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE1A23A6A3C; Mon, 17 Nov 2008 10:40:27 -0800 (PST) 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 223503A68AC for ; Mon, 17 Nov 2008 10:40: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 RLspqdZt9Zbf for ; Mon, 17 Nov 2008 10:40:23 -0800 (PST) Received: from mho-02-bos.mailhop.org (mho-02-bos.mailhop.org [63.208.196.179]) by core3.amsl.com (Postfix) with ESMTP id 8ACA43A6A3C for ; Mon, 17 Nov 2008 10:40:23 -0800 (PST) Received: from [130.129.78.103] by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1L291K-000CTY-Ds; Mon, 17 Nov 2008 18:40:22 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 130.129.78.103 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18UxrOae1KuYoCNwtPTPNeZ In-Reply-To: <4921B8C0.2000103@gmail.com> References: <49215489.9090903@gmail.com> <49217694.4040205@gmail.com> <4921798C.2010301@gmail.com> <457BAFB4-F3C9-4DBA-89F3-23E6F2665195@thomasclausen.org> <492199D7.2020108@earthlink.net> <4921A435.3030104@gmail.com> <4921B8C0.2000103@gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <1AC33188-375F-40DE-8EF4-7B2C5C4E1E56@ThomasClausen.org> From: Thomas Heide Clausen Date: Mon, 17 Nov 2008 19:40:48 +0100 To: Alexandru Petrescu X-Mailer: Apple Mail (2.753.1) Cc: autoconf@ietf.org Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Alex, You are absolutely right, IP works fine over some classic WiFi configurations, such as hosts-accesspoints or a fully connected graph of hosts. The kind of connectivity that this document is describing is, however, neither of these two. Thomas On Nov 17, 2008, at 19:32 PM, Alexandru Petrescu wrote: > Christopher, please allow me top-posting in this case. > > I do not agree with this document. Although I may have seen in > practice some of the problems mentioned in this document (e.g. the > B-C-D asymetricity in Figure 2) the solutions were not at IP level > but below (e.g. MAC repeater, antenna range extender). IPv6 works > ok over WiFi. > > Alex > > Dearlove, Christopher (UK) wrote: >> Alexander Petrescu wrote: >>> Charles E. Perkins wrote: >>>> In fact, the problem is really quite difficult, if not intractable. >>>> Are 802.11a and 802.11b two different physical media? >>>> For the purposes of such a list, do different frequency bands >>>> present two different media? Two different codes? >>> If the a/b difference is a problem then the solution is at their >>> level >>> and not above. I.e. IP can't fix the differences in coding or >> frequency. >> I think you've missed Charlie's point, which isn't that >> 802.11a/b is a problem as a link layer, it's that whether >> 802.11a and 802.11b are one standard or two (or more) is >> not clear, in fact it's not even a well-defined question. >> According to http://www.theregister.co.uk/2008/11/13/wimax_again/ >> the FDD and TDD modes of IEEE 802.16e-2005 are being considered >> as separate standards by the ITU for IMT-2000 inclusion. This >> is not directly relevant to this document, but illustrates that >> "how many standards" is not just a technical question. >> However please note that, of my knowledge, this report may or may >> not be accurate, I have no personal knowledge of the issue. >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 17 11:04:01 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDFBD3A6928; Mon, 17 Nov 2008 11:04:01 -0800 (PST) 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 44DBF3A68A2 for ; Mon, 17 Nov 2008 11:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuV15Y1W+rw3 for ; Mon, 17 Nov 2008 11:03:59 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 28D213A67A6 for ; Mon, 17 Nov 2008 11:03:59 -0800 (PST) Received: (qmail 21100 invoked from network); 17 Nov 2008 20:03:49 +0100 Received: from unknown (HELO M90Teco) (130.129.95.96) by server9.hosting2go.nl with SMTP; 17 Nov 2008 20:03:49 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <49215489.9090903@gmail.com> <49217694.4040205@gmail.com> <4921798C.2010301@gmail.com> <457BAFB4-F3C9-4DBA-89F3-23E6F2665195@thomasclausen.org> <492199D7.2020108@earthlink.net> <4921A435.3030104@gmail.com> <4921B8C0.2000103@gmail.com> In-Reply-To: <4921B8C0.2000103@gmail.com> Date: Mon, 17 Nov 2008 20:03:17 +0100 Message-ID: <005701c948e7$393ca210$abb5e630$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclI4uBR/aYp+4XuT7Ci0Hpg6KbbvgAA3CEw Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > IPv6 works ok over WiFi. Alex, Are you trying to confuse us? Please read my posting on IBSS and the requirement on direct STA - STA connectivity. Where is described how to run IPv6 over a network that isn't? There are many solutions, and running a MANET routing protocol is just one of them. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 17 11:38:02 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25BC53A69D8; Mon, 17 Nov 2008 11:38:02 -0800 (PST) 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 2B67A3A69A3 for ; Mon, 17 Nov 2008 11:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JaSE4E7NHML for ; Mon, 17 Nov 2008 11:37:59 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id B46253A696D for ; Mon, 17 Nov 2008 11:37:58 -0800 (PST) Received: from [130.129.63.219] (unknown [130.129.63.219]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 17CDF5CBD28; Mon, 17 Nov 2008 20:37:54 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Teco Boot In-Reply-To: <005501c948e0$0367d3a0$0a377ae0$@nl> References: <492154 89.9090903@gmail.com> <49217694.4040205@gmail.com> <4921798C.2010301@gmail.com> <457BAFB4-F3C9-4DBA-89 F3-23E6F2665195@thomasclausen.org> <492199D7.2020108@earthlink.net> <4921A435.3030104 @gmail.com> <005501c948e0$0367d3a0$0a377ae0$@nl> Organization: Universidad Carlos III de Madrid Date: Mon, 17 Nov 2008 20:33:00 +0100 Message-Id: <1226950380.4512.84.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: autoconf@ietf.org Subject: Re: [Autoconf] draft-clausen-manet-linktype X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0367935653==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============0367935653== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-XlEJt8ix+hYfO4eIDkr8" --=-XlEJt8ix+hYfO4eIDkr8 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Teco, > An IBSS is NOT equivalent with a MANET: > >>> IEEE 802.11-2007: > An IBSS consists of STAs that are directly connected. > <<< > The target of MANET routing is repairing connectivity problems when STAs = are > out of reach from each other. But this implies that the topology is not i= n > line with the service definition for IBSS. I'm not sure I got this right. AFAIK, in a practical deployment of an IBSS wireless network, you might end up with nodes that are not directly reachable but belong to the same IBSS. Since there is no central entity (like the AP), there is no way of ensuring that all nodes from the same IBSS have direct connectivity to each other, right? Carlos >=20 > Teco. >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2009: 2nd Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-XlEJt8ix+hYfO4eIDkr8 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkkhxuwACgkQNdy6TdFwT2cLxACgvWpbInQMdB5ZOSJOUsnv2VRH p5kAoKoLoOy1TE1GCPGbX6J+QaHys2VF =gAeP -----END PGP SIGNATURE----- --=-XlEJt8ix+hYfO4eIDkr8-- --===============0367935653== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf --===============0367935653==-- From autoconf-bounces@ietf.org Mon Nov 17 12:35:55 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3472D3A69E3; Mon, 17 Nov 2008 12:35:55 -0800 (PST) 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 64A5C28C0F2 for ; Mon, 17 Nov 2008 12:35:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkIIqMFNpHHz for ; Mon, 17 Nov 2008 12:35:52 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 4952428C0EA for ; Mon, 17 Nov 2008 12:35:52 -0800 (PST) Received: (qmail 13204 invoked from network); 17 Nov 2008 21:35:44 +0100 Received: from unknown (HELO M90Teco) (130.129.95.96) by server9.hosting2go.nl with SMTP; 17 Nov 2008 21:35:44 +0100 From: "Teco Boot" To: References: <492154 89.9090903@gmail.com> <49217694.4040205@gmail.com> <4921798C.2010301@gmail.com> <457BAFB4-F3C9-4DBA-89 F3-23E6F2665195@thomasclausen.org> <492199D7.2020108@earthlink.net> <4921A435.3030104 @gmail.com> <005501c948e0$0367d3a0$0a377ae0$@nl> <1226950380.4512.84.camel@localhost> In-Reply-To: <1226950380.4512.84.camel@localhost> Date: Mon, 17 Nov 2008 21:35:12 +0100 Message-ID: <006b01c948f4$108520b0$318f6210$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclI6/+gcNLZHaoxRWu5OCPYvgMVzgAAB06Q Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > > An IBSS is NOT equivalent with a MANET: > > >>> IEEE 802.11-2007: > > An IBSS consists of STAs that are directly connected. > > <<< > > The target of MANET routing is repairing connectivity problems when > > STAs are out of reach from each other. But this implies that the > > topology is not in line with the service definition for IBSS. > > I'm not sure I got this right. AFAIK, in a practical deployment of an > IBSS wireless network, you might end up with nodes that are not > directly reachable but belong to the same IBSS. Since there is no > central entity (like the AP), there is no way of ensuring that all > nodes from the same IBSS have direct connectivity to each other, right? I agree on that theory and real world problems could deviate. But I think that it is important to make clear what the IEEE standard describes. And can someone help me what "venacular" means? Maybe it is a typo and should be "vernacular". >>> IEEE 802.11-2007: 3.5 ad hoc network: Often used as a venacular term for an independent basic service set (IBSS). <<< Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 17 14:24:12 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A24CE28C15B; Mon, 17 Nov 2008 14:24:12 -0800 (PST) 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 B587C28C15B for ; Mon, 17 Nov 2008 14:24:11 -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=[AWL=0.000, 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 uJg8SLs+ERjR for ; Mon, 17 Nov 2008 14:24:10 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id C0FC128C127 for ; Mon, 17 Nov 2008 14:24:10 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-153.messagelabs.com!1226960649!11380553!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 29852 invoked from network); 17 Nov 2008 22:24:09 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-153.messagelabs.com with SMTP; 17 Nov 2008 22:24:09 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mAHMO494014853; Mon, 17 Nov 2008 15:24:09 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id mAHMO3lF011221; Mon, 17 Nov 2008 16:24:03 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.24]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id mAHMO1ZZ011211; Mon, 17 Nov 2008 16:24:02 -0600 (CST) Message-ID: <4921EF01.8090307@gmail.com> Date: Mon, 17 Nov 2008 23:24:01 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Teco Boot References: <49215489.9090903@gmail.com> <49217694.4040205@gmail.com> <4921798C.2010301@gmail.com> <457BAFB4-F3C9-4DBA-89F3-23E6F2665195@thomasclausen.org> <492199D7.2020108@earthlink.net> <4921A435.3030104@gmail.com> <005501c948e0$0367d3a0$0a377ae0$@nl> In-Reply-To: <005501c948e0$0367d3a0$0a377ae0$@nl> X-Antivirus: avast! (VPS 081117-0, 17/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org Subject: Re: [Autoconf] STAs out of reach from each other 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Teco Boot wrote: [...] > An IBSS is NOT equivalent with a MANET: > >>>> IEEE 802.11-2007: > An IBSS consists of STAs that are directly connected. <<<< > > The target of MANET routing is repairing connectivity problems when > STAs are out of reach from each other. I don't agree. When STAs are out of reach of each other it's because they're too far away one from the other. When STAs are too distanced routing protocols don't help. One needs basic connectivity when things are too far away. To obtain connectivity between STAs too distanced (more than 50m typically) one adds a longer range directional antenna, or higher-power amplifiers or repeaters (this latter tool being the same as with too long Ethernet cables). O'Reilly published some time ago some text in a book about practicals how to make wifi community networks over wider, kilometer-range areas, none uses MANET protocols but antennas in chips tins yes, if you wish. > But this implies that the topology is not in line with the service > definition for IBSS. I don't understand... actually I don't know what's the service of an IBSS (Independent Basic Service Set), I just know IBSS is like when we want to run a set of STAs without AP... but not sure what's that service... maybe it's a link-layer term that is irrelevant here. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 17 14:24:18 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56F6828C171; Mon, 17 Nov 2008 14:24:18 -0800 (PST) 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 9A91B28C172 for ; Mon, 17 Nov 2008 14:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.096 X-Spam-Level: X-Spam-Status: No, score=0.096 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckF6mk2Eh1di for ; Mon, 17 Nov 2008 14:24:15 -0800 (PST) Received: from mailoutb.tno.nl (mailoutb.tno.nl [134.221.1.17]) by core3.amsl.com (Postfix) with ESMTP id 50D8728C164 for ; Mon, 17 Nov 2008 14:24:15 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,620,1220220000"; d="scan'208";a="2935260" Received: from ms-dt01thalia.tno.nl (HELO ms-dt01thalia.tsn.tno.nl) ([134.221.225.157]) by mailhost1b.tno.nl with ESMTP; 17 Nov 2008 23:24:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 17 Nov 2008 23:24:13 +0100 Message-ID: <7877C5C0B5CC894AB26113CF06CF886301238C98@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <1226950380.4512.84.camel@localhost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] draft-clausen-manet-linktype Thread-Index: AclI7APajZlWd8CfTmOG+297UI6hQAAFGd8g References: <492154 89.9090903@gmail.com><49217694.4040205@gmail.com><4921798C.2010301@gmail.com><457BAFB4-F3C9-4DBA-89 F3-23E6F2665195@thomasclausen.org><492199D7.2020108@earthlink.net> <4921A435.3030104 @gmail.com><005501c948e0$0367d3a0$0a377ae0$@nl> <1226950380.4512.84.camel@localhost> From: "Velt, R. (Ronald) in 't" To: Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi, > -----Original Message----- > From: autoconf-bounces@ietf.org = > [mailto:autoconf-bounces@ietf.org] On Behalf Of Carlos Jes=FAs = > Bernardos Cano > Sent: maandag 17 november 2008 20:33 > To: Teco Boot > Cc: autoconf@ietf.org > Subject: Re: [Autoconf] draft-clausen-manet-linktype > = > Hi Teco, > = > > An IBSS is NOT equivalent with a MANET: > > >>> IEEE 802.11-2007: > > An IBSS consists of STAs that are directly connected. > > <<< > > The target of MANET routing is repairing connectivity problems when = > > STAs are out of reach from each other. But this implies that the = > > topology is not in line with the service definition for IBSS. > = > I'm not sure I got this right. AFAIK, in a practical = > deployment of an IBSS wireless network, you might end up with = > nodes that are not directly reachable but belong to the same = > IBSS. Since there is no central entity (like the AP), there = > is no way of ensuring that all nodes from the same IBSS have = > direct connectivity to each other, right? That's just because people are extending 802.11 IBSS mode beyond IEEE's ori= ginally intended model of usage. MANET is indeed the solution by which conn= ectivity can be achieved even if STA are not in direct reach of each other.= However, you might be facing some nasty problems with IBSS splits and merg= es, Time Stamp Function synchronisation, etc. Whether you come across these= is dependent on how well your particular devices / implementations deal wi= th this beyond-the-spec usage. IEEE 802.11s is another story, of course... Ronald > = > Carlos > = > > = > > Teco. > > = > > = > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www.ietf.org/mailman/listinfo/autoconf > -- = > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > WEEDEV 2009: 2nd Workshop on Experimental Evaluation and > Deployment Experiences on Vehicular networks > http://www.weedev.org/ > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > = This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/disclaimer/email.html _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 17 14:26:55 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0A463A6A7D; Mon, 17 Nov 2008 14:26:55 -0800 (PST) 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 307E828C127 for ; Mon, 17 Nov 2008 14:26:55 -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 CLYBERyHuwEH for ; Mon, 17 Nov 2008 14:26:54 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 51A723A6907 for ; Mon, 17 Nov 2008 14:26:54 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-153.messagelabs.com!1226960813!7544733!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 15058 invoked from network); 17 Nov 2008 22:26:53 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-153.messagelabs.com with SMTP; 17 Nov 2008 22:26:53 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mAHMQrlF016006; Mon, 17 Nov 2008 15:26:53 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id mAHMQrKu013489; Mon, 17 Nov 2008 16:26:53 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.24]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id mAHMQpnN013476; Mon, 17 Nov 2008 16:26:52 -0600 (CST) Message-ID: <4921EFAB.5010007@gmail.com> Date: Mon, 17 Nov 2008 23:26:51 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Teco Boot References: <49215489.9090903@gmail.com> <49217694.4040205@gmail.com> <4921798C.2010301@gmail.com> <457BAFB4-F3C9-4DBA-89F3-23E6F2665195@thomasclausen.org> <492199D7.2020108@earthlink.net> <4921A435.3030104@gmail.com> <4921B8C0.2000103@gmail.com> <005701c948e7$393ca210$abb5e630$@nl> In-Reply-To: <005701c948e7$393ca210$abb5e630$@nl> X-Antivirus: avast! (VPS 081117-0, 17/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Teco Boot wrote: >> IPv6 works ok over WiFi. > > Alex, > > Are you trying to confuse us? Teco: no, I'm not trying to confuse anybody, sorry for this impression, let me try to clarify. > Please read my posting on IBSS and the requirement on direct STA - > STA connectivity. I read it replied separately. > Where is described how to run IPv6 over a network that isn't? I think I agree. One first needs to build a link-layer network before being able to run IP over it. This draft's Figure 3 B-C-D is not such a link-layer network. > There are many solutions, and running a MANET routing protocol is > just one of them. I don't agree. MANET routing protocol runs at IP layer. IP layer can't be used to build link-layer networks. To build link-layer networks one uses link-layer tools. A humble opinion that is. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 17 14:37:29 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2B7F3A6A7D; Mon, 17 Nov 2008 14:37:28 -0800 (PST) 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 6C8283A6A7D for ; Mon, 17 Nov 2008 14:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6+gRzr9I-mu for ; Mon, 17 Nov 2008 14:37:27 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 412A23A6907 for ; Mon, 17 Nov 2008 14:37:26 -0800 (PST) Received: (qmail 20674 invoked from network); 17 Nov 2008 23:37:23 +0100 Received: from unknown (HELO M90Teco) (130.129.95.96) by server9.hosting2go.nl with SMTP; 17 Nov 2008 23:37:23 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <49215489.9090903@gmail.com> <49217694.4040205@gmail.com> <4921798C.2010301@gmail.com> <457BAFB4-F3C9-4DBA-89F3-23E6F2665195@thomasclausen.org> <492199D7.2020108@earthlink.net> <4921A435.3030104@gmail.com> <005501c948e0$0367d3a0$0a377ae0$@nl> <4921EF01.8090307@gmail.com> In-Reply-To: <4921EF01.8090307@gmail.com> Date: Mon, 17 Nov 2008 23:36:51 +0100 Message-ID: <007201c94905$0f7108e0$2e531aa0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclJAzdnUJqjYn+ZRMCvcHrptwg6rgAAMGgQ Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] STAs out of reach from each other 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > > An IBSS is NOT equivalent with a MANET: > > > >>>> IEEE 802.11-2007: > > An IBSS consists of STAs that are directly connected. > <<<< > > > > The target of MANET routing is repairing connectivity problems when > > STAs are out of reach from each other. > > I don't agree. When STAs are out of reach of each other it's because > they're too far away one from the other. When STAs are too distanced > routing protocols don't help. One needs basic connectivity when things > are too far away. To obtain connectivity between STAs too distanced > (more than 50m typically) one adds a longer range directional antenna, > or higher-power amplifiers or repeaters (this latter tool being the > same > as with too long Ethernet cables). O'Reilly published some time ago > some text in a book about practicals how to make wifi community > networks > over wider, kilometer-range areas, none uses MANET protocols but > antennas in chips tins yes, if you wish. Sorry, I can't follow. If you want to discuss what functionality the MANET Routing should provide, please post on MANET ML. > > But this implies that the topology is not in line with the service > > definition for IBSS. > > I don't understand... actually I don't know what's the service of an > IBSS (Independent Basic Service Set), I just know IBSS is like when we > want to run a set of STAs without AP... but not sure what's that > service... maybe it's a link-layer term that is irrelevant here. Please read standards before posting. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 17 14:42:49 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 268D23A6A59; Mon, 17 Nov 2008 14:42:49 -0800 (PST) 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 942A73A6A59 for ; Mon, 17 Nov 2008 14:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzJV-dKvoH5A for ; Mon, 17 Nov 2008 14:42:48 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 841983A689E for ; Mon, 17 Nov 2008 14:42:47 -0800 (PST) Received: (qmail 23301 invoked from network); 17 Nov 2008 23:42:43 +0100 Received: from unknown (HELO M90Teco) (130.129.95.96) by server9.hosting2go.nl with SMTP; 17 Nov 2008 23:42:43 +0100 From: "Teco Boot" To: "'Thomas Heide Clausen'" References: <49215489.9090903@gmail.com> <49217694.4040205@gmail.com> <4921798C.2010301@gmail.com> <457BAFB4-F3C9-4DBA-89F3-23E6F2665195@thomasclausen.org> <492199D7.2020108@earthlink.net> <4921A435.3030104@gmail.com> <4921B8C0.2000103@gmail.com> <1AC33188-375F-40DE-8EF4-7B2C5C4E1E56@ThomasClausen.org> In-Reply-To: <1AC33188-375F-40DE-8EF4-7B2C5C4E1E56@ThomasClausen.org> Date: Mon, 17 Nov 2008 23:42:11 +0100 Message-ID: <007901c94905$ce7e7d30$6b7b7790$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclI5BZC/wgJkcFxRCq6jH/l2iQNcQAIO+nw Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Thomas, Another topic on your draft. You suggest using /62 or /63 on non-MANET interfaces. (typo in figure 7, p:3 is /63). By using these prefix lengths, you exclude SLAAC. SLAAC requires /64 prefix lengths (RFC2462). I am not sure this was intended or not. Regards, Teco _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 17 14:49:50 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC8373A6935; Mon, 17 Nov 2008 14:49:50 -0800 (PST) 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 B698C3A6935 for ; Mon, 17 Nov 2008 14:49:48 -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 L7C4V1A89Ykp for ; Mon, 17 Nov 2008 14:49:48 -0800 (PST) Received: from mho-02-bos.mailhop.org (mho-02-bos.mailhop.org [63.208.196.179]) by core3.amsl.com (Postfix) with ESMTP id 0B7DD3A6922 for ; Mon, 17 Nov 2008 14:49:48 -0800 (PST) Received: from [130.129.78.103] by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1L2Cug-0008k5-G2; Mon, 17 Nov 2008 22:49:46 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 130.129.78.103 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18ybxx7//JNuFcEyIs+5iCz In-Reply-To: <007901c94905$ce7e7d30$6b7b7790$@nl> References: <49215489.9090903@gmail.com> <49217694.4040205@gmail.com> <4921798C.2010301@gmail.com> <457BAFB4-F3C9-4DBA-89F3-23E6F2665195@thomasclausen.org> <492199D7.2020108@earthlink.net> <4921A435.3030104@gmail.com> <4921B8C0.2000103@gmail.com> <1AC33188-375F-40DE-8EF4-7B2C5C4E1E56@ThomasClausen.org> <007901c94905$ce7e7d30$6b7b7790$@nl> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <830D28F2-7D26-4C26-AC24-49FD688C17B2@thomasclausen.org> From: Thomas Heide Clausen Date: Mon, 17 Nov 2008 23:50:14 +0100 To: Teco Boot X-Mailer: Apple Mail (2.753.1) Cc: autoconf@ietf.org Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Teco, Uhmm, I think that was unintended -- fat fingers and all. Sorry. Thomas On Nov 17, 2008, at 23:42 PM, Teco Boot wrote: > Hi Thomas, > > Another topic on your draft. > You suggest using /62 or /63 on non-MANET interfaces. (typo in > figure 7, p:3 > is /63). > > By using these prefix lengths, you exclude SLAAC. SLAAC requires / > 64 prefix > lengths (RFC2462). > I am not sure this was intended or not. > > Regards, Teco > > > > > _______________________________________________ > 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 autoconf-bounces@ietf.org Mon Nov 17 15:02:21 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BED728C17D; Mon, 17 Nov 2008 15:02:21 -0800 (PST) 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 E247B28C17D for ; Mon, 17 Nov 2008 15:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BeAu61Azd73 for ; Mon, 17 Nov 2008 15:02:19 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id BD6FA28C0D0 for ; Mon, 17 Nov 2008 15:02:18 -0800 (PST) Received: (qmail 30863 invoked from network); 18 Nov 2008 00:02:14 +0100 Received: from unknown (HELO M90Teco) (130.129.95.96) by server9.hosting2go.nl with SMTP; 18 Nov 2008 00:02:14 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <49215489.9090903@gmail.com> <49217694.4040205@gmail.com> <4921798C.2010301@gmail.com> <457BAFB4-F3C9-4DBA-89F3-23E6F2665195@thomasclausen.org> <492199D7.2020108@earthlink.net> <4921A435.3030104@gmail.com> <4921B8C0.2000103@gmail.com> <005701c948e7$393ca210$abb5e630$@nl> <4921EFAB.5010007@gmail.com> In-Reply-To: <4921EFAB.5010007@gmail.com> Date: Tue, 18 Nov 2008 00:01:42 +0100 Message-ID: <007a01c94908$884ec740$98ec55c0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclJA5iOJVwIPy6rRKejFXNwraPXmwAAsLaQ Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > One first needs to build a link-layer network before > being able to run IP over it. This draft's Figure 3 B-C-D is not such > a link-layer network. The manet-linktype I-D describes the behavior as briefly discussed in RFC4861 section 2.2. Link Types, asymmetric reachability. (check also errata, http://www.rfc-editor.org/errata_search.php?rfc=4861) Figure 3 B-C-D is such a link-layer network. > > There are many solutions, and running a MANET routing protocol is > > just one of them. > > I don't agree. MANET routing protocol runs at IP layer. IP layer > can't > be used to build link-layer networks. To build link-layer networks one > uses link-layer tools. A humble opinion that is. MANET routing protocols provide L3 connectivity over link-layer types with asymmetric reachability. No one said that MANET routing protocols would be used for to build link-layer networks See also RFC4861 Appendix B, last item, on ND over link types with asymmetric and non-transitive reachability. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 17 15:02:41 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 985BD28C1A3; Mon, 17 Nov 2008 15:02:41 -0800 (PST) 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 BBDE528C1A3 for ; Mon, 17 Nov 2008 15:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.204 X-Spam-Level: X-Spam-Status: No, score=-0.204 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yfydShgYC5p for ; Mon, 17 Nov 2008 15:02:40 -0800 (PST) Received: from mailoutb.tno.nl (mailoutb.tno.nl [134.221.1.17]) by core3.amsl.com (Postfix) with ESMTP id CCBF828C1A1 for ; Mon, 17 Nov 2008 15:02:39 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,620,1220220000"; d="scan'208";a="2935534" Received: from ms-dt01thalia.tno.nl (HELO ms-dt01thalia.tsn.tno.nl) ([134.221.225.157]) by mailhost1b.tno.nl with ESMTP; 18 Nov 2008 00:02:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 00:02:38 +0100 Message-ID: <7877C5C0B5CC894AB26113CF06CF886301238C99@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <4921EFAB.5010007@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] draft-clausen-manet-linktype Thread-Index: AclJA5tPXO0JI6HTRfKRQMx5JbVmiAAAekCw References: <49215489.9090903@gmail.com> <49217694.4040205@gmail.com> <4921798C.2010301@gmail.com> <457BAFB4-F3C9-4DBA-89F3-23E6F2665195@thomasclausen.org> <492199D7.2020108@earthlink.net> <4921A435.3030104@gmail.com> <4921B8C0.2000103@gmail.com> <005701c948e7$393ca210$abb5e630$@nl> <4921EFAB.5010007@gmail.com> From: "Velt, R. (Ronald) in 't" To: Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Alex, > > I don't agree. MANET routing protocol runs at IP layer. IP > layer can't be used to build link-layer networks. To build > link-layer networks one uses link-layer tools. A humble > opinion that is. IP is well suited for connecting together different links into a network. That's what it does. Say node A is running PPP over one piece of wire to node B and PPP over another piece of wire to node C. These are different links even though the underlying L2 technology is the same. IP connects the links. The more I think about it, the more I am inclined to say that there is no such thing as "a MANET link". Instead, a node sees a time-varying collection of links, one per node it can reach. The slightly odd thing (and infinite source of confusion) is that several of these links can be accessed through the same physical interface. My 2 cents, Ronald This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 17 15:24:38 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 252E83A6944; Mon, 17 Nov 2008 15:24:38 -0800 (PST) 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 C94173A6944 for ; Mon, 17 Nov 2008 15:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 QHJXqSK0Bsih for ; Mon, 17 Nov 2008 15:24:36 -0800 (PST) Received: from mxav01.cc.niigata-u.ac.jp (mxav01.cc.niigata-u.ac.jp [133.35.17.129]) by core3.amsl.com (Postfix) with ESMTP id B28633A68EC for ; Mon, 17 Nov 2008 15:24:35 -0800 (PST) Received: from mxav01.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5E2CE4F4202 for ; Tue, 18 Nov 2008 08:24:32 +0900 (JST) Received: from chamame.ie.niigata-u.ac.jp (chamame.ie.niigata-u.ac.jp [133.35.169.34]) by mxav01.cc.niigata-u.ac.jp (Postfix) with SMTP id 5384C4F41F5 for ; Tue, 18 Nov 2008 08:24:32 +0900 (JST) Received: (qmail 12510 invoked from network); 18 Nov 2008 08:24:32 +0900 Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 18 Nov 2008 08:24:32 +0900 Message-Id: <7.0.0.16.2.20081118081902.0869a340@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Tue, 18 Nov 2008 08:24:38 +0900 To: "Velt, R. (Ronald) in 't" , From: mase In-Reply-To: <7877C5C0B5CC894AB26113CF06CF886301238C99@ms-dt01thalia.tsn .tno.nl> References: <49215489.9090903@gmail.com> <49217694.4040205@gmail.com> <4921798C.2010301@gmail.com> <457BAFB4-F3C9-4DBA-89F3-23E6F2665195@thomasclausen.org> <492199D7.2020108@earthlink.net> <4921A435.3030104@gmail.com> <4921B8C0.2000103@gmail.com> <005701c948e7$393ca210$abb5e630$@nl> <4921EFAB.5010007@gmail.com> <7877C5C0B5CC894AB26113CF06CF886301238C99@ms-dt01thalia.tsn.tno.nl> Mime-Version: 1.0 Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org At 08:02 08/11/18, Velt, R. (Ronald) in 't wrote: >Hi Alex, > > > > > > I don't agree. MANET routing protocol runs at IP layer. IP > > layer can't be used to build link-layer networks. To build > > link-layer networks one uses link-layer tools. A humble > > opinion that is. > >IP is well suited for connecting together different links into a >network. That's what it does. Say node A is running PPP over one piece >of wire to node B and PPP over another piece of wire to node C. These >are different links even though the underlying L2 technology is the >same. IP connects the links. The more I think about it, the more I am >inclined to say that there is no such thing as "a MANET link". Instead, >a node sees a time-varying collection of links, one per node it can >reach. The slightly odd thing (and infinite source of confusion) is that >several of these links can be accessed through the same physical >interface. And this single interface can work as that of the router carrying packets between these links (This does not occur in wired network). Kenichi >My 2 cents, >Ronald >This e-mail and its contents are subject to the DISCLAIMER at >http://www.tno.nl/disclaimer/email.html > >_______________________________________________ >Autoconf mailing list >Autoconf@ietf.org >https://www.ietf.org/mailman/listinfo/autoconf _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 17 15:51:04 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6435928C11A; Mon, 17 Nov 2008 15:51:04 -0800 (PST) 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 E37A03A6873 for ; Mon, 17 Nov 2008 15:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ck4Zqc1pwPfx for ; Mon, 17 Nov 2008 15:51:02 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id D14A93A6A8D for ; Mon, 17 Nov 2008 15:51:01 -0800 (PST) Received: (qmail 14531 invoked from network); 18 Nov 2008 00:50:57 +0100 Received: from unknown (HELO M90Teco) (130.129.95.96) by server9.hosting2go.nl with SMTP; 18 Nov 2008 00:50:57 +0100 From: "Teco Boot" To: "'mase'" , "'Velt, R. \(Ronald\) in 't'" References: <49215489.9090903@gmail.com> <49217694.4040205@gmail.com> <4921798C.2010301@gmail.com> <457BAFB4-F3C9-4DBA-89F3-23E6F2665195@thomasclausen.org> <492199D7.2020108@earthlink.net> <4921A435.3030104@gmail.com> <4921B8C0.2000103@gmail.com> <005701c948e7$393ca210$abb5e630$@nl> <4921EFAB.5010007@gmail.com> <7877C5C0B5CC894AB26113CF06CF886301238C99@ms-dt01thalia.tsn.tno.nl> <7.0.0.16.2.20081118081902.0869a340@ie.niigata-u.ac.jp> In-Reply-To: <7.0.0.16.2.20081118081902.0869a340@ie.niigata-u.ac.jp> Date: Tue, 18 Nov 2008 00:50:26 +0100 Message-ID: <007b01c9490f$569915a0$03cb40e0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclJC6p04rh1cfapT6O0+u5uKLytcAAAje9Q Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > > > I don't agree. MANET routing protocol runs at IP layer. IP > > > layer can't be used to build link-layer networks. To build > > > link-layer networks one uses link-layer tools. A humble > > > opinion that is. > > > >IP is well suited for connecting together different links into a > >network. That's what it does. Say node A is running PPP over one piece > >of wire to node B and PPP over another piece of wire to node C. These > >are different links even though the underlying L2 technology is the > >same. IP connects the links. The more I think about it, the more I am > >inclined to say that there is no such thing as "a MANET link". > Instead, > >a node sees a time-varying collection of links, one per node it can > >reach. The slightly odd thing (and infinite source of confusion) is > that > >several of these links can be accessed through the same physical > >interface. > > And this single interface can work as that of the router carrying > packets between these links (This does not occur in wired network). There are examples of non-fully-meshed wired link-layer networks also, e.g. NBMA such as X.21, FR and ATM and some broadband access systems. Using logical interfaces for each P2P link is one way solving problems, but this could have disadvantages like increased resources on routers. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 17 17:34:59 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 657503A69AF; Mon, 17 Nov 2008 17:34:59 -0800 (PST) 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 4BBC228C0E6 for ; Mon, 17 Nov 2008 17:34:58 -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=[AWL=0.000, 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 JYvG7BdMeMqn for ; Mon, 17 Nov 2008 17:34:57 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 83A9C3A67E1 for ; Mon, 17 Nov 2008 17:34:57 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-128.messagelabs.com!1226972096!11088388!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 29509 invoked from network); 18 Nov 2008 01:34:56 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-128.messagelabs.com with SMTP; 18 Nov 2008 01:34:56 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mAI1Yu3K003827; Mon, 17 Nov 2008 18:34:56 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id mAI1YtpK000730; Mon, 17 Nov 2008 19:34:55 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.52]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id mAI1Ys4m000703; Mon, 17 Nov 2008 19:34:54 -0600 (CST) Message-ID: <49221BBD.8000209@gmail.com> Date: Tue, 18 Nov 2008 02:34:53 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Velt, R. (Ronald) in 't" References: <49215489.9090903@gmail.com> <49217694.4040205@gmail.com> <4921798C.2010301@gmail.com> <457BAFB4-F3C9-4DBA-89F3-23E6F2665195@thomasclausen.org> <492199D7.2020108@earthlink.net> <4921A435.3030104@gmail.com> <4921B8C0.2000103@gmail.com> <005701c948e7$393ca210$abb5e630$@nl> <4921EFAB.5010007@gmail.com> <7877C5C0B5CC894AB26113CF06CF886301238C99@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <7877C5C0B5CC894AB26113CF06CF886301238C99@ms-dt01thalia.tsn.tno.nl> X-Antivirus: avast! (VPS 081117-0, 17/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Ronald, Velt, R. (Ronald) in 't wrote: > Hi Alex, > = > >> I don't agree. MANET routing protocol runs at IP layer. IP layer = >> can't be used to build link-layer networks. To build link-layer = >> networks one uses link-layer tools. A humble opinion that is. > = > IP is well suited for connecting together different links into a = > network. That's what it does. YEs, well suited for connecting one well-formed link to another = well-formed link. > Say node A is running PPP over one piece of wire to node B and PPP = > over another piece of wire to node C. YEs, ok. > These are different links even though the underlying L2 technology is > the same. I think you mean to say 'the same technology' to mean it has the same = name, like =FAsb', like a ptp link1 over usb and another ptp link2 over = another usb. I think you didn't mean to say that two point to point = links connect over the same medium which looks as ptp from some point to = another of its points, but shared from some other points to other points = within same medium. Such a medium doesn't exist. Or it's a badly = formed incomprehensible medium. > IP connects the links. Yes, provided the links are each well formed. Cables that intermittently connect because of false contacts are not links well formed and IP can't help with it. > The more I think about it, the more I am inclined to say that there > is no such thing as "a MANET link". Instead, a node sees a > time-varying collection of links, one per node it can reach. The > slightly odd thing (and infinite source of confusion) is that several > of these links can be accessed through the same physical interface. That gets indeed complex :-) Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email = ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 17 17:49:32 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3574E28C1D5; Mon, 17 Nov 2008 17:49:32 -0800 (PST) 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 24D7D28C1D5 for ; Mon, 17 Nov 2008 17:49:31 -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 LN89ZW3TEKxp for ; Mon, 17 Nov 2008 17:49:30 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 348B828C1BE for ; Mon, 17 Nov 2008 17:49:30 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-153.messagelabs.com!1226972968!5977516!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 26741 invoked from network); 18 Nov 2008 01:49:28 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-153.messagelabs.com with SMTP; 18 Nov 2008 01:49:28 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mAI1nMjH008700; Mon, 17 Nov 2008 18:49:28 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id mAI1nM0V029573; Mon, 17 Nov 2008 19:49:22 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.52]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id mAI1nLTJ029556; Mon, 17 Nov 2008 19:49:21 -0600 (CST) Message-ID: <49221F20.70002@gmail.com> Date: Tue, 18 Nov 2008 02:49:20 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Teco Boot References: <49215489.9090903@gmail.com> <49217694.4040205@gmail.com> <4921798C.2010301@gmail.com> <457BAFB4-F3C9-4DBA-89F3-23E6F2665195@thomasclausen.org> <492199D7.2020108@earthlink.net> <4921A435.3030104@gmail.com> <4921B8C0.2000103@gmail.com> <005701c948e7$393ca210$abb5e630$@nl> <4921EFAB.5010007@gmail.com> <007a01c94908$884ec740$98ec55c0$@nl> In-Reply-To: <007a01c94908$884ec740$98ec55c0$@nl> X-Antivirus: avast! (VPS 081117-0, 17/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Teco Boot wrote: >> One first needs to build a link-layer network before being able to >> run IP over it. This draft's Figure 3 B-C-D is not such a >> link-layer network. > > The manet-linktype I-D describes the behavior as briefly discussed in > RFC4861 section 2.2. Link Types, asymmetric reachability. I've always wondered what does the rfc4861 asymetricity mean in practice with respect to IPv6 over Ethernet rfc2464 and wifi. >>> There are many solutions, and running a MANET routing protocol is >>> just one of them. >> >> I don't agree. MANET routing protocol runs at IP layer. IP layer >> can't be used to build link-layer networks. To build link-layer >> networks one uses link-layer tools. A humble opinion that is. > > MANET routing protocols provide L3 connectivity over link-layer types > with asymmetric reachability. No one said that MANET routing > protocols would be used for to build link-layer networks Figure 3 B-C-D of draft-clausen doesn't say an 'asymmetric' link but more like an on-off diode type of link whereby B can reach C, C D but B can not reach D. For wifi that's a badly formed link, needs a mac repeater or a longer range device. MANET routing protocols are not for it. For that matter, the draft doesn't say 'asymmetric' anywhere... > See also RFC4861 Appendix B, last item, on ND over link types with > asymmetric and non-transitive reachability. The appendix of rfc4861 ND says: > Possible extensions for future [ND] study are: [...] > o Adding additional procedures for links where asymmetric and non- > transitive reachability is part of normal operations. Such > procedures might allow hosts and routers to find usable paths on, > e.g., radio links. Draft-clausen doesn't cite ND rfc4861. AUTOCONF tries to autoconfigure stuff, not to improve ND. It looks difficult to discern. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 17 19:53:02 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B7623A68DA; Mon, 17 Nov 2008 19:53:02 -0800 (PST) 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 769DB3A68DA for ; Mon, 17 Nov 2008 19:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZruQ3FP9KhN6 for ; Mon, 17 Nov 2008 19:53:00 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 2E2103A6828 for ; Mon, 17 Nov 2008 19:52:59 -0800 (PST) Received: (qmail 16242 invoked from network); 18 Nov 2008 04:52:48 +0100 Received: from unknown (HELO M90Teco) (12.104.246.2) by server9.hosting2go.nl with SMTP; 18 Nov 2008 04:52:48 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <49215489.9090903@gmail.com> <49217694.4040205@gmail.com> <4921798C.2010301@gmail.com> <457BAFB4-F3C9-4DBA-89F3-23E6F2665195@thomasclausen.org> <492199D7.2020108@earthlink.net> <4921A435.3030104@gmail.com> <4921B8C0.2000103@gmail.com> <005701c948e7$393ca210$abb5e630$@nl> <4921EFAB.5010007@gmail.com> <7877C5C0B5CC894AB26113CF06CF886301238C99@ms-dt01thalia.tsn.tno.nl> <49221BBD.8000209@gmail.com> In-Reply-To: <49221BBD.8000209@gmail.com> Date: Tue, 18 Nov 2008 04:52:46 +0100 Message-ID: <001501c94931$1faa00f0$5efe02d0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclJHeC6ZsxBcjuyRoeLgXpS0MUUKgAEu7iw Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > I think you didn't mean to say that two point to point > links connect over the same medium which looks as ptp from some point > to > another of its points, but shared from some other points to other > points > within same medium. Such a medium doesn't exist. Or it's a badly > formed incomprehensible medium. Strongly disagree. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 17 20:13:13 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7359928C1A6; Mon, 17 Nov 2008 20:13:13 -0800 (PST) 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 E6E8428C1A6 for ; Mon, 17 Nov 2008 20:13:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6rOhtuz-oUo for ; Mon, 17 Nov 2008 20:13:12 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id BAF0428C187 for ; Mon, 17 Nov 2008 20:13:11 -0800 (PST) Received: (qmail 21536 invoked from network); 18 Nov 2008 05:13:07 +0100 Received: from unknown (HELO M90Teco) (12.104.246.2) by server9.hosting2go.nl with SMTP; 18 Nov 2008 05:13:07 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <49215489.9090903@gmail.com> <49217694.4040205@gmail.com> <4921798C.2010301@gmail.com> <457BAFB4-F3C9-4DBA-89F3-23E6F2665195@thomasclausen.org> <492199D7.2020108@earthlink.net> <4921A435.3030104@gmail.com> <4921B8C0.2000103@gmail.com> <005701c948e7$393ca210$abb5e630$@nl> <4921EFAB.5010007@gmail.com> <007a01c94908$884ec740$98ec55c0$@nl> <49221F20.70002@gmail.com> In-Reply-To: <49221F20.70002@gmail.com> Date: Tue, 18 Nov 2008 05:13:05 +0100 Message-ID: <001601c94933$f624b3d0$e26e1b70$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclJH+ax63fEJSGUQ6KMqjPdyQA1NAAEWyJQ Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > >> One first needs to build a link-layer network before being able to > >> run IP over it. This draft's Figure 3 B-C-D is not such a > >> link-layer network. > > > > The manet-linktype I-D describes the behavior as briefly discussed in > > RFC4861 section 2.2. Link Types, asymmetric reachability. > > I've always wondered what does the rfc4861 asymetricity mean in > practice > with respect to IPv6 over Ethernet rfc2464 and wifi. There is more on this planet that you are aware of:-) > >>> There are many solutions, and running a MANET routing protocol is > >>> just one of them. > >> > >> I don't agree. MANET routing protocol runs at IP layer. IP layer > >> can't be used to build link-layer networks. To build link-layer > >> networks one uses link-layer tools. A humble opinion that is. > > > > MANET routing protocols provide L3 connectivity over link-layer types > > with asymmetric reachability. No one said that MANET routing > > protocols would be used for to build link-layer networks > > Figure 3 B-C-D of draft-clausen doesn't say an 'asymmetric' link but > more like an on-off diode type of link whereby B can reach C, C D but B > can not reach D. OK, multiple terms are used for the same meaning. Asymmetric is used where others use unidirectional. See recent postings on this topic. > For wifi that's a badly formed link, needs a mac > repeater or a longer range device. MANET routing protocols are not for > it. Strongly disagree. > For that matter, the draft doesn't say 'asymmetric' anywhere... Strongly disagree. Please reread the draft, especially section 6. > > See also RFC4861 Appendix B, last item, on ND over link types with > > asymmetric and non-transitive reachability. > > The appendix of rfc4861 ND says: > > Possible extensions for future [ND] study are: > [...] > > o Adding additional procedures for links where asymmetric and > non- > > transitive reachability is part of normal operations. Such > > procedures might allow hosts and routers to find usable paths > on, > > e.g., radio links. > > Draft-clausen doesn't cite ND rfc4861. > > AUTOCONF tries to autoconfigure stuff, not to improve ND. > > It looks difficult to discern. ND RFC is cited in the Autoconf charter, so is SLAAC (RFCs 2461, 2462). I think you have "traditional IP networks" (cited from charter) in mind. Please try to understand what a MANET really is. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 18 01:51:51 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA52C3A6AD3; Tue, 18 Nov 2008 01:51:51 -0800 (PST) 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 E26F63A6AD3 for ; Tue, 18 Nov 2008 01:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.98 X-Spam-Level: X-Spam-Status: No, score=-5.98 tagged_above=-999 required=5 tests=[AWL=0.619, 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 4hPxwYpwwTdm for ; Tue, 18 Nov 2008 01:51:50 -0800 (PST) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id E8E083A6AEB for ; Tue, 18 Nov 2008 01:51:49 -0800 (PST) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id mAI9pkUD020481 for ; Tue, 18 Nov 2008 09:51:46 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id mAI9pkL8022322 for ; Tue, 18 Nov 2008 09:51:46 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 18 Nov 2008 09:51:46 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Tue, 18 Nov 2008 09:51:45 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 18 Nov 2008 09:51:40 -0000 Message-ID: In-Reply-To: <49221F20.70002@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] draft-clausen-manet-linktype Thread-Index: AclJH+gY0r+QsbEmRL+IWBiridFmMQAQiPFA References: <49215489.9090903@gmail.com> <49217694.4040205@gmail.com> <4921798C.2010301@gmail.com> <457BAFB4-F3C9-4DBA-89F3-23E6F2665195@thomasclausen.org> <492199D7.2020108@earthlink.net> <4921A435.3030104@gmail.com> <4921B8C0.2000103@gmail.com> <005701c948e7$393ca210$abb5e630$@nl><4921EFAB.5010007@gmail.com> <007a01c94908$884ec740$98ec55c0$@nl> <49221F20.70002@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" , "Teco Boot" X-OriginalArrivalTime: 18 Nov 2008 09:51:45.0857 (UTC) FILETIME=[449E1310:01C94963] Cc: autoconf@ietf.org Subject: Re: [Autoconf] draft-clausen-manet-linktype 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > Figure 3 B-C-D of draft-clausen doesn't say an 'asymmetric' link but > more like an on-off diode type of link whereby B can reach C, C D but B > can not reach D. For wifi that's a badly formed link, needs a mac > repeater or a longer range device. MANET routing protocols are not for it. In many scenarios we don't have the luxury of installing MAC repeaters etc. we have to live with what we have and make best use of it. In this context, make best use means construct a MANET. That MANET may not use asymmetrically available links. But it will have to cope with that they may exist. In particular 802.11 broadcast (which you may need to find otherwise unknown neighbours) may have such propagation. OLSRv2, for example, creates a network that only uses symmetric links. But the NHDP component of it has to work even though links may be asymmetric. NHDP would be a lot simpler if node A, on receiving from node B could know that it could send to node B without having to verify that. But of course it can't. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 18 08:39:00 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0335A3A6A73; Tue, 18 Nov 2008 08:39:00 -0800 (PST) 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 8F76E3A6A73 for ; Tue, 18 Nov 2008 08:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 ke4Ue7MNNlpN for ; Tue, 18 Nov 2008 08:38:57 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id 6E05F3A69E5 for ; Tue, 18 Nov 2008 08:38:57 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 3so1663281ywj.49 for ; Tue, 18 Nov 2008 08:38:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=RKxrnUSrLlmLb98xYvxbBfuqYpqCYcCYtpJgxyf0Nk0=; b=Xa6jnuuSgYQVd1uZYoOIFuyYR7/ESM4fonqkQzXj+civbETijMJYG8oOsjcwKU6Bvz /bmNHznQdUirZmv4KPv9j4dGUTHFMkoqOyWW47aH/3b+zZyBRTFx2ng0Vs+xDdizgvht SPdTPs4rHIgEw/2rN/R9w9WEhNxTCNB9/hrbw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=DGuSMmmf7Zvy1QboZTV8v+vKLb6J9GqsbR8NIeprTW+i/AWXzMsp7B3XRScLUdnC7D aTlr58KgJkKBq8i8Zx06ro3W7TJGQdm2w3kUu6Li7HXgr5dSbSXMNQpFssycuWtx7ulh Akno7hftgaTLUfMJh2DFiLGnMxw/Uihfazz6g= Received: by 10.65.189.20 with SMTP id r20mr46709qbp.71.1227026332998; Tue, 18 Nov 2008 08:38:52 -0800 (PST) Received: from ?192.168.1.124? ([75.146.152.44]) by mx.google.com with ESMTPS id p6sm9650420qbp.17.2008.11.18.08.38.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 18 Nov 2008 08:38:52 -0800 (PST) Message-Id: From: Ian Chakeres To: autoconf@ietf.org In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 18 Nov 2008 06:57:51 -0500 References: X-Mailer: Apple Mail (2.929.2) Cc: Thomas Heide Clausen Subject: Re: [Autoconf] draft-clausen-manet-linktype - naming 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org I'd like to start a discussion thread on the naming of this draft/ linktype. I don't think that MANET should be in the name of the linktype. The characteristics and constraints of a linktype are not MANET specific. (I'd also like to repeat that MANET routing protocols will work quite happily over other link types as well.) I would rather describe these links as "non-reflexive and non- transitive (wireless) links". I'd also be happy with a nice acronym, like NBMA or UDLR. I'm interested in your thoughts. How do you think we should refer to this linktype? Ian On Nov 4, 2008, at 4:51 AM, Thomas Heide Clausen wrote: > Folks, > > As you know, we need to make progress on the architectural issues, > before we can hope to make progress on other matters within this WG. > One of the requests that have been made to us has been to "describe > the MANET Link Type", and so I have written together a strawman text > to this effect: > > http://www.ietf.org/internet-drafts/draft-clausen-manet-linktype-00.txt > > Feedback is, obviously, welcome -- preferably on the list such that > we could be prepared spend time on this also in MN. > > Note, however, that this is an individual I-D. > > I'd also like to draw your collective attention to: > > http://www.ietf.org/internet-drafts/draft-iab-ip-model-evolution-01.txt > > Which has served as a source of inspiration for the linktype text. > > Thanks, > > Thomas > _______________________________________________ > 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 autoconf-bounces@ietf.org Tue Nov 18 08:47:25 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 368CA28C1F3; Tue, 18 Nov 2008 08:47:25 -0800 (PST) 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 C8C9928C1F3 for ; Tue, 18 Nov 2008 08:47:23 -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 EsbCRrqVHvm4 for ; Tue, 18 Nov 2008 08:47:23 -0800 (PST) Received: from mho-01-bos.mailhop.org (mho-01-bos.mailhop.org [63.208.196.178]) by core3.amsl.com (Postfix) with ESMTP id 0139F28C1D7 for ; Tue, 18 Nov 2008 08:47:22 -0800 (PST) Received: from [130.129.78.103] by mho-01-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1L2TjU-0004qG-7S; Tue, 18 Nov 2008 16:47:20 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 130.129.78.103 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19ShFTHe6VUIq2KRLHCuZVW In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Thomas Heide Clausen Date: Tue, 18 Nov 2008 17:47:49 +0100 To: Ian Chakeres X-Mailer: Apple Mail (2.753.1) Cc: autoconf@ietf.org Subject: Re: [Autoconf] draft-clausen-manet-linktype - naming 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org On Nov 18, 2008, at 12:57 PM, Ian Chakeres wrote: > I'd like to start a discussion thread on the naming of this draft/ > linktype. > > I don't think that MANET should be in the name of the linktype. The > characteristics and constraints of a linktype are not MANET specific. > > (I'd also like to repeat that MANET routing protocols will work > quite happily over other link types as well.) > Just to point out: the above is explicitly stated in the document, so I hope that the parenthesis that Ian bring up is clear enough since it's a very important point. > I would rather describe these links as "non-reflexive and non- > transitive (wireless) links". I'd also be happy with a nice > acronym, like NBMA or UDLR. > > I'm interested in your thoughts. How do you think we should refer > to this linktype? In truth, I have no feelings either way on this matter. As it is, the document is only an individual submission, and does as such not represent any official position of the IETF or indeed of any working group. Should a working group wish to adopt the document (and I note from the autoconf mailing list discussions that, at least to this IETF participant, there seems to be no clear consensus in that direction within the autoconf working group, at least), and should that working group wish for an alternative name, I would a priori not have any objections. Thomas > Ian > > On Nov 4, 2008, at 4:51 AM, Thomas Heide Clausen wrote: > >> Folks, >> >> As you know, we need to make progress on the architectural issues, >> before we can hope to make progress on other matters within this >> WG. One of the requests that have been made to us has been to >> "describe the MANET Link Type", and so I have written together a >> strawman text to this effect: >> >> http://www.ietf.org/internet-drafts/draft-clausen-manet- >> linktype-00.txt >> >> Feedback is, obviously, welcome -- preferably on the list such >> that we could be prepared spend time on this also in MN. >> >> Note, however, that this is an individual I-D. >> >> I'd also like to draw your collective attention to: >> >> http://www.ietf.org/internet-drafts/draft-iab-ip-model- >> evolution-01.txt >> >> Which has served as a source of inspiration for the linktype text. >> >> Thanks, >> >> Thomas >> _______________________________________________ >> 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 autoconf-bounces@ietf.org Tue Nov 18 08:51:39 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 206023A687E; Tue, 18 Nov 2008 08:51:39 -0800 (PST) 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 E883D3A6808 for ; Tue, 18 Nov 2008 08:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.049 X-Spam-Level: X-Spam-Status: No, score=-6.049 tagged_above=-999 required=5 tests=[AWL=0.550, 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 1EDD76FDZCQ4 for ; Tue, 18 Nov 2008 08:51:37 -0800 (PST) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id AF01E3A687E for ; Tue, 18 Nov 2008 08:51:36 -0800 (PST) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id mAIGpXgs007973 for ; Tue, 18 Nov 2008 16:51:34 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id mAIGpXXs021831 for ; Tue, 18 Nov 2008 16:51:33 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 18 Nov 2008 16:51:33 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Tue, 18 Nov 2008 16:51:32 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 18 Nov 2008 16:51:31 -0000 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] draft-clausen-manet-linktype - naming Thread-Index: AclJnCuj0XJhGEfsSFmfh/qYDa2R2QAADdbw References: From: "Dearlove, Christopher (UK)" To: "Ian Chakeres" , X-OriginalArrivalTime: 18 Nov 2008 16:51:32.0768 (UTC) FILETIME=[E92FB200:01C9499D] Cc: Thomas Heide Clausen Subject: Re: [Autoconf] draft-clausen-manet-linktype - naming 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > I don't think that MANET should be in the name of the linktype. The > characteristics and constraints of a linktype are not MANET specific. This is true. > (I'd also like to repeat that MANET routing protocols will work quite > happily over other link types as well.) Except that the definition here is inclusive, i.e. it (by intent) includes those linktypes. > I would rather describe these links as "non-reflexive and non- > transitive (wireless) links". I'd also be happy with a nice acronym, > like NBMA or UDLR. Except that the point (I believe) is to support the MANET architecture document, so it can't be just about the difficult links. And links may be non-symmetric (not non-reflexive, see earlier posts) and/or non-transitive, they don't have to be both. (A fully acknowledgement based L2 might be symmetric but non-transitive, for example. I have to admit I don't have a non-contrived non-symmetric but transitive example.) I think you're in danger of simultaneously narrowing and widening the scope (narrower, because only talking about the "bad" links, wider because not just talking about MANETs) so that it isn't obviously supporting the MANET architecture document. What I don't know is if the intent is to agree on "this is what MANET links are like, and turn it into an RFC the architecture document depends on, or to use it as a stalking horse to get agreement on what a MANET link is, and then incorporate that into the MANET architecture document. In the latter case, considering anything but MANET links is a red herring, in the former case, yes, it could (but doesn't have to be) less MANET specific. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 18 12:23:44 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D639F28C246; Tue, 18 Nov 2008 12:23:44 -0800 (PST) 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 6D7FE28C241 for ; Tue, 18 Nov 2008 12:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 pbtBHghMJsg7 for ; Tue, 18 Nov 2008 12:23:42 -0800 (PST) Received: from mxav03.cc.niigata-u.ac.jp (mxav03.cc.niigata-u.ac.jp [133.35.17.131]) by core3.amsl.com (Postfix) with ESMTP id 63AEA28C236 for ; Tue, 18 Nov 2008 12:23:42 -0800 (PST) Received: from mxav03.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id BD3AA2901DC for ; Wed, 19 Nov 2008 05:23:36 +0900 (JST) Received: from chamame.ie.niigata-u.ac.jp (chamame.ie.niigata-u.ac.jp [133.35.169.34]) by mxav03.cc.niigata-u.ac.jp (Postfix) with SMTP id 708FE290201 for ; Wed, 19 Nov 2008 05:23:36 +0900 (JST) Received: (qmail 10804 invoked from network); 19 Nov 2008 05:23:36 +0900 Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 19 Nov 2008 05:23:36 +0900 Message-Id: <7.0.0.16.2.20081119050635.0880a730@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Wed, 19 Nov 2008 05:23:43 +0900 To: Ian Chakeres ,autoconf@ietf.org From: mase In-Reply-To: References: Mime-Version: 1.0 Cc: Thomas Heide Clausen Subject: Re: [Autoconf] draft-clausen-manet-linktype - naming 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org At 20:57 08/11/18, Ian Chakeres wrote: >I'd like to start a discussion thread on the naming of this draft/ linktype. > >I don't think that MANET should be in the name of the linktype. The >characteristics and constraints of a linktype are not MANET specific. > >(I'd also like to repeat that MANET routing protocols will work quite >happily over other link types as well.) > >I would rather describe these links as "non-reflexive and non- >transitive (wireless) links". I'd also be happy with a nice acronym, >like NBMA or UDLR. I don't think that the introduction/definition of such a special link type is useful for MANET discussions, since MANET protocols can work on other link types such as the Ethernet. I rather think that it is important to make clear link assumptions or requirements to be used for MANET in general. My sugestions are as follows: MANET protocols work on any link models, where each interface has at least one other interface to/from which it can send/receive packets. These neighbors may change over time. The link models given above of course inculde the Ethernet model as the special case. They also inculde non-reflexive and /or non-transitive links you defined. Kenichi >I'm interested in your thoughts. How do you think we should refer to >this linktype? > >Ian > >On Nov 4, 2008, at 4:51 AM, Thomas Heide Clausen wrote: > >>Folks, >> >>As you know, we need to make progress on the architectural issues, >>before we can hope to make progress on other matters within this WG. >>One of the requests that have been made to us has been to "describe >>the MANET Link Type", and so I have written together a strawman text >>to this effect: >> >> >> http://www.ietf.org/internet-drafts/draft-clausen-manet-linktype-00.txt >> >>Feedback is, obviously, welcome -- preferably on the list such that >>we could be prepared spend time on this also in MN. >> >>Note, however, that this is an individual I-D. >> >>I'd also like to draw your collective attention to: >> >> >> http://www.ietf.org/internet-drafts/draft-iab-ip-model-evolution-01.txt >> >>Which has served as a source of inspiration for the linktype text. >> >>Thanks, >> >>Thomas >>_______________________________________________ >>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 > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 18 12:54:50 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EC693A6A24; Tue, 18 Nov 2008 12:54:50 -0800 (PST) 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 5F1453A6A24 for ; Tue, 18 Nov 2008 12:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.354 X-Spam-Level: X-Spam-Status: No, score=-0.354 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQdqsFyeQECl for ; Tue, 18 Nov 2008 12:54:47 -0800 (PST) Received: from mailoutb.tno.nl (mailoutb.tno.nl [134.221.1.17]) by core3.amsl.com (Postfix) with ESMTP id 460623A677C for ; Tue, 18 Nov 2008 12:54:47 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,627,1220220000"; d="scan'208";a="2956762" Received: from ms-dt01thalia.tno.nl (HELO ms-dt01thalia.tsn.tno.nl) ([134.221.225.157]) by mailhost1b.tno.nl with ESMTP; 18 Nov 2008 21:54:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 21:54:45 +0100 Message-ID: <7877C5C0B5CC894AB26113CF06CF886301238C9D@ms-dt01thalia.tsn.tno.nl> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] draft-clausen-manet-linktype - naming Thread-Index: AclJnCytveRjzd9iRS6Gq8FdNa2z1AAG3gog References: From: "Velt, R. (Ronald) in 't" To: Subject: Re: [Autoconf] draft-clausen-manet-linktype - naming 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Ian, > -----Original Message----- > From: autoconf-bounces@ietf.org > [mailto:autoconf-bounces@ietf.org] On Behalf Of Ian Chakeres > Sent: dinsdag 18 november 2008 12:58 > To: autoconf@ietf.org > Cc: Thomas Heide Clausen > Subject: Re: [Autoconf] draft-clausen-manet-linktype - naming > > I'd like to start a discussion thread on the naming of this > draft/ linktype. Shouldn't we agree first that there actually is a link type "previously known as MANET link"? My working definition for a link would be the one Dave Thaler gives in draft-iab-ip-model-evolution-01: "A "link" in the IP service model refers to the topological area within which a packet with an IPv4 TTL or IPv6 Hop Limit of 1 can be delivered." (Inherited from RFC4903, but reworded slightly). Non-transitivity does not seem to fit this definition? > > I don't think that MANET should be in the name of the > linktype. The characteristics and constraints of a linktype > are not MANET specific. Strictly speaking, you are right. But: "what's in a name?". > > (I'd also like to repeat that MANET routing protocols will > work quite happily over other link types as well.) IMHO, that point has been made ad nauseam in previous Autoconf sessions. (In Philadelphia, in particular). It is true of course, but what does it prove? We already had those other link types covered; they are not what MANET protocols were designed for. MANET protocols come into their own when used over these special links. > > I would rather describe these links as "non-reflexive and > non- transitive (wireless) links". I'd also be happy with a > nice acronym, like NBMA or UDLR. > > I'm interested in your thoughts. How do you think we should > refer to this linktype? Sorry, can't think of a cute acronym right now... Ronald > > Ian > > On Nov 4, 2008, at 4:51 AM, Thomas Heide Clausen wrote: > > > Folks, > > > > As you know, we need to make progress on the architectural issues, > > before we can hope to make progress on other matters within this WG. > > One of the requests that have been made to us has been to "describe > > the MANET Link Type", and so I have written together a > strawman text > > to this effect: > > > > > > > http://www.ietf.org/internet-drafts/draft-clausen-manet-linktype-00.tx > > t > > > > Feedback is, obviously, welcome -- preferably on the list > such that we > > could be prepared spend time on this also in MN. > > > > Note, however, that this is an individual I-D. > > > > I'd also like to draw your collective attention to: > > > > > > > http://www.ietf.org/internet-drafts/draft-iab-ip-model-evolution-01.tx > > t > > > > Which has served as a source of inspiration for the linktype text. > > > > Thanks, > > > > Thomas > > _______________________________________________ > > 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 > This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 18 13:00:14 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EDEA3A6B2C; Tue, 18 Nov 2008 13:00:14 -0800 (PST) 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 1CE333A6B28 for ; Tue, 18 Nov 2008 13:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxnFG5p5PzZR for ; Tue, 18 Nov 2008 13:00:12 -0800 (PST) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by core3.amsl.com (Postfix) with ESMTP id E30B43A6B25 for ; Tue, 18 Nov 2008 13:00:11 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,627,1220220000"; d="scan'208";a="31580079" Received: from unknown (HELO BoolfightMaN-Laptop.local) ([130.129.29.95]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Nov 2008 22:00:09 +0100 Message-ID: <49232CD2.3030304@inria.fr> Date: Tue, 18 Nov 2008 22:00:02 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: autoconf@ietf.org References: <7877C5C0B5CC894AB26113CF06CF886301238C9D@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <7877C5C0B5CC894AB26113CF06CF886301238C9D@ms-dt01thalia.tsn.tno.nl> X-Enigmail-Version: 0.95.7 Subject: Re: [Autoconf] draft-clausen-manet-linktype - naming 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org >> I don't think that MANET should be in the name of the linktype. The >> characteristics and constraints of a linktype are not MANET specific. I agree too. Here's one way to see things: what is special about these links, is that their properties vary more than usual: (i) over time, and (ii) between different instances of links of the type. So all the protocols running above these links must be more "opportunistic" than usual. Which basically means: within a short window of opportunity, detect and take advantage (as much as possible) of the properties of such a link. So maybe we could simply call this category of link "opportunistic links"? What do you guys think? Emmanuel _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 18 15:21:50 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4886A3A6B2A; Tue, 18 Nov 2008 15:21:50 -0800 (PST) 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 C09D93A6B2A for ; Tue, 18 Nov 2008 15:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7q4JPJmU7fs7 for ; Tue, 18 Nov 2008 15:21:48 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id C351C3A6945 for ; Tue, 18 Nov 2008 15:21:47 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.68.36]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAINLked020414 for ; Tue, 18 Nov 2008 23:21:46 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAINLiQu140932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 15:21:45 -0800 (PST) Message-ID: <49234E08.6070707@sun.com> Date: Tue, 18 Nov 2008 15:21:44 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.17 (X11/20081023) MIME-Version: 1.0 To: autoconf@ietf.org Subject: [Autoconf] Old description for 6lowpan; thoughts on link vs. subnet 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org This document plus discussions with Dave helped me understand why it made sense to define link as within radio reachability: http://tools.ietf.org/html/draft-culler-6lowpan-architecture-00 Some more details are explained in http://tools.ietf.org/html/draft-shelby-6lowpan-nd-01 I think there are some details about the definition of link that isn't explicit anywhere. One possible definition is a unidirectional one: N2 is on the same link as N3 iff N2 can hear packets that N3 sends Another possible definition is to require that they can hear each other. What is important to me is that there is a way for an application that is part of the control plane, be it an implementation of a routing protocol, or an implementation of some (address) configuration protocol, or something else, has a mechanism by which it can reach its radio-hop neighbors. To me it makes sense to define "link" in such a way that link-local unicast/multicast can be used to ensure that packets only reach the radio-hop neighbors. The other part that is important to me is that the IP TTL can be used to limit the effect of transient routing loops. This implies that the routers must decrement ttl. Finally, from the perspective of local mobility it makes sense to define the subnet prefix as a domain of address allocation where a node can get an address allocated in that prefix and then use it as it moves around inside the domain. One implication of the above is that it doesn't make sense to announce any on-link prefix in Router Advertisements for these types of networks. (Depending on how address allocation is done it may or may not make sense to advertise prefixes with the "addrconf" bit set in RAs.) Another implication is that nodes that are in the same subnet prefix will see TTL decrement when sending packets to each other. I don't know what impact that has on applications, but since the subnet prefix isn't advertised as "on-link" the prefix wouldn't be visible to applications in the OS platforms I'm familiar with. Erik _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 01:42:38 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5743B3A67F5; Wed, 19 Nov 2008 01:42:38 -0800 (PST) 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 793FE3A67F5 for ; Wed, 19 Nov 2008 01:42:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.104 X-Spam-Level: X-Spam-Status: No, score=-6.104 tagged_above=-999 required=5 tests=[AWL=0.495, 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 HBru7J7jBl2h for ; Wed, 19 Nov 2008 01:42:36 -0800 (PST) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id 7B3903A676A for ; Wed, 19 Nov 2008 01:42:36 -0800 (PST) Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id mAJ9gVwe004241 for ; Wed, 19 Nov 2008 09:42:32 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id mAJ9gVuK024228 for ; Wed, 19 Nov 2008 09:42:31 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 19 Nov 2008 09:42:31 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 19 Nov 2008 09:42:31 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 19 Nov 2008 09:42:21 -0000 Message-ID: In-Reply-To: <49232CD2.3030304@inria.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] draft-clausen-manet-linktype - naming Thread-Index: AclJwKfdmHi6Q5ZtR9aMgX/XKtN7MAAak26w References: <7877C5C0B5CC894AB26113CF06CF886301238C9D@ms-dt01thalia.tsn.tno.nl> <49232CD2.3030304@inria.fr> From: "Dearlove, Christopher (UK)" To: "Emmanuel Baccelli" , X-OriginalArrivalTime: 19 Nov 2008 09:42:31.0198 (UTC) FILETIME=[246D93E0:01C94A2B] Subject: Re: [Autoconf] draft-clausen-manet-linktype - naming 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > what is special about these links, is that their properties vary more > than usual: > (i) over time, and > (ii) between different instances of links of the type. I think those are of secondary importance. It's the (possible) non-symmetry, non-transitivity that's of primary importance. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 04:11:37 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BC3A3A684B; Wed, 19 Nov 2008 04:11:37 -0800 (PST) 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 32B113A67B2 for ; Wed, 19 Nov 2008 04:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 0IUn8YvSAMRC for ; Wed, 19 Nov 2008 04:11:35 -0800 (PST) Received: from mxav03.cc.niigata-u.ac.jp (mxav03.cc.niigata-u.ac.jp [133.35.17.131]) by core3.amsl.com (Postfix) with ESMTP id 69A1D3A6882 for ; Wed, 19 Nov 2008 04:11:35 -0800 (PST) Received: from mxav03.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3399E29024C for ; Wed, 19 Nov 2008 21:11:26 +0900 (JST) Received: from chamame.ie.niigata-u.ac.jp (chamame.ie.niigata-u.ac.jp [133.35.169.34]) by mxav03.cc.niigata-u.ac.jp (Postfix) with SMTP id 200EF29022F for ; Wed, 19 Nov 2008 21:11:26 +0900 (JST) Received: (qmail 3122 invoked from network); 19 Nov 2008 21:11:26 +0900 Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 19 Nov 2008 21:11:26 +0900 Message-Id: <7.0.0.16.2.20081119210453.03f9e0d0@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Wed, 19 Nov 2008 21:11:25 +0900 To: "Dearlove, Christopher (UK)" , "Emmanuel Baccelli" , From: mase In-Reply-To: References: <7877C5C0B5CC894AB26113CF06CF886301238C9D@ms-dt01thalia.tsn.tno.nl> <49232CD2.3030304@inria.fr> Mime-Version: 1.0 Subject: Re: [Autoconf] draft-clausen-manet-linktype - naming 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org At 18:42 08/11/19, Dearlove, Christopher (UK) wrote: > > what is special about these links, is that their properties vary more > > than usual: > > (i) over time, and > > (ii) between different instances of links of the type. > >I think those are of secondary importance. It's the (possible) >non-symmetry, non-transitivity that's of primary importance. The real problem (or confusion), I think, is that when you say non-transitivity, you assume that all three nodes are on the same link. However, there are others who don't think that they are. Kenichi _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 04:23:58 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93CF13A6A63; Wed, 19 Nov 2008 04:23:58 -0800 (PST) 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 F422D3A6A63 for ; Wed, 19 Nov 2008 04:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.450, 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 pTB6kfsH4VQQ for ; Wed, 19 Nov 2008 04:23:57 -0800 (PST) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id EC7393A6A32 for ; Wed, 19 Nov 2008 04:23:55 -0800 (PST) Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id mAJCNqlG011655 for ; Wed, 19 Nov 2008 12:23:53 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id mAJCNqLX008957 for ; Wed, 19 Nov 2008 12:23:52 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 19 Nov 2008 12:23:51 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 19 Nov 2008 12:23:51 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 19 Nov 2008 12:23:49 -0000 Message-ID: In-Reply-To: <7.0.0.16.2.20081119210453.03f9e0d0@ie.niigata-u.ac.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] draft-clausen-manet-linktype - naming Thread-Index: AclKQAfDqx3ZqoN/RDOT9tKEEqlp/AAAByZg References: <7877C5C0B5CC894AB26113CF06CF886301238C9D@ms-dt01thalia.tsn.tno.nl><49232CD2.3030304@inria.fr> <7.0.0.16.2.20081119210453.03f9e0d0@ie.niigata-u.ac.jp> From: "Dearlove, Christopher (UK)" To: "mase" , "Emmanuel Baccelli" , X-OriginalArrivalTime: 19 Nov 2008 12:23:51.0556 (UTC) FILETIME=[AE5EFC40:01C94A41] Subject: Re: [Autoconf] draft-clausen-manet-linktype - naming 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > The real problem (or confusion), I think, is that when you say > non-transitivity, you assume that all three nodes are on the same > link. However, there are others who don't think that they are. I don't think that's my assumption. It's more fundamental than what you call a link. It's that if A's transmissions can reach B, and B's transmissions can reach C, but A's transmissions can't reach C, then we have non-transitivity. That's the usual case with wireless transmissions (to be precise, it's the usual case that A's transmissions may or may not reach C). Thus either A, B and C can't be on one link (if your model of a link is as Ethernet) or you need a different model of what a link is, and can consider A and B to have a link, and B and C to have a link (but not A and C). For MANETs the latter may be more useful. But the non-transitivity is there, whatever definitions you choose. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 05:35:51 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 222953A6B8A; Wed, 19 Nov 2008 05:35:51 -0800 (PST) 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 3985F3A6B89 for ; Wed, 19 Nov 2008 05:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 HzqlETRnqx7i for ; Wed, 19 Nov 2008 05:35:48 -0800 (PST) Received: from mxav03.cc.niigata-u.ac.jp (mxav03.cc.niigata-u.ac.jp [133.35.17.131]) by core3.amsl.com (Postfix) with ESMTP id 4EAAC3A692C for ; Wed, 19 Nov 2008 05:35:48 -0800 (PST) Received: from mxav03.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 939CA2901F6 for ; Wed, 19 Nov 2008 22:35:46 +0900 (JST) Received: from chamame.ie.niigata-u.ac.jp (chamame.ie.niigata-u.ac.jp [133.35.169.34]) by mxav03.cc.niigata-u.ac.jp (Postfix) with SMTP id 899252901D2 for ; Wed, 19 Nov 2008 22:35:46 +0900 (JST) Received: (qmail 4498 invoked from network); 19 Nov 2008 22:35:46 +0900 Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 19 Nov 2008 22:35:46 +0900 Message-Id: <7.0.0.16.2.20081119222923.03b6c5e0@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Wed, 19 Nov 2008 22:35:45 +0900 To: "Dearlove, Christopher (UK)" , "Emmanuel Baccelli" , From: mase In-Reply-To: References: <7877C5C0B5CC894AB26113CF06CF886301238C9D@ms-dt01thalia.tsn.tno.nl> <49232CD2.3030304@inria.fr> <7.0.0.16.2.20081119210453.03f9e0d0@ie.niigata-u.ac.jp> Mime-Version: 1.0 Subject: Re: [Autoconf] draft-clausen-manet-linktype - naming 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org At 21:23 08/11/19, Dearlove, Christopher (UK) wrote: > > The real problem (or confusion), I think, is that when you say > > non-transitivity, you assume that all three nodes are on the same > > link. However, there are others who don't think that they are. > >I don't think that's my assumption. > >It's more fundamental than what you call a link. It's that if >A's transmissions can reach B, and B's transmissions can reach C, >but A's transmissions can't reach C, then we have non-transitivity. >That's the usual case with wireless transmissions (to be precise, >it's the usual case that A's transmissions may or may not reach C). > >Thus either A, B and C can't be on one link (if your model of a >link is as Ethernet) or you need a different model of what a link >is, and can consider A and B to have a link, and B and C to have >a link (but not A and C). For MANETs the latter may be more useful. >But the non-transitivity is there, whatever definitions you choose. If there is the non-transitivity regardless of the link model or assumption, how does it help to discuss or define any link model for MANETs? Kenichi >******************************************************************** >This email and any attachments are confidential to the intended >recipient and may also be privileged. If you are not the intended >recipient please delete it from your system and notify the sender. >You should not copy it or use it for any purpose nor disclose or >distribute its contents to any other person. >******************************************************************** _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 05:41:52 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12DE63A68C6; Wed, 19 Nov 2008 05:41:52 -0800 (PST) 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 692B33A68C6 for ; Wed, 19 Nov 2008 05:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZPnATDUNwWV for ; Wed, 19 Nov 2008 05:41:49 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 391513A692C for ; Wed, 19 Nov 2008 05:41:49 -0800 (PST) Received: (qmail 9615 invoked from network); 19 Nov 2008 14:41:44 +0100 Received: from unknown (HELO M90Teco) (12.104.246.2) by server9.hosting2go.nl with SMTP; 19 Nov 2008 14:41:44 +0100 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" , "'mase'" , "'Emmanuel Baccelli'" , References: <7877C5C0B5CC894AB26113CF06CF886301238C9D@ms-dt01thalia.tsn.tno.nl><49232CD2.3030304@inria.fr> <7.0.0.16.2.20081119210453.03f9e0d0@ie.niigata-u.ac.jp> In-Reply-To: Date: Wed, 19 Nov 2008 14:41:42 +0100 Message-ID: <009c01c94a4c$8f8e3000$aeaa9000$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclKQAfDqx3ZqoN/RDOT9tKEEqlp/AAAByZgAAEazNA= Content-Language: nl Subject: Re: [Autoconf] draft-clausen-manet-linktype - naming 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > > The real problem (or confusion), I think, is that when you say > > non-transitivity, you assume that all three nodes are on the same > > link. However, there are others who don't think that they are. > > I don't think that's my assumption. > > It's more fundamental than what you call a link. It's that if > A's transmissions can reach B, and B's transmissions can reach C, > but A's transmissions can't reach C, then we have non-transitivity. > That's the usual case with wireless transmissions (to be precise, > it's the usual case that A's transmissions may or may not reach C). > > Thus either A, B and C can't be on one link (if your model of a > link is as Ethernet) or you need a different model of what a link > is, and can consider A and B to have a link, and B and C to have > a link (but not A and C). For MANETs the latter may be more useful. > But the non-transitivity is there, whatever definitions you choose. Agreed this a definition issue. In the Autoconf meeting, there was consensus on defining a xxx link type (name tbd), where different links are on the same interface. I think we can assume that the medium is shared (we are on the same electro-magnetic spectrum), but the degree of interference is not known on forehand (e.g. TDMA vs. CSMA/CA). The 802 series of standards could be helpful as a reference. The STDs refer to RFCs, why do we have some asymmetry here? Useful ones: IEEE802.1-2001 (section 6.3.3.describes usage of routers and the IP protocol) IEEE802.11-2007 (too many sections to list here) This is an interesting one: >>> 3.16 basic service set (BSS): Membership in a BSS does not imply that wireless communication with all other members of the BSS is possible. <<< And this one: >>> 3.76 link: In the context of an IEEE 802.11 medium access control (MAC) entity, a physical path consisting of exactly one traversal of the wireless medium (WM) that is used to transfer an MAC service data unit (MSDU) between two stations (STAs). <<< (this would exclude broadcast MSDU, which is not the case) Another comment on naming: I think we have two task. One of them is describing this "ad hoc wireless link". 802.11 definitions could be used, maybe some can come up with other refs. But in a MANET, multiple link types can be used. Think of an Ethernet cable connecting two radios "back-to-back" or using alternative radios with lower frequency / lower bandwidth / more Tx power / increased range. I think it helps to write down something on "MANET topologies". Just repeating myself: Lets postpone IP addressing and ND issues until we are familiar with MANETs that are out there. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 05:45:18 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D88D3A6B84; Wed, 19 Nov 2008 05:45:18 -0800 (PST) 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 D8DE43A692C for ; Wed, 19 Nov 2008 05:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.187 X-Spam-Level: X-Spam-Status: No, score=-6.187 tagged_above=-999 required=5 tests=[AWL=0.413, 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 Aj5L-4+sIw6h for ; Wed, 19 Nov 2008 05:45:15 -0800 (PST) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id 37EE528C11A for ; Wed, 19 Nov 2008 05:45:15 -0800 (PST) Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id mAJDjCZZ015373 for ; Wed, 19 Nov 2008 13:45:12 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id mAJDjCGp025842 for ; Wed, 19 Nov 2008 13:45:12 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 19 Nov 2008 13:45:11 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 19 Nov 2008 13:45:11 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 19 Nov 2008 13:45:10 -0000 Message-ID: In-Reply-To: <7.0.0.16.2.20081119222923.03b6c5e0@ie.niigata-u.ac.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] draft-clausen-manet-linktype - naming Thread-Index: AclKS8d6hj8wkx+CQb2oyuChsbu+0gAAOK9Q References: <7877C5C0B5CC894AB26113CF06CF886301238C9D@ms-dt01thalia.tsn.tno.nl><49232CD2.3030304@inria.fr><7.0.0.16.2.20081119210453.03f9e0d0@ie.niigata-u.ac.jp> <7.0.0.16.2.20081119222923.03b6c5e0@ie.niigata-u.ac.jp> From: "Dearlove, Christopher (UK)" To: "mase" , "Emmanuel Baccelli" , X-OriginalArrivalTime: 19 Nov 2008 13:45:11.0729 (UTC) FILETIME=[0B2E4A10:01C94A4D] Subject: Re: [Autoconf] draft-clausen-manet-linktype - naming 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > If there is the non-transitivity regardless of the link model or > assumption, how does it help to discuss or define any link model > for MANETs? First you recognise that you have non-transitivity. Then you decide what your link model should be that handles that. This is as opposed to when you have transitivity (and symmetry). Then you have a wider range of possible link models. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 06:03:38 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CF4F3A6B90; Wed, 19 Nov 2008 06:03:38 -0800 (PST) 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 976BA3A6B90 for ; Wed, 19 Nov 2008 06:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.204 X-Spam-Level: X-Spam-Status: No, score=-0.204 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MISSING_MIMEOLE=0.001, 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 l8UTZt-DF0qn for ; Wed, 19 Nov 2008 06:03:36 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 722713A6A91 for ; Wed, 19 Nov 2008 06:03:36 -0800 (PST) Received: (qmail 21047 invoked from network); 19 Nov 2008 15:03:32 +0100 Received: from unknown (HELO M90Teco) (12.104.246.2) by server9.hosting2go.nl with SMTP; 19 Nov 2008 15:03:32 +0100 From: "Teco Boot" To: Date: Wed, 19 Nov 2008 15:03:28 +0100 Message-ID: <00a301c94a4f$9b3c6c70$d1b54550$@nl> MIME-Version: 1.0 X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclKT5kUpY2dUU5bRlSoFacvDVrUkA== Content-Language: nl Importance: High Subject: [Autoconf] Crash meeting? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org I think it is important that we have a clear understanding of the situation, on who is doing what. And on the status of the MANET architecture document. I suggest having a short, informal and non-technical meeting. The outcome could be a small design team working on a new document, to be released soon. What about a rendezvous after the MANET meeting? We can schedule another time and place if we want to. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 06:23:52 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E04E23A6B93; Wed, 19 Nov 2008 06:23:52 -0800 (PST) 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 430283A6B93 for ; Wed, 19 Nov 2008 06:23:52 -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 MLQt66vEbV6S for ; Wed, 19 Nov 2008 06:23:51 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 751BF3A6B13 for ; Wed, 19 Nov 2008 06:23:51 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-128.messagelabs.com!1227104629!2691185!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 5692 invoked from network); 19 Nov 2008 14:23:50 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-128.messagelabs.com with SMTP; 19 Nov 2008 14:23:50 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mAJENnjK012121; Wed, 19 Nov 2008 07:23:49 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id mAJENn46026127; Wed, 19 Nov 2008 08:23:49 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id mAJENlFG026123; Wed, 19 Nov 2008 08:23:48 -0600 (CST) Message-ID: <49242173.9060500@gmail.com> Date: Wed, 19 Nov 2008 15:23:47 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <7877C5C0B5CC894AB26113CF06CF886301238C9D@ms-dt01thalia.tsn.tno.nl><49232CD2.3030304@inria.fr> <7.0.0.16.2.20081119210453.03f9e0d0@ie.niigata-u.ac.jp> In-Reply-To: X-Antivirus: avast! (VPS 081118-0, 18/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] Non-transitivity as issue X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Dearlove, Christopher (UK) wrote: >> The real problem (or confusion), I think, is that when you say >> non-transitivity, you assume that all three nodes are on the same >> link. However, there are others who don't think that they are. > > I don't think that's my assumption. > > It's more fundamental than what you call a link. It's that if A's > transmissions can reach B, and B's transmissions can reach C, but A's > transmissions can't reach C, then we have non-transitivity. In that sense, and from ND perspective, Internet is non-transitive: one's laptop reaches one's router, router reaches its next-hop router, but one's latop doesn't reach that latter router. I think it largely depends on where from we look at problems, from phy layer, from mac layer, from network layer, etc. One could find problems if crossing layers, and cross-layer solutions, it's very sensitive. Alex > That's the usual case with wireless transmissions (to be precise, > it's the usual case that A's transmissions may or may not reach C). > > Thus either A, B and C can't be on one link (if your model of a link > is as Ethernet) or you need a different model of what a link is, and > can consider A and B to have a link, and B and C to have a link (but > not A and C). For MANETs the latter may be more useful. But the > non-transitivity is there, whatever definitions you choose. > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > _______________________________________________ Autoconf mailing list > Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 06:28:08 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 913BD3A6B93; Wed, 19 Nov 2008 06:28:08 -0800 (PST) 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 00E523A6B93 for ; Wed, 19 Nov 2008 06:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.218 X-Spam-Level: X-Spam-Status: No, score=-6.218 tagged_above=-999 required=5 tests=[AWL=0.381, 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 p0huWqmUQkDY for ; Wed, 19 Nov 2008 06:28:06 -0800 (PST) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id CE9A93A6B13 for ; Wed, 19 Nov 2008 06:28:05 -0800 (PST) Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id mAJES1Ig027454 for ; Wed, 19 Nov 2008 14:28:01 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id mAJES1qo021965 for ; Wed, 19 Nov 2008 14:28:01 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 19 Nov 2008 14:28:01 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 19 Nov 2008 14:28:00 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 19 Nov 2008 14:27:59 -0000 Message-ID: In-Reply-To: <49242173.9060500@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Non-transitivity as issue Thread-Index: AclKUnR6a88aIr+GSYeBVc2bWEj3qAAAD82Q References: <7877C5C0B5CC894AB26113CF06CF886301238C9D@ms-dt01thalia.tsn.tno.nl><49232CD2.3030304@inria.fr> <7.0.0.16.2.20081119210453.03f9e0d0@ie.niigata-u.ac.jp> <49242173.9060500@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 19 Nov 2008 14:28:00.0996 (UTC) FILETIME=[06955240:01C94A53] Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] Non-transitivity as issue X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > In that sense, and from ND perspective, Internet is non-transitive: > one's laptop reaches one's router, router reaches its next-hop router, > but one's latop doesn't reach that latter router. True, but there are small pieces of it that are transitive (and other good things). And those are the small pieces (e.g. one Ethernet) that are considered links, set up as subnets, run ND, and all those things. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 06:40:47 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8555E3A6BA8; Wed, 19 Nov 2008 06:40:47 -0800 (PST) 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 2889A3A6B13 for ; Wed, 19 Nov 2008 06:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.253 X-Spam-Level: X-Spam-Status: No, score=-5.253 tagged_above=-999 required=5 tests=[AWL=1.346, 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 I6Pp8d0gOGCM for ; Wed, 19 Nov 2008 06:40:45 -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 331E33A6868 for ; Wed, 19 Nov 2008 06:40:37 -0800 (PST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id mAJEeLTH011317 for ; Wed, 19 Nov 2008 09:40:21 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mAJEeVcn159394 for ; Wed, 19 Nov 2008 09:40:31 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mAJEeUsV013998 for ; Wed, 19 Nov 2008 09:40:30 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-201-183.mts.ibm.com [9.65.201.183]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mAJEeSRe013836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Nov 2008 09:40:29 -0500 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id mAJEeRPu017560 for ; Wed, 19 Nov 2008 09:40:28 -0500 Message-Id: <200811191440.mAJEeRPu017560@cichlid.raleigh.ibm.com> To: autoconf@ietf.org Date: Wed, 19 Nov 2008 09:40:27 -0500 From: Thomas Narten Subject: [Autoconf] link definitions 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org It is very important that we are clear and precise about terminology. I suspect that 80% of the confusion we have had stems from folk using terminology loosely, causing the listener to think something completely different from what the speaker intends. (I saw clear examples of this in yesterday's meeting). That helps no one and keeps us going in circles. Let's start with "link". Even the term "link" is unclear. Are we talking about an "IP link" or what most of us would consider an "L2 link"? (They are not necessarily the same.) >From RFC 2460, link is defined as: link - a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IPv6. Examples are Ethernets (simple or bridged); PPP links; X.25, Frame Relay, or ATM networks; and internet (or higher) layer "tunnels", such as tunnels over IPv4 or IPv6 itself. What is unstated (but assumed) above is that all the nodes in the link can reach each other. Note also that the above is really an L2 definition. It means that a node attached to the link can send a packet to another node on the link (and vice versa). How that is done (whether via a shared wire, or via packet switches doing routing, a bridged ethernet, etc.) doesn't matter. The important thing is the abstraction, that every node on the link can reach every other node on the link. If we up-level to what IP sees, an "IP link" has a similar definition. It is assumed that all nodes on the link can directly send an IP datagram to another node on the link, and it will get delivered. Whether the underlying link has bridges/packet switches/etc. doesn't matter. From IP's perspective, it sends a packet and it gets deliverd without the TTL being decremented. That is what IP cares about. Also, by definition. for an "IP link", link-local multicast/broadcast means that the packet is delivered everywhere without decrementing a TTL. It has never made sense to me to say that "IP-level LL broadcast" doesn't work in a MANET, because that is calling something an "IP link" that does not have the properties to be a "IP link" in the normal sense. When talking about a "MANET link", we should (first) be talking about what is happening below IP (i.e., either at L2, or maybe L2.5, if one wants to think of running the MANET protocols over the interface to provide IP with an "IP link" abstraction). Exactly what are the features of such a link? A key question is what is the definition of a MANET Link? Previous documents/conversations have suggested to me that some folk want to make the entire collection of nodes running MANET form a MANET link. Looking at chart 37 of ThomasC's presentation yesterday, for example, is the entire white cloud (i.e. all the routers) considered to be one link? To me that raises the following questions: If the entire cloud is a link, why are we doing that? What desireable properties result from that? How does it make solving our problems any easier? If instead, we view the white cloud as collection of individual links (e.g., with a link defined by the set of neighbors within radio range of each other), we get a very different link model. This model presumably also has some important properties. What are they? How do they compare to the other model? Does the model make it easier or harder to solve certain problems? To me, the narrower defintion of a link seems more natural because I I have a good idea of how to map that into the "IP link" model in a way that is compatable with existing IP assumptions. For the former model to work with IP, we may well need to have a sub-layer between the raw links and IP that convert the raw links into an abstract link that has the properties that IP assumes will be there (like bi-directional connectivity). Neither model is "right" or "wrong", its just that they have different implications and engineering tradeoffs. In my mind, the excercise of defining a "MANET link" is all about being able to talk about different abstract models (like the two above) and then be able to talk (in specific engineering terms) about which one makes more sense to use in trying to make IP work well over MANETs. Thomas _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 06:41:31 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D33763A6BA3; Wed, 19 Nov 2008 06:41:31 -0800 (PST) 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 8E8413A6BA1 for ; Wed, 19 Nov 2008 06:41:30 -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 PFI7rGMI73Bd for ; Wed, 19 Nov 2008 06:41:29 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with SMTP id 9620D3A6868 for ; Wed, 19 Nov 2008 06:41:29 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-119.messagelabs.com!1227105687!23481900!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 31666 invoked from network); 19 Nov 2008 14:41:27 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-119.messagelabs.com with SMTP; 19 Nov 2008 14:41:27 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mAJEfRR1017104; Wed, 19 Nov 2008 07:41:27 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id mAJEfRCs017549; Wed, 19 Nov 2008 08:41:27 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id mAJEfPCA017531; Wed, 19 Nov 2008 08:41:26 -0600 (CST) Message-ID: <49242595.2030503@gmail.com> Date: Wed, 19 Nov 2008 15:41:25 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <7877C5C0B5CC894AB26113CF06CF886301238C9D@ms-dt01thalia.tsn.tno.nl><49232CD2.3030304@inria.fr> <7.0.0.16.2.20081119210453.03f9e0d0@ie.niigata-u.ac.jp> <49242173.9060500@gmail.com> In-Reply-To: X-Antivirus: avast! (VPS 081118-0, 18/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] Non-transitivity as issue X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Dearlove, Christopher (UK) wrote: >> In that sense, and from ND perspective, Internet is non-transitive: >> one's laptop reaches one's router, router reaches its next-hop >> router, but one's latop doesn't reach that latter router. > > True, but there are small pieces of it that are transitive (and other > good things). And those are the small pieces (e.g. one Ethernet) > that are considered links, set up as subnets, run ND, and all those > things. I don't think we can consider an Ethernet cable to be transitive. We can question the transitivity of two Ethernet cables: if they're connected by a hub (mac repeater) then Ethernet is transitive. If they're connected by a PC not running forwarding nor bridging then the two Ethernet cables are non-transitive. It depends how they're connected. For every wired and wireless technology there are connectors solving the non-transitivity problems at their particular layer. YOu said previously that in some instances such connectors are not available. Maybe we can insist describing these cases, thus motivating the need. Alex > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 06:57:53 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26FE528C113; Wed, 19 Nov 2008 06:57:53 -0800 (PST) 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 DAB8F3A6B9C for ; Wed, 19 Nov 2008 06:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52pQUCrZ+yvz for ; Wed, 19 Nov 2008 06:57:51 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id B9EF63A6B9A for ; Wed, 19 Nov 2008 06:57:50 -0800 (PST) Received: (qmail 24584 invoked from network); 19 Nov 2008 15:57:46 +0100 Received: from unknown (HELO M90Teco) (130.129.95.96) by server9.hosting2go.nl with SMTP; 19 Nov 2008 15:57:46 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <7877C5C0B5CC894AB26113CF06CF886301238C9D@ms-dt01thalia.tsn.tno.nl><49232CD2.3030304@inria.fr> <7.0.0.16.2.20081119210453.03f9e0d0@ie.niigata-u.ac.jp> <49242173.9060500@gmail.com> <49242595.2030503@gmail.com> In-Reply-To: <49242595.2030503@gmail.com> Date: Wed, 19 Nov 2008 15:57:15 +0100 Message-ID: <00a401c94a57$2f03fb10$8d0bf130$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclKVOsrceR+XvlJREuxtCpuGXcJhAAAhH3w Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] Non-transitivity as issue X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > I don't think we can consider an Ethernet cable to be transitive. > > We can question the transitivity of two Ethernet cables: if they're > connected by a hub (mac repeater) then Ethernet is transitive. If > they're connected by a PC not running forwarding nor bridging then the > two Ethernet cables are non-transitive. > > It depends how they're connected. For every wired and wireless > technology there are connectors solving the non-transitivity problems > at > their particular layer. YOu said previously that in some instances > such connectors are not available. Maybe we can insist describing > these > cases, thus motivating the need. Work is already been done in IEEE. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 06:59:24 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74EEB28C13D; Wed, 19 Nov 2008 06:59:24 -0800 (PST) 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 5AA043A6B9A for ; Wed, 19 Nov 2008 06:59:23 -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 17omv57+E6By for ; Wed, 19 Nov 2008 06:59:22 -0800 (PST) Received: from mho-02-bos.mailhop.org (mho-02-bos.mailhop.org [63.208.196.179]) by core3.amsl.com (Postfix) with ESMTP id 8FE3A3A67F9 for ; Wed, 19 Nov 2008 06:59:22 -0800 (PST) Received: from [130.129.78.103] by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1L2oWW-0002D6-ID; Wed, 19 Nov 2008 14:59:20 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 130.129.78.103 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+pcNBl9CZFBg8Rw+ZThhSk In-Reply-To: <00a301c94a4f$9b3c6c70$d1b54550$@nl> References: <00a301c94a4f$9b3c6c70$d1b54550$@nl> Mime-Version: 1.0 (Apple Message framework v753.1) X-Priority: 1 (Highest) Message-Id: <668C2F72-E9AC-4802-97D4-2D966C929DFF@thomasclausen.org> From: Thomas Heide Clausen Date: Wed, 19 Nov 2008 15:59:47 +0100 To: Teco Boot X-Mailer: Apple Mail (2.753.1) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Crash meeting? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Teco, I will, unfortunately, not be able to attend such a meeting after MANET, as I have to fly back immediately as the meeting concludes. It's unfortunate, to be sure, but I support the idea of such a meeting 100%. I'd like to ensure that if it takes place, then Shubhranshu will be there, and also that there be taken minutes which can be posted on the mailing list such that discussions can continue and be shared with those who're unable to attend the "crash meeting". Sounds good? Thomas On Nov 19, 2008, at 15:03 PM, Teco Boot wrote: > I think it is important that we have a clear understanding of the > situation, > on who is doing what. And on the status of the MANET architecture > document. > I suggest having a short, informal and non-technical meeting. The > outcome > could be a small design team working on a new document, to be > released soon. > What about a rendezvous after the MANET meeting? We can schedule > another > time and place if we want to. > Teco. > > _______________________________________________ > 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 autoconf-bounces@ietf.org Wed Nov 19 07:01:45 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E97628C1B5; Wed, 19 Nov 2008 07:01:45 -0800 (PST) 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 E198228C1B5 for ; Wed, 19 Nov 2008 07:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.245 X-Spam-Level: X-Spam-Status: No, score=-6.245 tagged_above=-999 required=5 tests=[AWL=0.354, 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 hiqq63fQaGBq for ; Wed, 19 Nov 2008 07:01:42 -0800 (PST) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id 2884528C1BC for ; Wed, 19 Nov 2008 07:00:51 -0800 (PST) Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id mAJF0lbj015298 for ; Wed, 19 Nov 2008 15:00:47 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id mAJF0l4A012257 for ; Wed, 19 Nov 2008 15:00:47 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 19 Nov 2008 15:00:47 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 19 Nov 2008 15:00:47 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 19 Nov 2008 15:00:44 -0000 Message-ID: In-Reply-To: <49242595.2030503@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Non-transitivity as issue Thread-Index: AclKVOte6UvGuhNLQuCl26sLqO0BvwAACoLw References: <7877C5C0B5CC894AB26113CF06CF886301238C9D@ms-dt01thalia.tsn.tno.nl><49232CD2.3030304@inria.fr> <7.0.0.16.2.20081119210453.03f9e0d0@ie.niigata-u.ac.jp> <49242173.9060500@gmail.com> <49242595.2030503@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 19 Nov 2008 15:00:47.0322 (UTC) FILETIME=[9A9ADBA0:01C94A57] Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] Non-transitivity as issue X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Alexander OPetrescu wrote: >Dearlove, Christopher (UK) wrote: >> And those are the small pieces (e.g. one Ethernet) >> that are considered links, set up as subnets, run ND, and all those >> things. > > I don't think we can consider an Ethernet cable to be transitive. > We can question the transitivity of two Ethernet cables: I didn't say two, I said one. (OK, I didn't qualify by cable. Put it in if you want it. And yes, of course one fails if too long, or badly configured, but that's not the case I'm referring to either.) > For every wired and wireless technology there are connectors solving > the non-transitivity problems at their particular layer. There may be connectors that may be available. They may not be. > YOu said previously that in some instances > such connectors are not available. I did, and I do. For any radio system with a range X (yes, I know things aren't usually that simple) if we deploy A, B, C in a line at a spacing of 3X/4, A and C can't communicate directly. And there are many cases where that's the problem, you can't add anything else. But A and C need to communicate. Fine, that's what the whole MANET concept is about. But if we are going to do it using IP, we need, if we are going to do it in an IETF-specified way, to go down the route we're on to define interfaces and link types and all those things. But whatever we do, there's one thing we are stuck with, and that is that A and C can't communicate directly. At the physical layer, up to whatever layer we implement the MANET at, there will be two transmissions to get information from A to C. If the MANET is at L2, most of the L3 problems are solved (but they are still someone's problem). But the MANET WG, and by extension the Autoconf WG, is about doing the MANET at L3, and hence we have the problem. I think this branch has become a blind alley, and I'll leave it here. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 07:21:16 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B4DE3A6805; Wed, 19 Nov 2008 07:21:16 -0800 (PST) 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 577803A6805 for ; Wed, 19 Nov 2008 07:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[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 UyiJoLQD7Fdu for ; Wed, 19 Nov 2008 07:21:14 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 6D3753A67F9 for ; Wed, 19 Nov 2008 07:21:14 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-128.messagelabs.com!1227108072!11186871!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 28180 invoked from network); 19 Nov 2008 15:21:12 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-128.messagelabs.com with SMTP; 19 Nov 2008 15:21:12 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mAJFL8TZ027025; Wed, 19 Nov 2008 08:21:12 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id mAJFL70f001638; Wed, 19 Nov 2008 09:21:07 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id mAJFL6sY001619; Wed, 19 Nov 2008 09:21:06 -0600 (CST) Message-ID: <49242EE1.2090203@gmail.com> Date: Wed, 19 Nov 2008 16:21:05 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <7877C5C0B5CC894AB26113CF06CF886301238C9D@ms-dt01thalia.tsn.tno.nl><49232CD2.3030304@inria.fr> <7.0.0.16.2.20081119210453.03f9e0d0@ie.niigata-u.ac.jp> <49242173.9060500@gmail.com> <49242595.2030503@gmail.com> In-Reply-To: X-Antivirus: avast! (VPS 081118-0, 18/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] Non-transitivity as issue X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Dearlove, Christopher (UK) wrote: > Alexander OPetrescu wrote: >> Dearlove, Christopher (UK) wrote: >>> And those are the small pieces (e.g. one Ethernet) that are >>> considered links, set up as subnets, run ND, and all those >>> things. >> I don't think we can consider an Ethernet cable to be transitive. > >> We can question the transitivity of two Ethernet cables: > > I didn't say two, I said one. (OK, I didn't qualify by cable. Put it > in if you want it. And yes, of course one fails if too long, or > badly configured, but that's not the case I'm referring to either.) > >> For every wired and wireless technology there are connectors >> solving the non-transitivity problems at their particular layer. > > There may be connectors that may be available. They may not be. > >> YOu said previously that in some instances such connectors are not >> available. > > I did, and I do. For any radio system with a range X (yes, I know > things aren't usually that simple) if we deploy A, B, C in a line at > a spacing of 3X/4, A and C can't communicate directly. I agree. And for any digital wired system they have max lenghts of transmission; eg Ethernet maximum is 150m IIRC - if we deploy a cable longer than 150m with a host in the middle there's non-transitivity issue. Fiber has similar limitations in cable length above which one needs repeater. USB and FireWire too. If when we say 'radio' we think signals travel through copper as radio waves, because they are waves with frequencies, then we equate the non-transitivity issue to cables too - which is a paradox: cables are non-transitive radio systems? This is where I believe it's biting its queue, because a too strong belief in that radio is something different may lead to paradoxes. For clarification: I believe despite its mentioning in authoritative books, the non-transitivity aspects are irrelevant to WiFi and IP. > And there are many cases where that's the problem, you can't add > anything else. But A and C need to communicate. Fine, that's what the > whole MANET concept is about. But if we are going to do it using IP, > we need, if we are going to do it in an IETF-specified way, to go > down the route we're on to define interfaces and link types and all > those things. But whatever we do, there's one thing we are stuck > with, and that is that A and C can't communicate directly. At the > physical layer, up to whatever layer we implement the MANET at, there > will be two transmissions to get information from A to C. If the > MANET is at L2, most of the L3 problems are solved (but they are > still someone's problem). > > But the MANET WG, and by extension the Autoconf WG, is about doing > the MANET at L3, and hence we have the problem. This is where we may may have another big misunderstanding. If AUTOCONF is all about MANET WG then I think I should stop posting here. > I think this branch has become a blind alley, and I'll leave it here. Well, I believe too, thanks for the mail. I think I'm not in disagreement with you to say that we completely disagree on the non-transitivity being or not being an issue. Alex > > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 08:02:05 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF4433A6BA9; Wed, 19 Nov 2008 08:02:05 -0800 (PST) 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 BB20A3A6BA9 for ; Wed, 19 Nov 2008 08:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[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 h5B4lM46tnqe for ; Wed, 19 Nov 2008 08:02:04 -0800 (PST) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id A1AE43A6BA3 for ; Wed, 19 Nov 2008 08:02:03 -0800 (PST) Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id mAJG20V7006063 for ; Wed, 19 Nov 2008 16:02:00 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id mAJG1xZZ021871 for ; Wed, 19 Nov 2008 16:01:59 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 19 Nov 2008 16:01:59 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 19 Nov 2008 16:01:59 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 19 Nov 2008 16:01:57 -0000 Message-ID: In-Reply-To: <49242EE1.2090203@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Non-transitivity as issue Thread-Index: AclKWnZxAE2Wq1+nT3aoySuBNp4fJgABUGGg References: <7877C5C0B5CC894AB26113CF06CF886301238C9D@ms-dt01thalia.tsn.tno.nl><49232CD2.3030304@inria.fr> <7.0.0.16.2.20081119210453.03f9e0d0@ie.niigata-u.ac.jp> <49242173.9060500@gmail.com> <49242595.2030503@gmail.com> <49242EE1.2090203@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 19 Nov 2008 16:01:59.0525 (UTC) FILETIME=[27689150:01C94A60] Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] Non-transitivity as issue X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org >> But the MANET WG, and by extension the Autoconf WG, is about doing >> the MANET at L3, and hence we have the problem. > This is where we may may have another big misunderstanding. If AUTOCONF > is all about MANET WG then I think I should stop posting here. Again, you misinterpret what I said. I said Autoconf is about MANETs at L3, not about MANET WG. Though right now the Autoconf task is a MANET architecture, and that must be consistent with the MANET WG (or if you prefer, the MANET WG should be consistent with it). Obviously Autoconf will do different work to the MANET WG. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 08:13:36 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E71528C15A; Wed, 19 Nov 2008 08:13:36 -0800 (PST) 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 6CAD83A6B8B for ; Wed, 19 Nov 2008 08:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 koXFG2r8D+pb for ; Wed, 19 Nov 2008 08:12:58 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 884F83A6B03 for ; Wed, 19 Nov 2008 08:12:58 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so11837yxg.49 for ; Wed, 19 Nov 2008 08:12:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=7tDQ1sRHs2dN3aTwbEnq2HLHSuOkrVHJ3/9lQmIWUmY=; b=ps2XgSBvJzwN0/yVvvG+d7iY0lCXnQADTJS0UllFdT0DfhXvi3m1489t5ReaN6r6hW E3Qz9mZ6FPl8q9egiPPgmgvjana6UuLkevo/dSRpdfF+ZEkGuKepGseZhcVVH1x/Sqwj 5xJQQzuKDh2adijC5MuIvqOpY54pZKi6DLhZg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=QzpTk86XtxWY0IGBzvwhQjwmjKGw06Dla5gOPvgXnOS/ur0nKMSnyMb1jWhada63EY 7dI9Mbn8IBtfVHgvMbis7fdDo5oP/AmjZFwG9LYk2qrz5HcmvUegIWS8iR+1nuyDJ7Cv TJ58ScyqzsaUigHcaEAVKrWnJsHMnpYp9yh3g= Received: by 10.142.241.15 with SMTP id o15mr614466wfh.104.1227111176452; Wed, 19 Nov 2008 08:12:56 -0800 (PST) Received: by 10.143.62.8 with HTTP; Wed, 19 Nov 2008 08:12:56 -0800 (PST) Message-ID: Date: Wed, 19 Nov 2008 08:12:56 -0800 From: "Seung Yi" To: autoconf@ietf.org MIME-Version: 1.0 Content-Disposition: inline Subject: [Autoconf] Why the link definition? X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: scicarus@iname.com List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org During the meeting yesterday, Thomas Clausen mentioned that there were a group of people who requested for the MANET link definition in a previous IETF meeting. Maybe it's just me but could someone clarify why one would need such a definition? As far as I'm concerned, I had no problem working on a MANET autoconfiguration design while considering a radio range (say, something like a 3D sphere for an omni radio like 802.11) as the replacement of a link. Only that, this new "link" had quite a few non-traditional characteristics such as, (1) the fact I can reach node B (therefore consider node B is on the link I'm on) doesn't mean I am on the link he's on, or some would describe as link asymmetry, and (2) the membership of other nodes on the link I'm on can change frequently and drastically. ND works when the network condition allows two nodes to actually share a view (or they can reach each other) and fails otherwise, which is completely fine because "neighbors" can be considered as two nodes that can reach each other at a point in time. Flat routing works just fine also. Depending on the address configuration, one can configure such a MANET as a set of nodes with disjoint prefixes or as a multi-link subnet. BTW, as long as you have a flat routing support, multi-link subnet works just fine. ND will not discover all other nodes in the same subnet, but it'll still discover all other nodes on the "link" I'm on. As mentioned in the meeting yesterday, I also haven't yet run into any application misbehavior because of the multi-link subnet configuration. Is there any reason that two (or more) nodes need to share a common view of a link to design anything? Maybe these are basic questions but I just thought I would ask before jumping into the discussion. Thanks, - Seung _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 08:46:12 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C89628C102; Wed, 19 Nov 2008 08:46:12 -0800 (PST) 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 4F75828C102 for ; Wed, 19 Nov 2008 08:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dnl3jzCpUIEm for ; Wed, 19 Nov 2008 08:46:07 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 8A2353A6BAB for ; Wed, 19 Nov 2008 08:46:06 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.224.130]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAJGk3rJ026540; Wed, 19 Nov 2008 16:46:03 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAJGk12v165165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Nov 2008 08:46:02 -0800 (PST) Message-ID: <492442C9.60404@sun.com> Date: Wed, 19 Nov 2008 08:46:01 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.17 (X11/20081023) MIME-Version: 1.0 To: Thomas Narten References: <200811191440.mAJEeRPu017560@cichlid.raleigh.ibm.com> In-Reply-To: <200811191440.mAJEeRPu017560@cichlid.raleigh.ibm.com> Cc: autoconf@ietf.org Subject: Re: [Autoconf] link definitions 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Thomas Narten wrote: > It is very important that we are clear and precise about > terminology. I suspect that 80% of the confusion we have had stems > from folk using terminology loosely, causing the listener to think > something completely different from what the speaker intends. (I saw > clear examples of this in yesterday's meeting). That helps no one and > keeps us going in circles. > > Let's start with "link". Even the term "link" is unclear. Are we > talking about an "IP link" or what most of us would consider an "L2 > link"? (They are not necessarily the same.) > > From RFC 2460, link is defined as: > > link - a communication facility or medium over which nodes can > communicate at the link layer, i.e., the layer > immediately below IPv6. Examples are Ethernets (simple > or bridged); PPP links; X.25, Frame Relay, or ATM > networks; and internet (or higher) layer "tunnels", > such as tunnels over IPv4 or IPv6 itself. > > What is unstated (but assumed) above is that all the nodes in the link > can reach each other. Note also that the above is really an L2 > definition. Are you renaming the above term "link" to be named "IP link"? > It means that a node attached to the link can send a > packet to another node on the link (and vice versa). How that is done > (whether via a shared wire, or via packet switches doing routing, a > bridged ethernet, etc.) doesn't matter. The important thing is the > abstraction, that every node on the link can reach every other node on > the link. By "packet" are you talking about an (arbitrary) L2 frame, i.e., something which might not be an IP packet? > If we up-level to what IP sees, an "IP link" has a similar > definition. It is assumed that all nodes on the link can directly send > an IP datagram to another node on the link, and it will get > delivered. Whether the underlying link has bridges/packet > switches/etc. doesn't matter. From IP's perspective, it sends a packet > and it gets deliverd without the TTL being decremented. That is what > IP cares about. AFAIU your use of "IP link" and "l2 link" I can't think of a useful case when they would differ. Do you see cases when they would differ? (If there are L3 routers which forward packets without decrementing TTL then they would differ, but that is not useful and presumably violates the router requirements RFC.) > Also, by definition. for an "IP link", link-local multicast/broadcast > means that the packet is delivered everywhere without decrementing a > TTL. It has never made sense to me to say that "IP-level LL broadcast" > doesn't work in a MANET, because that is calling something an "IP > link" that does not have the properties to be a "IP link" in the > normal sense. Agreed. > When talking about a "MANET link", we should (first) be talking about > what is happening below IP (i.e., either at L2, or maybe L2.5, if one > wants to think of running the MANET protocols over the interface to > provide IP with an "IP link" abstraction). Exactly what are the > features of such a link? > > A key question is what is the definition of a MANET Link? Previous > documents/conversations have suggested to me that some folk want to > make the entire collection of nodes running MANET form a MANET link. I don't think we need a separate definition of a Manet Link. > Looking at chart 37 of ThomasC's presentation yesterday, for example, > is the entire white cloud (i.e. all the routers) considered to be one > link? That doesn't make sense to me. I got the impression that this approach was taken to try to preserve that a subnet prefix corresponds to a piece of topology where ttl isn't decremented, and I think that isn't something we need to preserve when the subnet prefix isn't advertised as "on link". Erik _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 09:01:31 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76ABA3A6805; Wed, 19 Nov 2008 09:01:31 -0800 (PST) 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 C5AD73A6805 for ; Wed, 19 Nov 2008 09:01:30 -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 fyPNIRisjlgd for ; Wed, 19 Nov 2008 09:01:26 -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 8B1A63A67AD for ; Wed, 19 Nov 2008 09:01:26 -0800 (PST) Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by e8.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id mAJGv6k6008515 for ; Wed, 19 Nov 2008 11:57:06 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mAJH15WC1978438 for ; Wed, 19 Nov 2008 12:01:06 -0500 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mAJH0vC9005020 for ; Wed, 19 Nov 2008 10:00:57 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-65-201-183.mts.ibm.com [9.65.201.183]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mAJH0Xde002081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Nov 2008 10:00:35 -0700 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id mAJH0WeD000999; Wed, 19 Nov 2008 12:00:33 -0500 Message-Id: <200811191700.mAJH0WeD000999@cichlid.raleigh.ibm.com> To: Erik Nordmark In-reply-to: <492442C9.60404@sun.com> References: <200811191440.mAJEeRPu017560@cichlid.raleigh.ibm.com> <492442C9.60404@sun.com> Comments: In-reply-to Erik Nordmark message dated "Wed, 19 Nov 2008 08:46:01 -0800." Date: Wed, 19 Nov 2008 12:00:32 -0500 From: Thomas Narten Cc: autoconf@ietf.org Subject: Re: [Autoconf] link definitions 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Erik Nordmark writes: > Thomas Narten wrote: > > It is very important that we are clear and precise about > > terminology. I suspect that 80% of the confusion we have had stems > > from folk using terminology loosely, causing the listener to think > > something completely different from what the speaker intends. (I saw > > clear examples of this in yesterday's meeting). That helps no one and > > keeps us going in circles. > > > > Let's start with "link". Even the term "link" is unclear. Are we > > talking about an "IP link" or what most of us would consider an "L2 > > link"? (They are not necessarily the same.) > > > > From RFC 2460, link is defined as: > > > > link - a communication facility or medium over which nodes can > > communicate at the link layer, i.e., the layer > > immediately below IPv6. Examples are Ethernets (simple > > or bridged); PPP links; X.25, Frame Relay, or ATM > > networks; and internet (or higher) layer "tunnels", > > such as tunnels over IPv4 or IPv6 itself. > > > > What is unstated (but assumed) above is that all the nodes in the link > > can reach each other. Note also that the above is really an L2 > > definition. > Are you renaming the above term "link" to be named "IP link"? Probably.. :-) But I think it is useful to keep in mind that it is not a _requirement_ to have a one-to-one mapping between an "IP link" and an "L2 link". I don't think it makes sense in very many (if any?) cases, but one difficulty I have had in understanding MANETs is that I don't get a clear sense the WG has that agreement. (I'd love to learn I'm wrong, of course). > > It means that a node attached to the link can send a > > packet to another node on the link (and vice versa). How that is done > > (whether via a shared wire, or via packet switches doing routing, a > > bridged ethernet, etc.) doesn't matter. The important thing is the > > abstraction, that every node on the link can reach every other node on > > the link. > By "packet" are you talking about an (arbitrary) L2 frame, i.e., > something which might not be an IP packet? Correct. But of course, if one were to send an IP packet in such an L2 frame, it would be delivered without the need to decrement the IP TTL. > > If we up-level to what IP sees, an "IP link" has a similar > > definition. It is assumed that all nodes on the link can directly send > > an IP datagram to another node on the link, and it will get > > delivered. Whether the underlying link has bridges/packet > > switches/etc. doesn't matter. From IP's perspective, it sends a packet > > and it gets deliverd without the TTL being decremented. That is what > > IP cares about. > AFAIU your use of "IP link" and "l2 link" I can't think of a useful case > when they would differ. Do you see cases when they would differ? Well, in the autoconf discussions, I sometimes get the sense we are talking about two different "links": one as viewed at the IP layer and one that viewed from the perspective of describing a "manet link" (more generically), where it is NOT immediately clear (to me) that they are the same. I say that because at the MANET link level, there is talk about packets being forwarded through intermediate routers (with a decremented TTL), with this also somehow being an IP link (which I think is not legal by the definition of an IP link per below). > (If there are L3 routers which forward packets without decrementing TTL > then they would differ, but that is not useful and presumably violates > the router requirements RFC.) > > Also, by definition. for an "IP link", link-local multicast/broadcast > > means that the packet is delivered everywhere without decrementing a > > TTL. It has never made sense to me to say that "IP-level LL broadcast" > > doesn't work in a MANET, because that is calling something an "IP > > link" that does not have the properties to be a "IP link" in the > > normal sense. > Agreed. > > When talking about a "MANET link", we should (first) be talking about > > what is happening below IP (i.e., either at L2, or maybe L2.5, if one > > wants to think of running the MANET protocols over the interface to > > provide IP with an "IP link" abstraction). Exactly what are the > > features of such a link? > > > > A key question is what is the definition of a MANET Link? Previous > > documents/conversations have suggested to me that some folk want to > > make the entire collection of nodes running MANET form a MANET link. > I don't think we need a separate definition of a Manet Link. Well, we need to agree whether they can be the same definition or not (I'd prefer they are the same!). But if not, we get into the need to describe the properties of such a link (which presumably do not match the needed properties of an IP link) so that we can talk about how to transform such a link into something IP can work across. > > Looking at chart 37 of ThomasC's presentation yesterday, for example, > > is the entire white cloud (i.e. all the routers) considered to be one > > link? > That doesn't make sense to me. I got the impression that this approach > was taken to try to preserve that a subnet prefix corresponds to a > piece of topology where ttl isn't decremented, and I think that isn't > something we need to preserve when the subnet prefix isn't advertised as > "on link". Right. I think I agree with this as well. But as always, the challenge has been whether the WG overall has a consistent view/understanding of these sorts of key archtictural points. Thomas _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 09:40:51 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDACC3A698F; Wed, 19 Nov 2008 09:40:51 -0800 (PST) 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 83E9B3A698F for ; Wed, 19 Nov 2008 09:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.904 X-Spam-Level: X-Spam-Status: No, score=-0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qN3bLu18-TrP for ; Wed, 19 Nov 2008 09:40:50 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id C46A53A681D for ; Wed, 19 Nov 2008 09:40:49 -0800 (PST) Received: (qmail 26171 invoked from network); 19 Nov 2008 18:40:45 +0100 Received: from unknown (HELO M90Teco) (130.129.95.96) by server9.hosting2go.nl with SMTP; 19 Nov 2008 18:40:45 +0100 From: "Teco Boot" To: "'Thomas Narten'" References: <200811191440.mAJEeRPu017560@cichlid.raleigh.ibm.com> In-Reply-To: <200811191440.mAJEeRPu017560@cichlid.raleigh.ibm.com> Date: Wed, 19 Nov 2008 18:40:07 +0100 Message-ID: <000001c94a6d$f2ee6450$d8cb2cf0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclKVNlK7r1EEARZQw+/FuTsf8eqTAAArpHQ Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] link definitions 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > It is very important that we are clear and precise about > terminology. I suspect that 80% of the confusion we have had stems > from folk using terminology loosely, causing the listener to think > something completely different from what the speaker intends. (I saw > clear examples of this in yesterday's meeting). That helps no one and > keeps us going in circles. > > Let's start with "link". Even the term "link" is unclear. Are we > talking about an "IP link" or what most of us would consider an "L2 > link"? (They are not necessarily the same.) > > From RFC 2460, link is defined as: > > link - a communication facility or medium over which nodes > can > communicate at the link layer, i.e., the layer > immediately below IPv6. Examples are Ethernets > (simple > or bridged); PPP links; X.25, Frame Relay, or ATM > networks; and internet (or higher) layer "tunnels", > such as tunnels over IPv4 or IPv6 itself. > > What is unstated (but assumed) above is that all the nodes in the link > can reach each other. Note also that the above is really an L2 > definition. It means that a node attached to the link can send a > packet to another node on the link (and vice versa). How that is done > (whether via a shared wire, or via packet switches doing routing, a > bridged ethernet, etc.) doesn't matter. The important thing is the > abstraction, that every node on the link can reach every other node on > the link. Although I agree this is the general case, there may be exceptions. Think of private VLANs and hub&spoke NBMA networks where routers perform spoke-to-spoke forwarding functions (hairpinning). See also my posting on STD IEEE802.11-2007 on 3.16 (BSS), it clearly states that the assumption is false. I think the issues is more related to IBSS than BSS (or ESS). For those who do not know, most 802 standards can be downloaded on: http://standards.ieee.org/getieee802/ The question here is, do we want to support IPv6 on systems like 802.11 in IBSS mode? I think: yes, we do. Another question: do we want to repair asymmetric reachability (both unidirectional and non-transitive) at the IP layer? I think: yes we do, and that MANET protocols are designed doing so. I would say this is for routers only, not for hosts. Here may start some confusing. Because MANET protocol designers are so proud on their efforts (thanks folks!), they may forget that there are "well-behaving L2 systems" as well. And I can agree with the assumed intention of Thomas Narten: solve problems at the layer that introduced it. However, the question is: is this optimal?. I can demonstrate a layer-2 solution based on STP, but performance is not quite good. STP / RSTP is not designed with mobility in mind. I am not the expert in 802.11s, but I assume they reuse what is designed in the IETF MANET WG. And it is homogeneous. An advantage of a L3-MANET is that a heterogeneous networking infrastructure is supported. See also RFC2501 section 5. > A key question is what is the definition of a MANET Link? Previous > documents/conversations have suggested to me that some folk want to > make the entire collection of nodes running MANET form a MANET link. OK, we discussed this in the meeting and had consensus to step towards defining a MANET link model that meets the IP link requirements, e.g. link-local delivery, no TTL decrement and so on. There was a comment on wording in RFC4861. interface - a node's attachment to a link. ^ The "a" hurts. In RFC4861, a link is a "medium". Now, we decided to redefine this for MANETs. > If instead, we view the white cloud as collection of individual links > (e.g., with a link defined by the set of neighbors within radio range > of each other), we get a very different link model. This model > presumably also has some important properties. What are they? How do > they compare to the other model? Does the model make it easier or > harder to solve certain problems? I tried to come up with a definition for "collection of individual links" >>> A MANET Interface has a single outbound unidirectional P2MP link to a set of neighbors, a set of inbound unidirectional P2MP links from a set of neighbors, a set of bi-directional P2P links with a set of neighbors and a set of unidirectional P2P links from a set of neighbors. The sets of neighbors and the link qualities vary over time and link metrics may be asymmetric. Furthermore, links between the MANET Interfaces could be non-transitive. A characteristic of MANET Links is interference, i.e. a transmission from a MANET Interface could influence other MANET Links. <<< Maybe I should use broadcast instead of P2MP. On "certain problems": the target of the MANET routing protocols is solve those problems. This implies that there cannot be hosts on the MANET Link, as hosts do not routing. > In my mind, the excercise of defining a "MANET link" is all about > being able to talk about different abstract models (like the two > above) and then be able to talk (in specific engineering terms) about > which one makes more sense to use in trying to make IP work well over > MANETs. Can we scope down towards trying to make MANET Routing Protocols work well? For unicast routing, there are solutions and we are working on standard track protocols. For multicast routing, this is somewhat harder, but work in progress and solutions are out there. We have to work on link layer address resolving (ND), in my opinion this is relatively easy. And the real Autoconf work: Address Autoconfiguration with MANET and / or globally unique addresses. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 11:14:57 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B8A428C1D7; Wed, 19 Nov 2008 11:14:57 -0800 (PST) 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 1496428C1D5 for ; Wed, 19 Nov 2008 11:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXDGG5RQN96j for ; Wed, 19 Nov 2008 11:14:55 -0800 (PST) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id D513828C1D2 for ; Wed, 19 Nov 2008 11:14:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,633,1220220000"; d="scan'208";a="20142832" Received: from unknown (HELO BoolfightMaN-Laptop.local) ([130.129.29.95]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Nov 2008 20:14:51 +0100 Message-ID: <492465A9.60603@inria.fr> Date: Wed, 19 Nov 2008 20:14:49 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: autoconf@ietf.org X-Enigmail-Version: 0.95.7 Subject: Re: [Autoconf] draft-clausen-manet-linktype - naming 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org The thing that may be confusing people is that sometimes the link looks like an ethernet, and the next minute it looks different (for example you suddenly have no transitivity etc.). So maybe the most important thing is in fact this dynamism in property, which may be easier to explain. And thus the link model would fall out as the "least common denominator" of all these possible properties. Emmanuel On Wed, Nov 19, 2008 at 2:45 PM, Dearlove, Christopher (UK) wrote: > If there is the non-transitivity regardless of the link model or > assumption, how does it help to discuss or define any link model > for MANETs? First you recognise that you have non-transitivity. Then you decide what your link model should be that handles that. This is as opposed to when you have transitivity (and symmetry). Then you have a wider range of possible link models. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 13:50:32 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F4E73A6A84; Wed, 19 Nov 2008 13:50:32 -0800 (PST) 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 1AD1A3A6895 for ; Wed, 19 Nov 2008 13:50:31 -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 kCyCOem3YZ3M for ; Wed, 19 Nov 2008 13:50:30 -0800 (PST) Received: from maili.marvell.com (host2.marvell.com [65.219.4.2]) by core3.amsl.com (Postfix) with ESMTP id B50F73A6A84 for ; Wed, 19 Nov 2008 13:50:29 -0800 (PST) Received: from MSI-MTA.marvell.com (msi-mta.marvell.com [10.68.76.91]) by maili.marvell.com (Postfix) with ESMTP id 771DF5E61F; Wed, 19 Nov 2008 13:50:28 -0800 (PST) Received: from sc-owa01.marvell.com ([10.93.76.21]) by MSI-MTA.marvell.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Nov 2008 13:50:28 -0800 Received: from sc-owa02.marvell.com (10.93.76.22) by sc-owa01.marvell.com (10.93.76.21) with Microsoft SMTP Server (TLS) id 8.1.291.1; Wed, 19 Nov 2008 13:50:27 -0800 Received: from SC-EXCH1.marvell.com ([10.93.76.25]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Wed, 19 Nov 2008 13:50:27 -0800 From: Paul Lambert To: "Dearlove, Christopher (UK)" , Emmanuel Baccelli , "autoconf@ietf.org" Date: Wed, 19 Nov 2008 13:50:26 -0800 Thread-Topic: [Autoconf] draft-clausen-manet-linktype - naming Thread-Index: AclJwKfdmHi6Q5ZtR9aMgX/XKtN7MAAak26wABj3sKA= Message-ID: <5A22FB9EDAA74547916480634CCC743817AD0BBC82@SC-EXCH1.marvell.com> References: <7877C5C0B5CC894AB26113CF06CF886301238C9D@ms-dt01thalia.tsn.tno.nl> <49232CD2.3030304@inria.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 19 Nov 2008 21:50:28.0340 (UTC) FILETIME=[D6088B40:01C94A90] Subject: Re: [Autoconf] draft-clausen-manet-linktype - naming 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > > what is special about these links, is that their properties vary more > > than usual: > > (i) over time, and > > (ii) between different instances of links of the type. > > I think those are of secondary importance. It's the (possible) > non-symmetry, non-transitivity that's of primary importance. > I find this issue and the document in discussion to be quite confusing. I see no reason to define such special links. A link never has any guarantee of 'transitivity'. It appears that the mental model being used is biased to experiences with LANs where the 'links' provide a fully connected graph of connectivity. In general this is the special case. Transitivity is an unnecessary concept - it is however the type of connectivity that is the interesting edge condition for MANETs Regards, Paul PS - only recently lurking so please excuse me if my confusion is due to lack of full context. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 15:52:34 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C93C228C120; Wed, 19 Nov 2008 15:52:34 -0800 (PST) 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 AFA6B28C120 for ; Wed, 19 Nov 2008 15:52:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0-UFaVfCk0b for ; Wed, 19 Nov 2008 15:52:33 -0800 (PST) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id F342128C105 for ; Wed, 19 Nov 2008 15:52:32 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.104.45]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAJNqWgf006830; Wed, 19 Nov 2008 23:52:32 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAJNqRO7174626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Nov 2008 15:52:28 -0800 (PST) Message-ID: <4924A6BB.4070601@sun.com> Date: Wed, 19 Nov 2008 15:52:27 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.17 (X11/20081023) MIME-Version: 1.0 To: Thomas Narten References: <200811191440.mAJEeRPu017560@cichlid.raleigh.ibm.com> <492442C9.60404@sun.com> <200811191700.mAJH0WeD000999@cichlid.raleigh.ibm.com> In-Reply-To: <200811191700.mAJH0WeD000999@cichlid.raleigh.ibm.com> Cc: autoconf@ietf.org Subject: Re: [Autoconf] link definitions 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Thomas Narten wrote: > Well, in the autoconf discussions, I sometimes get the sense we are > talking about two different "links": one as viewed at the IP layer and > one that viewed from the perspective of describing a "manet link" > (more generically), where it is NOT immediately clear (to me) that > they are the same. I say that because at the MANET link level, there > is talk about packets being forwarded through intermediate routers > (with a decremented TTL), with this also somehow being an IP link > (which I think is not legal by the definition of an IP link per below). Yes, but I don't think that makes any sense. But even if there was such a thing as a "manet link" my understanding is that it wouldn't match your definition of "IP link", since AFAIK the manet routers decrement ttl. It is useful for manet, as well as 6lowpan, to have a prefix (which I think of a subnet prefix) span more than one link, because it allows nodes to move around inside the subnet without having to change their IP address and the whole think can be aggregated into a single route that is announced externally to the manet. We have many of the parts we need for this (RAs don't have to advertise any on-link prefixes), but one would need to do duplicate address detection differently. > Well, we need to agree whether they can be the same definition or not > (I'd prefer they are the same!). But if not, we get into the need to > describe the properties of such a link (which presumably do not match > the needed properties of an IP link) so that we can talk about how to > transform such a link into something IP can work across. Agreed. > But as always, the challenge has been whether the WG overall has a > consistent view/understanding of these sorts of key archtictural > points. I can't speak for the WG, but to me there has been two pieces missing: - the motivation for why it makes sense to define the link as what is within radio reachability - the terminology confusion where manet has described things as not having/needing any "links" since they just use "interfaces". Defining the link as "radio reachability" provides a definition which is both useful and consistent with (my understanding of) manet operational practices. (Of course, one can additionally have links that are glued onto the manet routers; these are the links between the "H" and "R" in Thomas' presentation.) Erik _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 16:41:45 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5B043A6B8B; Wed, 19 Nov 2008 16:41:45 -0800 (PST) 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 907E53A6B8B for ; Wed, 19 Nov 2008 16:41:44 -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 wN4kFlPYa-zw for ; Wed, 19 Nov 2008 16:41:43 -0800 (PST) Received: from maili.marvell.com (host2.marvell.com [65.219.4.2]) by core3.amsl.com (Postfix) with ESMTP id B58A13A6782 for ; Wed, 19 Nov 2008 16:41:43 -0800 (PST) Received: from MSI-MTA.marvell.com (msi-mta.marvell.com [10.68.76.91]) by maili.marvell.com (Postfix) with ESMTP id 0C6285A1BF; Wed, 19 Nov 2008 16:41:43 -0800 (PST) Received: from sc-owa01.marvell.com ([10.93.76.21]) by MSI-MTA.marvell.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Nov 2008 16:41:42 -0800 Received: from sc-owa02.marvell.com (10.93.76.22) by sc-owa01.marvell.com (10.93.76.21) with Microsoft SMTP Server (TLS) id 8.1.291.1; Wed, 19 Nov 2008 16:41:42 -0800 Received: from SC-EXCH1.marvell.com ([10.93.76.25]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Wed, 19 Nov 2008 16:41:42 -0800 From: Paul Lambert To: Erik Nordmark , Thomas Narten Date: Wed, 19 Nov 2008 16:41:41 -0800 Thread-Topic: [Autoconf] link definitions Thread-Index: AclKoeYJ7sHskPjQQC+LnCMBn66bVQABPMuw Message-ID: <5A22FB9EDAA74547916480634CCC743817AD0BBC91@SC-EXCH1.marvell.com> References: <200811191440.mAJEeRPu017560@cichlid.raleigh.ibm.com> <492442C9.60404@sun.com> <200811191700.mAJH0WeD000999@cichlid.raleigh.ibm.com> <4924A6BB.4070601@sun.com> In-Reply-To: <4924A6BB.4070601@sun.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 20 Nov 2008 00:41:42.0993 (UTC) FILETIME=[C2342C10:01C94AA8] Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] link definitions 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > > Thomas Narten wrote: > > > Well, in the autoconf discussions, I sometimes get the sense we are > > talking about two different "links": one as viewed at the IP layer and > > one that viewed from the perspective of describing a "manet link" > > (more generically), where it is NOT immediately clear (to me) that > > they are the same. I say that because at the MANET link level, there > > is talk about packets being forwarded through intermediate routers > > (with a decremented TTL), with this also somehow being an IP link > > (which I think is not legal by the definition of an IP link per below). > > Yes, but I don't think that makes any sense. > But even if there was such a thing as a "manet link" my understanding is > that it wouldn't match your definition of "IP link", since AFAIK the > manet routers decrement ttl. > > It is useful for manet, as well as 6lowpan, to have a prefix (which I > think of a subnet prefix) span more than one link, because it allows > nodes to move around inside the subnet without having to change their IP > address and the whole think can be aggregated into a single route that > is announced externally to the manet. > > We have many of the parts we need for this (RAs don't have to advertise > any on-link prefixes), but one would need to do duplicate address > detection differently. > > > Well, we need to agree whether they can be the same definition or not > > (I'd prefer they are the same!). But if not, we get into the need to > > describe the properties of such a link (which presumably do not match > > the needed properties of an IP link) so that we can talk about how to > > transform such a link into something IP can work across. > > Agreed. > > > But as always, the challenge has been whether the WG overall has a > > consistent view/understanding of these sorts of key archtictural > > points. > > I can't speak for the WG, but to me there has been two pieces missing: > - the motivation for why it makes sense to define the link as what is > within radio reachability > - the terminology confusion where manet has described things as not > having/needing any "links" since they just use "interfaces". > > Defining the link as "radio reachability" provides a definition which is > both useful and consistent with (my understanding of) manet operational > practices. Radio reachability is an incomplete definition. Please consider that all Wi-Fi links that use current mechanisms for 802.11 security require explicit establishment of the security association (Two - four way exchanges). Radio reachability does not imply link connectivity. Link connectivity is always arbitrary and reachability is only one aspect. I'm also finding that the explicit initial establishment of a "link" versus implicit reachability provides solutions in this architectural space rather than more constraints. The ability to have a clarity in the process of joining a network or creating a link enables better autoconf-like solutions. Specifically, the IP address assignment can be made an atomic operation with the addition of the link from the perspective of the network services. Paul _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 17:07:30 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 849EC28C1F2; Wed, 19 Nov 2008 17:07:30 -0800 (PST) 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 3A06628C1F2 for ; Wed, 19 Nov 2008 17:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayCkKuebODMg for ; Wed, 19 Nov 2008 17:07:28 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 039F328C1F1 for ; Wed, 19 Nov 2008 17:07:27 -0800 (PST) Received: (qmail 11044 invoked from network); 20 Nov 2008 02:07:24 +0100 Received: from unknown (HELO M90Teco) (12.104.246.2) by server9.hosting2go.nl with SMTP; 20 Nov 2008 02:07:24 +0100 From: "Teco Boot" To: "'Erik Nordmark'" References: <200811191440.mAJEeRPu017560@cichlid.raleigh.ibm.com> <492442C9.60404@sun.com> <200811191700.mAJH0WeD000999@cichlid.raleigh.ibm.com> <4924A6BB.4070601@sun.com> In-Reply-To: <4924A6BB.4070601@sun.com> Date: Thu, 20 Nov 2008 02:07:19 +0100 Message-ID: <004d01c94aac$57b1a4e0$0714eea0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclKoeijr9xE9KNsT+KLErv74NZ4xAAAhwpA Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] link definitions 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > It is useful for manet, as well as 6lowpan, to have a prefix (which I > think of a subnet prefix) span more than one link, because it allows > nodes to move around inside the subnet without having to change their > IP > address and the whole think can be aggregated into a single route that > is announced externally to the manet. I am not sure if we need this "wide prefix subnet". For the MANET Routers, we would use host prefixes (/128) on loopback interfaces, or maybe on the MANET interface itself if someone thinks this is a better approach. Configuring a /128 prefix on an interface would make the interface look like stub (not sure on this completely). Agreed on the aggregation prefix for the MANET. With multi-homing, we could have multiple aggregation prefixes. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 18:15:46 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B9C23A67A1; Wed, 19 Nov 2008 18:15:46 -0800 (PST) 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 6DE1C3A6895 for ; Wed, 19 Nov 2008 18:15:44 -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 NWCSA4vKAB8K for ; Wed, 19 Nov 2008 18:15:43 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id B7BC73A6778 for ; Wed, 19 Nov 2008 18:15:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=SccCvAiT4rd58xaSMLZqrvMXIl8I+R8apAdHh9SgNy8BPJidzZLZFI8DuW5UTDAl; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [130.129.28.139] by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L2z54-0007gw-Ie for autoconf@ietf.org; Wed, 19 Nov 2008 21:15:42 -0500 Message-ID: <4924C84D.5050502@earthlink.net> Date: Wed, 19 Nov 2008 18:15:41 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: autoconf@ietf.org X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5261090f2fcc5e0de68ed35ab06dfdc4da350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.28.139 Subject: [Autoconf] Subnet definition 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello folks, I'd like to propose the following two definitions. A "subnet" is a contiguous range of IP addresses that admits a routing prefix. A "subnet router" is a router that provides access to any node that uses one of the contiguous IP addresses belonging to the range of the subnet. ================================== However, there may be "routers" that do not make any such claim about routing to a subnet. In general, routers may forward packets to nodes that are on link but not part of any subnet for which the router provides access. This model of routing allows for a router to forward a packet to a node that is NOT on a subnet. It is my belief that these "non-subnet" routers are a crucial component of MANET routing, and that the attempt to fit them into any reasonable model of "subnet router" is doomed to frustration and failure. Regards, Charlie P. PS. I am resending this since the first attempt did not succeed... sorry if there is duplication. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 18:21:36 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 528763A6405; Wed, 19 Nov 2008 18:21:36 -0800 (PST) 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 D9BE73A6782 for ; Wed, 19 Nov 2008 18:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sOaIfDOyHkE for ; Wed, 19 Nov 2008 18:21:34 -0800 (PST) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 2DDE43A6405 for ; Wed, 19 Nov 2008 18:21:34 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.226.31]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAK2LX1I006736; Thu, 20 Nov 2008 02:21:33 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAK2LVXn177089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Nov 2008 18:21:32 -0800 (PST) Message-ID: <4924C975.60209@sun.com> Date: Wed, 19 Nov 2008 18:20:37 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.17 (X11/20081023) MIME-Version: 1.0 To: Paul Lambert References: <200811191440.mAJEeRPu017560@cichlid.raleigh.ibm.com> <492442C9.60404@sun.com> <200811191700.mAJH0WeD000999@cichlid.raleigh.ibm.com> <4924A6BB.4070601@sun.com> <5A22FB9EDAA74547916480634CCC743817AD0BBC91@SC-EXCH1.marvell.com> In-Reply-To: <5A22FB9EDAA74547916480634CCC743817AD0BBC91@SC-EXCH1.marvell.com> Cc: Thomas Narten , "autoconf@ietf.org" Subject: Re: [Autoconf] link definitions 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Paul Lambert wrote: > Radio reachability is an incomplete definition. Please consider that all Wi-Fi links that use current mechanisms for 802.11 security require explicit establishment of the security association (Two - four way exchanges). Radio reachability does not imply link connectivity. Link connectivity is always arbitrary and reachability is only one aspect. I agree that the term "radio reachability" is the wrong one to capture the security aspects for such technologies. What I mean (and I don't have a good term) is that if node A sends an L2 packet it arrives at node B, including any CRC or security checks. > I'm also finding that the explicit initial establishment of a "link" versus implicit reachability provides solutions in this architectural space rather than more constraints. The ability to have a clarity in the process of joining a network or creating a link enables better autoconf-like solutions. Specifically, the IP address assignment can be made an atomic operation with the addition of the link from the perspective of the network services. I don't see how you can this without either making assumptions about the capabilities of the L2 technology, or inventing some new L3 attachment protocol. Erik _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 18:21:37 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B2613A6849; Wed, 19 Nov 2008 18:21:37 -0800 (PST) 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 329F03A6782 for ; Wed, 19 Nov 2008 18:21:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ije2XtjlvSji for ; Wed, 19 Nov 2008 18:21:35 -0800 (PST) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 75B6F3A6405 for ; Wed, 19 Nov 2008 18:21:35 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.106.105]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAK2LYdl006741; Thu, 20 Nov 2008 02:21:34 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAK2LXtw177092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Nov 2008 18:21:34 -0800 (PST) Message-ID: <4924C9AD.9030904@sun.com> Date: Wed, 19 Nov 2008 18:21:33 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.17 (X11/20081023) MIME-Version: 1.0 To: scicarus@iname.com References: In-Reply-To: Cc: autoconf@ietf.org Subject: Re: [Autoconf] Why the link definition? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Seung Yi wrote: > As far as I'm concerned, I had no problem working on a MANET > autoconfiguration design while considering a radio range (say, > something like a 3D sphere for an omni radio like 802.11) as the > replacement of a link. Only that, this new "link" had quite a few > non-traditional characteristics such as, (1) the fact I can reach node > B (therefore consider node B is on the link I'm on) doesn't mean I am > on the link he's on, or some would describe as link asymmetry, and (2) > the membership of other nodes on the link I'm on can change frequently > and drastically. ND works when the network condition allows two nodes > to actually share a view (or they can reach each other) and fails > otherwise, which is completely fine because "neighbors" can be > considered as two nodes that can reach each other at a point in time. When you say "ND" what exactly do you mean? Two nodes using NS/NA exchanges to discover the L2 addresses to use for direct communication? The reason I'm asking for clarification is that I don't think that makes much sense when the link is defined as "within radio range", since that changes very frequently. That is why link-local addresses, as well as NS/NA as used on Ethernet, is of very limited use on such networks. But defining the link as a "within radio range" is AFAIK very useful for the routing protocols since they can use link-local communication (link-local addresses, and/or ttl=1) to find their neighbors. Erik _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 18:21:39 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A84ED3A6BCF; Wed, 19 Nov 2008 18:21:39 -0800 (PST) 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 0BE6F3A6BCF for ; Wed, 19 Nov 2008 18:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rw0kEDDPYvE for ; Wed, 19 Nov 2008 18:21:37 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 3C5843A6782 for ; Wed, 19 Nov 2008 18:21:37 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.108.31]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAK2LYVD018786; Thu, 20 Nov 2008 02:21:35 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAK2LXOv177093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Nov 2008 18:21:34 -0800 (PST) Message-ID: <4924C9A2.7080207@sun.com> Date: Wed, 19 Nov 2008 18:21:22 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.17 (X11/20081023) MIME-Version: 1.0 To: Teco Boot References: <200811191440.mAJEeRPu017560@cichlid.raleigh.ibm.com> <492442C9.60404@sun.com> <200811191700.mAJH0WeD000999@cichlid.raleigh.ibm.com> <4924A6BB.4070601@sun.com> <004d01c94aac$57b1a4e0$0714eea0$@nl> In-Reply-To: <004d01c94aac$57b1a4e0$0714eea0$@nl> Cc: autoconf@ietf.org Subject: Re: [Autoconf] link definitions 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Teco Boot wrote: >> It is useful for manet, as well as 6lowpan, to have a prefix (which I >> think of a subnet prefix) span more than one link, because it allows >> nodes to move around inside the subnet without having to change their >> IP >> address and the whole think can be aggregated into a single route that >> is announced externally to the manet. > > I am not sure if we need this "wide prefix subnet". For the MANET Routers, > we would use host prefixes (/128) on loopback interfaces, or maybe on the > MANET interface itself if someone thinks this is a better approach. > Configuring a /128 prefix on an interface would make the interface look like > stub (not sure on this completely). Which prefix are you going to allocate addresses from? That is the prefix I'm talking about. Erik _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 18:25:44 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2183E3A6782; Wed, 19 Nov 2008 18:25:44 -0800 (PST) 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 275053A6778 for ; Wed, 19 Nov 2008 18:23:13 -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 eOijFxwasXht for ; Wed, 19 Nov 2008 18:23:12 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 230C53A6405 for ; Wed, 19 Nov 2008 18:23:11 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so57609qwe.31 for ; Wed, 19 Nov 2008 18:23:09 -0800 (PST) Received: by 10.214.81.9 with SMTP id e9mr1942824qab.46.1227147789119; Wed, 19 Nov 2008 18:23:09 -0800 (PST) Received: from ?192.168.1.119? ([216.17.77.254]) by mx.google.com with ESMTPS id 6sm481596ywc.9.2008.11.19.18.23.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 19 Nov 2008 18:23:08 -0800 (PST) Message-ID: <4924CA09.7080607@polytechnique.edu> Date: Wed, 19 Nov 2008 20:23:05 -0600 From: Ulrich Herberg Organization: Ecole Polytechnique User-Agent: Thunderbird 2.0.0.17 (X11/20080922) MIME-Version: 1.0 To: Teco Boot References: <200811191440.mAJEeRPu017560@cichlid.raleigh.ibm.com> <492442C9.60404@sun.com> <200811191700.mAJH0WeD000999@cichlid.raleigh.ibm.com> <4924A6BB.4070601@sun.com> <004d01c94aac$57b1a4e0$0714eea0$@nl> In-Reply-To: <004d01c94aac$57b1a4e0$0714eea0$@nl> X-Enigmail-Version: 0.95.7 Cc: autoconf@ietf.org Subject: Re: [Autoconf] link definitions 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Teco Boot wrote: >> It is useful for manet, as well as 6lowpan, to have a prefix (which I >> think of a subnet prefix) span more than one link, because it allows >> nodes to move around inside the subnet without having to change their >> IP >> address and the whole think can be aggregated into a single route that >> is announced externally to the manet. >> > > I am not sure if we need this "wide prefix subnet". For the MANET Routers, > we would use host prefixes (/128) on loopback interfaces, or maybe on the > MANET interface itself if someone thinks this is a better approach. > Configuring a /128 prefix on an interface would make the interface look like > stub (not sure on this completely). > Agreed on the aggregation prefix for the MANET. With multi-homing, we could > have multiple aggregation prefixes. > As I am rather new to this working group, please forgive me (and correct me) if I do not know the whole history of the WG or do misunderstand something. In my opinion, it is wrong to have a MANET-wide subnet. As said by Thomas, having a subnet for the whole MANET -- considering we understand where the boundaries of "a" MANET are -- would mean that every router can reach each other without decrementing TTL. As far as I understood MANETs, this is not the case. Being on the same subnet means IMHO that you can assume to reach every other node without decrementing TTL, which is only the case for the router itself or subordinate hosts attached to it. However, this does not avoid aggregating prefixes -- you can still aggregate using shorter prefixes than the defined subnets. I do have a hard time understanding the history of the autoconf WG. I understand that it was asked by some people in the WG to define a link type for better understanding of the assumptions in a MANET. However, in the mailing list and during the meeting I rather had the impression that there is not much interest in the document, or at least that there is no consensus that this draft goes into the right direction. Even though I personally rather agree with Thomas' document, there might be a reason that it is wrong. However, for having a fruitful discussion, it would help a lot to have competing drafts from other WG members that disagree with the draft. It would be a lot easier for myself understanding the different possible views of "a link" and "a MANET", if there were different drafts that detail certain assumptions. Often the devil's in the details, so for me to understand the whole issue, it could help a lot not just talking about the definition of a link, but to write something down. I really would hope that those who have strong counter-arguments against the presented draft could write an ID, so that WG members could have an impression about different architectural views until IETF'74. Best regards, Ulrich _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 19:00:17 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29B623A66B4; Wed, 19 Nov 2008 19:00:17 -0800 (PST) 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 953153A66B4 for ; Wed, 19 Nov 2008 19:00:16 -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 t0XyH6ZJtIk1 for ; Wed, 19 Nov 2008 19:00:15 -0800 (PST) Received: from maili.marvell.com (host2.marvell.com [65.219.4.2]) by core3.amsl.com (Postfix) with ESMTP id ECDC53A6405 for ; Wed, 19 Nov 2008 19:00:15 -0800 (PST) Received: from MSI-MTA.marvell.com (msi-mta.marvell.com [10.68.76.91]) by maili.marvell.com (Postfix) with ESMTP id 2BD195EFE5; Wed, 19 Nov 2008 19:00:15 -0800 (PST) Received: from sc-owa01.marvell.com ([10.93.76.21]) by MSI-MTA.marvell.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Nov 2008 19:00:15 -0800 Received: from SC-EXCH1.marvell.com ([10.93.76.25]) by sc-owa01.marvell.com ([10.93.76.21]) with mapi; Wed, 19 Nov 2008 19:00:14 -0800 From: Paul Lambert To: Ulrich Herberg , Teco Boot Date: Wed, 19 Nov 2008 19:00:12 -0800 Thread-Topic: [Autoconf] link definitions Thread-Index: AclKt0t74D2ZkAaER2GFDWY18Dv7AgABCuwA Message-ID: <5A22FB9EDAA74547916480634CCC743817AD0BBC99@SC-EXCH1.marvell.com> References: <200811191440.mAJEeRPu017560@cichlid.raleigh.ibm.com> <492442C9.60404@sun.com> <200811191700.mAJH0WeD000999@cichlid.raleigh.ibm.com> <4924A6BB.4070601@sun.com> <004d01c94aac$57b1a4e0$0714eea0$@nl> <4924CA09.7080607@polytechnique.edu> In-Reply-To: <4924CA09.7080607@polytechnique.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 20 Nov 2008 03:00:15.0127 (UTC) FILETIME=[1C9F2A70:01C94ABC] Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] link definitions 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > Behalf Of Ulrich Herberg .... > > As I am rather new to this working group, please forgive me (and correct > me) if I do not know the whole history of the WG or do misunderstand > something. > In my opinion, it is wrong to have a MANET-wide subnet. As said by > Thomas, having a subnet for the whole MANET -- considering we understand > where the boundaries of "a" MANET are -- would mean that every router > can reach each other without decrementing TTL. As far as I understood > MANETs, this is not the case. I am new too .. but also confused on these definitions ... On the reachability, it is possible for the network layer to view the peer MANET devices as reachable without TTL decrementing if the link layer is bridging or is configured as a link layer mesh. The definitions (IMHO) are flawed in that they do not match well existing definitions of links and link layer service architectures (at least for 802 link layers). Paul _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 20:21:27 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7333D3A6877; Wed, 19 Nov 2008 20:21:27 -0800 (PST) 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 9F4483A686B for ; Wed, 19 Nov 2008 20:21:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojt+f6JfxEaN for ; Wed, 19 Nov 2008 20:21:24 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 71BC53A681C for ; Wed, 19 Nov 2008 20:21:23 -0800 (PST) Received: (qmail 30604 invoked from network); 20 Nov 2008 05:21:20 +0100 Received: from unknown (HELO M90Teco) (12.104.246.2) by server9.hosting2go.nl with SMTP; 20 Nov 2008 05:21:20 +0100 From: "Teco Boot" To: "'Erik Nordmark'" References: <200811191440.mAJEeRPu017560@cichlid.raleigh.ibm.com> <492442C9.60404@sun.com> <200811191700.mAJH0WeD000999@cichlid.raleigh.ibm.com> <4924A6BB.4070601@sun.com> <004d01c94aac$57b1a4e0$0714eea0$@nl> <4924C9A2.7080207@sun.com> In-Reply-To: <4924C9A2.7080207@sun.com> Date: Thu, 20 Nov 2008 05:21:15 +0100 Message-ID: <005201c94ac7$6eee0610$4cca1230$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclKtrgaKzYoRPnQS9uwFtkQ8QC2NAAEAvJQ Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] link definitions 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > >> It is useful for manet, as well as 6lowpan, to have a prefix (which > I > >> think of a subnet prefix) span more than one link, because it allows > >> nodes to move around inside the subnet without having to change > their > >> IP > >> address and the whole think can be aggregated into a single route > that > >> is announced externally to the manet. > > > > I am not sure if we need this "wide prefix subnet". For the MANET > Routers, > > we would use host prefixes (/128) on loopback interfaces, or maybe on > the > > MANET interface itself if someone thinks this is a better approach. > > Which prefix are you going to allocate addresses from? > > That is the prefix I'm talking about. OK, maybe I was confused by wording. c/subnet/summary/ and I am fine. But the host prefix does not span more than one link. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 21:00:00 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82B0E3A6877; Wed, 19 Nov 2008 21:00:00 -0800 (PST) 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 D5E763A6877 for ; Wed, 19 Nov 2008 20:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dihYIn0ukbFk for ; Wed, 19 Nov 2008 20:59:59 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id A34EE3A6358 for ; Wed, 19 Nov 2008 20:59:58 -0800 (PST) Received: (qmail 8180 invoked from network); 20 Nov 2008 05:59:49 +0100 Received: from unknown (HELO M90Teco) (12.104.246.2) by server9.hosting2go.nl with SMTP; 20 Nov 2008 05:59:49 +0100 From: "Teco Boot" To: "'Erik Nordmark'" References: <4924C9AD.9030904@sun.com> In-Reply-To: <4924C9AD.9030904@sun.com> Date: Thu, 20 Nov 2008 05:59:42 +0100 Message-ID: <005301c94acc$cf862a70$6e927f50$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclKtrsVHWvqIVUyQCSRgaRVf922XwAERgHg Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] Why the link definition? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > > As far as I'm concerned, I had no problem working on a MANET > > autoconfiguration design while considering a radio range (say, > > something like a 3D sphere for an omni radio like 802.11) as the > > replacement of a link. Only that, this new "link" had quite a few > > non-traditional characteristics such as, (1) the fact I can reach > node > > B (therefore consider node B is on the link I'm on) doesn't mean I am > > on the link he's on, or some would describe as link asymmetry, and > (2) > > the membership of other nodes on the link I'm on can change > frequently > > and drastically. ND works when the network condition allows two nodes > > to actually share a view (or they can reach each other) and fails > > otherwise, which is completely fine because "neighbors" can be > > considered as two nodes that can reach each other at a point in time. > > When you say "ND" what exactly do you mean? Two nodes using NS/NA > exchanges to discover the L2 addresses to use for direct communication? > > The reason I'm asking for clarification is that I don't think that > makes > much sense when the link is defined as "within radio range", since that > changes very frequently. > > That is why link-local addresses, as well as NS/NA as used on Ethernet, > is of very limited use on such networks. > > But defining the link as a "within radio range" is AFAIK very useful > for > the routing protocols since they can use link-local communication > (link-local addresses, and/or ttl=1) to find their neighbors. Just asking: what is the problem with using NS/NA exchanges to discover the L2 addresses with the link defined as a "within radio range"? Another question: do we need an "IPv6 Packets over WiFi" RFC? There are expired I-Ds. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 21:06:59 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5F5E3A681C; Wed, 19 Nov 2008 21:06:59 -0800 (PST) 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 2A71F3A681C for ; Wed, 19 Nov 2008 21:06:59 -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 NLiBRFaCX15T for ; Wed, 19 Nov 2008 21:06:58 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 321F93A6358 for ; Wed, 19 Nov 2008 21:06:58 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so305082wfd.31 for ; Wed, 19 Nov 2008 21:06:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=6utSCtsQ//vPHL4ZNOJKCzOeDLL9yvIYmOv/VKukqbE=; b=qUaxFS9ZvRvLKd7zzNaEBvvsJtHI4G8Kdc1BAlRex40fVg5JUgpMfVf8IHmf4zI1pq M7rGEBHsU5Qaa8h7rm8uf1K55KKURKWpLVDr/FpIeadI8wYegoiRq9cPHJ/tnm+0FiYa 9iYwlFt4BEkfA0bJz75bgwV2peAbqqNklZCps= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=KIoN0srYYcvd62cvtjvMWhsIJ8zyOdUY84LzSlcSploD347Gckm5quJheYgx5B+UUY bYSvXPM02AtQ9Wm+pOoaCfBTPcrWhnTIektg9hpjfJ5M307Ir+gncdOxJfeMgt6F8f71 fGZG2u11eS0HCCvQalR882Iq8Gd6gLofOyABs= Received: by 10.142.223.20 with SMTP id v20mr946880wfg.7.1227157616750; Wed, 19 Nov 2008 21:06:56 -0800 (PST) Received: by 10.143.91.1 with HTTP; Wed, 19 Nov 2008 21:06:56 -0800 (PST) Message-ID: Date: Wed, 19 Nov 2008 21:06:56 -0800 From: "Seung Yi" To: "Charles E. Perkins" In-Reply-To: <4924C84D.5050502@earthlink.net> MIME-Version: 1.0 Content-Disposition: inline References: <4924C84D.5050502@earthlink.net> Cc: autoconf@ietf.org Subject: Re: [Autoconf] Subnet definition X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: scicarus@iname.com List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org On Wed, Nov 19, 2008 at 6:15 PM, Charles E. Perkins wrote: > > Hello folks, > > I'd like to propose the following two definitions. > > A "subnet" is a contiguous range of IP addresses that > admits a routing prefix. > > A "subnet router" is a router that provides access to > any node that uses one of the contiguous IP addresses > belonging to the range of the subnet. > > ================================== > /snip/ Somewhat related to Charlie's posting, there is one thing I've been curious about for a while but couldn't find a definite answer to: "Why was the concept of the "subnet" introduced in the first place?" I think the story might be something like this. First, there was an Ethernet segment (or something similar), which is an L2 concept. One of the characteristics of an Ethernet segment is, when one node on the segment sends something, every other nodes on the segment can hear/receive that. To abstract that concept (that I can reach everyone by simply relying on L2 facility) in L3, one introduces the concept of the "subnet". By carefully assigning IP addresses from a subnet range to all nodes on a single Ethernet segment, one can enable L3 communication between them without having to run a routing protocol. So, the concept of the "subnet" seems nothing but an artificial construct one uses in L3 to abstract underlying L2 connectivity. Moving back to MANET, - If a MANET is running some sort of L2 routing protocol and presents an Ethernet-like view of L2 to L3, it is fine to assign IP addresses from a subnet range. Everything should work as in an Ethernet segment. (To my understanding, this is how some of military IP radios work). - If there is no such L2 routing available and all L2 can do is something like 802.11 ad-hoc mode, you can still assign IP addresses from a subnet range to MANET routers if you want. However, you will get a multi-link subnet as the result. ND will find all other nodes in range but not all other nodes in the subnet. Link-local multicast will reach only the nodes in range, but not all the nodes in the subnet. If you have a way to handle multi-link subnet, that this is fine. - Finally, you can assign IP addresses to each MANET router so that every node belongs to its own singleton subnet. ND and link-local multicast will work correctly. Only they cannot be used as MANET-wide communication primitives. If my original guess about the concept of the "subnet" is correct, any of these three options seems like an acceptable choice for the IP address assignment scheme. Still, lot of people on the list seems to be arguing for one or the other. Are there really a good reason to discount any of these choices? Thanks, - Seung _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 21:18:57 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E05843A67E7; Wed, 19 Nov 2008 21:18:57 -0800 (PST) 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 5ECAF3A67E7 for ; Wed, 19 Nov 2008 21:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57fjysFR-b7D for ; Wed, 19 Nov 2008 21:18:56 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 41D583A6358 for ; Wed, 19 Nov 2008 21:18:56 -0800 (PST) Received: (qmail 16679 invoked from network); 20 Nov 2008 06:18:47 +0100 Received: from unknown (HELO M90Teco) (12.104.246.2) by server9.hosting2go.nl with SMTP; 20 Nov 2008 06:18:47 +0100 From: "Teco Boot" To: "'Charles E. Perkins'" References: <4924C84D.5050502@earthlink.net> In-Reply-To: <4924C84D.5050502@earthlink.net> Date: Thu, 20 Nov 2008 06:18:43 +0100 Message-ID: <005401c94acf$75e49490$61adbdb0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclKte6jHxlRIwwaSBauzxa0gV3qggAFxJ9g Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] Subnet definition 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > A "subnet" is a contiguous range of IP addresses that > admits a routing prefix. Why not using the term routing prefix for a routing prefix? > A "subnet router" is a router that provides access to > any node that uses one of the contiguous IP addresses > belonging to the range of the subnet. If we stick on MANET, we discuss only router related topics, agreed? And routers do provide routes to destinations, OK? > ================================== > > However, there may be "routers" that do not > make any such claim about routing to a subnet. > > In general, routers may forward packets to > nodes that are on link but not part of any > subnet for which the router provides access. > This model of routing allows for a router to > forward a packet to a node that is NOT on > a subnet. > > It is my belief that these "non-subnet" routers > are a crucial component of MANET routing, > and that the attempt to fit them into any > reasonable model of "subnet router" is > doomed to frustration and failure. I have to think more about this, but for now I can't see a problem. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 21:32:17 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF4E53A67AC; Wed, 19 Nov 2008 21:32:17 -0800 (PST) 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 36A943A67AC for ; Wed, 19 Nov 2008 21:32:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgQuL5B5opvt for ; Wed, 19 Nov 2008 21:32:15 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 166F43A657C for ; Wed, 19 Nov 2008 21:32:14 -0800 (PST) Received: (qmail 21908 invoked from network); 20 Nov 2008 06:32:06 +0100 Received: from unknown (HELO M90Teco) (12.104.246.2) by server9.hosting2go.nl with SMTP; 20 Nov 2008 06:32:06 +0100 From: "Teco Boot" To: "'Ulrich Herberg'" References: <200811191440.mAJEeRPu017560@cichlid.raleigh.ibm.com> <492442C9.60404@sun.com> <200811191700.mAJH0WeD000999@cichlid.raleigh.ibm.com> <4924A6BB.4070601@sun.com> <004d01c94aac$57b1a4e0$0714eea0$@nl> <4924CA09.7080607@polytechnique.edu> In-Reply-To: <4924CA09.7080607@polytechnique.edu> Date: Thu, 20 Nov 2008 06:31:59 +0100 Message-ID: <005501c94ad1$51ab7060$f5025120$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclKtu+I6pVyb/QQTW+BYcm0KyiCtQAGPwng Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] link definitions 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > In my opinion, it is wrong to have a MANET-wide subnet. As said by > Thomas, having a subnet for the whole MANET -- considering we > understand > where the boundaries of "a" MANET are -- would mean that every router > can reach each other without decrementing TTL. As far as I understood > MANETs, this is not the case. Being on the same subnet means IMHO that > you can assume to reach every other node without decrementing TTL, > which > is only the case for the router itself or subordinate hosts attached to > it. However, this does not avoid aggregating prefixes -- you can still > aggregate using shorter prefixes than the defined subnets. We are on the same page. But be careful with the term subnet. I prefer using routing prefix if we discuss routing. > I do have a hard time understanding the history of the autoconf WG. I > understand that it was asked by some people in the WG to define a link > type for better understanding of the assumptions in a MANET. However, > in > the mailing list and during the meeting I rather had the impression > that > there is not much interest in the document, or at least that there is > no > consensus that this draft goes into the right direction. Even though I > personally rather agree with Thomas' document, there might be a reason > that it is wrong. However, for having a fruitful discussion, it would > help a lot to have competing drafts from other WG members that disagree > with the draft. It would be a lot easier for myself understanding the > different possible views of "a link" and "a MANET", if there were > different drafts that detail certain assumptions. Often the devil's in > the details, so for me to understand the whole issue, it could help a > lot not just talking about the definition of a link, but to write > something down. I really would hope that those who have strong > counter-arguments against the presented draft could write an ID, so > that > WG members could have an impression about different architectural views > until IETF'74. I had the feeling that there was some misunderstanding on "link" terminology. I think it makes sense to converge to some unambiguous definitions. And I think we are not far from that. Then we can continue our work on problem statement and follow-up. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 21:45:44 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB11F3A6955; Wed, 19 Nov 2008 21:45:44 -0800 (PST) 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 EB1483A6955 for ; Wed, 19 Nov 2008 21:45:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhoWCajUEk4m for ; Wed, 19 Nov 2008 21:45:43 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id C12CD3A694D for ; Wed, 19 Nov 2008 21:45:42 -0800 (PST) Received: (qmail 27818 invoked from network); 20 Nov 2008 06:45:33 +0100 Received: from unknown (HELO M90Teco) (12.104.246.2) by server9.hosting2go.nl with SMTP; 20 Nov 2008 06:45:33 +0100 From: "Teco Boot" To: References: <4924C84D.5050502@earthlink.net> In-Reply-To: Date: Thu, 20 Nov 2008 06:45:28 +0100 Message-ID: <005601c94ad3$32cfbdc0$986f3940$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclKzdR1sII4zhjkQz+qBltK15UQrAAA+Rhg Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] Subnet definition 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > - If a MANET is running some sort of L2 routing protocol and > presents an Ethernet-like view of L2 to L3, it is fine to assign IP > addresses from a subnet range. Everything should work as in an > Ethernet segment. (To my understanding, this is how some of military > IP radios work). We should not make too many assumptions. For example, even the 802.11 standard specifies you cannot assume all STAs are connected. You are right, some of the military provide something similar to an Ethernet segment. Others don't. > - If there is no such L2 routing available and all L2 can do is > something like 802.11 ad-hoc mode, you can still assign IP addresses > from a subnet range to MANET routers if you want. However, you will > get a multi-link subnet as the result. ND will find all other nodes in > range but not all other nodes in the subnet. Link-local multicast will > reach only the nodes in range, but not all the nodes in the subnet. If > you have a way to handle multi-link subnet, that this is fine. Why should we assign IP addresses from a subnet to MANET interfaces? Routing works well without, using link local addresses. Routers usually support a loopback interface. Just configure a host prefix on the loopback and we are done. > - Finally, you can assign IP addresses to each MANET router so that > every node belongs to its own singleton subnet. ND and link-local > multicast will work correctly. Only they cannot be used as MANET-wide > communication primitives. Why can't these addresses be used? Routers provide reachability for prefixes, or am I missing something? Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Nov 19 22:43:58 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23EAE3A6849; Wed, 19 Nov 2008 22:43:58 -0800 (PST) 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 2A2E33A6849 for ; Wed, 19 Nov 2008 22:43:57 -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 6UC-YmeBcJ3g for ; Wed, 19 Nov 2008 22:43:56 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 5C2863A680D for ; Wed, 19 Nov 2008 22:43:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=RmiolKwPGIzkrOoWZf4hNzRufnXO3+Iaima5pqv6YQRbg+vWrdwZz7sq/6FpDirH; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [130.129.78.128] by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L33Gc-0001F3-DJ; Thu, 20 Nov 2008 01:43:54 -0500 Message-ID: <49250727.6040308@earthlink.net> Date: Wed, 19 Nov 2008 22:43:51 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Teco Boot References: <4924C84D.5050502@earthlink.net> <005401c94acf$75e49490$61adbdb0$@nl> In-Reply-To: <005401c94acf$75e49490$61adbdb0$@nl> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f527478f09ef3779c830241d5f2c346e368350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.78.128 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Subnet definition 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello Teco, Teco Boot wrote: >> A "subnet" is a contiguous range of IP addresses that >> admits a routing prefix. >> > > Why not using the term routing prefix for a routing prefix? > There are two important answers to this question. 1. A subnet is something that needs definition so that we can avoid confusion. No one has been getting confused about what a routing prefix is supposed to mean. 2. A subnet is a collection of network nodes, and a routing prefix is a number and a length. But you correctly point out that the definition should probably be improved. Perhaps the following definition is better: A "subnet" is a collection of network nodes whose addresses are all within a contiguous range of IP addresses that admits a routing prefix. Anyway, even if the elements of two sets have a natural one-to-one correspondence, we can still usefully consider and understand their differences. > > >> A "subnet router" is a router that provides access to >> any node that uses one of the contiguous IP addresses >> belonging to the range of the subnet. >> > > If we stick on MANET, we discuss only router related topics, agreed? > > And routers do provide routes to destinations, OK? > It seems to me that there has been a lot of confusion about routers and subnets, and I think we could go forward faster if we could manage to resolve that confusion. Sometimes you have to enlarge the field of view in order to see the elephant in the room (to mix metaphors :-) Regards, Charlie P. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 20 04:37:37 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 608403A688A; Thu, 20 Nov 2008 04:37:37 -0800 (PST) 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 39BD63A6768 for ; Thu, 20 Nov 2008 04:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBHtZHUQ5+SZ for ; Thu, 20 Nov 2008 04:37:35 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 100AC3A688A for ; Thu, 20 Nov 2008 04:37:34 -0800 (PST) Received: (qmail 18160 invoked from network); 20 Nov 2008 13:37:30 +0100 Received: from unknown (HELO M90Teco) (12.104.246.2) by server9.hosting2go.nl with SMTP; 20 Nov 2008 13:37:30 +0100 From: "Teco Boot" To: "'Charles E. Perkins'" References: <4924C84D.5050502@earthlink.net> <005401c94acf$75e49490$61adbdb0$@nl> <49250727.6040308@earthlink.net> In-Reply-To: <49250727.6040308@earthlink.net> Date: Thu, 20 Nov 2008 13:37:25 +0100 Message-ID: <006301c94b0c$bfa5ba90$3ef12fb0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclK21yu2yJxTBX8SNe6kQBlbOVjOgALXCeg Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] Subnet definition 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Charlie, > 1. A subnet is something that needs definition so that we > can avoid confusion. No one has been getting confused > about what a routing prefix is supposed to mean. > 2. A subnet is a collection of network nodes, and a routing > prefix is a number and a length. But you correctly point > out that the definition should probably be improved. > > Perhaps the following definition is better: > A "subnet" is a collection of network nodes whose addresses are > all within a contiguous range of IP addresses that admits a routing > prefix. I am not sure on this definition. Assume a site with a /48 prefix length, and many Ethernet segments connected with routers, would you say that the site is a /48 subnet? Or a bundle of /64 subnets, with a subnet on each Ethernet segment? Both? Correct me if I am wrong, but I think it is a bundle of subnets (RFC940 / RFC4291 / I-D.6man-ipv6-subnet-model). With mobility in mind, I think we are working with a model that each object_moving_as_a_whole may have a set of subnets. This would make sure subnets don't break. Of course subnets are not assigned to multiple of those objects, but this is BCP. I kept anycast out-of-scope. > >> A "subnet router" is a router that provides access to > >> any node that uses one of the contiguous IP addresses > >> belonging to the range of the subnet. Keeping prefix assignment is mind, do you mean that a subnet_router is a router assigned and configured a subnet prefix to one of its interfaces? I can agree on this definition. Within the scope of MANETs, we should define that subnet prefixes are not assigned to multiple routers, that are not part of the same object_moving_as_a_whole. Agreed on that? Regards, Teco _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 20 06:39:55 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A681E3A698C; Thu, 20 Nov 2008 06:39:55 -0800 (PST) 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 E52E83A698C for ; Thu, 20 Nov 2008 06:39:54 -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, 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 c3VTrdzhaY3e for ; Thu, 20 Nov 2008 06:39:54 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by core3.amsl.com (Postfix) with ESMTP id 168BA3A68A7 for ; Thu, 20 Nov 2008 06:39:54 -0800 (PST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id mAKEccuF025162 for ; Thu, 20 Nov 2008 07:38:38 -0700 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mAKEdf36125202 for ; Thu, 20 Nov 2008 07:39:44 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mAKEdfTR020944 for ; Thu, 20 Nov 2008 07:39:41 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-65-201-183.mts.ibm.com [9.65.201.183]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mAKEddMK020861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2008 07:39:40 -0700 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id mAKEdcHG003838; Thu, 20 Nov 2008 09:39:38 -0500 Message-Id: <200811201439.mAKEdcHG003838@cichlid.raleigh.ibm.com> To: "Charles E. Perkins" In-reply-to: <4924C84D.5050502@earthlink.net> References: <4924C84D.5050502@earthlink.net> Comments: In-reply-to "Charles E. Perkins" message dated "Wed, 19 Nov 2008 18:15:41 -0800." Date: Thu, 20 Nov 2008 09:39:38 -0500 From: Thomas Narten Cc: autoconf@ietf.org Subject: Re: [Autoconf] Subnet definition 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org I agree that we need a clean definition of subnet. The term is overloaded and different people have different meanings associated with it. That has contributed to confusion in the discussions... Note also that I think Erik's observation about "on-link" being a key issue to also be clear about is correct. "Charles E. Perkins" writes: > A "subnet" is a contiguous range of IP addresses that > admits a routing prefix. I'd change that as follows (to highlight the properties that are important to us): A "subnet" is the range of IP addresses that are covered by a prefix. All that a subnet defines is which addresses are considered to be on the subnet and which are not. In many cases (in IPv4) there is a one-to-one mapping between a subnet and a link. I.e., on an Ethernet, you assign a subnet to the ethernet link. All the addresses covered by the prefix are assumed to reside on that Ethernet, and are neighbors of each other. Using IPv6 terminology, we would say "link" rather than subnet and we would say all the addresses covered by the subnet are "on link". (But note that in IPv6, you can have links with addresses assigned to it, but for which there is no prefix that is considered "on link".) But if one talks to routing folk, a subnet is an abstraction that is not tied to a physical link. For example, IBM has been assigned net 9.0.0.0. So, to BGP, 9.0.0.0/8 is a "subnet", even though the actual network is a huge cloud of thousands of individual networks. And, within IBM, talking about 9.0.0.0/8 as a "subnet" makes little sense, because we see the individual links that have been subnetted and given individual subnet numbers. We talk about 9.2.27.0/24 and the like. Thus, when talking about a subnet, we also have to consider the on-link properties (if any), as differing assumptions on that point can lead to very different ideas about how things do (or don't) work. Back to the simple Ethernet, all the addresses covered by the prefix are typically considered on-link. When talking about MANETs, and talking about subnets (or prefixes) we also have to talk about the on-link properties (or lack thereof). For example, going back to chart 37 of ThomasC's presentation, it may well make sense to consider the entire cloud of routers to be part of one subnet, but it does not make sense (I assume) to consider that same subnet to be "on-link" anywhere within that cloud. Within the cloud, the subnet is further subdivided into smaller subnets. Each of those individual (smaller) subnets may well have on-link properties for small portions of the overall cloud. Thomas _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 20 07:40:59 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9344028C111; Thu, 20 Nov 2008 07:40:59 -0800 (PST) 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 9A31E3A67DB for ; Thu, 20 Nov 2008 07:40:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sR70+UoYXWc for ; Thu, 20 Nov 2008 07:40:57 -0800 (PST) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.191]) by core3.amsl.com (Postfix) with ESMTP id 45FE128C11D for ; Thu, 20 Nov 2008 07:40:41 -0800 (PST) Received: by rn-out-0910.google.com with SMTP id j77so444013rne.18 for ; Thu, 20 Nov 2008 07:40:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=rpZaTySh0S6iGjnF7s6e08/0aTIt0c13p4vYu9TjJ9k=; b=VFYqlNPTgDsurdTYT9qVSvFSOyVZvePuBdiM0GKCM+yOSVH4NjfvhHQIfnPv9NY04g qqU+nDb4IffeSK7+6ieOYZdv8tR+k1ZNqvE57dICmoZkcMdhvwWSMsYYcNO4tHNTq2yV 62YouPy6Tqc2xbpKlP+rw0/7yODyQ1gucS+eQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=SvueFK5R32gT4KatAhJTMrex1y878vtyoOUrksLRkPEog9kw8Kh68xnFQK7Sf9aXMv h4R/JwuE42nFYl1hNix5LEThz4W7ZQ7/OJaHddl+xr27U1+6EADxno4fqCGyQI3i7S6Z OET3ruSZHGZa/ph/C5xP71uqr6RKtILWlTCas= Received: by 10.142.50.5 with SMTP id x5mr1184454wfx.230.1227195639017; Thu, 20 Nov 2008 07:40:39 -0800 (PST) Received: by 10.143.91.1 with HTTP; Thu, 20 Nov 2008 07:40:38 -0800 (PST) Message-ID: Date: Thu, 20 Nov 2008 07:40:38 -0800 From: "Seung Yi" To: "Teco Boot" In-Reply-To: <005601c94ad3$32cfbdc0$986f3940$@nl> MIME-Version: 1.0 Content-Disposition: inline References: <4924C84D.5050502@earthlink.net> <005601c94ad3$32cfbdc0$986f3940$@nl> X-Google-Sender-Auth: 01558986d914ba2c Cc: autoconf@ietf.org Subject: Re: [Autoconf] Subnet definition 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Teco, On Wed, Nov 19, 2008 at 9:45 PM, Teco Boot wrote: >> - If there is no such L2 routing available and all L2 can do is >> something like 802.11 ad-hoc mode, you can still assign IP addresses >> from a subnet range to MANET routers if you want. However, you will >> get a multi-link subnet as the result. ND will find all other nodes in >> range but not all other nodes in the subnet. Link-local multicast will >> reach only the nodes in range, but not all the nodes in the subnet. If >> you have a way to handle multi-link subnet, that this is fine. > > Why should we assign IP addresses from a subnet to MANET interfaces? Routing > works well without, using link local addresses. Routers usually support a > loopback interface. Just configure a host prefix on the loopback and we are > done. > > I actually tried using the loopback interface. It's not as straightforward as it seems. For example, binding an application to use the address on the loopback is not very simple without modifying the app. The point I tried to make here was that I don't see any reason to prohibit assigning IP addresses from a subnet range to MANET interfaces. >> - Finally, you can assign IP addresses to each MANET router so that >> every node belongs to its own singleton subnet. ND and link-local >> multicast will work correctly. Only they cannot be used as MANET-wide >> communication primitives. > > Why can't these addresses be used? Routers provide reachability for > prefixes, or am I missing something? > > By "they", I meant "ND and link-local multicast". I tried to say "ND and link-local multicast" cannot be used as MANET-wide communication primitives. There is no problem with address assignments. A more general point, I think, was I don't see anything wrong with any of these three address assignment schemes. They can all be made to work with other supporting mechanisms. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 20 07:46:10 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E67F93A683B; Thu, 20 Nov 2008 07:46:10 -0800 (PST) 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 417093A67B5 for ; Thu, 20 Nov 2008 07:46:10 -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 ZgQzdx80zMlN for ; Thu, 20 Nov 2008 07:46:09 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by core3.amsl.com (Postfix) with ESMTP id 355B83A6800 for ; Thu, 20 Nov 2008 07:46:08 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b6so235087ana.4 for ; Thu, 20 Nov 2008 07:46:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=4LAPzNjtsXdjBgEI2Nq8jEkcsDJRjkJgxMQEGUOBlTI=; b=xIa59ILgL81VLB+cBW8HKb4EROlzYhCDF09nQfxWRglWGZGD2faD79NbC6qjTcwPU9 SNmrNXmon2+9QwL9aXStxtZe/0TPM1w7A8xP5DbBUDh+LGvhy2IhMU56naX0RjvA/+7t a2dA9KIw+DlyyN4m/92y20AsAhVlnhHLu9vAw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=i9Lcy2z8bJhX/y04naViKYfdEPyxx6T23yZ2+Acko5TxOW+N/CvnscewvO6Rd5kU0o qNgpGhNiKib7t9misr8QGX+spGjZ26BnLWjObpano2nf0G0rfNNmfkxvSCAiOn8+HTp0 nSMdf7dB+Rgb8jQ+3CpTgTia99jo8DyvCGMqk= Received: by 10.142.185.21 with SMTP id i21mr1188027wff.220.1227195966661; Thu, 20 Nov 2008 07:46:06 -0800 (PST) Received: by 10.143.91.1 with HTTP; Thu, 20 Nov 2008 07:46:06 -0800 (PST) Message-ID: Date: Thu, 20 Nov 2008 07:46:06 -0800 From: "Seung Yi" To: "Thomas Narten" In-Reply-To: <200811201439.mAKEdcHG003838@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Disposition: inline References: <4924C84D.5050502@earthlink.net> <200811201439.mAKEdcHG003838@cichlid.raleigh.ibm.com> Cc: autoconf@ietf.org Subject: Re: [Autoconf] Subnet definition X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: scicarus@iname.com List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org On Thu, Nov 20, 2008 at 6:39 AM, Thomas Narten wrote: > I agree that we need a clean definition of subnet. The term is > overloaded and different people have different meanings associated > with it. That has contributed to confusion in the discussions... > > Note also that I think Erik's observation about "on-link" being a key > issue to also be clear about is correct. > >>>>>> snip <<<<<<<<<< > For example, going back to chart 37 of ThomasC's presentation, it may > well make sense to consider the entire cloud of routers to be part of > one subnet, but it does not make sense (I assume) to consider that > same subnet to be "on-link" anywhere within that cloud. Within the > cloud, the subnet is further subdivided into smaller subnets. Each of > those individual (smaller) subnets may well have on-link properties > for small portions of the overall cloud. > > Thomas That is exactly what I tried to convey. It may be just a happy coincidence that there is one-to-one mapping between a subnet and an Ethernet link. As long as we do not assume such mapping should always exist and treat a subnet as just a contiguous range of IP addresses (therefore an abstract concept rather than being tied to any L2 facility), everything looks straightforward to me. - Seung _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 20 07:46:24 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21A5E28C111; Thu, 20 Nov 2008 07:46:24 -0800 (PST) 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 B0AE228C111 for ; Thu, 20 Nov 2008 07:46: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 LQNbxSf9QImp for ; Thu, 20 Nov 2008 07:46:21 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id B434C3A67B5 for ; Thu, 20 Nov 2008 07:46:21 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id mAKFk1cs021344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Nov 2008 09:46:11 -0600 (CST) 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 mAKFk1rj009517; Thu, 20 Nov 2008 09:46:01 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id mAKFjwCV009430; Thu, 20 Nov 2008 09:46:00 -0600 (CST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Nov 2008 07:45:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 07:45:53 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1053EEE6F@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Subnet definition Thread-Index: AclLJmd0ql9BqKlsTm66wQUOQluiHgAAE3Lw References: <4924C84D.5050502@earthlink.net><005601c94ad3$32cfbdc0$986f3940$@nl> From: "Templin, Fred L" To: "Seung Yi" , "Teco Boot" X-OriginalArrivalTime: 20 Nov 2008 15:45:54.0745 (UTC) FILETIME=[12C49290:01C94B27] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-5.500.1027-16290.000 X-TM-AS-Result: No--22.752200-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: autoconf@ietf.org Subject: Re: [Autoconf] Subnet definition 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Seung, >-----Original Message----- >From: Seung Yi [mailto:scicarus@iname.com] >Sent: Thursday, November 20, 2008 7:41 AM >To: Teco Boot >Cc: autoconf@ietf.org >Subject: Re: [Autoconf] Subnet definition > >Teco, > >On Wed, Nov 19, 2008 at 9:45 PM, Teco Boot wrote: >>> - If there is no such L2 routing available and all L2 can do is >>> something like 802.11 ad-hoc mode, you can still assign IP addresses >>> from a subnet range to MANET routers if you want. However, you will >>> get a multi-link subnet as the result. ND will find all other nodes in >>> range but not all other nodes in the subnet. Link-local multicast will >>> reach only the nodes in range, but not all the nodes in the subnet. If >>> you have a way to handle multi-link subnet, that this is fine. >> >> Why should we assign IP addresses from a subnet to MANET interfaces? Routing >> works well without, using link local addresses. Routers usually support a >> loopback interface. Just configure a host prefix on the loopback and we are >> done. >> >> > >I actually tried using the loopback interface. It's not as >straightforward as it seems. For example, binding an application to >use the address on the loopback is not very simple without modifying >the app. First, you are talking about IPv4 here; not IPv6. Second, it doesn't have to be a loopback interface; it could be an Ethernet for example. Please see also Dave Thaler's discussion on strong vs weak end system model from the plenary. Fred fred.l.templin@boeing.com >The point I tried to make here was that I don't see any reason to >prohibit assigning IP addresses from a subnet range to MANET >interfaces. > >>> - Finally, you can assign IP addresses to each MANET router so that >>> every node belongs to its own singleton subnet. ND and link-local >>> multicast will work correctly. Only they cannot be used as MANET-wide >>> communication primitives. >> >> Why can't these addresses be used? Routers provide reachability for >> prefixes, or am I missing something? >> >> > >By "they", I meant "ND and link-local multicast". I tried to say "ND >and link-local multicast" cannot be used as MANET-wide communication >primitives. There is no problem with address assignments. > >A more general point, I think, was I don't see anything wrong with any >of these three address assignment schemes. They can all be made to >work with other supporting mechanisms. >_______________________________________________ >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 autoconf-bounces@ietf.org Thu Nov 20 08:17:38 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7C403A69AD; Thu, 20 Nov 2008 08:17:38 -0800 (PST) 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 BAC573A69AD for ; Thu, 20 Nov 2008 08:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FOyZBcYiLGs for ; Thu, 20 Nov 2008 08:17:37 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 9A48F3A6980 for ; Thu, 20 Nov 2008 08:17:36 -0800 (PST) Received: (qmail 7450 invoked from network); 20 Nov 2008 17:17:32 +0100 Received: from unknown (HELO M90Teco) (12.104.246.2) by server9.hosting2go.nl with SMTP; 20 Nov 2008 17:17:32 +0100 From: "Teco Boot" To: "'Seung Yi'" References: <4924C84D.5050502@earthlink.net> <005601c94ad3$32cfbdc0$986f3940$@nl> In-Reply-To: Date: Thu, 20 Nov 2008 17:17:27 +0100 Message-ID: <007301c94b2b$7bfa06b0$73ee1410$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclLJlhba/Lj2chRSdqWiEtw1SdByQABDZyw Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] Subnet definition 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > I actually tried using the loopback interface. It's not as > straightforward as it seems. For example, binding an application to > use the address on the loopback is not very simple without modifying > the app. Are we discussing a RFC3484 compliant router? > >> - Finally, you can assign IP addresses to each MANET router so > that > >> every node belongs to its own singleton subnet. ND and link-local > >> multicast will work correctly. Only they cannot be used as MANET- > wide > >> communication primitives. > > > > Why can't these addresses be used? Routers provide reachability for > > prefixes, or am I missing something? > > By "they", I meant "ND and link-local multicast". I tried to say "ND > and link-local multicast" cannot be used as MANET-wide communication > primitives. There is no problem with address assignments. You described a problem with MANET-wide communications and problems. Did you mean that with LL addresses you cannot reach the whole MANET / whole Internet? This is by definition. Or am I missing something? Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 20 08:30:21 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F8993A6806; Thu, 20 Nov 2008 08:30:21 -0800 (PST) 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 DDCD23A6806 for ; Thu, 20 Nov 2008 08:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXL3rKiutytk for ; Thu, 20 Nov 2008 08:30:20 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by core3.amsl.com (Postfix) with ESMTP id 98D353A67B5 for ; Thu, 20 Nov 2008 08:30:19 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,639,1220220000"; d="scan'208";a="17424561" Received: from unknown (HELO BoolfightMaN-Laptop.local) ([130.129.29.95]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Nov 2008 17:30:16 +0100 Message-ID: <49259096.7080709@inria.fr> Date: Thu, 20 Nov 2008 17:30:14 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: autoconf@ietf.org X-Enigmail-Version: 0.95.7 Subject: Re: [Autoconf] Subnet definition 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Maybe we are hitting the heart of the misunderstanding. I think we should indeed distinguish prefix and subnet terms, and stick to something like: - a prefix is a contiguous range of IP addresses. - a subnet is a set of IP addresses (that may or may not be a prefix) that are on the same link. All these addresses are then on-link with respect to this link. - a link is what L2 provides, which reaches everything within TTL 1 beyond a given interface. If we stick to these definitions, we will indeed save ourselves lots of trouble. Do you agree? Emmanuel On Thu, Nov 20, 2008 at 3:39 PM, Thomas Narten wrote: I agree that we need a clean definition of subnet. The term is overloaded and different people have different meanings associated with it. That has contributed to confusion in the discussions... Note also that I think Erik's observation about "on-link" being a key issue to also be clear about is correct. "Charles E. Perkins" writes: > A "subnet" is a contiguous range of IP addresses that > admits a routing prefix. I'd change that as follows (to highlight the properties that are important to us): A "subnet" is the range of IP addresses that are covered by a prefix. All that a subnet defines is which addresses are considered to be on the subnet and which are not. In many cases (in IPv4) there is a one-to-one mapping between a subnet and a link. I.e., on an Ethernet, you assign a subnet to the ethernet link. All the addresses covered by the prefix are assumed to reside on that Ethernet, and are neighbors of each other. Using IPv6 terminology, we would say "link" rather than subnet and we would say all the addresses covered by the subnet are "on link". (But note that in IPv6, you can have links with addresses assigned to it, but for which there is no prefix that is considered "on link".) But if one talks to routing folk, a subnet is an abstraction that is not tied to a physical link. For example, IBM has been assigned net 9.0.0.0. So, to BGP, 9.0.0.0/8 is a "subnet", even though the actual network is a huge cloud of thousands of individual networks. And, within IBM, talking about 9.0.0.0/8 as a "subnet" makes little sense, because we see the individual links that have been subnetted and given individual subnet numbers. We talk about 9.2.27.0/24 and the like. Thus, when talking about a subnet, we also have to consider the on-link properties (if any), as differing assumptions on that point can lead to very different ideas about how things do (or don't) work. Back to the simple Ethernet, all the addresses covered by the prefix are typically considered on-link. When talking about MANETs, and talking about subnets (or prefixes) we also have to talk about the on-link properties (or lack thereof). For example, going back to chart 37 of ThomasC's presentation, it may well make sense to consider the entire cloud of routers to be part of one subnet, but it does not make sense (I assume) to consider that same subnet to be "on-link" anywhere within that cloud. Within the cloud, the subnet is further subdivided into smaller subnets. Each of those individual (smaller) subnets may well have on-link properties for small portions of the overall cloud. Thomas _______________________________________________ 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 autoconf-bounces@ietf.org Thu Nov 20 08:36:17 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E047B28C1CD; Thu, 20 Nov 2008 08:36:17 -0800 (PST) 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 793D828C181 for ; Thu, 20 Nov 2008 08:36:16 -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 we0n1tXmym6U for ; Thu, 20 Nov 2008 08:36:15 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 7D74628C11C for ; Thu, 20 Nov 2008 08:36:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Ubs8neC70KjTg1j2lSmR0uiptnMmZKRywqEAZNr7dbt+7LxMBxs5rWD1V3cetLpP; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [130.129.28.139] by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L3CVn-0006Wj-Gt; Thu, 20 Nov 2008 11:36:11 -0500 Message-ID: <492591FA.8030605@earthlink.net> Date: Thu, 20 Nov 2008 08:36:10 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Teco Boot References: <4924C84D.5050502@earthlink.net> <005401c94acf$75e49490$61adbdb0$@nl> <49250727.6040308@earthlink.net> <006301c94b0c$bfa5ba90$3ef12fb0$@nl> In-Reply-To: <006301c94b0c$bfa5ba90$3ef12fb0$@nl> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5232e70d598f1b9c45fc2611083b233f7b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.28.139 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Subnet definition 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello Teco, Teco Boot wrote: > >> >> Perhaps the following definition is better: >> A "subnet" is a collection of network nodes whose addresses are >> all within a contiguous range of IP addresses that admits a routing >> prefix. >> > > I am not sure on this definition. Assume a site with a /48 prefix length, > and many Ethernet segments connected with routers, would you say that the > site is a /48 subnet? Or a bundle of /64 subnets, with a subnet on each > Ethernet segment? Both? > By the above definition, they are all subnets, and the site router is a subnet router for a /48 subnet. The site router then delegates responsibility for some (or all) of the nodes at the site to subnet routers that route to smaller subnets. > Correct me if I am wrong, but I think it is a bundle of subnets (RFC940 / > RFC4291 / I-D.6man-ipv6-subnet-model). > I didn't find the term "bundle". But anyway I think you are correct, and that the only extra piece is that a subnet can have sub-subnets which themselves satisfy the definition of subnet. > With mobility in mind, I think we are working with a model that each > object_moving_as_a_whole may have a set of subnets. This would make sure > subnets don't break. Of course subnets are not assigned to multiple of those > objects, but this is BCP. I kept anycast out-of-scope. > Anycast does not need definition in order for use to understand what subnet should mean. > > >>>> A "subnet router" is a router that provides access to >>>> any node that uses one of the contiguous IP addresses >>>> belonging to the range of the subnet. >>>> > > Keeping prefix assignment is mind, do you mean that a subnet_router is a > router assigned and configured a subnet prefix to one of its interfaces? I > can agree on this definition. > Yes, that is correct. But, and very importantly, if a router accepts this delegation, it has the responsibility for keeping track of network nodes using any of the addresses in the subnet. Otherwise, the host may be subject to becoming unreachable. > Within the scope of MANETs, we should define that subnet prefixes are not > assigned to multiple routers, that are not part of the same > object_moving_as_a_whole. Agreed on that? > This is not relevant. A group of routers may share responsibility for a subnet, for instance using VRRP or some redundancy protocol. IPv6 allows multiple routers to advertise reachability to the same subnet. Mobility of the subnet only has the effect of making it more difficult to discharge the responsibility. It should not affect the basic definition or intuition of a subnet. Regards, Charlie P. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 20 08:42:12 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC12528C1FF; Thu, 20 Nov 2008 08:42:12 -0800 (PST) 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 91DCD28C1F4 for ; Thu, 20 Nov 2008 08:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7d7uDJk6008 for ; Thu, 20 Nov 2008 08:42:11 -0800 (PST) Received: from mailouta.tno.nl (mailouta.tno.nl [134.221.1.16]) by core3.amsl.com (Postfix) with ESMTP id 757F928C1FF for ; Thu, 20 Nov 2008 08:42:11 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,639,1220220000"; d="scan'208";a="12960780" Received: from ms-dt01thalia.tno.nl (HELO ms-dt01thalia.tsn.tno.nl) ([134.221.225.157]) by mailhost1a.tno.nl with ESMTP; 20 Nov 2008 17:42:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 17:42:08 +0100 Message-ID: <7877C5C0B5CC894AB26113CF06CF886301238CA2@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <49250727.6040308@earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Subnet definition Thread-Index: AclK21+pkw9OT6jJQ9+tUpKdLlq2XAAUqlLg References: <4924C84D.5050502@earthlink.net><005401c94acf$75e49490$61adbdb0$@nl> <49250727.6040308@earthlink.net> From: "Velt, R. (Ronald) in 't" To: "Charles E. Perkins" , "Teco Boot" Cc: autoconf@ietf.org Subject: Re: [Autoconf] Subnet definition 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello Charlie, all, > -----Original Message----- > From: autoconf-bounces@ietf.org > [mailto:autoconf-bounces@ietf.org] On Behalf Of Charles E. Perkins > Sent: donderdag 20 november 2008 7:44 > To: Teco Boot > Cc: autoconf@ietf.org > Subject: Re: [Autoconf] Subnet definition > > > Hello Teco, > > Teco Boot wrote: > >> A "subnet" is a contiguous range of IP addresses that admits a > >> routing prefix. > >> > > > > Why not using the term routing prefix for a routing prefix? > > > > There are two important answers to this question. > 1. A subnet is something that needs definition so that we > can avoid confusion. No one has been getting confused > about what a routing prefix is supposed to mean. > 2. A subnet is a collection of network nodes, and a routing > prefix is a number and a length. But you correctly point > out that the definition should probably be improved. > > Perhaps the following definition is better: > A "subnet" is a collection of network nodes whose addresses are > all within a contiguous range of IP addresses that admits a routing > prefix. According to draft-iab-ip-model-evolution-01 by Dave Thaler: 'A "subnet" in the IP service model refers to the topological area within which addresses from the same subnet prefix are assigned to interfaces.' Don't see much wrong with that definition. Ronald > > Anyway, even if the elements of two sets have a natural > one-to-one correspondence, we can still usefully consider and > understand their differences. > > > > > > > > >> A "subnet router" is a router that provides access to any > node that > >> uses one of the contiguous IP addresses belonging to the > range of the > >> subnet. > >> > > > > If we stick on MANET, we discuss only router related topics, agreed? > > > > And routers do provide routes to destinations, OK? > > > > It seems to me that there has been a lot of confusion about > routers and subnets, and I think we could go forward faster > if we could manage to resolve that confusion. > > > Sometimes you have to enlarge the field of view in order to > see the elephant in the room (to mix metaphors :-) > > Regards, > Charlie P. > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 20 08:43:24 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FFB128C111; Thu, 20 Nov 2008 08:43:24 -0800 (PST) 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 AD1EE3A6974 for ; Thu, 20 Nov 2008 08:43:23 -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 XVm92NAx70KS for ; Thu, 20 Nov 2008 08:43:22 -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 C73663A6943 for ; Thu, 20 Nov 2008 08:43:22 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id mAKGgwuU028103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2008 08:43:07 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id mAKGgwBU026796; Thu, 20 Nov 2008 08:42:58 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id mAKGguQw026587; Thu, 20 Nov 2008 08:42:58 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Nov 2008 08:42:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 08:42:56 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1053EEF00@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <492591FA.8030605@earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Subnet definition Thread-Index: AclLLh3KUC4pppsxR/KhJ657PlUAnAAACqWg References: <4924C84D.5050502@earthlink.net><005401c94acf$75e49490$61adbdb0$@nl><49250727.6040308@earthlink.net><006301c94b0c$bfa5ba90$3ef12fb0$@nl> <492591FA.8030605@earthlink.net> From: "Templin, Fred L" To: "Charles E. Perkins" , "Teco Boot" X-OriginalArrivalTime: 20 Nov 2008 16:42:57.0801 (UTC) FILETIME=[0B117790:01C94B2F] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-5.500.1027-16290.000 X-TM-AS-Result: No--5.886400-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: autoconf@ietf.org Subject: Re: [Autoconf] Subnet definition 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org >-----Original Message----- >From: Charles E. Perkins [mailto:charles.perkins@earthlink.net] >Sent: Thursday, November 20, 2008 8:36 AM >To: Teco Boot >Cc: autoconf@ietf.org >Subject: Re: [Autoconf] Subnet definition > > >Hello Teco, > >Teco Boot wrote: >> >>> >>> Perhaps the following definition is better: >>> A "subnet" is a collection of network nodes whose addresses are >>> all within a contiguous range of IP addresses that admits a routing >>> prefix. >>> >> >> I am not sure on this definition. Assume a site with a /48 prefix length, >> and many Ethernet segments connected with routers, would you say that the >> site is a /48 subnet? Or a bundle of /64 subnets, with a subnet on each >> Ethernet segment? Both? >> > >By the above definition, they are all subnets, and the site router >is a subnet router for a /48 subnet. The site router then delegates >responsibility for some (or all) of the nodes at the site to subnet >routers that route to smaller subnets. Does it configure and respond to a subnet router anycast address then? Fred Fred.l.templin@boeing.com >> Correct me if I am wrong, but I think it is a bundle of subnets (RFC940 / >> RFC4291 / I-D.6man-ipv6-subnet-model). >> > >I didn't find the term "bundle". But anyway I think you are correct, >and that the only extra piece is that a subnet can have sub-subnets >which themselves satisfy the definition of subnet. > >> With mobility in mind, I think we are working with a model that each >> object_moving_as_a_whole may have a set of subnets. This would make sure >> subnets don't break. Of course subnets are not assigned to multiple of those >> objects, but this is BCP. I kept anycast out-of-scope. >> > >Anycast does not need definition in order for use to >understand what subnet should mean. > >> >> >>>>> A "subnet router" is a router that provides access to >>>>> any node that uses one of the contiguous IP addresses >>>>> belonging to the range of the subnet. >>>>> >> >> Keeping prefix assignment is mind, do you mean that a subnet_router is a >> router assigned and configured a subnet prefix to one of its interfaces? I >> can agree on this definition. >> > >Yes, that is correct. But, and very importantly, if a router accepts this >delegation, it has the responsibility for keeping track of network nodes >using any of the addresses in the subnet. Otherwise, the host may be >subject to becoming unreachable. >> Within the scope of MANETs, we should define that subnet prefixes are not >> assigned to multiple routers, that are not part of the same >> object_moving_as_a_whole. Agreed on that? >> > >This is not relevant. A group of routers may share responsibility >for a subnet, for instance using VRRP or some redundancy >protocol. IPv6 allows multiple routers to advertise reachability >to the same subnet. Mobility of the subnet only has the effect >of making it more difficult to discharge the responsibility. It >should not affect the basic definition or intuition of a subnet. > > >Regards, >Charlie P. > > >_______________________________________________ >Autoconf mailing list >Autoconf@ietf.org >https://www.ietf.org/mailman/listinfo/autoconf _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 20 08:45:09 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 127C628C181; Thu, 20 Nov 2008 08:45:09 -0800 (PST) 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 7F05928C230 for ; Thu, 20 Nov 2008 08:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2G8em8KUSdFs for ; Thu, 20 Nov 2008 08:45:06 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 4EA0628C22E for ; Thu, 20 Nov 2008 08:45:05 -0800 (PST) Received: (qmail 24698 invoked from network); 20 Nov 2008 17:45:02 +0100 Received: from unknown (HELO M90Teco) (12.104.246.2) by server9.hosting2go.nl with SMTP; 20 Nov 2008 17:45:02 +0100 From: "Teco Boot" To: , "'Thomas Narten'" References: <4924C84D.5050502@earthlink.net> <200811201439.mAKEdcHG003838@cichlid.raleigh.ibm.com> In-Reply-To: Date: Thu, 20 Nov 2008 17:44:57 +0100 Message-ID: <007401c94b2f$532d17a0$f98746e0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclLJx4+NjPJlgbnRX6gK+vCd7+EDAABJZig Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] Subnet definition 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > That is exactly what I tried to convey. It may be just a happy > coincidence that there is one-to-one mapping between a subnet and an > Ethernet link. As long as we do not assume such mapping should always > exist and treat a subnet as just a contiguous range of IP addresses > (therefore an abstract concept rather than being tied to any L2 > facility), everything looks straightforward to me. > I want to make clear that such assumptions are in contradiction with the IP model. RFC4903 Multi-Link Subnet Issues: >>> A multi-link subnet model should be avoided. IETF working groups using, or considering using, multi-link subnets today should investigate moving to one of the other models. <<< This applies to both IPv4 and IPv6. Read RFC4903 for details. I currently see no reason for an exception. But of course I could be wrong. Site remark: anycast is out-of-scope in this discussion, for obvious reasons. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 20 08:54:49 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CF7E28C20D; Thu, 20 Nov 2008 08:54:49 -0800 (PST) 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 1D3BA28C20D for ; Thu, 20 Nov 2008 08:54:48 -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 lhSNLqSddNAx for ; Thu, 20 Nov 2008 08:54:47 -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 1488B28C1F4 for ; Thu, 20 Nov 2008 08:54:47 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id mAKGsWUE007214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Nov 2008 08:54:32 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id mAKGsV0X008400; Thu, 20 Nov 2008 08:54:31 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id mAKGsUeV008302; Thu, 20 Nov 2008 08:54:31 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Nov 2008 08:54:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 08:54:28 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1053EEF2C@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <007401c94b2f$532d17a0$f98746e0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Subnet definition Thread-Index: AclLJx4+NjPJlgbnRX6gK+vCd7+EDAABJZigAAEh7kA= References: <4924C84D.5050502@earthlink.net> <200811201439.mAKEdcHG003838@cichlid.raleigh.ibm.com> <007401c94b2f$532d17a0$f98746e0$@nl> From: "Templin, Fred L" To: "Teco Boot" , , "Thomas Narten" X-OriginalArrivalTime: 20 Nov 2008 16:54:30.0031 (UTC) FILETIME=[A7AB61F0:01C94B30] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-5.500.1027-16290.000 X-TM-AS-Result: No--6.486500-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: autoconf@ietf.org Subject: Re: [Autoconf] Subnet definition 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org >-----Original Message----- >From: Teco Boot [mailto:teco@inf-net.nl] >Sent: Thursday, November 20, 2008 8:45 AM >To: scicarus@iname.com; 'Thomas Narten' >Cc: autoconf@ietf.org >Subject: Re: [Autoconf] Subnet definition > >> That is exactly what I tried to convey. It may be just a happy >> coincidence that there is one-to-one mapping between a subnet and an >> Ethernet link. As long as we do not assume such mapping should always >> exist and treat a subnet as just a contiguous range of IP addresses >> (therefore an abstract concept rather than being tied to any L2 >> facility), everything looks straightforward to me. >> > >I want to make clear that such assumptions are in contradiction with the IP >model. >RFC4903 Multi-Link Subnet Issues: >>>> > A multi-link subnet model should be avoided. IETF working groups > using, or considering using, multi-link subnets today should > investigate moving to one of the other models. ><<< >This applies to both IPv4 and IPv6. Read RFC4903 for details. I currently >see no reason for an exception. >But of course I could be wrong. > >Site remark: anycast is out-of-scope in this discussion, for obvious >reasons. Subnet router anycast address is an RFC4291-required address for subnet routers. Are we talking about a different kind of "subnet router"? Fred fred.l.templin@boeing.com > >Teco. > > >_______________________________________________ >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 autoconf-bounces@ietf.org Thu Nov 20 09:18:13 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F90E3A6943; Thu, 20 Nov 2008 09:18:13 -0800 (PST) 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 277AC3A67FA for ; Thu, 20 Nov 2008 09:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GO0wpqp6+d+0 for ; Thu, 20 Nov 2008 09:18:11 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id C5AC93A6943 for ; Thu, 20 Nov 2008 09:18:10 -0800 (PST) Received: (qmail 10443 invoked from network); 20 Nov 2008 18:18:01 +0100 Received: from unknown (HELO M90Teco) (12.104.246.2) by server9.hosting2go.nl with SMTP; 20 Nov 2008 18:18:01 +0100 From: "Teco Boot" To: "'Charles E. Perkins'" References: <4924C84D.5050502@earthlink.net> <005401c94acf$75e49490$61adbdb0$@nl> <49250727.6040308@earthlink.net> <006301c94b0c$bfa5ba90$3ef12fb0$@nl> <492591FA.8030605@earthlink.net> In-Reply-To: <492591FA.8030605@earthlink.net> Date: Thu, 20 Nov 2008 18:17:56 +0100 Message-ID: <008101c94b33$ef129ec0$cd37dc40$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclLLhws6TjJwO/WRgqhgmITUZddHgAAZHQg Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] Subnet definition 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Charlie, > Teco Boot wrote: > > > >> > >> Perhaps the following definition is better: > >> A "subnet" is a collection of network nodes whose addresses are > >> all within a contiguous range of IP addresses that admits a > routing > >> prefix. > >> > > > > I am not sure on this definition. Assume a site with a /48 prefix > length, > > and many Ethernet segments connected with routers, would you say that > the > > site is a /48 subnet? Or a bundle of /64 subnets, with a subnet on > each > > Ethernet segment? Both? > > > > By the above definition, they are all subnets, and the site router > is a subnet router for a /48 subnet. The site router then delegates > responsibility for some (or all) of the nodes at the site to subnet > routers that route to smaller subnets. If this router has the /48 prefix assigned to one of its interfaces, yes I agree. With the longest match rule, all packets for destinations on the other subnets (or aggregation prefixes) are forwarded to a nexthop router. The remaining address blocks could be used for addresses on this link. SLAAC cannot be used in this model (i.e. no /64 prefix length). If this router has the /48 prefix NOT assigned to one of its interfaces, NO, I do not agree. In my BRDP solution I use something similar, but maybe more practical. I suggest a /64 on the BR MANET interface (could be a /128 also, but /64 better fits current text on SLAAC). MANET Routers may generate a /128 host prefix. The longest match rule guarantees that packets are delivered to the destination. > > > Correct me if I am wrong, but I think it is a bundle of subnets > (RFC940 / > > RFC4291 / I-D.6man-ipv6-subnet-model). > > > > I didn't find the term "bundle". But anyway I think you are correct, > and that the only extra piece is that a subnet can have sub-subnets > which themselves satisfy the definition of subnet. Sorry, I meant a "set of". And no, I do not totally agree on sub-subnet. Prefixes and sub-prefixes are OK for me. Only a prefix "bound" to an interface makes it a subnet. > >>>> A "subnet router" is a router that provides access to > >>>> any node that uses one of the contiguous IP addresses > >>>> belonging to the range of the subnet. > >>>> > > > > Keeping prefix assignment is mind, do you mean that a subnet_router > is a > > router assigned and configured a subnet prefix to one of its > interfaces? I > > can agree on this definition. > > > > Yes, that is correct. But, and very importantly, if a router accepts > this > delegation, it has the responsibility for keeping track of network > nodes > using any of the addresses in the subnet. Otherwise, the host may be > subject to becoming unreachable. Agreed on that subnets SHOULD NOT be delegated? > > Within the scope of MANETs, we should define that subnet prefixes are > not > > assigned to multiple routers, that are not part of the same > > object_moving_as_a_whole. Agreed on that? > > > > This is not relevant. A group of routers may share responsibility > for a subnet, for instance using VRRP or some redundancy > protocol. IPv6 allows multiple routers to advertise reachability > to the same subnet. Mobility of the subnet only has the effect > of making it more difficult to discharge the responsibility. It > should not affect the basic definition or intuition of a subnet. I think this is essential. VRRP will not work in a MANET, if the VRRP Routers are part of different object_moving_as_a_whole. This would break the subnets. I suggest not get into split subnet repair mechanisms. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 20 09:20:44 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C06D28C19C; Thu, 20 Nov 2008 09:20:44 -0800 (PST) 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 AF7AD28C19C for ; Thu, 20 Nov 2008 09:20:43 -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 xSKUjbQsLF+m for ; Thu, 20 Nov 2008 09:20:42 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id DD76F3A69BA for ; Thu, 20 Nov 2008 09:20:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=WLU17rnQnLdNHRoksciN4d8/ehbInHdBRST+RpGyGUB4ZAqlTukAWRXFAmZyeD+p; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [130.129.28.139] by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L3DCr-0001pp-EC; Thu, 20 Nov 2008 12:20:41 -0500 Message-ID: <49259C68.1040407@earthlink.net> Date: Thu, 20 Nov 2008 09:20:40 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Velt, R. (Ronald) in 't" References: <4924C84D.5050502@earthlink.net><005401c94acf$75e49490$61adbdb0$@nl> <49250727.6040308@earthlink.net> <7877C5C0B5CC894AB26113CF06CF886301238CA2@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <7877C5C0B5CC894AB26113CF06CF886301238CA2@ms-dt01thalia.tsn.tno.nl> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52235b59e5980769fbe0ad9195c5c447eb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.28.139 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Subnet definition 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello Ronald, Velt, R. (Ronald) in 't wrote: > > According to draft-iab-ip-model-evolution-01 by Dave Thaler: 'A "subnet" > in the IP service model refers to the topological area within which > addresses from the same subnet prefix are assigned to interfaces.' > > This also is O.K. with me, as long as we don't have to get bogged down in defining "topological area" and "assignment". But I'd be happy if consensus settles on this definition (soon). Regards, Charlie P. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 20 09:25:27 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B5A83A6A34; Thu, 20 Nov 2008 09:25:27 -0800 (PST) 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 E81A03A6A34 for ; Thu, 20 Nov 2008 09:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 nzjLz66w2+RO for ; Thu, 20 Nov 2008 09:25:25 -0800 (PST) Received: from mxav01.cc.niigata-u.ac.jp (mxav01.cc.niigata-u.ac.jp [133.35.17.129]) by core3.amsl.com (Postfix) with ESMTP id BEFE13A6A27 for ; Thu, 20 Nov 2008 09:25:24 -0800 (PST) Received: from mxav01.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id CE8A74F4202 for ; Fri, 21 Nov 2008 02:25:20 +0900 (JST) Received: from chamame.ie.niigata-u.ac.jp (chamame.ie.niigata-u.ac.jp [133.35.169.34]) by mxav01.cc.niigata-u.ac.jp (Postfix) with SMTP id C37534F4200 for ; Fri, 21 Nov 2008 02:25:20 +0900 (JST) Received: (qmail 11865 invoked from network); 21 Nov 2008 02:25:20 +0900 Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 21 Nov 2008 02:25:20 +0900 Message-Id: <7.0.0.16.2.20081121021715.03d4fbd8@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Fri, 21 Nov 2008 02:25:21 +0900 To: Emmanuel Baccelli ,autoconf@ietf.org From: mase In-Reply-To: <49259096.7080709@inria.fr> References: <49259096.7080709@inria.fr> Mime-Version: 1.0 Subject: Re: [Autoconf] Subnet definition 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Dear Emmanuel, At 01:30 08/11/21, Emmanuel Baccelli wrote: >Maybe we are hitting the heart of the misunderstanding. I think we >should indeed distinguish prefix and subnet terms, and stick to >something like: > >- a prefix is a contiguous range of IP addresses. >- a subnet is a set of IP addresses (that may or may not be a prefix) >that are on the same link. All these addresses are then on-link with >respect to this link. >- a link is what L2 provides, which reaches everything within TTL 1 >beyond a given interface. I agree. If we accept the definitions above, I think that subnet is not a useful concept for MANET, because each interface may have a differenct set of neighbors. It just inroduces confusions. Kenichi >If we stick to these definitions, we will indeed save ourselves lots of >trouble. Do you agree? >Emmanuel > > > > > >On Thu, Nov 20, 2008 at 3:39 PM, Thomas Narten wrote: >I agree that we need a clean definition of subnet. The term is >overloaded and different people have different meanings associated >with it. That has contributed to confusion in the discussions... > >Note also that I think Erik's observation about "on-link" being a key >issue to also be clear about is correct. > >"Charles E. Perkins" writes: > > > A "subnet" is a contiguous range of IP addresses that > > admits a routing prefix. > >I'd change that as follows (to highlight the properties that are >important to us): > >A "subnet" is the range of IP addresses that are covered by a >prefix. All that a subnet defines is which addresses are considered to >be on the subnet and which are not. > >In many cases (in IPv4) there is a one-to-one mapping between a subnet >and a link. I.e., on an Ethernet, you assign a subnet to the ethernet >link. All the addresses covered by the prefix are assumed to reside >on that Ethernet, and are neighbors of each other. Using IPv6 >terminology, we would say "link" rather than subnet and we would say >all the addresses covered by the subnet are "on link". (But note that >in IPv6, you can have links with addresses assigned to it, but for >which there is no prefix that is considered "on link".) > >But if one talks to routing folk, a subnet is an abstraction that is >not tied to a physical link. For example, IBM has been assigned net >9.0.0.0. So, to BGP, 9.0.0.0/8 is a "subnet", even though the actual >network is a huge cloud of thousands of individual networks. > >And, within IBM, talking about 9.0.0.0/8 as a "subnet" makes little >sense, because we see the individual links that have been subnetted >and given individual subnet numbers. We talk about 9.2.27.0/24 and the >like. > >Thus, when talking about a subnet, we also have to consider the >on-link properties (if any), as differing assumptions on that point >can lead to very different ideas about how things do (or don't) work. > >Back to the simple Ethernet, all the addresses covered by the prefix >are typically considered on-link. > >When talking about MANETs, and talking about subnets (or prefixes) we >also have to talk about the on-link properties (or lack thereof). > >For example, going back to chart 37 of ThomasC's presentation, it may >well make sense to consider the entire cloud of routers to be part of >one subnet, but it does not make sense (I assume) to consider that >same subnet to be "on-link" anywhere within that cloud. Within the >cloud, the subnet is further subdivided into smaller subnets. Each of >those individual (smaller) subnets may well have on-link properties >for small portions of the overall cloud. > >Thomas >_______________________________________________ >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 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 20 09:27:53 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C37BC3A6943; Thu, 20 Nov 2008 09:27:53 -0800 (PST) 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 C6DA83A6943 for ; Thu, 20 Nov 2008 09:27:52 -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 3pWWXTew7FhD for ; Thu, 20 Nov 2008 09:27:52 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id F17C33A67FA for ; Thu, 20 Nov 2008 09:27:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=rSuQcMT6wE7uB/OBhN7bfrJJxejsm3onBhowz5bhGQNJYV5Dt+YojGBoP05NUtOt; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [130.129.28.139] by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L3DJm-0007i3-Ot; Thu, 20 Nov 2008 12:27:50 -0500 Message-ID: <49259E14.6080201@earthlink.net> Date: Thu, 20 Nov 2008 09:27:48 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Templin, Fred L" References: <4924C84D.5050502@earthlink.net><005401c94acf$75e49490$61adbdb0$@nl><49250727.6040308@earthlink.net><006301c94b0c$bfa5ba90$3ef12fb0$@nl> <492591FA.8030605@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A1053EEF00@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1053EEF00@XCH-NW-7V2.nw.nos.boeing.com> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52df8ecf27719dc2f4d0ae35608ca61b87350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.28.139 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Subnet definition 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello Fred, You raise a very interesting point! Templin, Fred L wrote: > >> .............. the site router >> is a subnet router for a /48 subnet. The site router then delegates >> responsibility for some (or all) of the nodes at the site to subnet >> routers that route to smaller subnets. >> > > Does it configure and respond to a subnet router anycast address then? > In order to conform to RFC 4291, it needs to do this. For this purpose, it might be most convenient for a site router to avoid overlapping the anycast address ranges for any sub-subnet. Otherwise, by the rules of anycast, two routers at the same anycast address have to decide how to do the right thing (e.g., see RFC 2526). Regards, Charlie P. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 20 09:37:18 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E98793A6911; Thu, 20 Nov 2008 09:37:18 -0800 (PST) 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 1D7463A6911 for ; Thu, 20 Nov 2008 09:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dh5MOyUVMhVV for ; Thu, 20 Nov 2008 09:37:16 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id F0D723A68CD for ; Thu, 20 Nov 2008 09:37:15 -0800 (PST) Received: (qmail 20131 invoked from network); 20 Nov 2008 18:37:06 +0100 Received: from unknown (HELO M90Teco) (12.104.246.2) by server9.hosting2go.nl with SMTP; 20 Nov 2008 18:37:06 +0100 From: "Teco Boot" To: "'Templin, Fred L'" References: <4924C84D.5050502@earthlink.net> <200811201439.mAKEdcHG003838@cichlid.raleigh.ibm.com> <007401c94b2f$532d17a0$f98746e0$@nl> <39C363776A4E8C4A94691D2BD9D1C9A1053EEF2C@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1053EEF2C@XCH-NW-7V2.nw.nos.boeing.com> Date: Thu, 20 Nov 2008 18:37:01 +0100 Message-ID: <008701c94b36$99a93450$ccfb9cf0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclLJx4+NjPJlgbnRX6gK+vCd7+EDAABJZigAAEh7kAAAVf58A== Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] Subnet definition 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > >Site remark: anycast is out-of-scope in this discussion, for obvious > >reasons. > > Subnet router anycast address is an RFC4291-required address > for subnet routers. Are we talking about a different kind of > "subnet router"? Sorry, I meant non-LL anycast. Those prefixes may be assigned to interfaces of routers that are not on the same link. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 20 10:01:56 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0985A3A677D; Thu, 20 Nov 2008 10:01:56 -0800 (PST) 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 25A933A67FA for ; Thu, 20 Nov 2008 09:34:44 -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 sEQ71mogORbN for ; Thu, 20 Nov 2008 09:34:43 -0800 (PST) Received: from mail-bw0-f13.google.com (mail-bw0-f13.google.com [209.85.218.13]) by core3.amsl.com (Postfix) with ESMTP id D68F83A68BE for ; Thu, 20 Nov 2008 09:34:42 -0800 (PST) Received: by bwz6 with SMTP id 6so17867bwz.13 for ; Thu, 20 Nov 2008 09:34:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=/ouRbPaKE11XOYQFT1sMem16GMNJtp7xDbj2olCnZFc=; b=ZGGCQCHC3Ih7jxrVHPShJ5gmdA8TNQOmRrK1gGW8Tcu5C7bwd8P170qV8nfftDSs5m /PgavY8HgjsCyzjbW5cjdREY70TNNkG+PLUZ8RyESWM594ew4PNoU+hHmpsiIazO1xu8 8oIumQYs9tcpHltjKjDJc1DMfxd6GW0BLFNUc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=vKZt7Ev0Dx36NMXddwgQOAvnUXUX64CU/V0gK1/ZmMsK5F4SPit83Tpjbw4ootTjq2 mEpN8v1ItP3cluOQkvi+sasXoM6FpGSg40oOAjQA3RnKFMW9avbX4xfymFnl6nWvd+xX 5GGA3rH7nOrTfAAk4hnoKplThXcmQ/cz3jSRQ= Received: by 10.180.216.19 with SMTP id o19mr803927bkg.54.1227202478523; Thu, 20 Nov 2008 09:34:38 -0800 (PST) Received: by 10.181.208.13 with HTTP; Thu, 20 Nov 2008 09:34:37 -0800 (PST) Message-ID: Date: Thu, 20 Nov 2008 18:34:37 +0100 From: "Emmanuel Baccelli" To: autoconf@ietf.org In-Reply-To: <7.0.0.16.2.20081121021715.03d4fbd8@ie.niigata-u.ac.jp> MIME-Version: 1.0 References: <49259096.7080709@inria.fr> <7.0.0.16.2.20081121021715.03d4fbd8@ie.niigata-u.ac.jp> X-Google-Sender-Auth: 74ce291b7ff009b7 Subject: Re: [Autoconf] Subnet definition 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: , Content-Type: multipart/mixed; boundary="===============0905648740==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============0905648740== Content-Type: multipart/alternative; boundary="----=_Part_7115_29186833.1227202478519" ------=_Part_7115_29186833.1227202478519 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline > - a prefix is a contiguous range of IP addresses. >> - a subnet is a set of IP addresses (that may or may not be a prefix) >> that are on the same link. All these addresses are then on-link with >> respect to this link. >> - a link is what L2 provides, which reaches everything within TTL 1 >> beyond a given interface. >> > > I agree. If we accept the definitions above, I think that subnet is not a > useful concept for MANET, because each interface may have a differenct set > of neighbors. It just inroduces confusions. > > Yes. These definitions make a needed clarification for us. And they are compatible with the IP service model described by D. Thaler. Emmanuel ------=_Part_7115_29186833.1227202478519 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

- a prefix is a contiguous range of IP addresses.
- a subnet is a set of IP addresses (that may or may not be a prefix)
that are on the same link. All these addresses are then on-link with
respect to this link.
- a link is what L2 provides, which reaches everything within TTL 1
beyond a given interface.

I agree. If we accept the definitions above, I think that subnet is not a useful concept for MANET, because each interface may have a differenct set of neighbors. It just inroduces confusions.


Yes. These definitions make a needed clarification for us. And they are compatible with the IP service model described by D. Thaler.

Emmanuel


------=_Part_7115_29186833.1227202478519-- --===============0905648740== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf --===============0905648740==-- From autoconf-bounces@ietf.org Thu Nov 20 10:09:59 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A782C28C13F; Thu, 20 Nov 2008 10:09:59 -0800 (PST) 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 27F2D28C13F for ; Thu, 20 Nov 2008 10:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNN+WVPtKsu3 for ; Thu, 20 Nov 2008 10:09:58 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 0483B28C0ED for ; Thu, 20 Nov 2008 10:09:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,639,1220227200"; d="scan'208,217";a="28526330" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 20 Nov 2008 18:09:56 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAKI9uLJ018807; Thu, 20 Nov 2008 13:09:56 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAKI9uiU019280; Thu, 20 Nov 2008 18:09:56 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 13:09:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 13:09:55 -0500 Message-ID: <7FB7EE0A621BA44B8B69E5F0A09DC764070ABC92@xmb-rtp-208.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Subnet definition Thread-Index: AclLOhVExJRE1IGMQqywa2irOwy2YgAAQKgg References: <49259096.7080709@inria.fr><7.0.0.16.2.20081121021715.03d4fbd8@ie.niigata-u.ac.jp> From: "Stan Ratliff (sratliff)" To: "Emmanuel Baccelli" , X-OriginalArrivalTime: 20 Nov 2008 18:09:56.0141 (UTC) FILETIME=[3170F5D0:01C94B3B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3923; t=1227204596; x=1228068596; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20=22Stan=20Ratliff=20(sratliff)=22=20 |Subject:=20RE=3A=20[Autoconf]=20Subnet=20definition |Sender:=20 |To:=20=22Emmanuel=20Baccelli=22=20,=20; bh=lqmw5lVBZIsFYnPBJsgVV8EkDpk0IKORUeUR1LPrYyk=; b=HDJoWg7DZFW8pO8jkbJRH99gH2iLDCwPcm1y/2xVc6tGYH6Rb2uE12mh58 yMxr0eVS4VJZWuoifCgRQMj5JWv4WsuCT0DuIIKvYftQM5o5yDxb8gJgQzEF gwoFEYnK98; Authentication-Results: rtp-dkim-2; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Autoconf] Subnet definition 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: , Content-Type: multipart/mixed; boundary="===============0368138051==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0368138051== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C94B3B.314DB400" This is a multi-part message in MIME format. ------_=_NextPart_001_01C94B3B.314DB400 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Emmanuel,=20 =20 I agree with you -- these are a good set of definitions=20 from which to proceed.=20 =20 Regards, Stan ________________________________ From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On Behalf Of Emmanuel Baccelli Sent: Thursday, November 20, 2008 12:35 PM To: autoconf@ietf.org Subject: Re: [Autoconf] Subnet definition - a prefix is a contiguous range of IP addresses. - a subnet is a set of IP addresses (that may or may not be a prefix) that are on the same link. All these addresses are then on-link with respect to this link. - a link is what L2 provides, which reaches everything within TTL 1 beyond a given interface. =09 I agree. If we accept the definitions above, I think that subnet is not a useful concept for MANET, because each interface may have a differenct set of neighbors. It just inroduces confusions. =09 =09 Yes. These definitions make a needed clarification for us. And they are compatible with the IP service model described by D. Thaler. Emmanuel ------_=_NextPart_001_01C94B3B.314DB400 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Emmanuel, =
 
I agree = with you -- these=20 are a good set of definitions
from which = to proceed.=20
 
Regards,
Stan

From: autoconf-bounces@ietf.org=20 [mailto:autoconf-bounces@ietf.org] On Behalf Of Emmanuel=20 Baccelli
Sent: Thursday, November 20, 2008 12:35 = PM
To:=20 autoconf@ietf.org
Subject: Re: [Autoconf] Subnet=20 definition


-=20 a prefix is a contiguous range of IP addresses.
- a subnet is a = set of IP=20 addresses (that may or may not be a prefix)
that are on the same = link.=20 All these addresses are then on-link with
respect to this = link.
- a=20 link is what L2 provides, which reaches everything within TTL = 1
beyond a=20 given interface.

I agree. If we accept the = definitions above, I think that subnet is not a useful concept for = MANET,=20 because each interface may have a differenct set of neighbors. It just = inroduces confusions.


Yes. These definitions make a needed clarification for us. And they = are=20 compatible with the IP service model described by D. Thaler.

Emmanuel


------_=_NextPart_001_01C94B3B.314DB400-- --===============0368138051== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf --===============0368138051==-- From autoconf-bounces@ietf.org Thu Nov 20 10:50:18 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 708CD3A67D2; Thu, 20 Nov 2008 10:50:18 -0800 (PST) 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 896423A67D2 for ; Thu, 20 Nov 2008 10:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8p3Cp30sbYAD for ; Thu, 20 Nov 2008 10:50:16 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 4BA2F3A67AF for ; Thu, 20 Nov 2008 10:50:16 -0800 (PST) Received: (qmail 29106 invoked from network); 20 Nov 2008 19:50:11 +0100 Received: from unknown (HELO M90Teco) (12.104.246.2) by server9.hosting2go.nl with SMTP; 20 Nov 2008 19:50:11 +0100 From: "Teco Boot" To: "'Emmanuel Baccelli'" References: <49259096.7080709@inria.fr> In-Reply-To: <49259096.7080709@inria.fr> Date: Thu, 20 Nov 2008 19:50:06 +0100 Message-ID: <00a001c94b40$cf06cf90$6d146eb0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclLLUkrUo4KxiWBS/aRHWy7AdvguwAEKSiw Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] Subnet definition 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > > - a prefix is a contiguous range of IP addresses. > - a subnet is a set of IP addresses (that may or may not be a prefix) > that are on the same link. All these addresses are then on-link with > respect to this link. > - a link is what L2 provides, which reaches everything within TTL 1 > beyond a given interface. > > If we stick to these definitions, we will indeed save ourselves lots of > trouble. Do you agree? In general, I agree on the intention. But we should be very careful here. I suggest xref to RFCs that are in line with what you say. And try to use the same wording. And explain if not (e.g. clarify or correct) There would be small nits forever. Just to come up with some, what with off-link addresses? Are two of those in the same prefix also in the same subnet? Use "without TTL decrement" instead of "TTL 1"? Somewhat more important: Is a IP addresses within a prefix, that is assigned & configured on an interface, but that is not on-link, part of a subnet? If not, I think somewhat should write this down. 6MAN? Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 20 11:14:04 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A65283A6831; Thu, 20 Nov 2008 11:14:04 -0800 (PST) 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 7B4D63A6831 for ; Thu, 20 Nov 2008 11:14:03 -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 4IGYc9JzrC7N for ; Thu, 20 Nov 2008 11:14:02 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id 176693A677D for ; Thu, 20 Nov 2008 11:14:01 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id d23so431590fga.41 for ; Thu, 20 Nov 2008 11:13:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=XuhbdjNZJGhd25SKGU4IJ0MjinQU5a22qcZSkDhJ4dU=; b=E7A9PGdx+oRtYnqCWdyM8he0Zd9wS+yPGPGt5RKMo/PrdajnFmy4YvWFpocI8qt4aN it7IAq4o3jepyRr14pNfYECYqJ/VkKWwzdFSv0DwpsT2G1xM25lkfVvBPk4OIZTRtiH2 C0K5VFIfdRwdh7mnIn6Xf/jm6uJrFnqvpGQd8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=D7AOWBrcJ+K1EFl7VxmuW35X9UtMAGKyTPlFdq3sEaJEQ/mq5lF7GXJfkkvTanvnuO amolsfQv0r16Ul78sLLsIJpmIZ+U6WT6SfpZ/lOw7hSvy0NeoCMDaWIbboOXDviIe84Z Ygd91j6y/69WrPOmRZRvp8iyr5j91c08iRvD4= Received: by 10.181.224.3 with SMTP id b3mr821812bkr.183.1227208439243; Thu, 20 Nov 2008 11:13:59 -0800 (PST) Received: by 10.181.208.13 with HTTP; Thu, 20 Nov 2008 11:13:59 -0800 (PST) Message-ID: Date: Thu, 20 Nov 2008 20:13:59 +0100 From: "Emmanuel Baccelli" To: autoconf@ietf.org In-Reply-To: <00a001c94b40$cf06cf90$6d146eb0$@nl> MIME-Version: 1.0 References: <49259096.7080709@inria.fr> <00a001c94b40$cf06cf90$6d146eb0$@nl> X-Google-Sender-Auth: 1f3bd4f1a9a443c1 Subject: Re: [Autoconf] Subnet definition 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: , Content-Type: multipart/mixed; boundary="===============0045908093==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============0045908093== Content-Type: multipart/alternative; boundary="----=_Part_7590_29790169.1227208439249" ------=_Part_7590_29790169.1227208439249 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Great. So we could refine on this basis. See inline: On Thu, Nov 20, 2008 at 7:50 PM, Teco Boot wrote: > > > > - a prefix is a contiguous range of IP addresses. > > - a subnet is a set of IP addresses (that may or may not be a prefix) > > that are on the same link. All these addresses are then on-link with > > respect to this link. > > - a link is what L2 provides, which reaches everything within TTL 1 > > beyond a given interface. > > > > If we stick to these definitions, we will indeed save ourselves lots of > > trouble. Do you agree? > > In general, I agree on the intention. But we should be very careful here. > I suggest xref to RFCs that are in line with what you say. And try to use > the same wording. And explain if not (e.g. clarify or correct) > OK. Let's do that. Any suggestions? > > There would be small nits forever. Just to come up with some, what with > off-link addresses? Are two of those in the same prefix also in the same > subnet? Use "without TTL decrement" instead of "TTL 1"? If we base ourselves on these definitions, an address is off-link if it is not on the same subnet, i.e. not in the set of IP addresses that form this subnet. As Thomas Narten pointed out, this set may not be a prefix. So being in the same prefix does not necessarily mean being on the same subnet. I'm personally OK with using "without TTL decrement". > Somewhat more important: Is a IP addresses within a prefix, that is > assigned > & configured on an interface, but that is not on-link, part of a subnet? If > not, I think somewhat should write this down. 6MAN? > > I'm not sure I understand your question. Do you mean: if the set of addresses that form a subnet is not a prefix, what do you configure the interface with, in terms of prefix? If this is correct, I think this is an architectural question, that we may want to answer in a second phase. Don't you think? Emmanuel ------=_Part_7590_29790169.1227208439249 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Great. So we could refine on this basis. See inline:

On Thu, Nov 20, 2008 at 7:50 PM, Teco Boot <teco@inf-net.nl> wrote:
>
> - a prefix is a contiguous range of IP addresses.
> - a subnet is a set of IP addresses (that may or may not be a prefix)
> that are on the same link. All these addresses are then on-link with
> respect to this link.
> - a link is what L2 provides, which reaches everything within TTL 1
> beyond a given interface.
>
> If we stick to these definitions, we will indeed save ourselves lots of
> trouble. Do you agree?

In general, I agree on the intention. But we should be very careful here.
I suggest xref to RFCs that are in line with what you say. And try to use
the same wording. And explain if not (e.g. clarify or correct)

OK. Let's do that. Any suggestions?
 

There would be small nits forever. Just to come up with some, what with
off-link addresses? Are two of those in the same prefix also in the same
subnet? Use "without TTL decrement" instead of "TTL 1"?

If we base ourselves on these definitions, an address is off-link if it is not on the same subnet, i.e. not in the set of IP addresses that form this subnet. 

As Thomas Narten pointed out, this set may not be a prefix. So being in the same prefix does not necessarily mean being on the same subnet.

I'm personally OK with using "without TTL decrement".


Somewhat more important: Is a IP addresses within a prefix, that is assigned
& configured on an interface, but that is not on-link, part of a subnet? If
not, I think somewhat should write this down. 6MAN?


I'm not sure I understand your question. Do you mean: if the set of addresses that form a subnet is not a prefix, what do you configure the interface with, in terms of prefix? If this is correct, I think this is an architectural question, that we may want to answer in a second phase. Don't you think?

Emmanuel
------=_Part_7590_29790169.1227208439249-- --===============0045908093== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf --===============0045908093==-- From autoconf-bounces@ietf.org Thu Nov 20 11:20:43 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB2373A6835; Thu, 20 Nov 2008 11:20:43 -0800 (PST) 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 47FC13A6835 for ; Thu, 20 Nov 2008 11:20:42 -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 LfHnV9fzQ5b5 for ; Thu, 20 Nov 2008 11:20:41 -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 665163A677D for ; Thu, 20 Nov 2008 11:20:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=amDHbF8UIB1vyI3r00RaAcVIW0MMiBNZGxWRXo6vI0A1yy5K3+B4MvM13B+h/eNc; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [130.129.28.139] by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L3F4y-0004HP-4f; Thu, 20 Nov 2008 14:20:40 -0500 Message-ID: <4925B886.506@earthlink.net> Date: Thu, 20 Nov 2008 11:20:38 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Emmanuel Baccelli References: <49259096.7080709@inria.fr> In-Reply-To: <49259096.7080709@inria.fr> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5222013f24647b15264fde713b44ab9b4c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.28.139 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Subnet definition 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello Emmanuel, I want to differ with this proposal, as follows: Emmanuel Baccelli wrote: > Maybe we are hitting the heart of the misunderstanding. I think we > should indeed distinguish prefix and subnet terms, and stick to > something like: > > - a prefix is a contiguous range of IP addresses. > O.K., except that it _defines_ a contiguous range of IP addresses. > - a subnet is a set of IP addresses (that may or may not be a prefix) > that are on the same link. All these addresses are then on-link with > respect to this link. > I would greatly prefer to separate the definition of a subnet from the definition of a link. We should make a subnet a matter of addressability, not a matter of transmission ranges. In other words, it's a layer-3 concept, not a layer-2 concept. > - a link is what L2 provides, which reaches everything within TTL 1 > beyond a given interface. > I agree with this as far as it goes -- at least as a good starting point. Regards, Charlie P. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 20 11:31:21 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5351B3A6914; Thu, 20 Nov 2008 11:31:21 -0800 (PST) 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 783083A6914 for ; Thu, 20 Nov 2008 11:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WNV1eRMix3J for ; Thu, 20 Nov 2008 11:31:19 -0800 (PST) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by core3.amsl.com (Postfix) with ESMTP id 3DA333A6906 for ; Thu, 20 Nov 2008 11:31:19 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,639,1220220000"; d="scan'208";a="31663576" Received: from unknown (HELO BoolfightMaN-Laptop.local) ([130.129.29.95]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Nov 2008 20:31:13 +0100 Message-ID: <4925BAFE.6040109@inria.fr> Date: Thu, 20 Nov 2008 20:31:10 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: autoconf@ietf.org References: <49259096.7080709@inria.fr> <4925B886.506@earthlink.net> In-Reply-To: <4925B886.506@earthlink.net> X-Enigmail-Version: 0.95.7 Subject: Re: [Autoconf] Subnet definition 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Charlie, great that you think this is a good starting point ;) See below: Charles E. Perkins a =E9crit : >> >> - a prefix is a contiguous range of IP addresses. >> = > O.K., except that it _defines_ a contiguous range of IP addresses. > = I'm personally OK with this. >> - a subnet is a set of IP addresses (that may or may not be a prefix) >> that are on the same link. All these addresses are then on-link with >> respect to this link. >> = > = > I would greatly prefer to separate the definition of a subnet > from the definition of a link. We should make a subnet a matter > of addressability, not a matter of transmission ranges. In other > words, it's a layer-3 concept, not a layer-2 concept. > = I think that even if it is a layer 3 concept, the definition of subnet should be tied with TTL decrement, and thus to a link. The reasons for this are all the comments from Dave Thaler about the IP service model, and other comments from Thomas Narten about 9.0.0.0/8 being a "subnet" to some people. So I think having a stricter, tying definition about a subnet is actually what we need to get out of this mess, while sticking to what MANET reality is. Don't you think? >> - a link is what L2 provides, which reaches everything within TTL 1 >> beyond a given interface. >> = > = > I agree with this as far as it goes -- at least as a good > starting point. > = > Regards, > Charlie P. > = Great. Let's refine. Emmanuel _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 20 11:35:33 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E51FB28C1B9; Thu, 20 Nov 2008 11:35:33 -0800 (PST) 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 7C42028C1D2 for ; Thu, 20 Nov 2008 11:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.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 jbgNRg8hu5Mj for ; Thu, 20 Nov 2008 11:35:27 -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 26CA528C1B9 for ; Thu, 20 Nov 2008 11:35:27 -0800 (PST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e8.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id mAKJVGnx016101 for ; Thu, 20 Nov 2008 14:31:16 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mAKJZP5h133136 for ; Thu, 20 Nov 2008 14:35:25 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mAKJZ5os024605 for ; Thu, 20 Nov 2008 14:35:05 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-201-183.mts.ibm.com [9.65.201.183]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mAKJZ4Ko024467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 20 Nov 2008 14:35:05 -0500 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id mAKJZMqN011528 for ; Thu, 20 Nov 2008 14:35:22 -0500 Message-Id: <200811201935.mAKJZMqN011528@cichlid.raleigh.ibm.com> To: autoconf@ietf.org Date: Thu, 20 Nov 2008 14:35:22 -0500 From: Thomas Narten Subject: [Autoconf] why were are defining a link model... 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Just a quick reminder, so we don't lose sight of the actual goal of this WG. The reason we have been having this long discussion about the link model, and the reason why I still think it is quite important to get some basic agreement on terminology and architecture is so we can get agreement and a shared understanding of what the actual problem is this WG needs to work on. In the past, we were worlds apart as to what the actual problem was and/or why existing protocols weren't good enough. You can't have a discussion about that if the details of what a MANET is (and is not) are not understood in a consistent manner. Going back to the charter, here are two of original deliverables: > - Develop an IPv6 address autoconfiguration mechanism to be used by ad > hoc nodes for configuring unique local addresses as well as, in cases > where Internet connectivity exists, globally routable unique > addresses. > - Develop a mechanism to promote configured address uniqueness in the > situation where different ad hoc networks merge. When I see the above words, I immediately ask such questions as : - which "ad hoc nodes"? the Routers? the hosts hanging off of them? - what is a ULA as referred to above? addresses that can be used within the MANET that are unique within the MANET? If so, why is it not good enough to use an IPv6 ULA prefix and the MANET router's MAC address to create unique addresses? (hint: the answer almost certainly depends on what assumption one makes about links/subnets) and so forth. Thomas _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 20 12:02:26 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A4A928C27B; Thu, 20 Nov 2008 12:02:26 -0800 (PST) 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 A938D28C234 for ; Thu, 20 Nov 2008 12:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.204 X-Spam-Level: X-Spam-Status: No, score=-1.204 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 6Ps4m1IjHrg9 for ; Thu, 20 Nov 2008 12:02:24 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 75D6B28C27F for ; Thu, 20 Nov 2008 12:02:00 -0800 (PST) Received: (qmail 3314 invoked from network); 20 Nov 2008 21:01:56 +0100 Received: from unknown (HELO M90Teco) (130.129.95.96) by server9.hosting2go.nl with SMTP; 20 Nov 2008 21:01:56 +0100 From: "Teco Boot" To: "'Emmanuel Baccelli'" References: <49259096.7080709@inria.fr> <00a001c94b40$cf06cf90$6d146eb0$@nl> In-Reply-To: Date: Thu, 20 Nov 2008 21:01:21 +0100 Message-ID: <00a701c94b4a$d555e890$8001b9b0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclLRCgiXsQUPN0hT4ycgzfJbFlGtQAAeUrw Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] Subnet definition 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > If we base ourselves on these definitions, = > an address is off-link if it is not on the same subnet, > i.e. not in the set of IP addresses that form this subnet.=A0 > As Thomas Narten pointed out, this set may not be a prefix. = > So being in the same prefix does not necessarily mean being = > on the same subnet. OK. draft-ietf-6man-ipv6-subnet-model-02 (IPv6 Subnet Model: the Relationship between Links and Subnet Prefixes) discusses this. Can we conclude that "IPv6 subnet" equals "IPv6 on-link prefix" equals "IPv6 subnet prefix" as described in this I-D? (I added IPv6 as context qualifier) I had the impression that some intended that a subnet is a set of on-link addresses, which typically would not be contiguous. = Why not using the aliases as above? = If not, post this as issue on the 6man draft? If so, let's follow the 6man draft terminology and use subnet as alias for on-link prefix. Maybe prefer on-link prefix to keep in line with the 6man I-D. >> Somewhat more important: Is a IP addresses within a prefix, = >> that is assigned & configured on an interface, but that is = >> not on-link, part of a subnet? If not, I think somewhat = >> should write this down. 6MAN? > I'm not sure I understand your question. = > Do you mean: if the set of addresses that form a subnet is not a prefix, = > what do you configure the interface with, in terms of prefix? = > If this is correct, I think this is an architectural question, = > that we may want to answer in a second phase. Don't you think? Assumed we use the term subnet for on-link prefix; addresses assigned to interfaces = that have a link with each other, but addresses are off-link, these addresses are not = in the same on-link prefix and thus not in the same subnet. If subnet not equals on-link prefix, I agree answering in a second phase. Teco _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 20 12:02:31 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6771D3A6A22; Thu, 20 Nov 2008 12:02:31 -0800 (PST) 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 5145C28C235 for ; Thu, 20 Nov 2008 12:02:30 -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 KEjVzQpaEZJE for ; Thu, 20 Nov 2008 12:02:29 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id EA65B3A6A04 for ; Thu, 20 Nov 2008 12:02:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ImynN01BSM8FHhqVLznjrbByFrX6q2oXLMttopNhd254Hm7etTo187c4xEDeVonB; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [130.129.28.139] by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L3Fj5-0001tg-J4; Thu, 20 Nov 2008 15:02:07 -0500 Message-ID: <4925C233.50209@earthlink.net> Date: Thu, 20 Nov 2008 12:01:55 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Emmanuel Baccelli References: <49259096.7080709@inria.fr> <4925B886.506@earthlink.net> <4925BAFE.6040109@inria.fr> In-Reply-To: <4925BAFE.6040109@inria.fr> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f524831a153c7f15b5a3372c5f7820fabfe350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.28.139 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Subnet definition 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello Emmanuel, More discussion... Emmanuel Baccelli wrote: > >> I would greatly prefer to separate the definition of a subnet >> from the definition of a link. We should make a subnet a matter >> of addressability, not a matter of transmission ranges. In other >> words, it's a layer-3 concept, not a layer-2 concept. >> >> > > I think that even if it is a layer 3 concept, the definition of subnet > should be tied with TTL decrement, and thus to a link. > > The reasons for this are all the comments from Dave Thaler about the IP > service model, and other comments from Thomas Narten about 9.0.0.0/8 > being a "subnet" to some people. > Well, 9.0.0.0/8 _could_ be a subnet to some people. And I very much believe that "subnet" has to be _strictly_ a layer 3 concept, to be realized in whatever way is determined to be the best way according to the system designers. It could be a subnet realized by GRE over MPEG. There could be tricycles involved. Why should IP care? > So I think having a stricter, tying definition about a subnet is > actually what we need to get out of this mess, while sticking to what > MANET reality is. Don't you think? > What's important about a subnet is reachability from the subnet router. It might even be that the subnet router does not have completely awareness of how the reachability is achieved, if the mechanisms for providing reachability are isolated into auxiliary functional units. So, I don't agree with this suggestion to have a stricter definition. Regards, Charlie P. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 20 12:16:25 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F04933A6BAF; Thu, 20 Nov 2008 12:16:25 -0800 (PST) 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 801DE3A6AF5 for ; Thu, 20 Nov 2008 12:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zj9kHvODkWim for ; Thu, 20 Nov 2008 12:16:23 -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 045B33A6BBE for ; Thu, 20 Nov 2008 12:15:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=D9kuRfElVa3qvrATWgd+xyQ7LUep8yHfdFtMX0/J5g38ms8IByc1UpZxwo/Wg+Fd; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [130.129.28.139] by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L3FwN-0007q4-Kp; Thu, 20 Nov 2008 15:15:51 -0500 Message-ID: <4925C576.6030209@earthlink.net> Date: Thu, 20 Nov 2008 12:15:50 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Thomas Narten References: <4924C84D.5050502@earthlink.net> <200811201439.mAKEdcHG003838@cichlid.raleigh.ibm.com> In-Reply-To: <200811201439.mAKEdcHG003838@cichlid.raleigh.ibm.com> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52259b71916292992bfd15b341a848f8b2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.28.139 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Subnet definition 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello Thomas, Continuing the discussion [thanks for joining in]... Thomas Narten wrote: > I agree that we need a clean definition of subnet. The term is > overloaded and different people have different meanings associated > with it. That has contributed to confusion in the discussions... > Here, I definitely agree. > Note also that I think Erik's observation about "on-link" being a key > issue to also be clear about is correct. > I'm a bit nervous about this one. I can't be comfortable until I know what kind of link is under discussion. > > I'd change that as follows (to highlight the properties that are > important to us): > > A "subnet" is the range of IP addresses that are covered by a > prefix. All that a subnet defines is which addresses are considered to > be on the subnet and which are not. > I definitely agree with this. > > But if one talks to routing folk, a subnet is an abstraction that is > not tied to a physical link. For example, IBM has been assigned net > 9.0.0.0. So, to BGP, 9.0.0.0/8 is a "subnet", even though the actual > network is a huge cloud of thousands of individual networks. > This is a crucial observation, which we should keep in mind throughout the discussion. > > When talking about MANETs, and talking about subnets (or prefixes) we > also have to talk about the on-link properties (or lack thereof). > Here is where I start to get nervous again. > For example, going back to chart 37 of ThomasC's presentation, it may > well make sense to consider the entire cloud of routers to be part of > one subnet, but it does not make sense (I assume) to consider that > same subnet to be "on-link" anywhere within that cloud. I agree with this, but I worry that there is still room for confusion. For instance, what if the entire cloud of routers is NOT part of one subnet, purely for the reason that no one router can be reasonably expected to offer connectivity to the entire cloud? Furthermore, under many reasonable scenarios, we ought to continue to allow for hosts with IP addresses that are NOT part of the subnet prefix to still get service from the cloud. Regards, Charlie P. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 20 13:05:13 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 403853A6831; Thu, 20 Nov 2008 13:05:13 -0800 (PST) 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 52B723A6831 for ; Thu, 20 Nov 2008 13:05:11 -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=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=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 KvAKYw2-GQBz for ; Thu, 20 Nov 2008 13:05:10 -0800 (PST) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.184]) by core3.amsl.com (Postfix) with ESMTP id A3FEC3A677D for ; Thu, 20 Nov 2008 13:05:09 -0800 (PST) Received: by mu-out-0910.google.com with SMTP id w1so588658mue.9 for ; Thu, 20 Nov 2008 13:05:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=evj5IC56feu92rnJZFBoPFOS9SaRZuGbE81A6lb5V1I=; b=GNkGat+Zh55vjL7QZ9BIH0tngg+Wh30XkCbpEWUTmFjB/jXG/ukSGJ8t4n7MnYKPmJ C3Ri4fisNrX89YDGj9yh2wwBtkO9TcPJ/PXJDwUXFDBpcV0wmnmrktvwcHPkyZMti9Ge KwCHzqfGaHE25Py/hTShXMw17u2DL6qH2ychg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=L9lXhV7zxQeubFxtVsXbVYKvtEAwKWifRC7en0QFGKVBTxhzCY9jPc/hLMQ4TOrZyh w6wyz6SHm0rlqGoommPQ/eXyP2B6ZHwY5fbMGQp8QfwTIoJrT44zrQbJnSMt1WuTamGr 2DoGc02hJLjYTycxNwxmvTnjlOHQTnLPZ/Bdo= Received: by 10.181.139.4 with SMTP id r4mr861967bkn.89.1227215106382; Thu, 20 Nov 2008 13:05:06 -0800 (PST) Received: by 10.181.208.13 with HTTP; Thu, 20 Nov 2008 13:05:06 -0800 (PST) Message-ID: Date: Thu, 20 Nov 2008 22:05:06 +0100 From: "Emmanuel Baccelli" To: autoconf@ietf.org In-Reply-To: <4925C233.50209@earthlink.net> MIME-Version: 1.0 References: <49259096.7080709@inria.fr> <4925B886.506@earthlink.net> <4925BAFE.6040109@inria.fr> <4925C233.50209@earthlink.net> X-Google-Sender-Auth: b48b5672150fb54b Subject: Re: [Autoconf] Subnet definition 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: , Content-Type: multipart/mixed; boundary="===============1967163034==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============1967163034== Content-Type: multipart/alternative; boundary="----=_Part_7865_28876137.1227215106388" ------=_Part_7865_28876137.1227215106388 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi again Charlie, > >> I would greatly prefer to separate the definition of a subnet >>> from the definition of a link. We should make a subnet a matter >>> of addressability, not a matter of transmission ranges. In other >>> words, it's a layer-3 concept, not a layer-2 concept. >>> >>> >>> >> >> I think that even if it is a layer 3 concept, the definition of subnet >> should be tied with TTL decrement, and thus to a link. >> >> The reasons for this are all the comments from Dave Thaler about the IP >> service model, and other comments from Thomas Narten about 9.0.0.0/8 >> being a "subnet" to some people. >> >> > > Well, 9.0.0.0/8 _could_ be a subnet to some people. And I very > much believe that "subnet" has to be _strictly_ a layer 3 concept, to be > realized in whatever way is determined to be the best way > according to the system designers. It could be a subnet realized > by GRE over MPEG. There could be tricycles involved. Why > should IP care? > I think I see what you mean. But then what is the difference between a subnet and a prefix? If there is no difference, why do 2 terms exist? If there is a difference, then I think the safest in our context is along the lines we are currently refining, i.e. - a prefix defines a contiguous range of IP addresses. - a subnet is a set of IP addresses (that may or may not be a prefix) that are on the same link. These addresses are then on-link with respect to this link. All other addresses are off-link. - a link is what lower layers reach without TTL decrement, through a given interface. >From what you say, I guess the difference you are trying to make between "subnet" and "prefix" involves routability. However, according to how non-routing people use these terms, both are routable (for example Narten's 9.0.0.0/8 ), and this it is still confusing. Thus I think we really do need stricter definitions that do not involve routing concepts, in order to distinguish the term "subnet" from the term "prefix". Moreover, TTL is a L3 thing. So the definition above is still intrinsically L3, so we are fine in that respect. > > So I think having a stricter, tying definition about a subnet is >> actually what we need to get out of this mess, while sticking to what >> MANET reality is. Don't you think? >> >> > > What's important about a subnet is reachability from the > subnet router. It might even be that the subnet router does > not have completely awareness of how the reachability is > achieved, if the mechanisms for providing reachability > are isolated into auxiliary functional units. > > So, I don't agree with this suggestion to have a stricter > definition. > > > Regards, > Charlie P. > > ------=_Part_7865_28876137.1227215106388 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi again Charlie,



I would greatly prefer to separate the definition of a subnet
from the definition of a link.  We should make a subnet a matter
of addressability, not a matter of transmission ranges.  In other
words, it's a layer-3 concept, not a layer-2 concept.

   

I think that even if it is a layer 3 concept, the definition of subnet
should be tied with TTL decrement, and thus to a link.

The reasons for this are all the comments from Dave Thaler about the IP
service model, and other comments from Thomas Narten about 9.0.0.0/8
being a "subnet" to some people.
 

Well, 9.0.0.0/8  _could_  be a subnet to some people.  And I very
much believe that "subnet" has to be _strictly_ a layer 3 concept, to be
realized in whatever way is determined to be the best way
according to the system designers.  It could be a subnet realized
by GRE over MPEG.  There could be tricycles involved.  Why
should IP care?

I think I see what you mean. But then what is the difference between a subnet and a prefix? If there is no difference, why do 2 terms exist? If there is a difference, then I think the safest in our context is along the lines we are currently refining, i.e.

- a prefix defines a contiguous range of IP addresses.
- a subnet is a set of IP addresses (that may or may not be a prefix)
that are on the same link. These addresses are then on-link with
respect to this link. All other addresses are off-link.
- a link is what lower layers reach without TTL decrement, through a given interface.


From what you say, I guess the difference you are trying to make between "subnet" and "prefix" involves routability. However, according to how non-routing people use these terms, both are routable (for example Narten's 9.0.0.0/8 ), and this it is still confusing. Thus I think we really do need stricter definitions that do not involve routing concepts, in order to distinguish the term "subnet" from the term "prefix".

Moreover, TTL is a L3 thing. So the definition above is still intrinsically L3, so we are fine in that respect.


 

So I think having a stricter, tying definition about a subnet is
actually what we need to get out of this mess, while sticking to what
MANET reality is. Don't you think?
 

What's important about a subnet is reachability from the
subnet router.  It might even be that the subnet router does
not have completely awareness of how the reachability is
achieved, if the mechanisms for providing reachability
are isolated into auxiliary functional units.

So, I don't agree with this suggestion to have a stricter
definition.


Regards,
Charlie P.


------=_Part_7865_28876137.1227215106388-- --===============1967163034== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf --===============1967163034==-- From autoconf-bounces@ietf.org Thu Nov 20 13:14:17 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1BAE3A68A2; Thu, 20 Nov 2008 13:14:17 -0800 (PST) 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 3B0923A68A2 for ; Thu, 20 Nov 2008 13:14:16 -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=[AWL=0.000, 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 PvdHEk0tlwoH for ; Thu, 20 Nov 2008 13:14:15 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.184]) by core3.amsl.com (Postfix) with ESMTP id 05EE13A677D for ; Thu, 20 Nov 2008 13:14:14 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id 18so664817fkq.5 for ; Thu, 20 Nov 2008 13:14:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=LKdcvjb5wLNlbEAzspyayeKtX9Ddt2GV2j0UZleTy0E=; b=p//9jvuIm4uUkg8EH0mUWpcS3MaLVhOL2a+tCQKUqELGh+kj5GBcMg3/UwSTss6b8t SUPv/kNlze9WGIogYQmJZ/NEW73TVpCo0Hzmi3D1NFOrZRhEq5ZGx6RuQH9n55giCXwq seqgKUbLDmL0CMVmVslFUNmo3PQ2QcS2JaOJI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=SwRlvSL3tPRRkHne6T/23MwHjTHVbmcykZ82pwEcI/o9d2BQFWyJ/J4ZAELiDsD/h8 q5aG4rYtkcSLv81sFMGlVZCTfELohlnwcYsAhkkrdpRB60/nnCRk6s1+RR2uLv/Y+lxM aKSc0bAGTMzqgg98dCcZlcCu5UEm3Bow4G05c= Received: by 10.181.10.7 with SMTP id n7mr861563bki.103.1227215653085; Thu, 20 Nov 2008 13:14:13 -0800 (PST) Received: by 10.181.208.13 with HTTP; Thu, 20 Nov 2008 13:14:13 -0800 (PST) Message-ID: Date: Thu, 20 Nov 2008 22:14:13 +0100 From: "Emmanuel Baccelli" To: autoconf@ietf.org In-Reply-To: <200811201935.mAKJZMqN011528@cichlid.raleigh.ibm.com> MIME-Version: 1.0 References: <200811201935.mAKJZMqN011528@cichlid.raleigh.ibm.com> X-Google-Sender-Auth: 5ff6f8de124b7e40 Subject: Re: [Autoconf] why were are defining a link model... 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: , Content-Type: multipart/mixed; boundary="===============1921624597==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============1921624597== Content-Type: multipart/alternative; boundary="----=_Part_7925_497257.1227215653086" ------=_Part_7925_497257.1227215653086 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Thomas, On Thu, Nov 20, 2008 at 8:35 PM, Thomas Narten wrote: > > > When I see the above words, I immediately ask such questions as : > > - which "ad hoc nodes"? the Routers? the hosts hanging off of them? > > - what is a ULA as referred to above? addresses that can be used > within the MANET that are unique within the MANET? If so, why is it > not good enough to use an IPv6 ULA prefix and the MANET router's MAC > address to create unique addresses? (hint: the answer almost > certainly depends on what assumption one makes about links/subnets) > > and so forth. > > Thomas OK. So on this subject, could you actually tell us what you think about the following definitions? - a prefix defines a contiguous range of IP addresses.- a subnet is a set of IP addresses (that may or may not be a prefix) that are on the same link. These addresses are then on-link with respect to this link. All other addresses are off-link. - a link is what lower layers reach without TTL decrement, through a given interface. Do they make sense to you? Or what do you suggest alternatively? cheers Emmanuel ------=_Part_7925_497257.1227215653086 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Thomas,

On Thu, Nov 20, 2008 at 8:35 PM, Thomas Narten <narten@us.ibm.com> wrote:

When I see the above words, I immediately ask such questions as :

- which "ad hoc nodes"? the Routers? the hosts hanging off of them?
 

- what is a ULA as referred to above? addresses that can be used
 within the MANET that are unique within the MANET? If so, why is it
 not good enough to use an IPv6 ULA prefix and the MANET router's MAC
 address to create unique addresses? (hint: the answer almost
 certainly depends on what assumption one makes about links/subnets)

and so forth.

Thomas


OK. So on this subject, could you actually tell us what you think about the following definitions? 

- a prefix defines a contiguous range of IP addresses.
- a subnet is a set of IP addresses (that may or may not be a prefix)
that are on the same link. These addresses are then on-link with
respect to this link. All other addresses are off-link.
- a link is what lower layers reach without TTL decrement, through a given interface.

Do they make sense to you? Or what do you suggest alternatively?

cheers
Emmanuel


 
------=_Part_7925_497257.1227215653086-- --===============1921624597== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf --===============1921624597==-- From autoconf-bounces@ietf.org Thu Nov 20 15:16:11 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFEAF3A6A04; Thu, 20 Nov 2008 15:16:11 -0800 (PST) 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 AC2533A6A04 for ; Thu, 20 Nov 2008 15:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHjUfX3Lxhow for ; Thu, 20 Nov 2008 15:16:10 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 7EB073A6984 for ; Thu, 20 Nov 2008 15:16:09 -0800 (PST) Received: (qmail 5475 invoked from network); 21 Nov 2008 00:16:04 +0100 Received: from unknown (HELO M90Teco) (12.104.246.2) by server9.hosting2go.nl with SMTP; 21 Nov 2008 00:16:04 +0100 From: "Teco Boot" To: Date: Fri, 21 Nov 2008 00:15:58 +0100 Message-ID: <00c801c94b65$f3af1e90$db0d5bb0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclLZfDV4A+SUu8RRTe77WNsYeKjeA== Content-Language: nl x-cr-puzzleid: {BA1A81E2-AE30-4147-801B-D058D875F2BB} x-cr-hashedpuzzle: AoP8 ApR8 CBr0 C2Xl DEoA DH/9 D2hq E/pz FHqB F8bw GtxS HB9U H80w ID8q IbcE IwP9; 1; YQB1AHQAbwBjAG8AbgBmAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {BA1A81E2-AE30-4147-801B-D058D875F2BB}; dABlAGMAbwBAAGkAbgBmAC0AbgBlAHQALgBuAGwA; Thu, 20 Nov 2008 23:15:56 GMT; VAByAHkAIAB0AG8AIABlAGwAaQBtAGkAbgBhAHQAZQAgAHQAZQByAG0AIABzAHUAYgBuAGUAdAA/AA== Subject: [Autoconf] Try to eliminate term subnet? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org All, It seems that the term "subnet" is confusing. So I can agree with Thomas C his draft, title Figure 5: MANET Subnet Challenge I think we make life more easy to get rid of confusing terminology. Has someone a problem not using the term subnet in our documents? We know what prefixes are (entities where we can route to) and what addresses are (endpoint identifiers). Then we can work on the details on IPv6 address assignments, which have IMHO nothing to do with the discussion on the term subnet. Just recap the proposal from Emmanuel, eliminating subnet: - a prefix defines a contiguous range of IP addresses. - a link is what lower layers reach without TTL decrement, through a given interface. In our charter, the term subnet is mentioned a few times: === The address autoconfiguration related protocol specifications such as RFCs 2462, 2461, as used in traditional IP networks, assume that subnet-local signals (e.g. link-local multicast signals) are received by each of the hosts on the particular subnet without being forwarded by the routers defining the subnet boundary. Hence, ad hoc networks (as defined and understood by the IETF MANET WG) cannot use these protocol specifications as-is. === I would read this as: === The address autoconfiguration related protocol specifications such as RFCs 2462, 2461, as used in traditional IP networks, assume that link-local signals (e.g. link-local multicast signals) are received by each of the hosts on the particular medium without being forwarded by the routers defining the medium boundary. Hence, ad hoc networks (as defined and understood by the IETF MANET WG) cannot use these protocol specifications as-is. === 1st subnet -> link 2nd subnet -> medium 3th subnet -> medium RFC4861 says that a link is a medium, which does not apply for RF communication. The description for a link in RFC4861 says link equals medium, but luckily, it does not list RF spectrum as an example. So if we refine our understanding of a link and / or communications facility for RF, we are done. Actually I am writing something down on what service 802.11-2007 provides for the IP layer. Regards, Teco _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 20 15:53:17 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46E5A3A689E; Thu, 20 Nov 2008 15:53:17 -0800 (PST) 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 010F53A68EC for ; Thu, 20 Nov 2008 15:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 UWO6500mkldb for ; Thu, 20 Nov 2008 15:53:13 -0800 (PST) Received: from mxav02.cc.niigata-u.ac.jp (mxav02.cc.niigata-u.ac.jp [133.35.17.130]) by core3.amsl.com (Postfix) with ESMTP id DCCAE3A677D for ; Thu, 20 Nov 2008 15:53:12 -0800 (PST) Received: from mxav02.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DBF6D4541FC for ; Fri, 21 Nov 2008 08:53:02 +0900 (JST) Received: from chamame.ie.niigata-u.ac.jp (chamame.ie.niigata-u.ac.jp [133.35.169.34]) by mxav02.cc.niigata-u.ac.jp (Postfix) with SMTP id D1C95454056 for ; Fri, 21 Nov 2008 08:53:02 +0900 (JST) Received: (qmail 19625 invoked from network); 21 Nov 2008 08:53:02 +0900 Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 21 Nov 2008 08:53:02 +0900 Message-Id: <7.0.0.16.2.20081121085043.03fc1478@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Fri, 21 Nov 2008 08:53:03 +0900 To: "Teco Boot" , From: mase In-Reply-To: <00c801c94b65$f3af1e90$db0d5bb0$@nl> References: <00c801c94b65$f3af1e90$db0d5bb0$@nl> Mime-Version: 1.0 Subject: Re: [Autoconf] Try to eliminate term subnet? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org I strongly agree with not using the term "subnet". As I wrote, I think that subnet only introduces a lot of confusions. Kenichi At 08:15 08/11/21, Teco Boot wrote: >All, > >It seems that the term "subnet" is confusing. >So I can agree with Thomas C his draft, title Figure 5: MANET Subnet >Challenge > >I think we make life more easy to get rid of confusing terminology. >Has someone a problem not using the term subnet in our documents? We know >what prefixes are (entities where we can route to) and what addresses are >(endpoint identifiers). Then we can work on the details on IPv6 address >assignments, which have IMHO nothing to do with the discussion on the term >subnet. > > >Just recap the proposal from Emmanuel, eliminating subnet: >- a prefix defines a contiguous range of IP addresses. >- a link is what lower layers reach without TTL decrement, through a given >interface. > > >In our charter, the term subnet is mentioned a few times: >=== >The address autoconfiguration related protocol specifications such as >RFCs 2462, 2461, as used in traditional IP networks, assume that >subnet-local signals (e.g. link-local multicast signals) are received >by each of the hosts on the particular subnet without being forwarded >by the routers defining the subnet boundary. Hence, ad hoc networks >(as defined and understood by the IETF MANET WG) cannot use these >protocol specifications as-is. >=== > >I would read this as: >=== >The address autoconfiguration related protocol specifications such as >RFCs 2462, 2461, as used in traditional IP networks, assume that >link-local signals (e.g. link-local multicast signals) are received >by each of the hosts on the particular medium without being forwarded >by the routers defining the medium boundary. Hence, ad hoc networks >(as defined and understood by the IETF MANET WG) cannot use these >protocol specifications as-is. >=== >1st subnet -> link >2nd subnet -> medium >3th subnet -> medium > >RFC4861 says that a link is a medium, which does not apply for RF >communication. >The description for a link in RFC4861 says link equals medium, but luckily, >it does not list RF spectrum as an example. >So if we refine our understanding of a link and / or communications facility >for RF, we are done. >Actually I am writing something down on what service 802.11-2007 provides >for the IP layer. > > >Regards, Teco > > > >_______________________________________________ >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 autoconf-bounces@ietf.org Thu Nov 20 16:10:10 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73C773A6873; Thu, 20 Nov 2008 16:10:10 -0800 (PST) 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 928433A6873 for ; Thu, 20 Nov 2008 16:10:08 -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 EK2Hd3JmlGFL for ; Thu, 20 Nov 2008 16:10:07 -0800 (PST) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id 51ABF3A67F0 for ; Thu, 20 Nov 2008 16:10:06 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,639,1220227200"; d="scan'208";a="34149104" Received: from hkg-dkim-2.cisco.com ([10.75.231.163]) by ind-iport-1.cisco.com with ESMTP; 21 Nov 2008 00:09:50 +0000 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAL09nrh019229; Fri, 21 Nov 2008 08:09:49 +0800 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by hkg-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAL09nIC026882; Fri, 21 Nov 2008 00:09:49 GMT Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Nov 2008 08:09:49 +0800 Received: from [130.129.29.177] ([10.75.233.253]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Nov 2008 08:09:48 +0800 Message-Id: <510B2BB1-FC3F-460A-B377-8E6BBBF81F62@cisco.com> From: Ralph Droms To: autoconf@ietf.org In-Reply-To: <7.0.0.16.2.20081121085043.03fc1478@ie.niigata-u.ac.jp> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 20 Nov 2008 19:09:44 -0500 References: <00c801c94b65$f3af1e90$db0d5bb0$@nl> <7.0.0.16.2.20081121085043.03fc1478@ie.niigata-u.ac.jp> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 21 Nov 2008 00:09:48.0569 (UTC) FILETIME=[77880090:01C94B6D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3104; t=1227226189; x=1228090189; c=relaxed/simple; s=hkgdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[Autoconf]=20Try=20to=20eliminate=20ter m=20subnet? |Sender:=20; bh=KXrdQOKWUyXMzkPlEa6n4/LsirtZPvvtsSlCwGEDg34=; b=Pwiazas4W0c3Q74vEf7VlBcgSzjiAVKHnW32/h9MNf8L3ji013C4lvVqnj blokFZ3xu2W9Uj1QQpGbhxf2mCWkgN1LOqUBglp+UldHoF2AG+4eLkdxztIM 4TWrxCPe6pijN7Ug3c+u7Kt9tLMT7cVqH5RlCTV2J3QE2l5PfZ4Lo=; Authentication-Results: hkg-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim2001 verified; ); Subject: Re: [Autoconf] Try to eliminate term subnet? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org +1 "subnet" is overloaded in so many ways. If it is used in a document, it MUST be clearly and carefully defined. - Ralph On Nov 20, 2008, at Nov 20, 2008,6:53 PM, mase wrote: > I strongly agree with not using the term "subnet". As I wrote, I > think that subnet only introduces a lot of confusions. > > Kenichi > > At 08:15 08/11/21, Teco Boot wrote: >> All, >> >> It seems that the term "subnet" is confusing. >> So I can agree with Thomas C his draft, title Figure 5: MANET Subnet >> Challenge >> >> I think we make life more easy to get rid of confusing terminology. >> Has someone a problem not using the term subnet in our documents? >> We know >> what prefixes are (entities where we can route to) and what >> addresses are >> (endpoint identifiers). Then we can work on the details on IPv6 >> address >> assignments, which have IMHO nothing to do with the discussion on >> the term >> subnet. >> >> >> Just recap the proposal from Emmanuel, eliminating subnet: >> - a prefix defines a contiguous range of IP addresses. >> - a link is what lower layers reach without TTL decrement, through >> a given >> interface. >> >> >> In our charter, the term subnet is mentioned a few times: >> === >> The address autoconfiguration related protocol specifications such as >> RFCs 2462, 2461, as used in traditional IP networks, assume that >> subnet-local signals (e.g. link-local multicast signals) are received >> by each of the hosts on the particular subnet without being forwarded >> by the routers defining the subnet boundary. Hence, ad hoc networks >> (as defined and understood by the IETF MANET WG) cannot use these >> protocol specifications as-is. >> === >> >> I would read this as: >> === >> The address autoconfiguration related protocol specifications such as >> RFCs 2462, 2461, as used in traditional IP networks, assume that >> link-local signals (e.g. link-local multicast signals) are received >> by each of the hosts on the particular medium without being forwarded >> by the routers defining the medium boundary. Hence, ad hoc networks >> (as defined and understood by the IETF MANET WG) cannot use these >> protocol specifications as-is. >> === >> 1st subnet -> link >> 2nd subnet -> medium >> 3th subnet -> medium >> >> RFC4861 says that a link is a medium, which does not apply for RF >> communication. >> The description for a link in RFC4861 says link equals medium, but >> luckily, >> it does not list RF spectrum as an example. >> So if we refine our understanding of a link and / or communications >> facility >> for RF, we are done. >> Actually I am writing something down on what service 802.11-2007 >> provides >> for the IP layer. >> >> >> Regards, Teco >> >> >> >> _______________________________________________ >> 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 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 20 16:23:30 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21B673A6873; Thu, 20 Nov 2008 16:23:30 -0800 (PST) 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 05EB43A6873 for ; Thu, 20 Nov 2008 16:23:29 -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 P2x438YgtUJy for ; Thu, 20 Nov 2008 16:23:28 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 0140D3A67F0 for ; Thu, 20 Nov 2008 16:23:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=LIj9FhCgXbjhJRcUxtybKoQkA/Qa9s8y53B2e0/dtWflJJlup1I0REHjg4Pj8uP5; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [130.129.28.139] by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L3Jny-0007ki-HF for autoconf@ietf.org; Thu, 20 Nov 2008 19:23:26 -0500 Message-ID: <4925FF7D.5050900@earthlink.net> Date: Thu, 20 Nov 2008 16:23:25 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: autoconf@ietf.org References: <00c801c94b65$f3af1e90$db0d5bb0$@nl> In-Reply-To: <00c801c94b65$f3af1e90$db0d5bb0$@nl> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5288d0f54b2333c2092244785d6fcd6854350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.28.139 Subject: Re: [Autoconf] Try to eliminate term subnet? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello folks, I am very nervous about not having a definition for the term "subnet" for two reasons: - If we don't define it, we must constantly be on watch to make sure it is not used, and to explain why it is not used. This will be a battle of perpetual weariness. - As difficult as it may be, a subnet would naturally be the unit of address allocation. And, that's what we are tasked with doing in [autoconf]. Of course we could allocate addresses out of some random grab bag of addresses, but I'm willing to bet people would not like that. Besides that, if we're willing to forgo the pleasure of making a subnet map onto a pretend Ethernet, I think it is manageable. We have some candidate definitions that seem to work. Why not go forward with one of them? Regards, Charlie P. Teco Boot wrote: > All, > > It seems that the term "subnet" is confusing. > So I can agree with Thomas C his draft, title Figure 5: MANET Subnet > Challenge > > I think we make life more easy to get rid of confusing terminology. > Has someone a problem not using the term subnet in our documents? We know > what prefixes are (entities where we can route to) and what addresses are > (endpoint identifiers). Then we can work on the details on IPv6 address > assignments, which have IMHO nothing to do with the discussion on the term > subnet. > > > Just recap the proposal from Emmanuel, eliminating subnet: > - a prefix defines a contiguous range of IP addresses. > - a link is what lower layers reach without TTL decrement, through a given > interface. > > > In our charter, the term subnet is mentioned a few times: > === > The address autoconfiguration related protocol specifications such as > RFCs 2462, 2461, as used in traditional IP networks, assume that > subnet-local signals (e.g. link-local multicast signals) are received > by each of the hosts on the particular subnet without being forwarded > by the routers defining the subnet boundary. Hence, ad hoc networks > (as defined and understood by the IETF MANET WG) cannot use these > protocol specifications as-is. > === > > I would read this as: > === > The address autoconfiguration related protocol specifications such as > RFCs 2462, 2461, as used in traditional IP networks, assume that > link-local signals (e.g. link-local multicast signals) are received > by each of the hosts on the particular medium without being forwarded > by the routers defining the medium boundary. Hence, ad hoc networks > (as defined and understood by the IETF MANET WG) cannot use these > protocol specifications as-is. > === > 1st subnet -> link > 2nd subnet -> medium > 3th subnet -> medium > > RFC4861 says that a link is a medium, which does not apply for RF > communication. > The description for a link in RFC4861 says link equals medium, but luckily, > it does not list RF spectrum as an example. > So if we refine our understanding of a link and / or communications facility > for RF, we are done. > Actually I am writing something down on what service 802.11-2007 provides > for the IP layer. > > > Regards, Teco > > > > _______________________________________________ > 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 autoconf-bounces@ietf.org Thu Nov 20 16:43:50 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AC783A6873; Thu, 20 Nov 2008 16:43:50 -0800 (PST) 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 C4D113A6873 for ; Thu, 20 Nov 2008 16:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.489 X-Spam-Level: X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[AWL=1.109, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7m+5Ghoj6BB for ; Thu, 20 Nov 2008 16:43:47 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by core3.amsl.com (Postfix) with ESMTP id 05B563A67F0 for ; Thu, 20 Nov 2008 16:43:46 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id 18so741272fkq.5 for ; Thu, 20 Nov 2008 16:43:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=v6ZbXmKOOq8af2vX/zb0yjpqsIlfMFKrWl8ouf1BYjw=; b=sjKElKV4KjNOEETM2Dh+EjY8yn+8XpAKW+HBJmkUvhg+EJFujQoEm2o8/ZZzZ8ysFA 447BtvH2j3+iyoW0L2Rpw43Nw3Yw06/IIlgOXGYa+AGR97qnIcVXqgGfPKQnl1bQ4T/y 0QkEWUp4gp3ut321v+8rXs9Ga5OJdLgYbuQvk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=QBIUQQflrKI4Qv17RzNrQDe9I6sWXUef081Mv4XYYb1GpqukgTf9/s8JjS8Gu+qds+ KQU9RZ9KvE4wU+2BOjA7SWB1Jb1gQ4a6+7ETtKsn1h5RWcTzwqKm4l0F2So584fyYx3E I1ZVNoq1SVm+Qug1vOxq64uhd6eiIQDxaCsyc= Received: by 10.181.50.1 with SMTP id c1mr1987bkk.3.1227228223782; Thu, 20 Nov 2008 16:43:43 -0800 (PST) Received: by 10.181.208.13 with HTTP; Thu, 20 Nov 2008 16:43:43 -0800 (PST) Message-ID: Date: Fri, 21 Nov 2008 01:43:43 +0100 From: "Emmanuel Baccelli" To: autoconf@ietf.org In-Reply-To: <4925FF7D.5050900@earthlink.net> MIME-Version: 1.0 References: <00c801c94b65$f3af1e90$db0d5bb0$@nl> <4925FF7D.5050900@earthlink.net> Subject: Re: [Autoconf] Try to eliminate term subnet? 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: , Content-Type: multipart/mixed; boundary="===============1800203706==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============1800203706== Content-Type: multipart/alternative; boundary="----=_Part_8447_13621069.1227228223745" ------=_Part_8447_13621069.1227228223745 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree with Charlie. I think we have no choice: we (in autoconf) must unfortunately explain somewhere how we relate to the basic term "subnet", as well as to the terms "prefix", "link" etc.Emmanuel On Fri, Nov 21, 2008 at 1:23 AM, Charles E. Perkins < charles.perkins@earthlink.net> wrote: > > Hello folks, > > I am very nervous about not having a definition for the > term "subnet" for two reasons: > > - If we don't define it, we must constantly be on watch to > make sure it is not used, and to explain why it is not > used. This will be a battle of perpetual weariness. > > - As difficult as it may be, a subnet would naturally be > the unit of address allocation. And, that's what we > are tasked with doing in [autoconf]. Of course we > could allocate addresses out of some random grab > bag of addresses, but I'm willing to bet people would > not like that. > > Besides that, if we're willing to forgo the pleasure of > making a subnet map onto a pretend Ethernet, I think > it is manageable. > > We have some candidate definitions that seem to > work. Why not go forward with one of them? > > Regards, > Charlie P. > > > > Teco Boot wrote: > >> All, >> >> It seems that the term "subnet" is confusing. >> So I can agree with Thomas C his draft, title Figure 5: MANET Subnet >> Challenge >> >> I think we make life more easy to get rid of confusing terminology. >> Has someone a problem not using the term subnet in our documents? We know >> what prefixes are (entities where we can route to) and what addresses are >> (endpoint identifiers). Then we can work on the details on IPv6 address >> assignments, which have IMHO nothing to do with the discussion on the term >> subnet. >> >> >> Just recap the proposal from Emmanuel, eliminating subnet: >> - a prefix defines a contiguous range of IP addresses. >> - a link is what lower layers reach without TTL decrement, through a given >> interface. >> >> >> In our charter, the term subnet is mentioned a few times: >> === >> The address autoconfiguration related protocol specifications such as >> RFCs 2462, 2461, as used in traditional IP networks, assume that >> subnet-local signals (e.g. link-local multicast signals) are received >> by each of the hosts on the particular subnet without being forwarded >> by the routers defining the subnet boundary. Hence, ad hoc networks >> (as defined and understood by the IETF MANET WG) cannot use these >> protocol specifications as-is. >> === >> >> I would read this as: >> === >> The address autoconfiguration related protocol specifications such as >> RFCs 2462, 2461, as used in traditional IP networks, assume that >> link-local signals (e.g. link-local multicast signals) are received >> by each of the hosts on the particular medium without being forwarded >> by the routers defining the medium boundary. Hence, ad hoc networks >> (as defined and understood by the IETF MANET WG) cannot use these >> protocol specifications as-is. >> === >> 1st subnet -> link >> 2nd subnet -> medium >> 3th subnet -> medium >> >> RFC4861 says that a link is a medium, which does not apply for RF >> communication. >> The description for a link in RFC4861 says link equals medium, but >> luckily, >> it does not list RF spectrum as an example. >> So if we refine our understanding of a link and / or communications >> facility >> for RF, we are done. >> Actually I am writing something down on what service 802.11-2007 provides >> for the IP layer. >> >> >> Regards, Teco >> >> >> >> _______________________________________________ >> 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 > ------=_Part_8447_13621069.1227228223745 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree with Charlie. I think we have no choice: we (in autoconf) must unfortunately explain somewhere how we relate to the basic term "subnet", as well as to the terms "prefix", "link" etc.
Emmanuel

On Fri, Nov 21, 2008 at 1:23 AM, Charles E. Perkins <charles.perkins@earthlink.net> wrote:

Hello folks,

I am very nervous about not having a definition for the
term "subnet" for two reasons:

- If we don't define it, we must constantly be on watch to
  make sure it is not used, and to explain why it is not
  used.  This will be a battle of perpetual weariness.

- As difficult as it may be, a subnet would naturally be
  the unit of address allocation.  And, that's what we
  are tasked with doing in [autoconf].  Of course we
  could allocate addresses out of some random grab
  bag of addresses, but I'm willing to bet people would
  not like that.

Besides that, if we're willing to forgo the pleasure of
making a subnet map onto a pretend Ethernet, I think
it is manageable.

We have some candidate definitions that seem to
work.  Why not go forward with one of them?

Regards,
Charlie P.



Teco Boot wrote:
All,

It seems that the term "subnet" is confusing.
So I can agree with Thomas C his draft, title Figure 5: MANET Subnet
Challenge

I think we make life more easy to get rid of confusing terminology.
Has someone a problem not using the term subnet in our documents? We know
what prefixes are (entities where we can route to) and what addresses are
(endpoint identifiers). Then we can work on the details on IPv6 address
assignments, which have IMHO nothing to do with the discussion on the term
subnet.


Just recap the proposal from Emmanuel, eliminating subnet:
- a prefix defines a contiguous range of IP addresses.
- a link is what lower layers reach without TTL decrement, through a given
interface.


In our charter, the term subnet is mentioned a few times:
===
The address autoconfiguration related protocol specifications such as
RFCs 2462, 2461, as used in traditional IP networks, assume that
subnet-local signals (e.g. link-local multicast signals) are received
by each of the hosts on the particular subnet without being forwarded
by the routers defining the subnet boundary. Hence, ad hoc networks
(as defined and understood by the IETF MANET WG) cannot use these
protocol specifications as-is.
===

I would read this as:
===
The address autoconfiguration related protocol specifications such as
RFCs 2462, 2461, as used in traditional IP networks, assume that
link-local signals (e.g. link-local multicast signals) are received
by each of the hosts on the particular medium without being forwarded
by the routers defining the medium boundary. Hence, ad hoc networks
(as defined and understood by the IETF MANET WG) cannot use these
protocol specifications as-is.
===
1st subnet -> link
2nd subnet -> medium
3th subnet -> medium

RFC4861 says that a link is a medium, which does not apply for RF
communication.
The description for a link in RFC4861 says link equals medium, but luckily,
it does not list RF spectrum as an example.
So if we refine our understanding of a link and / or communications facility
for RF, we are done.
Actually I am writing something down on what service 802.11-2007 provides
for the IP layer.


Regards, Teco



_______________________________________________
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

------=_Part_8447_13621069.1227228223745-- --===============1800203706== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf --===============1800203706==-- From autoconf-bounces@ietf.org Thu Nov 20 16:49:37 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFE793A6898; Thu, 20 Nov 2008 16:49:37 -0800 (PST) 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 4A6A23A6898 for ; Thu, 20 Nov 2008 16:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTF3medEYnXg for ; Thu, 20 Nov 2008 16:49:36 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.191]) by core3.amsl.com (Postfix) with ESMTP id 732593A6873 for ; Thu, 20 Nov 2008 16:49:35 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id 18so743238fkq.5 for ; Thu, 20 Nov 2008 16:49:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=x6gSNHfhns7359/rQGvykeY7wFHQYyrilvGvGXLWtQc=; b=vpLxI3qRcNMSR67ASgSf6guLLiFqnKFowtU3m06catS6TKiuGcKZREuXX26qY2sECA cZVjVbh1Mgd64Q/7GgG74/p8M2mNU/No+Yefvb+GT8wJ8d6gqMQ6qhGLK7XV25SFP4MM giRkMDnQjBFbQppptM7rRZQdV3EC2s95mV7+s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=wYs7dN+MoE8KT68MdHkMQFZjGWdtUQ/QEd7IN/s7ej9qO97xCfP32F4C8udE1sKR1c g0pwYnC3IRGSoUbHbVPKqCcS3gYNmMcF/8D5npOOYlHD3Umvb/6PjShcjt1Gq1QGNvv/ +L4HC6mZwzl328v1feIZwqmlGCRYDpt53muHQ= Received: by 10.181.52.14 with SMTP id e14mr4113bkk.99.1227228572353; Thu, 20 Nov 2008 16:49:32 -0800 (PST) Received: by 10.181.208.13 with HTTP; Thu, 20 Nov 2008 16:49:32 -0800 (PST) Message-ID: Date: Fri, 21 Nov 2008 01:49:32 +0100 From: "Emmanuel Baccelli" To: autoconf@ietf.org In-Reply-To: MIME-Version: 1.0 References: <00c801c94b65$f3af1e90$db0d5bb0$@nl> <4925FF7D.5050900@earthlink.net> Subject: Re: [Autoconf] Try to eliminate term subnet? 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: , Content-Type: multipart/mixed; boundary="===============0458225607==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============0458225607== Content-Type: multipart/alternative; boundary="----=_Part_8474_841075.1227228572318" ------=_Part_8474_841075.1227228572318 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline That said, once properly defined in our context, we may not use the concept as much as elsewhere...Emmanuel On Fri, Nov 21, 2008 at 1:43 AM, Emmanuel Baccelli < emmanuel.baccelli@gmail.com> wrote: > I agree with Charlie. I think we have no choice: we (in autoconf) must > unfortunately explain somewhere how we relate to the basic term "subnet", as > well as to the terms "prefix", "link" etc. Emmanuel > > > On Fri, Nov 21, 2008 at 1:23 AM, Charles E. Perkins < > charles.perkins@earthlink.net> wrote: > >> >> Hello folks, >> >> I am very nervous about not having a definition for the >> term "subnet" for two reasons: >> >> - If we don't define it, we must constantly be on watch to >> make sure it is not used, and to explain why it is not >> used. This will be a battle of perpetual weariness. >> >> - As difficult as it may be, a subnet would naturally be >> the unit of address allocation. And, that's what we >> are tasked with doing in [autoconf]. Of course we >> could allocate addresses out of some random grab >> bag of addresses, but I'm willing to bet people would >> not like that. >> >> Besides that, if we're willing to forgo the pleasure of >> making a subnet map onto a pretend Ethernet, I think >> it is manageable. >> >> We have some candidate definitions that seem to >> work. Why not go forward with one of them? >> >> Regards, >> Charlie P. >> >> >> >> Teco Boot wrote: >> >>> All, >>> >>> It seems that the term "subnet" is confusing. >>> So I can agree with Thomas C his draft, title Figure 5: MANET Subnet >>> Challenge >>> >>> I think we make life more easy to get rid of confusing terminology. >>> Has someone a problem not using the term subnet in our documents? We know >>> what prefixes are (entities where we can route to) and what addresses are >>> (endpoint identifiers). Then we can work on the details on IPv6 address >>> assignments, which have IMHO nothing to do with the discussion on the >>> term >>> subnet. >>> >>> >>> Just recap the proposal from Emmanuel, eliminating subnet: >>> - a prefix defines a contiguous range of IP addresses. >>> - a link is what lower layers reach without TTL decrement, through a >>> given >>> interface. >>> >>> >>> In our charter, the term subnet is mentioned a few times: >>> === >>> The address autoconfiguration related protocol specifications such as >>> RFCs 2462, 2461, as used in traditional IP networks, assume that >>> subnet-local signals (e.g. link-local multicast signals) are received >>> by each of the hosts on the particular subnet without being forwarded >>> by the routers defining the subnet boundary. Hence, ad hoc networks >>> (as defined and understood by the IETF MANET WG) cannot use these >>> protocol specifications as-is. >>> === >>> >>> I would read this as: >>> === >>> The address autoconfiguration related protocol specifications such as >>> RFCs 2462, 2461, as used in traditional IP networks, assume that >>> link-local signals (e.g. link-local multicast signals) are received >>> by each of the hosts on the particular medium without being forwarded >>> by the routers defining the medium boundary. Hence, ad hoc networks >>> (as defined and understood by the IETF MANET WG) cannot use these >>> protocol specifications as-is. >>> === >>> 1st subnet -> link >>> 2nd subnet -> medium >>> 3th subnet -> medium >>> >>> RFC4861 says that a link is a medium, which does not apply for RF >>> communication. >>> The description for a link in RFC4861 says link equals medium, but >>> luckily, >>> it does not list RF spectrum as an example. >>> So if we refine our understanding of a link and / or communications >>> facility >>> for RF, we are done. >>> Actually I am writing something down on what service 802.11-2007 provides >>> for the IP layer. >>> >>> >>> Regards, Teco >>> >>> >>> >>> _______________________________________________ >>> 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 >> > > ------=_Part_8474_841075.1227228572318 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline That said, once properly defined in our context, we may not use the concept as much as elsewhere...
Emmanuel

On Fri, Nov 21, 2008 at 1:43 AM, Emmanuel Baccelli <emmanuel.baccelli@gmail.com> wrote:
I agree with Charlie. I think we have no choice: we (in autoconf) must unfortunately explain somewhere how we relate to the basic term "subnet", as well as to the terms "prefix", "link" etc.
Emmanuel


On Fri, Nov 21, 2008 at 1:23 AM, Charles E. Perkins <charles.perkins@earthlink.net> wrote:

Hello folks,

I am very nervous about not having a definition for the
term "subnet" for two reasons:

- If we don't define it, we must constantly be on watch to
  make sure it is not used, and to explain why it is not
  used.  This will be a battle of perpetual weariness.

- As difficult as it may be, a subnet would naturally be
  the unit of address allocation.  And, that's what we
  are tasked with doing in [autoconf].  Of course we
  could allocate addresses out of some random grab
  bag of addresses, but I'm willing to bet people would
  not like that.

Besides that, if we're willing to forgo the pleasure of
making a subnet map onto a pretend Ethernet, I think
it is manageable.

We have some candidate definitions that seem to
work.  Why not go forward with one of them?

Regards,
Charlie P.



Teco Boot wrote:
All,

It seems that the term "subnet" is confusing.
So I can agree with Thomas C his draft, title Figure 5: MANET Subnet
Challenge

I think we make life more easy to get rid of confusing terminology.
Has someone a problem not using the term subnet in our documents? We know
what prefixes are (entities where we can route to) and what addresses are
(endpoint identifiers). Then we can work on the details on IPv6 address
assignments, which have IMHO nothing to do with the discussion on the term
subnet.


Just recap the proposal from Emmanuel, eliminating subnet:
- a prefix defines a contiguous range of IP addresses.
- a link is what lower layers reach without TTL decrement, through a given
interface.


In our charter, the term subnet is mentioned a few times:
===
The address autoconfiguration related protocol specifications such as
RFCs 2462, 2461, as used in traditional IP networks, assume that
subnet-local signals (e.g. link-local multicast signals) are received
by each of the hosts on the particular subnet without being forwarded
by the routers defining the subnet boundary. Hence, ad hoc networks
(as defined and understood by the IETF MANET WG) cannot use these
protocol specifications as-is.
===

I would read this as:
===
The address autoconfiguration related protocol specifications such as
RFCs 2462, 2461, as used in traditional IP networks, assume that
link-local signals (e.g. link-local multicast signals) are received
by each of the hosts on the particular medium without being forwarded
by the routers defining the medium boundary. Hence, ad hoc networks
(as defined and understood by the IETF MANET WG) cannot use these
protocol specifications as-is.
===
1st subnet -> link
2nd subnet -> medium
3th subnet -> medium

RFC4861 says that a link is a medium, which does not apply for RF
communication.
The description for a link in RFC4861 says link equals medium, but luckily,
it does not list RF spectrum as an example.
So if we refine our understanding of a link and / or communications facility
for RF, we are done.
Actually I am writing something down on what service 802.11-2007 provides
for the IP layer.


Regards, Teco



_______________________________________________
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


------=_Part_8474_841075.1227228572318-- --===============0458225607== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf --===============0458225607==-- From autoconf-bounces@ietf.org Thu Nov 20 16:56:43 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B7173A68F1; Thu, 20 Nov 2008 16:56:43 -0800 (PST) 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 0A4023A68F1 for ; Thu, 20 Nov 2008 16:56:42 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcnanVdwE4uw for ; Thu, 20 Nov 2008 16:56:35 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 56C153A68BD for ; Thu, 20 Nov 2008 16:56:33 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id mAL0u4ID009121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2008 16:56:09 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id mAL0u4Nc006383; Thu, 20 Nov 2008 16:56:04 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id mAL0u3Nu006350; Thu, 20 Nov 2008 16:56:04 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Nov 2008 16:56:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 16:56:01 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1053EF3CF@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Try to eliminate term subnet? Thread-Index: AclLcwg4JQ2AqMvUShC52g8EpYE5AgAAL5pw References: <00c801c94b65$f3af1e90$db0d5bb0$@nl><4925FF7D.5050900@earthlink.net> From: "Templin, Fred L" To: "Emmanuel Baccelli" , X-OriginalArrivalTime: 21 Nov 2008 00:56:02.0448 (UTC) FILETIME=[ECE45900:01C94B73] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-5.500.1027-16290.000 X-TM-AS-Result: No--27.010100-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: [Autoconf] Try to eliminate term subnet? 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: , Content-Type: multipart/mixed; boundary="===============0666775108==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0666775108== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C94B73.ECA6E5E0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C94B73.ECA6E5E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > That said, once properly defined in our context, we may not use the concept as much as elsewhere... =20 Then, why bother saying it? Less is more... =20 Fred fred.l.templin@boeing.com =20 ________________________________ From: Emmanuel Baccelli [mailto:emmanuel.baccelli@gmail.com]=20 Sent: Thursday, November 20, 2008 4:50 PM To: autoconf@ietf.org Subject: Re: [Autoconf] Try to eliminate term subnet? =20 That said, once properly defined in our context, we may not use the concept as much as elsewhere... Emmanuel On Fri, Nov 21, 2008 at 1:43 AM, Emmanuel Baccelli wrote: I agree with Charlie. I think we have no choice: we (in autoconf) must unfortunately explain somewhere how we relate to the basic term "subnet", as well as to the terms "prefix", "link" etc. Emmanuel =20 On Fri, Nov 21, 2008 at 1:23 AM, Charles E. Perkins wrote: Hello folks, I am very nervous about not having a definition for the term "subnet" for two reasons: - If we don't define it, we must constantly be on watch to make sure it is not used, and to explain why it is not used. This will be a battle of perpetual weariness. - As difficult as it may be, a subnet would naturally be the unit of address allocation. And, that's what we are tasked with doing in [autoconf]. Of course we could allocate addresses out of some random grab bag of addresses, but I'm willing to bet people would not like that. Besides that, if we're willing to forgo the pleasure of making a subnet map onto a pretend Ethernet, I think it is manageable. We have some candidate definitions that seem to work. Why not go forward with one of them? Regards, Charlie P. Teco Boot wrote: All, It seems that the term "subnet" is confusing. So I can agree with Thomas C his draft, title Figure 5: MANET Subnet Challenge I think we make life more easy to get rid of confusing terminology. Has someone a problem not using the term subnet in our documents? We know what prefixes are (entities where we can route to) and what addresses are (endpoint identifiers). Then we can work on the details on IPv6 address assignments, which have IMHO nothing to do with the discussion on the term subnet. Just recap the proposal from Emmanuel, eliminating subnet: - a prefix defines a contiguous range of IP addresses. - a link is what lower layers reach without TTL decrement, through a given interface. In our charter, the term subnet is mentioned a few times: =3D=3D=3D The address autoconfiguration related protocol specifications such as RFCs 2462, 2461, as used in traditional IP networks, assume that subnet-local signals (e.g. link-local multicast signals) are received by each of the hosts on the particular subnet without being forwarded by the routers defining the subnet boundary. Hence, ad hoc networks (as defined and understood by the IETF MANET WG) cannot use these protocol specifications as-is. =3D=3D=3D I would read this as: =3D=3D=3D The address autoconfiguration related protocol specifications such as RFCs 2462, 2461, as used in traditional IP networks, assume that link-local signals (e.g. link-local multicast signals) are received by each of the hosts on the particular medium without being forwarded by the routers defining the medium boundary. Hence, ad hoc networks (as defined and understood by the IETF MANET WG) cannot use these protocol specifications as-is. =3D=3D=3D 1st subnet -> link 2nd subnet -> medium 3th subnet -> medium RFC4861 says that a link is a medium, which does not apply for RF communication. The description for a link in RFC4861 says link equals medium, but luckily, it does not list RF spectrum as an example. So if we refine our understanding of a link and / or communications facility for RF, we are done. Actually I am writing something down on what service 802.11-2007 provides for the IP layer. Regards, Teco _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf =20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf =20 =20 ------_=_NextPart_001_01C94B73.ECA6E5E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> That said, once properly defined in our context, we may not = use the concept as much as elsewhere...

 

Then, why bother saying it? Less is = more…

 

Fred

fred.l.templin@boeing.com

 

From: = Emmanuel Baccelli [mailto:emmanuel.baccelli@gmail.com]
Sent: Thursday, November = 20, 2008 4:50 PM
To: autoconf@ietf.org
Subject: Re: [Autoconf] = Try to eliminate term subnet?

 

That said, once properly defined in our context, we may not use = the concept as much as elsewhere...

Emmanuel

On Fri, Nov 21, 2008 at 1:43 AM, Emmanuel Baccelli <emmanuel.baccelli@gmail.com> wrote:

I agree with Charlie. I think we have no choice: we (in = autoconf) must unfortunately explain somewhere how we relate to the basic term "subnet", as well as to the terms "prefix", "link" etc.

Emmanuel

 

On Fri, Nov 21, 2008 at 1:23 AM, Charles E. Perkins <charles.perkins@earthlink.net> wrote:


Hello folks,

I am very nervous about not having a definition for the
term "subnet" for two reasons:

- If we don't define it, we must constantly be on watch to
  make sure it is not used, and to explain why it is not
  used.  This will be a battle of perpetual weariness.

- As difficult as it may be, a subnet would naturally be
  the unit of address allocation.  And, that's what we
  are tasked with doing in [autoconf].  Of course we
  could allocate addresses out of some random grab
  bag of addresses, but I'm willing to bet people would
  not like that.

Besides that, if we're willing to forgo the pleasure of
making a subnet map onto a pretend Ethernet, I think
it is manageable.

We have some candidate definitions that seem to
work.  Why not go forward with one of them?

Regards,
Charlie P.




Teco Boot wrote:

All,

It seems that the term "subnet" is confusing.
So I can agree with Thomas C his draft, title Figure 5: MANET Subnet
Challenge

I think we make life more easy to get rid of confusing terminology.
Has someone a problem not using the term subnet in our documents? We = know
what prefixes are (entities where we can route to) and what addresses = are
(endpoint identifiers). Then we can work on the details on IPv6 = address
assignments, which have IMHO nothing to do with the discussion on the = term
subnet.


Just recap the proposal from Emmanuel, eliminating subnet:
- a prefix defines a contiguous range of IP addresses.
- a link is what lower layers reach without TTL decrement, through a = given
interface.


In our charter, the term subnet is mentioned a few times:
=3D=3D=3D
The address autoconfiguration related protocol specifications such = as
RFCs 2462, 2461, as used in traditional IP networks, assume that
subnet-local signals (e.g. link-local multicast signals) are = received
by each of the hosts on the particular subnet without being = forwarded
by the routers defining the subnet boundary. Hence, ad hoc networks
(as defined and understood by the IETF MANET WG) cannot use these
protocol specifications as-is.
=3D=3D=3D

I would read this as:
=3D=3D=3D
The address autoconfiguration related protocol specifications such = as
RFCs 2462, 2461, as used in traditional IP networks, assume that
link-local signals (e.g. link-local multicast signals) are received
by each of the hosts on the particular medium without being = forwarded
by the routers defining the medium boundary. Hence, ad hoc networks
(as defined and understood by the IETF MANET WG) cannot use these
protocol specifications as-is.
=3D=3D=3D
1st subnet -> link
2nd subnet -> medium
3th subnet -> medium

RFC4861 says that a link is a medium, which does not apply for RF
communication.
The description for a link in RFC4861 says link equals medium, but = luckily,
it does not list RF spectrum as an example.
So if we refine our understanding of a link and / or communications = facility
for RF, we are done.
Actually I am writing something down on what service 802.11-2007 = provides
for the IP layer.


Regards, Teco



_______________________________________________
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=

 

 

------_=_NextPart_001_01C94B73.ECA6E5E0-- --===============0666775108== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf --===============0666775108==-- From autoconf-bounces@ietf.org Thu Nov 20 17:43:11 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2A723A68EC; Thu, 20 Nov 2008 17:43:11 -0800 (PST) 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 A8D943A68EC for ; Thu, 20 Nov 2008 17:43:09 -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 JQ3zJ0rTmpvk for ; Thu, 20 Nov 2008 17:43:08 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id CA7D33A689E for ; Thu, 20 Nov 2008 17:43:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=XjYEVA/2FMcVnuaiCoj0ZOB+9B2+fLpEAlb27HuyKNddp1kMZNSkjpItMnX/HJ/c; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [130.129.28.139] by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L3L35-0001pv-Cx; Thu, 20 Nov 2008 20:43:07 -0500 Message-ID: <4926122A.4000501@earthlink.net> Date: Thu, 20 Nov 2008 17:43:06 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "Templin, Fred L" References: <00c801c94b65$f3af1e90$db0d5bb0$@nl><4925FF7D.5050900@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A1053EF3CF@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1053EF3CF@XCH-NW-7V2.nw.nos.boeing.com> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f524dbe1c3f5b65da119830ff63ffaf7bc8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.28.139 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Try to eliminate term subnet? 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: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello Fred, Templin, Fred L wrote: > > > That said, once properly defined in our context, we may not use the = > concept as much as elsewhere... > > Then, why bother saying it? Less is more=85 > But, you didn't respond to the two points I had raised in my email... namely: > > - If we don't define it, we must constantly be on watch to > make sure it is not used, and to explain why it is not > used. This will be a battle of perpetual weariness. > > - As difficult as it may be, a subnet would naturally be > the unit of address allocation. And, that's what we > are tasked with doing in [autoconf]. Of course we > could allocate addresses out of some random grab > bag of addresses, but I'm willing to bet people would > not like that. Regards, Charlie P. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 20 19:48:05 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A391C3A67C0; Thu, 20 Nov 2008 19:48:05 -0800 (PST) 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 19F6E3A67C0 for ; Thu, 20 Nov 2008 19:48:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wn9uW6cCDg6i for ; Thu, 20 Nov 2008 19:48:04 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 2D52D3A635F for ; Thu, 20 Nov 2008 19:48:02 -0800 (PST) Received: (qmail 18478 invoked from network); 21 Nov 2008 04:47:57 +0100 Received: from unknown (HELO M90Teco) (12.104.246.2) by server9.hosting2go.nl with SMTP; 21 Nov 2008 04:47:57 +0100 From: "Teco Boot" To: "'Charles E. Perkins'" , "'Templin, Fred L'" References: <00c801c94b65$f3af1e90$db0d5bb0$@nl><4925FF7D.5050900@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A1053EF3CF@XCH-NW-7V2.nw.nos.boeing.com> <4926122A.4000501@earthlink.net> In-Reply-To: <4926122A.4000501@earthlink.net> Date: Fri, 21 Nov 2008 04:47:52 +0100 Message-ID: <00db01c94b8b$eed566b0$cc803410$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclLeocDGNtqIGxMSiWYxoocmBEd1wADaCSw Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] Try to eliminate term subnet? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > > - If we don't define it, we must constantly be on watch to > > make sure it is not used, and to explain why it is not > > used. This will be a battle of perpetual weariness. We can describe that subnet is not well defined and therefore we prefer less confusing terminology. I think if we try to define it, and fail, that this will be a battle of perpetual weariness Moreover, I prefer leaving this task for the 6man wg. > > - As difficult as it may be, a subnet would naturally be > > the unit of address allocation. And, that's what we > > are tasked with doing in [autoconf]. Of course we > > could allocate addresses out of some random grab > > bag of addresses, but I'm willing to bet people would > > not like that. I think we should use prefix delegation instead of "subnet address allocation". For now I do not see any reason not using DHCPv6-PD. And maybe use DHCPv6 for the counterpart of stateless address autoconfiguration (not using the quite confusing wording of "stateful configuration", see RFC4862). Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 20 20:37:07 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5348E3A6A6D; Thu, 20 Nov 2008 20:37:07 -0800 (PST) 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 C418828C14A for ; Thu, 20 Nov 2008 20:37:05 -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=[AWL=0.000, 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 sKuWqaW1j1QS for ; Thu, 20 Nov 2008 20:37:05 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id EF75C3A6922 for ; Thu, 20 Nov 2008 20:37:04 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id mAL4alBW008020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2008 20:36:52 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id mAL4alfQ005984; Thu, 20 Nov 2008 20:36:47 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id mAL4aku3005981; Thu, 20 Nov 2008 20:36:46 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Nov 2008 20:36:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 20:36:44 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1053EF41B@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <4926122A.4000501@earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Try to eliminate term subnet? Thread-Index: AclLeoG+U898ZPT3SVmH0zYdtlzTrAAFExmw References: <00c801c94b65$f3af1e90$db0d5bb0$@nl><4925FF7D.5050900@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A1053EF3CF@XCH-NW-7V2.nw.nos.boeing.com> <4926122A.4000501@earthlink.net> From: "Templin, Fred L" To: "Charles E. Perkins" X-OriginalArrivalTime: 21 Nov 2008 04:36:46.0222 (UTC) FILETIME=[C2CBE2E0:01C94B92] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-5.500.1027-16292.000 X-TM-AS-Result: No--15.260300-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: autoconf@ietf.org Subject: Re: [Autoconf] Try to eliminate term subnet? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Charlie, >-----Original Message----- >From: Charles E. Perkins [mailto:charles.perkins@earthlink.net] >Sent: Thursday, November 20, 2008 5:43 PM >To: Templin, Fred L >Cc: autoconf@ietf.org >Subject: Re: [Autoconf] Try to eliminate term subnet? > > >Hello Fred, > >Templin, Fred L wrote: >> >> > That said, once properly defined in our context, we may not use the >> concept as much as elsewhere... >> >> Then, why bother saying it? Less is more... >> > >But, you didn't respond to the two points I had >raised in my email... namely: OK, since you insist. Let's consider bringing the more addressing-neutral term "subnetwork" into the terminology, where a subnetwork is a connected routing region within a MANET, and the MANET may contain many such subnetworks. We then need a way of identifying each subnetwork, and traditional approaches would call for assigning an address/prefix on a subnetwork interface, where the prefix is shorter than /32 (IPv4) or /128 (IPv6). But, we already know that that is problematic for MANETs, since the subnetwork can split (half going to partition A and the other half going to partition B) and then mayhem ensues in a number of ways. So, let's instead have all routers in the subnetwork configure a common "subnet router anycast" address taken from a common IP prefix, but without assigning any addresses from the prefix to a MANET interface. So for example, we could assign the IPv6 prefix: "2001:DB8:1:2::/64" to a subnetwork, and each MANET router in the subnetwork assigns the IPv6 subnet router anycast address "2001:DB8:1:2::" to its loopback interface. So, no MANET routers in the subnetwork have a unicast IPv6 address assignment from the prefix, but all MANET routers have the subnet router anycast address on their loopbacks. The routers can retain the anycast address even if the subnetwork partitions and keep it for as long as it still makes sense for them to retain membership to that subnetwork. If they want to join other subnetworks too, that's OK - they just configure additional subnet router anycast addresses. We can now happily ping toward the subnet router anycast address from anywhere, and the nearest MANET router will answer us back. I call it the "no-subnet subnetwork model", but I don't mind if we end up calling it something else. Fred fred.l.templin@boeing.com >> - If we don't define it, we must constantly be on watch to >> make sure it is not used, and to explain why it is not >> used. This will be a battle of perpetual weariness. >> >> - As difficult as it may be, a subnet would naturally be >> the unit of address allocation. And, that's what we >> are tasked with doing in [autoconf]. Of course we >> could allocate addresses out of some random grab >> bag of addresses, but I'm willing to bet people would >> not like that. > > >Regards, >Charlie P. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 20 21:30:17 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A25293A6A9B; Thu, 20 Nov 2008 21:30:17 -0800 (PST) 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 1709B3A6A99 for ; Thu, 20 Nov 2008 21:30:16 -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 HY53rZPcgLku for ; Thu, 20 Nov 2008 21:30:15 -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 49CF03A6A92 for ; Thu, 20 Nov 2008 21:30:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=eF8Xsbc7yJmDMhjgBk18VaCO0mTP2uiHpK5QpjjdWOY5N1XYO17GoPG2fOpXmtJ7; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [130.129.78.128] by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L3Oaq-0005aO-Oy; Fri, 21 Nov 2008 00:30:12 -0500 Message-ID: <49264763.9030401@earthlink.net> Date: Thu, 20 Nov 2008 21:30:11 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "Templin, Fred L" References: <00c801c94b65$f3af1e90$db0d5bb0$@nl><4925FF7D.5050900@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A1053EF3CF@XCH-NW-7V2.nw.nos.boeing.com> <4926122A.4000501@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A1053EF41B@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1053EF41B@XCH-NW-7V2.nw.nos.boeing.com> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f522b4f854a2a749b5b8ef904aca0b9a13c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.78.128 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Try to eliminate term subnet? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello Fred, From your discussion, I don't see your concern, or where we should make any modification to avoid difficulties. More inline... Templin, Fred L wrote: > > Let's consider bringing the more > addressing-neutral term "subnetwork" into the terminology, > where a subnetwork is a connected routing region within a > MANET, and the MANET may contain many such subnetworks. > Here, one key operative word is "may"... Or, the MANET may not contain subnetworks. > We then need a way of identifying each subnetwork, and > traditional approaches would call for assigning an > address/prefix on a subnetwork interface, where the > prefix is shorter than /32 (IPv4) or /128 (IPv6). Check. But, again keeping in mind this is specific to the needs of the network. > But, > we already know that that is problematic for MANETs, > since the subnetwork can split (half going to partition > A and the other half going to partition B) and then > mayhem ensues in a number of ways. > If this happens, the subnet is broken. In real life, subnets can break. Then people wonder what happened. It could be that it would be more frequent in a MANET. But: (a) we _could_ have a MANET without any proper subnetworks (b) there are cases where a stable subnet would exist. > So, let's instead have all routers in the subnetwork > configure a common "subnet router anycast" address > taken from a common IP prefix, but without assigning > any addresses from the prefix to a MANET interface. > So for example, we could assign the IPv6 prefix: > "2001:DB8:1:2::/64" to a subnetwork, and each MANET > router in the subnetwork assigns the IPv6 subnet router > anycast address "2001:DB8:1:2::" to its loopback > interface. > > So, no MANET routers in the subnetwork have a unicast > IPv6 address assignment from the prefix, but all MANET > routers have the subnet router anycast address on their > loopbacks. The routers can retain the anycast address > even if the subnetwork partitions and keep it for as > long as it still makes sense for them to retain > membership to that subnetwork. If they want to join > other subnetworks too, that's OK - they just configure > additional subnet router anycast addresses. > > We can now happily ping toward the subnet router anycast > address from anywhere, and the nearest MANET router will > answer us back. I call it the "no-subnet subnetwork model", > but I don't mind if we end up calling it something else. > Here, I am in the dark about why you would do this. For one thing, if you have two different routers serving the same subnet, they basically have to provide reachability to the same hosts. I do not see how you are doing this. Unless of course there are no hosts on the subnetwork. In which case, perhaps the conditions are all satisfied vacuously. In that case, it may be an interesting technical exercise, but I don't see where it is guiding us, nor where it causes the definitions to fail. > > >>> - If we don't define it, we must constantly be on watch to >>> make sure it is not used, and to explain why it is not >>> used. This will be a battle of perpetual weariness. >>> >>> - As difficult as it may be, a subnet would naturally be >>> the unit of address allocation. And, that's what we >>> are tasked with doing in [autoconf]. Of course we >>> could allocate addresses out of some random grab >>> bag of addresses, but I'm willing to bet people would >>> not like that. >>> I also do not see how it answers the two concerns I raised. Regards, Charlie P. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 20 21:37:06 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C73903A6828; Thu, 20 Nov 2008 21:37:06 -0800 (PST) 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 1A4903A6828 for ; Thu, 20 Nov 2008 21:37: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=[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 2E0XSRlCuMWh for ; Thu, 20 Nov 2008 21:37:05 -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 3263C3A67EE for ; Thu, 20 Nov 2008 21:37:05 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=kouj2NxHJyhgSfCuz+ARp/8HhKLlUaxXsnuDGTAU/faTad7exdbjB9diwExcS32z; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [130.129.78.128] by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L3OhT-0001VQ-9w; Fri, 21 Nov 2008 00:37:03 -0500 Message-ID: <492648FD.8060004@earthlink.net> Date: Thu, 20 Nov 2008 21:37:01 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Teco Boot References: <00c801c94b65$f3af1e90$db0d5bb0$@nl><4925FF7D.5050900@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A1053EF3CF@XCH-NW-7V2.nw.nos.boeing.com> <4926122A.4000501@earthlink.net> <00db01c94b8b$eed566b0$cc803410$@nl> In-Reply-To: <00db01c94b8b$eed566b0$cc803410$@nl> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52c2322f22b9c6f954d035fb0411993f2b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.78.128 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Try to eliminate term subnet? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello Teco, Teco Boot wrote: >>> - If we don't define it, we must constantly be on watch to >>> make sure it is not used, and to explain why it is not >>> used. This will be a battle of perpetual weariness. >>> > > We can describe that subnet is not well defined and therefore we prefer less > confusing terminology. > A subnet is an appropriate range of addresses. What's not well-defined about that? > I think if we try to define it, and fail, that this will be a battle of > perpetual weariness > Moreover, I prefer leaving this task for the 6man wg. > What if they don't do it the way we need it, or make it more complicated? Did they even volunteer to do this definition? > > >>> - As difficult as it may be, a subnet would naturally be >>> the unit of address allocation. And, that's what we >>> are tasked with doing in [autoconf]. Of course we >>> could allocate addresses out of some random grab >>> bag of addresses, but I'm willing to bet people would >>> not like that. >>> > > I think we should use prefix delegation instead of "subnet address > allocation". > Well, that's O.K. with me, but it will still be viewed as an allocation related to managing the subnet. And, anyway, what if we want to allocate addresses from 168.254/16 for some hoss on a disconnected MANET? Who is delegating the prefix? > For now I do not see any reason not using DHCPv6-PD. > What if there's no DHCP server around? > And maybe use DHCPv6 for the counterpart of stateless address > autoconfiguration (not using the quite confusing wording of "stateful > configuration", see RFC4862). > What if there's no DHCP server around? Regards, Charlie P. PS. Is there an echo in here? _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Nov 20 22:47:06 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 696883A685D; Thu, 20 Nov 2008 22:47:06 -0800 (PST) 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 C06543A685D for ; Thu, 20 Nov 2008 22:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCcISMeC9xah for ; Thu, 20 Nov 2008 22:47:04 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 0EF363A6828 for ; Thu, 20 Nov 2008 22:47:03 -0800 (PST) Received: from [130.129.76.121] (unknown [130.129.76.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 3867DACB05F for ; Fri, 21 Nov 2008 07:47:00 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: autoconf@ietf.org Organization: Universidad Carlos III de Madrid Date: Fri, 21 Nov 2008 07:46:57 +0100 Message-Id: <1227250017.19012.167.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: [Autoconf] About MANET Links, subnets, etc X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2010714959==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============2010714959== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-yXkUjtwRs4YrIYdN2idH" --=-yXkUjtwRs4YrIYdN2idH Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi all, Apologies for jumping into the discussion kind-of late. I've been trying to follow all the e-mails and provide comments, but so far I've experienced some contradictory feelings. Some times I thought "OK, I agree with this" and then another e-mail arrived arguing the opposite that made change my mind. So, let me try to provide my (current) view on some of the things that have been discussed. Most of them might have been already proposed by others, so I'm just taking those pieces from here and there that I'm happy with. 1. About "MANET Links". I'm not completely sure we really need to define anything new. I see MANETs as networks composed of a set of routers that move. These routers have interfaces that belong to links -- these links being defined by the L2 reachability/radio coverage/connectivity of the interface. The difference is that these links are quite dynamic (because the routers move) and might not have some nice properties, such as transitivity, symmetry, etc (but this is because of the L2 technology of the interface). 2. About "subnets" and addressing. In my understanding of a MANET, I see each of the routers of a MANET getting one (or several) unique IPv6 prefix. Out of that prefix, the MANET router configures and address for its loopback interface. On the interface over which the MANET router runs a MANET routing protocol, only a link-local address needs to be configured. The router may be delegated more than one prefix, to configure other physical interfaces (regular hosts might attach to these interfaces, and configure IPv6 address from the delegated prefixes). The MANET routing protocol takes care of providing reachability within the MANET, MANET routers do not need to change their IP addresses due to inner mobility within the MANET. 3. About "links". I think the term "link" should be accompanied by the layer for which the term "link" is meaningful. There might be L2 links and L3 links and should not necessarily be the same. I'd say that a "LX link" is defined by "what can be reached in 1 LX hop". In the case of IP, an "L3/IP link" would be defined by what can be reached in 1 IP hop, i.e. without decrementing the IPv6 hop count of the packet. 4. About what we should do in the autoconf WG: to define the mechanism(s) to provide each MANET router with a unique IPv6 prefix (that could even be a /128). Something that might be tricky is how to guarantee that configured link-local addresses on the MANET interfaces are unique within the scope of the link, since that scope is quite dynamic (members of that link change over time, and even not all the members of that link may have the same view of the link). Potentially, a solution would be to ensure that these addresses are unique within the whole MANET, since that would ensure that they are in the scope of the link. Well, probably I will change my mind about some of these things after getting your opinion guys :-) Carlos --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2009: 2nd Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-yXkUjtwRs4YrIYdN2idH Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkkmWWEACgkQNdy6TdFwT2dRXQCgi5HK9ZiH+rechCjJiuHBIpxi Q80An3PZ4QwCVEa5oUvvCsE8aIb4lj1U =PQyz -----END PGP SIGNATURE----- --=-yXkUjtwRs4YrIYdN2idH-- --===============2010714959== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf --===============2010714959==-- From autoconf-bounces@ietf.org Fri Nov 21 03:19:52 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 427443A6894; Fri, 21 Nov 2008 03:19:52 -0800 (PST) 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 3B5353A6894 for ; Fri, 21 Nov 2008 03:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.3 X-Spam-Level: X-Spam-Status: No, score=-5.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 IzZ+EkNWkleM for ; Fri, 21 Nov 2008 03:19:50 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 389EB3A67B4 for ; Fri, 21 Nov 2008 03:19:50 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-128.messagelabs.com!1227266388!4312268!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 2968 invoked from network); 21 Nov 2008 11:19:48 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-128.messagelabs.com with SMTP; 21 Nov 2008 11:19:48 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mALBJiwK025648; Fri, 21 Nov 2008 04:19:44 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id mALBJhmt026582; Fri, 21 Nov 2008 05:19:43 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id mALBJghB026578; Fri, 21 Nov 2008 05:19:43 -0600 (CST) Message-ID: <4926994E.5010909@gmail.com> Date: Fri, 21 Nov 2008 12:19:42 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Charles E. Perkins" References: <00c801c94b65$f3af1e90$db0d5bb0$@nl> <4925FF7D.5050900@earthlink.net> In-Reply-To: <4925FF7D.5050900@earthlink.net> X-Antivirus: avast! (VPS 081120-0, 20/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org Subject: Re: [Autoconf] Try to eliminate term subnet? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Charles E. Perkins wrote: > > Hello folks, > > I am very nervous about not having a definition for the > term "subnet" for two reasons: > > - If we don't define it, we must constantly be on watch to > make sure it is not used, and to explain why it is not > used. This will be a battle of perpetual weariness. > > - As difficult as it may be, a subnet would naturally be > the unit of address allocation. And, that's what we > are tasked with doing in [autoconf]. Of course we > could allocate addresses out of some random grab > bag of addresses, but I'm willing to bet people would > not like that. > > Besides that, if we're willing to forgo the pleasure of > making a subnet map onto a pretend Ethernet, I think > it is manageable. I gently beg to differ: I could live with 'subnet' defined in relationship with a specific link-layer. For example, if we say that a wifi essid corresponds to a subnet, and vice-versa, then many people would probably understand same thing, there wouldn't be much confusion. We could understand limitations in terms of subnet size based on the size of the wifi essid, and more. If one tries to make a subnet different than the span of a wifi essid then one would describe: -why does one assume only wifi to be MANET - maybe because experimentation happened that way? That's ok, just say it. One wouldn't extend the wifi experience to other untried media. -why the essid-IPsubnet bijection is not enough, what's special about that particular essid. -why can't one build a MANET with wifi links having one subnet per essid, what breaks when one builds a MANET with wifi links and one IPsubnet per ESSID? I could depict a MANET with wifi links and a IPsubnet per essid, if that could help in some way. Alex > > We have some candidate definitions that seem to > work. Why not go forward with one of them? > > Regards, > Charlie P. > > > Teco Boot wrote: >> All, >> >> It seems that the term "subnet" is confusing. >> So I can agree with Thomas C his draft, title Figure 5: MANET Subnet >> Challenge >> >> I think we make life more easy to get rid of confusing terminology. >> Has someone a problem not using the term subnet in our documents? We know >> what prefixes are (entities where we can route to) and what addresses are >> (endpoint identifiers). Then we can work on the details on IPv6 address >> assignments, which have IMHO nothing to do with the discussion on the >> term >> subnet. >> >> >> Just recap the proposal from Emmanuel, eliminating subnet: >> - a prefix defines a contiguous range of IP addresses. >> - a link is what lower layers reach without TTL decrement, through a >> given >> interface. >> >> >> In our charter, the term subnet is mentioned a few times: >> === >> The address autoconfiguration related protocol specifications such as >> RFCs 2462, 2461, as used in traditional IP networks, assume that >> subnet-local signals (e.g. link-local multicast signals) are received >> by each of the hosts on the particular subnet without being forwarded >> by the routers defining the subnet boundary. Hence, ad hoc networks >> (as defined and understood by the IETF MANET WG) cannot use these >> protocol specifications as-is. >> === >> >> I would read this as: >> === >> The address autoconfiguration related protocol specifications such as >> RFCs 2462, 2461, as used in traditional IP networks, assume that >> link-local signals (e.g. link-local multicast signals) are received >> by each of the hosts on the particular medium without being forwarded >> by the routers defining the medium boundary. Hence, ad hoc networks >> (as defined and understood by the IETF MANET WG) cannot use these >> protocol specifications as-is. >> === >> 1st subnet -> link >> 2nd subnet -> medium >> 3th subnet -> medium >> >> RFC4861 says that a link is a medium, which does not apply for RF >> communication. >> The description for a link in RFC4861 says link equals medium, but >> luckily, >> it does not list RF spectrum as an example. >> So if we refine our understanding of a link and / or communications >> facility >> for RF, we are done. >> Actually I am writing something down on what service 802.11-2007 provides >> for the IP layer. >> >> >> Regards, Teco >> >> >> >> _______________________________________________ >> 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 > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 21 03:30:34 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E5B43A6868; Fri, 21 Nov 2008 03:30:34 -0800 (PST) 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 BE7293A6868 for ; Fri, 21 Nov 2008 03:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 wFzpdolsHmzD for ; Fri, 21 Nov 2008 03:30:32 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id DD1353A67A8 for ; Fri, 21 Nov 2008 03:30:32 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-128.messagelabs.com!1227267031!14620901!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 621 invoked from network); 21 Nov 2008 11:30:31 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-128.messagelabs.com with SMTP; 21 Nov 2008 11:30:31 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mALBUPGf027374; Fri, 21 Nov 2008 04:30:25 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id mALBUOuP012812; Fri, 21 Nov 2008 05:30:24 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id mALBUNEO012793; Fri, 21 Nov 2008 05:30:24 -0600 (CST) Message-ID: <49269BCF.10402@gmail.com> Date: Fri, 21 Nov 2008 12:30:23 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Charles E. Perkins" References: <00c801c94b65$f3af1e90$db0d5bb0$@nl><4925FF7D.5050900@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A1053EF3CF@XCH-NW-7V2.nw.nos.boeing.com> <4926122A.4000501@earthlink.net> <00db01c94b8b$eed566b0$cc803410$@nl> <492648FD.8060004@earthlink.net> In-Reply-To: <492648FD.8060004@earthlink.net> X-Antivirus: avast! (VPS 081120-0, 20/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org Subject: Re: [Autoconf] what if there's no DHCP Server around? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Charles E. Perkins wrote: > > Hello Teco, > > Teco Boot wrote: >>>> - If we don't define it, we must constantly be on watch to make >>>> sure it is not used, and to explain why it is not used. This >>>> will be a battle of perpetual weariness. >>>> >> >> We can describe that subnet is not well defined and therefore we >> prefer less confusing terminology. >> > > A subnet is an appropriate range of addresses. What's not > well-defined about that? > >> I think if we try to define it, and fail, that this will be a >> battle of perpetual weariness Moreover, I prefer leaving this task >> for the 6man wg. >> > > What if they don't do it the way we need it, or make it more > complicated? Did they even volunteer to do this definition? > > >> >> >>>> - As difficult as it may be, a subnet would naturally be the >>>> unit of address allocation. And, that's what we are tasked with >>>> doing in [autoconf]. Of course we could allocate addresses out >>>> of some random grab bag of addresses, but I'm willing to bet >>>> people would not like that. >>>> >> >> I think we should use prefix delegation instead of "subnet address >> allocation". >> > > Well, that's O.K. with me, but it will still be viewed as an > allocation related to managing the subnet. And, anyway, what if we > want to allocate addresses from 168.254/16 for some hoss on a > disconnected MANET? Who is delegating the prefix? > >> For now I do not see any reason not using DHCPv6-PD. >> > > What if there's no DHCP server around? > >> And maybe use DHCPv6 for the counterpart of stateless address >> autoconfiguration (not using the quite confusing wording of >> "stateful configuration", see RFC4862). >> > > What if there's no DHCP server around? Charlie, I hear this like the question Christopher had previously: what happens if there is no MAC repeater or long-range antenna extender to extend a wifi network. I'm afraid my personal answer to this is another question, if I'm permitted: what if there's no that-something-yet-to-be-designed around? This leads to much speculation, and one couldn't answer logically on it. I mean at least I couldn't. Maybe better would be to find out what's wrong with having a DHCPServer around? Maybe in a MANET-inspired network all nodes are potentially DHCPServers, so how would one elect _the_ DHCPServer? I see this as outlining a potential problem. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 21 05:41:25 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 519103A6919; Fri, 21 Nov 2008 05:41:25 -0800 (PST) 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 C91A33A6919 for ; Fri, 21 Nov 2008 05:41:23 -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 kLMkgPpy-pvX for ; Fri, 21 Nov 2008 05:41:22 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id 3D4C83A6842 for ; Fri, 21 Nov 2008 05:41:21 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so188863qwe.31 for ; Fri, 21 Nov 2008 05:41:19 -0800 (PST) Received: by 10.214.182.7 with SMTP id e7mr308608qaf.28.1227274878965; Fri, 21 Nov 2008 05:41:18 -0800 (PST) Received: from ?192.168.0.101? (sfp221-96.harvard.edu [128.103.221.96]) by mx.google.com with ESMTPS id 5sm3604706yxt.1.2008.11.21.05.41.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 21 Nov 2008 05:41:18 -0800 (PST) Message-ID: <4926BA7C.40209@polytechnique.edu> Date: Fri, 21 Nov 2008 07:41:16 -0600 From: Ulrich Herberg Organization: Ecole Polytechnique User-Agent: Thunderbird 2.0.0.17 (X11/20080922) MIME-Version: 1.0 To: Alexandru Petrescu References: <00c801c94b65$f3af1e90$db0d5bb0$@nl> <4925FF7D.5050900@earthlink.net> <4926994E.5010909@gmail.com> In-Reply-To: <4926994E.5010909@gmail.com> X-Enigmail-Version: 0.95.7 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Try to eliminate term subnet? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Alexandru Petrescu wrote: > [...] > I gently beg to differ: I could live with 'subnet' defined in > relationship with a specific link-layer. > > For example, if we say that a wifi essid corresponds to a subnet, and > vice-versa, then many people would probably understand same thing, > there wouldn't be much confusion. We could understand limitations in > terms of subnet size based on the size of the wifi essid, and more. > If one tries to make a subnet different than the span of a wifi essid > then one would describe: > > -why does one assume only wifi to be MANET - maybe because > experimentation happened that way? That's ok, just say it. One > wouldn't extend the wifi experience to other untried media. I do not think MANET is limited to 802.11. There are many other link layer technologies that form a perfectly good MANET, such as ethernet for example. > -why the essid-IPsubnet bijection is not enough, what's special about > that particular essid. I really don't think considering the ESSID is a good idea. It does not really say anything about the connectivity of nodes. You could have several IBBS with the same ESSID without being connected because they are too far apart. Or they use a different channel. Or some stations use WEP/WPA, others don't. So they would not necessarily be within the same subnet. Personally, a subnet for me means that all stations within the same subnet are on the same link, i.e. they can reach each other without decrementing TTL. The other way round is not necessarily true, on a same link there may be different subnets. > -why can't one build a MANET with wifi links having one subnet per > essid, what breaks when one builds a MANET with wifi links and one > IPsubnet per ESSID? I do not think that there is any definition of a MANET that limits this IP layer technology to 802.11. Nor should there be such a definition. > > I could depict a MANET with wifi links and a IPsubnet per essid, if > that could help in some way. > > Alex Ulrich _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 21 05:53:11 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B0CF3A69F0; Fri, 21 Nov 2008 05:53:11 -0800 (PST) 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 91AA33A69F0 for ; Fri, 21 Nov 2008 05:53:10 -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 lBeCLsReWuKY for ; Fri, 21 Nov 2008 05:53:09 -0800 (PST) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.185]) by core3.amsl.com (Postfix) with ESMTP id 8FC793A68C8 for ; Fri, 21 Nov 2008 05:53:09 -0800 (PST) Received: by rn-out-0910.google.com with SMTP id j77so811501rne.18 for ; Fri, 21 Nov 2008 05:53:07 -0800 (PST) Received: by 10.90.33.15 with SMTP id g15mr280516agg.71.1227275587193; Fri, 21 Nov 2008 05:53:07 -0800 (PST) Received: from ?192.168.0.101? (sfp221-96.harvard.edu [128.103.221.96]) by mx.google.com with ESMTPS id b45sm2361428hsa.10.2008.11.21.05.53.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 21 Nov 2008 05:53:06 -0800 (PST) Message-ID: <4926BD40.3000201@polytechnique.edu> Date: Fri, 21 Nov 2008 07:53:04 -0600 From: Ulrich Herberg Organization: Ecole Polytechnique User-Agent: Thunderbird 2.0.0.17 (X11/20080922) MIME-Version: 1.0 To: Alexandru Petrescu References: <00c801c94b65$f3af1e90$db0d5bb0$@nl><4925FF7D.5050900@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A1053EF3CF@XCH-NW-7V2.nw.nos.boeing.com> <4926122A.4000501@earthlink.net> <00db01c94b8b$eed566b0$cc803410$@nl> <492648FD.8060004@earthlink.net> <49269BCF.10402@gmail.com> In-Reply-To: <49269BCF.10402@gmail.com> X-Enigmail-Version: 0.95.7 Cc: autoconf@ietf.org Subject: Re: [Autoconf] what if there's no DHCP Server around? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Alexandru Petrescu wrote: > [...] >> >>> For now I do not see any reason not using DHCPv6-PD. >>> >> >> What if there's no DHCP server around? >> >>> And maybe use DHCPv6 for the counterpart of stateless address >>> autoconfiguration (not using the quite confusing wording of >>> "stateful configuration", see RFC4862). >>> >> >> What if there's no DHCP server around? > > Charlie, I hear this like the question Christopher had previously: what > happens if there is no MAC repeater or long-range antenna extender to > extend a wifi network. > > I'm afraid my personal answer to this is another question, if I'm > permitted: what if there's no that-something-yet-to-be-designed around? > > This leads to much speculation, and one couldn't answer logically on it. > I mean at least I couldn't. I think Charlie's question is perfectly adequate. What does it mean to use DHCP or DHCP-PD when you do not have a DHCP server around? Or if a node cannot reach it... DHCP(-PD) could be a solution of MANETs in the subordinate case, but it does not answer our fabulous questions: "What is a link? What is a subnet?" > > Maybe better would be to find out what's wrong with having a DHCPServer > around? Maybe in a MANET-inspired network all nodes are potentially > DHCPServers, so how would one elect _the_ DHCPServer? I see this as > outlining a potential problem. I do not understand this. What does it mean that every node is a DHCP server? There is no such thing as _the_ DHCP server. A DHCP server is just an application that has a certain pool of IP addresses and can assign on request one or several addresses / prefixes to a client. We have to be careful not to enter in the solution space, because DHCP may be part of an autoconf solution, but I do not think it helps us to understand the architecture of a MANET or the relationship between link/interface/subnet etc. Ulrich _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 21 06:00:35 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74BDC3A687D; Fri, 21 Nov 2008 06:00:35 -0800 (PST) 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 104FC3A687D for ; Fri, 21 Nov 2008 06:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 W2GPZxUwLqoT for ; Fri, 21 Nov 2008 06:00:33 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 236073A67ED for ; Fri, 21 Nov 2008 06:00:33 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-3.tower-128.messagelabs.com!1227276031!1581292!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 12390 invoked from network); 21 Nov 2008 14:00:31 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-128.messagelabs.com with SMTP; 21 Nov 2008 14:00:31 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mALE0Uwe023288; Fri, 21 Nov 2008 07:00:31 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id mALE0U8Y026349; Fri, 21 Nov 2008 08:00:30 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id mALE0TAl026320; Fri, 21 Nov 2008 08:00:29 -0600 (CST) Message-ID: <4926BEFC.8040000@gmail.com> Date: Fri, 21 Nov 2008 15:00:28 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Ulrich Herberg References: <00c801c94b65$f3af1e90$db0d5bb0$@nl> <4925FF7D.5050900@earthlink.net> <4926994E.5010909@gmail.com> <4926BA7C.40209@polytechnique.edu> In-Reply-To: <4926BA7C.40209@polytechnique.edu> X-Antivirus: avast! (VPS 081120-0, 20/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org Subject: Re: [Autoconf] Try to eliminate term subnet? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Ulrich, Ulrich Herberg wrote: > Alexandru Petrescu wrote: >> [...] I gently beg to differ: I could live with 'subnet' defined in >> relationship with a specific link-layer. >> >> For example, if we say that a wifi essid corresponds to a subnet, >> and vice-versa, then many people would probably understand same >> thing, there wouldn't be much confusion. We could understand >> limitations in terms of subnet size based on the size of the wifi >> essid, and more. If one tries to make a subnet different than the >> span of a wifi essid then one would describe: >> >> -why does one assume only wifi to be MANET - maybe because >> experimentation happened that way? That's ok, just say it. One >> wouldn't extend the wifi experience to other untried media. > > I do not think MANET is limited to 802.11. There are many other link > layer technologies that form a perfectly good MANET, such as ethernet > for example. Yes, one could use Ethernet to build MANETs. The question is on whether one has used Ethernet to build a small MANET and what were the issues of using Ethernet to build such a MANET. Was there any issue with a subnet model? Was that MANET any different than using Ethernet to build a normal network (non-MANET), with respect to the IP subnet model? >> -why the essid-IPsubnet bijection is not enough, what's special >> about that particular essid. > > I really don't think considering the ESSID is a good idea. It does > not really say anything about the connectivity of nodes. I beg to differ: all stations configuring same ESSID are within reach with each other, at link-layer. If they're not in reach is because they are purposefully moved out of reach. > You could have several IBBS with the same ESSID without being > connected because they are too far apart. Or they use a different > channel. Or some stations use WEP/WPA, others don't. Ok. Then we could refine the definition to say that all wifi stations using same ESSID, within a 50m radius (that's a wifi typical characteristic) and using same MAC address for that ESSID (that's another typical wifi characteristic, it's the MAC address of the ESSID, not of any other node) constitute an IP subnet. What do you think are the characteristics of a well-formed well-desitinguishable wifi link? -same essid? -same channel? -same auth method? -same MAC address of the link? All of the above? Only some combinations? This is easy to define. > So they would not necessarily be within the same subnet. Personally, > a subnet for me means that all stations within the same subnet are > on the same link, i.e. they can reach each other without decrementing > TTL. Link-IPsubnet equating constant TTL is fine with me. But I'm afraid this definition will not clarify the AUTOCONF path, simply because defenders of the MANET characteristics claim this _may_ not be true in MANETs. > The other way round is not necessarily true, on a same link there may > be different subnets. Different subnet prefixes on the same link - yes, yet TTL is constant on each of these subnets. >> -why can't one build a MANET with wifi links having one subnet per >> essid, what breaks when one builds a MANET with wifi links and one >> IPsubnet per ESSID? > > I do not think that there is any definition of a MANET that limits > this IP layer technology to 802.11. Nor should there be such a > definition. I half disagree with you. MANET experience should clarify which link-layer technology was experimented. It's nonsense to ignore completely the name of the link-layer technology used in experimentation. At the same time I agree that MANET-inspired networks were built with other link-layer technologies than 802.11. But these experiments, their results, as well as the issues there may have been - have never been reported here. I don't think we can work with issues that are being speculated upon. Alex >> I could depict a MANET with wifi links and a IPsubnet per essid, if >> that could help in some way. >> >> Alex > Ulrich > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 21 06:00:58 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B60643A69F0; Fri, 21 Nov 2008 06:00:58 -0800 (PST) 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 0DCBF3A6933 for ; Fri, 21 Nov 2008 06:00:58 -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=[AWL=0.000, 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 hIhtpjXCwa77 for ; Fri, 21 Nov 2008 06:00:57 -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 1385B3A69F0 for ; Fri, 21 Nov 2008 06:00:57 -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 mALE0b1v000940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 21 Nov 2008 06:00:38 -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 mALE0bg7001976; Fri, 21 Nov 2008 08:00:37 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id mALE0axR001950; Fri, 21 Nov 2008 08:00:37 -0600 (CST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Nov 2008 06:00:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Nov 2008 06:00:34 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1053EF44E@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <49264763.9030401@earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Try to eliminate term subnet? Thread-Index: AclLmj4ou7S7gg34StKbUKA/fWXoRgART1gA References: <00c801c94b65$f3af1e90$db0d5bb0$@nl><4925FF7D.5050900@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A1053EF3CF@XCH-NW-7V2.nw.nos.boeing.com> <4926122A.4000501@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A1053EF41B@XCH-NW-7V2.nw.nos.boeing.com> <49264763.9030401@earthlink.net> From: "Templin, Fred L" To: "Charles E. Perkins" X-OriginalArrivalTime: 21 Nov 2008 14:00:36.0297 (UTC) FILETIME=[8717AB90:01C94BE1] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-5.500.1027-16292.001 X-TM-AS-Result: No--34.561500-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: autoconf@ietf.org Subject: Re: [Autoconf] Try to eliminate term subnet? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org >-----Original Message----- >From: Charles E. Perkins [mailto:charles.perkins@earthlink.net] >Sent: Thursday, November 20, 2008 9:30 PM >To: Templin, Fred L >Cc: autoconf@ietf.org >Subject: Re: [Autoconf] Try to eliminate term subnet? > > >Hello Fred, > > From your discussion, I don't see your concern, >or where we should make any modification to >avoid difficulties. More inline... > >Templin, Fred L wrote: >> >> Let's consider bringing the more >> addressing-neutral term "subnetwork" into the terminology, >> where a subnetwork is a connected routing region within a >> MANET, and the MANET may contain many such subnetworks. >> > >Here, one key operative word is "may"... Or, the MANET may not >contain subnetworks. Even if there are no multiple subnetworks, the MANET will still contain at least one subnetwork which is the MANET itself. >> We then need a way of identifying each subnetwork, and >> traditional approaches would call for assigning an >> address/prefix on a subnetwork interface, where the >> prefix is shorter than /32 (IPv4) or /128 (IPv6). > >Check. But, again keeping in mind this is specific to the >needs of the network. > >> But, >> we already know that that is problematic for MANETs, >> since the subnetwork can split (half going to partition >> A and the other half going to partition B) and then >> mayhem ensues in a number of ways. >> > >If this happens, the subnet is broken. In real life, subnets >can break. Then people wonder what happened. It could >be that it would be more frequent in a MANET. But: >(a) we _could_ have a MANET without any proper > subnetworks >(b) there are cases where a stable subnet would exist. > >> So, let's instead have all routers in the subnetwork >> configure a common "subnet router anycast" address >> taken from a common IP prefix, but without assigning >> any addresses from the prefix to a MANET interface. >> So for example, we could assign the IPv6 prefix: >> "2001:DB8:1:2::/64" to a subnetwork, and each MANET >> router in the subnetwork assigns the IPv6 subnet router >> anycast address "2001:DB8:1:2::" to its loopback >> interface. >> >> So, no MANET routers in the subnetwork have a unicast >> IPv6 address assignment from the prefix, but all MANET >> routers have the subnet router anycast address on their >> loopbacks. The routers can retain the anycast address >> even if the subnetwork partitions and keep it for as >> long as it still makes sense for them to retain >> membership to that subnetwork. If they want to join >> other subnetworks too, that's OK - they just configure >> additional subnet router anycast addresses. >> >> We can now happily ping toward the subnet router anycast >> address from anywhere, and the nearest MANET router will >> answer us back. I call it the "no-subnet subnetwork model", >> but I don't mind if we end up calling it something else. >> > >Here, I am in the dark about why you would do this. > >For one thing, if you have two different routers serving the >same subnet, they basically have to provide reachability to >the same hosts. I do not see how you are doing this. >Unless of course there are no hosts on the subnetwork. >In which case, perhaps the conditions are all satisfied >vacuously. > >In that case, it may be an interesting technical exercise, >but I don't see where it is guiding us, nor where it causes >the definitions to fail. All right, then let's take the ISATAP approach. In ISATAP, we can have multiple subnetwork border routers; each advertising different on-link IPv6 prefixes on their ISATAP interface. MANET routers and hosts that receive the prefix assign it to their ISATAP interface and use SLAAC to configure an address from the prefix as-normal. So, the MANET router/host can configure one or more on-link prefixes on its ISATAP interfaces - one or more for each subnetwork border router it receives an RA from. Now, if the ISATAP link stays together we have normal use of the on-link prefixes. If the ISATAP link partitions, then the MANET routers and hosts in partition A that have a subnetwork border router advertising 2001:DB8:1:2::/48 will retain that prefix and let all others time out, while the nodes in partition B that have a subnetwork border router advertising 2001:DB8:3:4::/48 will retain *that* prefix and let others time out. MANET routers can happily source packets either using the address assigned to their ISATAP interface or an address assigned to another non-MANET interface. Or, they can forward packets on behalf of nodes attached to their non-MANET interfaces. Simple hosts can source packets using the address assigned to their ISATAP interfaces only and would be exposed to address selection agility in case of partitions, which is why simple hosts may in some cases be better server by getting themselves attached to a network reached by MANET router's non-MANET interface. Does it work for you? Fred fred.l.templin@boeing.com >>>> - If we don't define it, we must constantly be on watch to >>>> make sure it is not used, and to explain why it is not >>>> used. This will be a battle of perpetual weariness. >>>> >>>> - As difficult as it may be, a subnet would naturally be >>>> the unit of address allocation. And, that's what we >>>> are tasked with doing in [autoconf]. Of course we >>>> could allocate addresses out of some random grab >>>> bag of addresses, but I'm willing to bet people would >>>> not like that. >>>> > > >I also do not see how it answers the two concerns I raised. > >Regards, >Charlie P. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 21 06:11:04 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C8C83A6842; Fri, 21 Nov 2008 06:11:04 -0800 (PST) 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 665113A6842 for ; Fri, 21 Nov 2008 06:11: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 H16NclrNrqA1 for ; Fri, 21 Nov 2008 06:11:01 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with SMTP id 4DE9B3A67ED for ; Fri, 21 Nov 2008 06:11:01 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-119.messagelabs.com!1227276658!30205319!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [136.182.1.13] Received: (qmail 5806 invoked from network); 21 Nov 2008 14:10:59 -0000 Received: from unknown (HELO motgate3.mot.com) (136.182.1.13) by server-11.tower-119.messagelabs.com with SMTP; 21 Nov 2008 14:10:59 -0000 Received: from il27exr04.cig.mot.com ([10.17.196.73]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id mALEAwC8013428; Fri, 21 Nov 2008 07:10:58 -0700 (MST) Received: from il27vts03 (il27vts03.cig.mot.com [10.17.196.87]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id mALEAwRT018590; Fri, 21 Nov 2008 08:10:58 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id mALEAvYK018584; Fri, 21 Nov 2008 08:10:57 -0600 (CST) Message-ID: <4926C170.40707@gmail.com> Date: Fri, 21 Nov 2008 15:10:56 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Ulrich Herberg References: <00c801c94b65$f3af1e90$db0d5bb0$@nl><4925FF7D.5050900@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A1053EF3CF@XCH-NW-7V2.nw.nos.boeing.com> <4926122A.4000501@earthlink.net> <00db01c94b8b$eed566b0$cc803410$@nl> <492648FD.8060004@earthlink.net> <49269BCF.10402@gmail.com> <4926BD40.3000201@polytechnique.edu> In-Reply-To: <4926BD40.3000201@polytechnique.edu> X-Antivirus: avast! (VPS 081120-0, 20/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org Subject: Re: [Autoconf] what if there's no DHCP Server around? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Ulrich Herberg wrote: > Alexandru Petrescu wrote: >> [...] >>>> For now I do not see any reason not using DHCPv6-PD. >>>> >>> What if there's no DHCP server around? >>> >>>> And maybe use DHCPv6 for the counterpart of stateless address >>>> autoconfiguration (not using the quite confusing wording of >>>> "stateful configuration", see RFC4862). >>>> >>> What if there's no DHCP server around? >> Charlie, I hear this like the question Christopher had previously: >> what happens if there is no MAC repeater or long-range antenna >> extender to extend a wifi network. >> >> I'm afraid my personal answer to this is another question, if I'm >> permitted: what if there's no that-something-yet-to-be-designed >> around? >> >> This leads to much speculation, and one couldn't answer logically >> on it. I mean at least I couldn't. > > I think Charlie's question is perfectly adequate. What does it mean > to use DHCP or DHCP-PD when you do not have a DHCP server around? Or > if a node cannot reach it... Then what could one answer? If there's no DHCP Server around then I can't auto-configure an address using DHCP. Or maybe I could use SLAAC (stateless autoconf), or maybe I could use link-local addresses - why not? Are you going then to question 'what if there's no link-local addresses, and no slaac'? What could one then answer? Questioning the presence of such widely-available software is a paradox in itself. The only reason I could understand when someone asks 'what if there's no DHCP Server' is to understand as 'what if there's no fixed infrastructure housing a DHCP Server, around that MANET?' I can perfectly understand this, there are many cases of autonomous networks. But within each autonomous network it's very easy to have a DHCP Server. > DHCP(-PD) could be a solution of MANETs in the subordinate case, but > it does not answer our fabulous questions: "What is a link? What is a > subnet?" >> Maybe better would be to find out what's wrong with having a >> DHCPServer around? Maybe in a MANET-inspired network all nodes are >> potentially DHCPServers, so how would one elect _the_ DHCPServer? >> I see this as outlining a potential problem. > > I do not understand this. What does it mean that every node is a DHCP > server? Well I mean in a MANET built out of off-the-shelf linux machines, where each one can easily run DHCP Server software. > There is no such thing as _the_ DHCP server. A DHCP server is just an > application that has a certain pool of IP addresses and can assign > on request one or several addresses / prefixes to a client. In a MANET with two servers each running a DHCP Server, and one DHCP Client, which Server will the Client choose to send its DHCP Request to (after having received two DHCP Advertise from two different Servers)? > We have to be careful not to enter in the solution space, because > DHCP may be part of an autoconf solution, but I do not think it helps > us to understand the architecture of a MANET or the relationship > between link/interface/subnet etc. Careful yes, Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 21 06:18:54 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FEC33A691C; Fri, 21 Nov 2008 06:18:54 -0800 (PST) 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 AC72B3A691C for ; Fri, 21 Nov 2008 06:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.3 X-Spam-Level: X-Spam-Status: No, score=-5.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 gS1j6BEWcAwb for ; Fri, 21 Nov 2008 06:18:53 -0800 (PST) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id A1F103A67ED for ; Fri, 21 Nov 2008 06:18:52 -0800 (PST) Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id mALEIk8O021347 for ; Fri, 21 Nov 2008 14:18:49 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id mALEIkg4015205 for ; Fri, 21 Nov 2008 14:18:46 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Fri, 21 Nov 2008 14:18:46 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Fri, 21 Nov 2008 14:18:46 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Nov 2008 14:18:45 -0000 Message-ID: In-Reply-To: <4926BEFC.8040000@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Try to eliminate term subnet? Thread-Index: AclL4Yew9DEdg2DGRqOcmNucdSR+dgAADwzw References: <00c801c94b65$f3af1e90$db0d5bb0$@nl> <4925FF7D.5050900@earthlink.net><4926994E.5010909@gmail.com> <4926BA7C.40209@polytechnique.edu> <4926BEFC.8040000@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" , "Ulrich Herberg" X-OriginalArrivalTime: 21 Nov 2008 14:18:46.0303 (UTC) FILETIME=[10C962F0:01C94BE4] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Try to eliminate term subnet? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > MANET experience should clarify which link-layer technology was > experimented. It's nonsense to ignore completely the name of the > link-layer technology used in experimentation. If we were working with a single link layer technology, we'd create the network at L2. The point of working at L3 is to build an approach that is, as far as possible, independent of the L2 technology. We do not wish to be tied to one, or even a defined list, of L2 technologies, or even one L2 technology at a time. Consider the MANET protocols that exist in the IETF: AODV, DSR, OLSR, TBRPF and now DYMO, OLSRv2 and SMF. Where in any of those is there a specification of what L2 they are designed to run over? At most they indicate what behaviour they want from L2 (such as local broadcast, possibly link quality information, and so on). One reason no one's getting into a discussion of what L2 technologies they have used, or plan to use (apart from possible commercial and other considerations) is that it would be a diversion down a blind alley. The relevance of specific L2 technologies is for reasons such as to illustrate specific points (such as the "B can communicate, on a single interface, with A and C, but A and C can't communicate directly and must relay through B - which can be illustrated by 802.11 on a single channel, single ESSID etc., but A and C physically too far apart). ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 21 07:08:32 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92D103A68D3; Fri, 21 Nov 2008 07:08:32 -0800 (PST) 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 DCD0B3A68D3 for ; Fri, 21 Nov 2008 07:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 aAkavth0J2pB for ; Fri, 21 Nov 2008 07:08:30 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id A88A53A67E2 for ; Fri, 21 Nov 2008 07:08:30 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-153.messagelabs.com!1227280108!27233434!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 12647 invoked from network); 21 Nov 2008 15:08:28 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-153.messagelabs.com with SMTP; 21 Nov 2008 15:08:28 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id mALF8SdQ010064; Fri, 21 Nov 2008 08:08:28 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id mALF8Sh7022869; Fri, 21 Nov 2008 09:08:28 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id mALF8Qlm022845; Fri, 21 Nov 2008 09:08:27 -0600 (CST) Message-ID: <4926CEEA.6010005@gmail.com> Date: Fri, 21 Nov 2008 16:08:26 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <00c801c94b65$f3af1e90$db0d5bb0$@nl> <4925FF7D.5050900@earthlink.net><4926994E.5010909@gmail.com> <4926BA7C.40209@polytechnique.edu> <4926BEFC.8040000@gmail.com> In-Reply-To: X-Antivirus: avast! (VPS 081120-0, 20/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org Subject: Re: [Autoconf] Try to eliminate term subnet? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Dearlove, Christopher (UK) wrote: >> MANET experience should clarify which link-layer technology was >> experimented. It's nonsense to ignore completely the name of the >> link-layer technology used in experimentation. > > If we were working with a single link layer technology, we'd create > the network at L2. > > The point of working at L3 is to build an approach that is, as far as > possible, independent of the L2 technology. We do not wish to be > tied to one, or even a defined list, of L2 technologies, or even one > L2 technology at a time. I can understand IP being able to run over multiple types of link-layer technologies. Stress that for each of those link-layers the behaviour of IP over them is very well defined and understood (IP-over-foo RFCs). This is completely different than assuming IP runs over _everything_ and because everything isn't spelled out we don't know what's inside and because of that ND/DHCP may not run over it. > Consider the MANET protocols that exist in the IETF: AODV, DSR, OLSR, > TBRPF and now DYMO, OLSRv2 and SMF. Where in any of those is there a > specification of what L2 they are designed to run over? I don't know, could you please say? Do we know which link-layer tech was used to experiment AODV, DSR, OLSR, TBRPF, DYMO, OLSRv2 and SMF? > At most they indicate what behaviour they want from L2 (such as local > broadcast, possibly link quality information, and so on). In expressing the expected behaviour it would be easier if they used Ethernet terms, or other SDO terms. > One reason no one's getting into a discussion of what L2 technologies > they have used, or plan to use (apart from possible commercial and > other considerations) I was wondering about the commercial and possibly military considerations which are not spelled out potentially due to obvious confidentiality reasons. Could one base public work on secret requirements? One has seen a lot of silence in the WG recently, is that the confidentiality aspect? Alex > is that it would be a diversion down a blind alley. The relevance of > specific L2 technologies is for reasons such as to illustrate > specific points (such as the "B can communicate, on a single > interface, with A and C, but A and C can't communicate directly and > must relay through B - which can be illustrated by 802.11 on a single > channel, single ESSID etc., but A and C physically too far apart). > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 21 07:34:03 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5765A3A6925; Fri, 21 Nov 2008 07:34:03 -0800 (PST) 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 791CC3A6925 for ; Fri, 21 Nov 2008 07:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 yYQ5W2UJVIl8 for ; Fri, 21 Nov 2008 07:34:01 -0800 (PST) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id 6584D3A67E2 for ; Fri, 21 Nov 2008 07:34:01 -0800 (PST) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id mALFXurY010028 for ; Fri, 21 Nov 2008 15:33:58 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id mALFXu08019908 for ; Fri, 21 Nov 2008 15:33:56 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Fri, 21 Nov 2008 15:33:55 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Fri, 21 Nov 2008 15:33:55 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Nov 2008 15:33:54 -0000 Message-ID: In-Reply-To: <4926CEEA.6010005@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Try to eliminate term subnet? Thread-Index: AclL6wXwTKs1hDbaTxWERPCKoN1S1QAAqNdQ References: <00c801c94b65$f3af1e90$db0d5bb0$@nl> <4925FF7D.5050900@earthlink.net><4926994E.5010909@gmail.com> <4926BA7C.40209@polytechnique.edu> <4926BEFC.8040000@gmail.com> <4926CEEA.6010005@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 21 Nov 2008 15:33:55.0568 (UTC) FILETIME=[90849F00:01C94BEE] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Try to eliminate term subnet? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > This is completely different than assuming IP runs over _everything_ No, we're defining a general model for what a MANET runs over. Not everything, just things that fit that general model. Go back to RFC 2501. That approach is what we've been doing for the last more years than I've been involved. This is really just attempting to codify things. >> Consider the MANET protocols that exist in the IETF: AODV, DSR, OLSR, >> TBRPF and now DYMO, OLSRv2 and SMF. Where in any of those is there a >> specification of what L2 they are designed to run over? > I don't know, could you please say? That was a rhetorical question. There isn't any such statement in them. At least not in terms of specific systems. That's intent, not accident. > In expressing the expected behaviour it would be easier if they used > Ethernet terms, or other SDO terms. Trying to use agreed terms is exactly what people are trying to do! But trying to discuss what specific L2s is a blind alley you've headed down. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 21 07:49:07 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BACCA3A682C; Fri, 21 Nov 2008 07:49:07 -0800 (PST) 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 4A7953A682C for ; Fri, 21 Nov 2008 07:49: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, 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 Wy23zD7faiEZ for ; Fri, 21 Nov 2008 07:49:06 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 665863A67E2 for ; Fri, 21 Nov 2008 07:49:06 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-2.tower-128.messagelabs.com!1227282544!5312652!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [136.182.1.14] Received: (qmail 17020 invoked from network); 21 Nov 2008 15:49:04 -0000 Received: from unknown (HELO motgate4.mot.com) (136.182.1.14) by server-2.tower-128.messagelabs.com with SMTP; 21 Nov 2008 15:49:04 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id mALFn1uZ013016; Fri, 21 Nov 2008 08:49:01 -0700 (MST) Received: from il27vts01 (il27vts01.cig.mot.com [10.17.196.85]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id mALFn1JH004305; Fri, 21 Nov 2008 09:49:01 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id mALFmxJ6004277; Fri, 21 Nov 2008 09:49:00 -0600 (CST) Message-ID: <4926D86A.4050604@gmail.com> Date: Fri, 21 Nov 2008 16:48:58 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <00c801c94b65$f3af1e90$db0d5bb0$@nl> <4925FF7D.5050900@earthlink.net><4926994E.5010909@gmail.com> <4926BA7C.40209@polytechnique.edu> <4926BEFC.8040000@gmail.com> <4926CEEA.6010005@gmail.com> In-Reply-To: X-Antivirus: avast! (VPS 081120-0, 20/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org Subject: Re: [Autoconf] Try to eliminate term subnet? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Christopher, thanks for message, Dearlove, Christopher (UK) wrote: >> This is completely different than assuming IP runs over _everything_ > > No, we're defining a general model for what a MANET runs over. > Not everything, just things that fit that general model. > > Go back to RFC 2501. That approach is what we've been doing for the > last more years than I've been involved. This is really just attempting > to codify things. > >>> Consider the MANET protocols that exist in the IETF: AODV, DSR, OLSR, >>> TBRPF and now DYMO, OLSRv2 and SMF. Where in any of those is there a >>> specification of what L2 they are designed to run over? > >> I don't know, could you please say? > > That was a rhetorical question. There isn't any such statement in them. > At least not in terms of specific systems. That's intent, not accident. If so, then I assume they work with existing auto-configuration mechanisms, because they make the same unspoken assumptions on the IP subnets as OSPF and RIP make, and these do work with existing auto-configuration mechanisms. >> In expressing the expected behaviour it would be easier if they used >> Ethernet terms, or other SDO terms. > > Trying to use agreed terms is exactly what people are trying to do! There doesn't seem to be agreement on a common term for 'subnet', subject of this topic being a reflection. At the same time many people seem to agree on constant-TTL over an Ethernet. > But trying to discuss what specific L2s is a blind alley you've headed > down. Let me try to express why this is not a blind alley. There are real competitors for the IP-over-generalizedlink concept. The competitors are the several SDOs designing links from ground up to the application - without using IP. These links are for networks truly ressembling MANETs. IP ignores them, SDOs ignore IP. What gets deployed out there are these proprietary links without IP. This is why I believe AUTOCONF stating the link-layer assumptions is not a blind alley, but rather a potential opening. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 21 08:01:46 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64BF83A6A2E; Fri, 21 Nov 2008 08:01:46 -0800 (PST) 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 16C533A6A2E for ; Fri, 21 Nov 2008 08:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 0TVK5OOxi3WM for ; Fri, 21 Nov 2008 08:01:44 -0800 (PST) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id F35963A6A10 for ; Fri, 21 Nov 2008 08:01:43 -0800 (PST) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id mALG1epM026095 for ; Fri, 21 Nov 2008 16:01:40 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id mALG1eQ3030186 for ; Fri, 21 Nov 2008 16:01:40 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Fri, 21 Nov 2008 16:01:39 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Fri, 21 Nov 2008 16:01:39 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Nov 2008 16:01:37 -0000 Message-ID: In-Reply-To: <4926D86A.4050604@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Try to eliminate term subnet? Thread-Index: AclL8K+P3Ap0i55ST1CN+DDevek2NAAABRUg References: <00c801c94b65$f3af1e90$db0d5bb0$@nl> <4925FF7D.5050900@earthlink.net><4926994E.5010909@gmail.com> <4926BA7C.40209@polytechnique.edu> <4926BEFC.8040000@gmail.com> <4926CEEA.6010005@gmail.com> <4926D86A.4050604@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 21 Nov 2008 16:01:39.0303 (UTC) FILETIME=[702E6F70:01C94BF2] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Try to eliminate term subnet? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org >> That was a rhetorical question. There isn't any such statement in them. >> At least not in terms of specific systems. That's intent, not accident. > If so, then I assume they work with existing auto-configuration > mechanisms That would be a bad assumption. If it were true, why would we need the Autoconf WG? Some work with static address configuration. Others do various things. But if any autoconfigured addresses out of the box, with unmodified existing protocols, with no issues, why would we be here? > because they make the same unspoken assumptions on the IP > subnets as OSPF and RIP make, and these do work with existing > auto-configuration mechanisms. False premise, false conclusion. >> Trying to use agreed terms is exactly what people are trying to do! > There doesn't seem to be agreement on a common term for 'subnet' The first word above is "trying", and in fact I accidentally said it twice. Not yet succeeding. >> But trying to discuss what specific L2s is a blind alley you've headed >> down. > This is why I believe AUTOCONF stating the link-layer assumptions is not > a blind alley, but rather a potential opening. Again, you've made a jump from what I said, to what I didn't say. I said discussing specific L2s was a blind alley. I didn't say discussing the characteristics of L2s was a blind alley. What do you think the MANET link type document was trying to do? But again, this has diverged so far from being useful, that I will stop here. Note that all questions above are rhetorical, if that isn't obvious. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 21 08:13:19 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83FE73A6A6C; Fri, 21 Nov 2008 08:13:19 -0800 (PST) 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 8AACC3A6A6C for ; Fri, 21 Nov 2008 08:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, 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 7X99JXgPTgjv for ; Fri, 21 Nov 2008 08:13:17 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 8EC9128C0D0 for ; Fri, 21 Nov 2008 08:13:17 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-128.messagelabs.com!1227283995!27893302!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [136.182.1.13] Received: (qmail 31673 invoked from network); 21 Nov 2008 16:13:15 -0000 Received: from unknown (HELO motgate3.mot.com) (136.182.1.13) by server-4.tower-128.messagelabs.com with SMTP; 21 Nov 2008 16:13:15 -0000 Received: from il27exr01.cig.mot.com ([10.17.196.70]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id mALGDENt002861; Fri, 21 Nov 2008 09:13:14 -0700 (MST) Received: from il27vts02.mot.com (il27vts02.cig.mot.com [10.17.196.86]) by il27exr01.cig.mot.com (8.13.1/Vontu) with SMTP id mALGDESc022441; Fri, 21 Nov 2008 10:13:14 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il27exr01.cig.mot.com (8.13.1/8.13.0) with ESMTP id mALGDDkq022395; Fri, 21 Nov 2008 10:13:13 -0600 (CST) Message-ID: <4926DE19.7030901@gmail.com> Date: Fri, 21 Nov 2008 17:13:13 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <00c801c94b65$f3af1e90$db0d5bb0$@nl> <4925FF7D.5050900@earthlink.net><4926994E.5010909@gmail.com> <4926BA7C.40209@polytechnique.edu> <4926BEFC.8040000@gmail.com> <4926CEEA.6010005@gmail.com> <4926D86A.4050604@gmail.com> In-Reply-To: X-Antivirus: avast! (VPS 081120-0, 20/11/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org Subject: Re: [Autoconf] Try to eliminate term subnet? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Dearlove, Christopher (UK) wrote: >> If so, then I assume they work with existing auto-configuration >> mechanisms > > That would be a bad assumption. If it were true, why would we need > the Autoconf WG? > > Some work with static address configuration. Do you mean manually adding an address to an interface? Or link-local IPv6 address forming over Ethernet (fe80-prepended addresses, rfc2464)? > Others do various things. But if any autoconfigured addresses out of > the box, with unmodified existing protocols, with no issues, why > would we be here? If we knew why people did these various other things (instead of link-local addresses, or of slaac, or of dhcp) then we could understand why we are here. There sure were reasons, but which? Could one quickly list a simple one? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 21 11:09:23 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D3BA3A685A; Fri, 21 Nov 2008 11:09:23 -0800 (PST) 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 1D1143A685A for ; Fri, 21 Nov 2008 11:09:22 -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 dODAS7FuxzGX for ; Fri, 21 Nov 2008 11:09:21 -0800 (PST) Received: from maili.marvell.com (host2.marvell.com [65.219.4.2]) by core3.amsl.com (Postfix) with ESMTP id 25D113A6452 for ; Fri, 21 Nov 2008 11:09:20 -0800 (PST) Received: from MSI-MTA.marvell.com (msi-mta.marvell.com [10.68.76.91]) by maili.marvell.com (Postfix) with ESMTP id 6CDA562011; Fri, 21 Nov 2008 11:09:19 -0800 (PST) Received: from sc-owa01.marvell.com ([10.93.76.21]) by MSI-MTA.marvell.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Nov 2008 11:09:19 -0800 Received: from sc-owa02.marvell.com (10.93.76.22) by sc-owa01.marvell.com (10.93.76.21) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 21 Nov 2008 11:09:19 -0800 Received: from SC-EXCH1.marvell.com ([10.93.76.25]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Fri, 21 Nov 2008 11:09:18 -0800 From: Paul Lambert To: Alexandru Petrescu , Ulrich Herberg Date: Fri, 21 Nov 2008 11:09:17 -0800 Thread-Topic: Alternative IP Address Assignment Mechanisms for Ad Hoc Wireless-> was RE: [Autoconf] what if there's no DHCP Server around? Thread-Index: AclL4v6BOHl4EPaETMGLQCu4aCRHpAAJ/YeA Message-ID: <5A22FB9EDAA74547916480634CCC743817AD0BBCCD@SC-EXCH1.marvell.com> References: <00c801c94b65$f3af1e90$db0d5bb0$@nl><4925FF7D.5050900@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A1053EF3CF@XCH-NW-7V2.nw.nos.boeing.com> <4926122A.4000501@earthlink.net> <00db01c94b8b$eed566b0$cc803410$@nl> <492648FD.8060004@earthlink.net> <49269BCF.10402@gmail.com> <4926BD40.3000201@polytechnique.edu> <4926C170.40707@gmail.com> In-Reply-To: <4926C170.40707@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 21 Nov 2008 19:09:19.0404 (UTC) FILETIME=[A7B97EC0:01C94C0C] Cc: "autoconf@ietf.org" Subject: [Autoconf] Alternative IP Address Assignment Mechanisms for Ad Hoc Wireless-> was RE: what if there's no DHCP Server around? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > -----Original Message----- > From: Alexandru Petrescu > Sent: Friday, November 21, 2008 6:11 AM > To: Ulrich Herberg > Cc: autoconf@ietf.org > Subject: Re: [Autoconf] what if there's no DHCP Server around? > > Ulrich Herberg wrote: > > Alexandru Petrescu wrote: > >> [...] > >>>> For now I do not see any reason not using DHCPv6-PD. > >>>> > >>> What if there's no DHCP server around? > >>> > >>>> And maybe use DHCPv6 for the counterpart of stateless address > >>>> autoconfiguration (not using the quite confusing wording of > >>>> "stateful configuration", see RFC4862). > >>>> > >>> What if there's no DHCP server around? > >> Charlie, I hear this like the question Christopher had previously: > >> what happens if there is no MAC repeater or long-range antenna > >> extender to extend a wifi network. > >> > >> I'm afraid my personal answer to this is another question, if I'm > >> permitted: what if there's no that-something-yet-to-be-designed > >> around? > >> > >> This leads to much speculation, and one couldn't answer logically > >> on it. I mean at least I couldn't. > > > > I think Charlie's question is perfectly adequate. What does it mean > > to use DHCP or DHCP-PD when you do not have a DHCP server around? Or > > if a node cannot reach it... > > Then what could one answer? If there's no DHCP Server around then I > can't auto-configure an address using DHCP. Or maybe I could use SLAAC > (stateless autoconf), or maybe I could use link-local addresses - why not? > > Are you going then to question 'what if there's no link-local addresses, > and no slaac'? What could one then answer? Questioning the presence of > such widely-available software is a paradox in itself. > > The only reason I could understand when someone asks 'what if there's no > DHCP Server' is to understand as 'what if there's no fixed > infrastructure housing a DHCP Server, around that MANET?' I can > perfectly understand this, there are many cases of autonomous networks. > But within each autonomous network it's very easy to have a DHCP Server. > > > DHCP(-PD) could be a solution of MANETs in the subordinate case, but > > it does not answer our fabulous questions: "What is a link? What is a > > subnet?" > >> Maybe better would be to find out what's wrong with having a > >> DHCPServer around? Maybe in a MANET-inspired network all nodes are > >> potentially DHCPServers, so how would one elect _the_ DHCPServer? > >> I see this as outlining a potential problem. > > > > I do not understand this. What does it mean that every node is a DHCP > > server? > > Well I mean in a MANET built out of off-the-shelf linux machines, where > each one can easily run DHCP Server software. There are several issues with using DHCP in mobile devices: 1) in an ad hoc network ... there may not be a consistently available single device - yes, it's hard to know which one to elect 2) ad hoc connectivity makes it impossible to pick a viable routable subnet 3) multicast may not have the full connectivity expected and is not always reliable for discovery 4) It's hard for users to configure (imagine setting the DHCP server settings on your Wi-Fi enabled camera) Note - I'm currently working with consumer device manufacturers to field ad hoc wireless products. IP address assignment is an issue ... and we may end up fielding proprietary protocols. Link local might work ... but also has an issue with multicast ... and needs some enhancements. Are there other proposals or protocols available for IP address assignment in ad hoc wireless networks? Paul > > > There is no such thing as _the_ DHCP server. A DHCP server is just an > > application that has a certain pool of IP addresses and can assign > > on request one or several addresses / prefixes to a client. > > In a MANET with two servers each running a DHCP Server, and one DHCP > Client, which Server will the Client choose to send its DHCP Request to > (after having received two DHCP Advertise from two different Servers)? > > > We have to be careful not to enter in the solution space, because > > DHCP may be part of an autoconf solution, but I do not think it helps > > us to understand the architecture of a MANET or the relationship > > between link/interface/subnet etc. > > Careful yes, > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 21 12:08:57 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFE853A67F4; Fri, 21 Nov 2008 12:08:56 -0800 (PST) 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 B4F3B3A67F4 for ; Fri, 21 Nov 2008 12:08:55 -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 V3nWshw3cIDg for ; Fri, 21 Nov 2008 12:08:54 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id 364F23A67A7 for ; Fri, 21 Nov 2008 12:08:54 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id d23so819874fga.41 for ; Fri, 21 Nov 2008 12:08:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=C9OHw7hxPYpVRcR5bloyahJbRu/O/+srjuKhknrq6BE=; b=iw1Paqbguk+eYvvis646A/qNqD6BVQoe5eyvqeVfneAs6/ifXxikndK10VXaIk1MD6 2T8N4wgCX8cMNWDY2UejaQKM0TrNiBcKogK1TlkDsq8zRoWC1abX6dIcUP9+rOCMfxfk ZxofuHtZgKNxepswvZC2N7FZ2rHxucb+PPZKw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=d7pIW6VrrXeh0ECZSy16BxRM5KkNTkaOEOfOsLJxr5jKI27iQ7m+xWOmzrptX+UbL/ Co2fn+3V8ssGqXqpK/DvxlbmbU8T3Z+IgzOyjS2zpA4y+a4kR80lstpKhTs5mSnkHId8 q0FTDl82C7No1qHJZyJlQOZr/hCpF+uugXFVk= Received: by 10.181.60.14 with SMTP id n14mr266907bkk.79.1227298130412; Fri, 21 Nov 2008 12:08:50 -0800 (PST) Received: by 10.181.201.6 with HTTP; Fri, 21 Nov 2008 12:08:50 -0800 (PST) Message-ID: Date: Fri, 21 Nov 2008 21:08:50 +0100 From: "Emmanuel Baccelli" To: autoconf@ietf.org In-Reply-To: <5A22FB9EDAA74547916480634CCC743817AD0BBCCD@SC-EXCH1.marvell.com> MIME-Version: 1.0 References: <00c801c94b65$f3af1e90$db0d5bb0$@nl> <39C363776A4E8C4A94691D2BD9D1C9A1053EF3CF@XCH-NW-7V2.nw.nos.boeing.com> <4926122A.4000501@earthlink.net> <00db01c94b8b$eed566b0$cc803410$@nl> <492648FD.8060004@earthlink.net> <49269BCF.10402@gmail.com> <4926BD40.3000201@polytechnique.edu> <4926C170.40707@gmail.com> <5A22FB9EDAA74547916480634CCC743817AD0BBCCD@SC-EXCH1.marvell.com> X-Google-Sender-Auth: 0141d8eb2376bd60 Subject: Re: [Autoconf] Alternative IP Address Assignment Mechanisms for Ad Hoc Wireless-> was RE: what if there's no DHCP Server around? 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: , Content-Type: multipart/mixed; boundary="===============0935932559==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============0935932559== Content-Type: multipart/alternative; boundary="----=_Part_65156_10249495.1227298130398" ------=_Part_65156_10249495.1227298130398 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Fri, Nov 21, 2008 at 8:09 PM, Paul Lambert wrote: > > > Well I mean in a MANET built out of off-the-shelf linux machines, where > > each one can easily run DHCP Server software. > > There are several issues with using DHCP in mobile devices: > 1) in an ad hoc network ... there may not be a consistently available > single device - yes, it's hard to know which one to elect > 2) ad hoc connectivity makes it impossible to pick a viable routable subnet > 3) multicast may not have the full connectivity expected and is not always > reliable for discovery > 4) It's hard for users to configure (imagine setting the DHCP server > settings on your Wi-Fi enabled camera) > > Note - I'm currently working with consumer device manufacturers to field ad > hoc wireless products. IP address assignment is an issue ... and we may end > up fielding proprietary protocols. > > Link local might work ... but also has an issue with multicast ... and > needs some enhancements. > > Are there other proposals or protocols available for IP address assignment > in ad hoc wireless networks? > > Paul > There is SLAAC (RFC 2462). But you run into other problems with it on ad hoc networks, due to link properties in this context. Emmanuel ------=_Part_65156_10249495.1227298130398 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Fri, Nov 21, 2008 at 8:09 PM, Paul Lambert <paul@marvell.com> wrote:

> Well I mean in a MANET built out of off-the-shelf linux machines, where
> each one can easily run DHCP Server software.

There are several issues with using DHCP in mobile devices:
1) in an ad hoc network ... there may not be a consistently available single device - yes, it's hard to know which one to elect
2) ad hoc connectivity makes it impossible to pick a viable routable subnet
3) multicast may not have the full connectivity expected and is not always reliable for discovery
4) It's hard for users to configure (imagine setting the DHCP server settings on your Wi-Fi enabled camera)

Note - I'm currently working with consumer device manufacturers to field ad hoc wireless products.  IP address assignment is an issue ... and we may end up fielding proprietary protocols.

Link local might work ... but also has an issue with multicast ... and needs some enhancements.

Are there other proposals or protocols available for IP address assignment in ad hoc wireless networks?

Paul


There is SLAAC (RFC 2462). But you run into other problems with it on ad hoc networks, due to link properties in this context.
Emmanuel
------=_Part_65156_10249495.1227298130398-- --===============0935932559== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf --===============0935932559==-- From autoconf-bounces@ietf.org Fri Nov 21 18:08:43 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16CFC3A6834; Fri, 21 Nov 2008 18:08:43 -0800 (PST) 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 CE6673A6834 for ; Fri, 21 Nov 2008 18:08:40 -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 HruNvwF7EN-l for ; Fri, 21 Nov 2008 18:08:38 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 2113F3A6808 for ; Fri, 21 Nov 2008 18:08:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=kDuJPf+ptlFDF7qfCrZkergFdAErMYZ9w6nsm17irQl8NtVf8haiSNs7GrVTlqR7; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.138.86.46] (helo=[192.168.1.109]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L3hvG-00050F-Vs; Fri, 21 Nov 2008 21:08:35 -0500 Message-ID: <492769A1.1010702@earthlink.net> Date: Fri, 21 Nov 2008 18:08:33 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Paul Lambert References: <00c801c94b65$f3af1e90$db0d5bb0$@nl><4925FF7D.5050900@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A1053EF3CF@XCH-NW-7V2.nw.nos.boeing.com> <4926122A.4000501@earthlink.net> <00db01c94b8b$eed566b0$cc803410$@nl> <492648FD.8060004@earthlink.net> <49269BCF.10402@gmail.com> <4926BD40.3000201@polytechnique.edu> <4926C170.40707@gmail.com> <5A22FB9EDAA74547916480634CCC743817AD0BBCCD@SC-EXCH1.marvell.com> In-Reply-To: <5A22FB9EDAA74547916480634CCC743817AD0BBCCD@SC-EXCH1.marvell.com> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52ce12e18124c79d6c2514dab444e10125350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.138.86.46 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Alternative IP Address Assignment Mechanisms for Ad Hoc Wireless-> was RE: what if there's no DHCP Server around? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello Paul, Paul Lambert wrote: > > > Note - I'm currently working with consumer device manufacturers to field ad hoc wireless products. IP address assignment is an issue ... and we may end up fielding proprietary protocols. > > Link local might work ... but also has an issue with multicast ... and needs some enhancements. > > Are there other proposals or protocols available for IP address assignment in ad hoc wireless networks? > Yes! We've been arguing about subnets and links for so long, maybe people forgot why the working group was formed! There are some very interesting and some very straightforward approaches. These systems have been built and tested and found to be worthwhile. That was why we started the group, in the belief that a standard approach would create new markets for ad hoc networks, as well as providing new insights. Ryuji and I published what I thought was a very valuable approach lo these many years ago. I do not want to sound bitter, but the people complaining the most about lack of architecture do not seem to have contributed any of their solutions or experience with implementations. So I want to get past this definitional phase in a very definitive way, by actually identifying definitions that will satisfy even the most demanding aficionado of architectural correctness. This does _not_ mean sweeping anything under the rug. It means being correct, relevant, persuasive, coherent, and unyielding to the temptations of basing the definitions upon how many angels can dance on the head of an ad hoc pin. Regards, Charlie P. PS. I guess your note just reminded me of how long it has been. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 21 18:14:56 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 379053A69B1; Fri, 21 Nov 2008 18:14:56 -0800 (PST) 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 34E1C3A6971 for ; Fri, 21 Nov 2008 18:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.849 X-Spam-Level: X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+NeB3uIsnnr for ; Fri, 21 Nov 2008 18:14:53 -0800 (PST) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 5C15A3A694E for ; Fri, 21 Nov 2008 18:14:53 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.68.36]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAM2Ekx5026520; Sat, 22 Nov 2008 02:14:46 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAM2Eka0245544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Nov 2008 18:14:46 -0800 (PST) Message-ID: <49273A3C.60503@sun.com> Date: Fri, 21 Nov 2008 14:46:20 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.17 (X11/20081023) MIME-Version: 1.0 To: Teco Boot References: <4924C9AD.9030904@sun.com> <005301c94acc$cf862a70$6e927f50$@nl> In-Reply-To: <005301c94acc$cf862a70$6e927f50$@nl> Cc: autoconf@ietf.org Subject: Re: [Autoconf] Why the link definition? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Teco Boot wrote: > Just asking: what is the problem with using NS/NA exchanges to discover the > L2 addresses with the link defined as a "within radio range"? I don't what I said that made you think that is a problem. Once you know that an address is on-link then there is no problem to use NS/NA to find out the L2 address. But in a Manet in practice you might only end up using this for link-local address. The reason is that in order to know that a global address (any address that isn't link-local) is "reachable using one radio hop", you'd look at the Manet forwarding tables, and those tables might very well indicate the link-local address which is the IP next-hop to send the packet to. Hence you can just do the NS/NA for that link-local address (if you don't already have a neighbor cache entry for it.) > Another question: do we need an "IPv6 Packets over WiFi" RFC? There are > expired I-Ds. WiFi tries to look like an Ethernet, which means that we can use just "IPv6 over Ethernet". But that might not be the most efficient way to do it. Thus it might be that draft-shelby-6lowpan-nd (as it evolves) will be something that will be useful for WiFi or even Ethernet in general. Erik _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 21 18:14:56 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6464728C0DB; Fri, 21 Nov 2008 18:14:56 -0800 (PST) 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 42B053A6971 for ; Fri, 21 Nov 2008 18:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.863 X-Spam-Level: X-Spam-Status: No, score=-5.863 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUFB+czjo9il for ; Fri, 21 Nov 2008 18:14:54 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 6CCDA3A694E for ; Fri, 21 Nov 2008 18:14:54 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.226.130]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAM2EmZv029329; Sat, 22 Nov 2008 02:14:49 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAM2Eltg245547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Nov 2008 18:14:48 -0800 (PST) Message-ID: <49273F12.1000908@sun.com> Date: Fri, 21 Nov 2008 15:06:58 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.17 (X11/20081023) MIME-Version: 1.0 To: Teco Boot References: <200811191440.mAJEeRPu017560@cichlid.raleigh.ibm.com> <492442C9.60404@sun.com> <200811191700.mAJH0WeD000999@cichlid.raleigh.ibm.com> <4924A6BB.4070601@sun.com> <004d01c94aac$57b1a4e0$0714eea0$@nl> <4924CA09.7080607@polytechnique.edu> <005501c94ad1$51ab7060$f5025120$@nl> In-Reply-To: <005501c94ad1$51ab7060$f5025120$@nl> Cc: autoconf@ietf.org Subject: Re: [Autoconf] link definitions 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Teco Boot wrote: > We are on the same page. But be careful with the term subnet. I prefer using > routing prefix if we discuss routing. I'm starting to get the feeling we should stay away from "subnet" or "subnet prefix", since "subnet" has too much historical stuff associated with it. But the prefix will presumably be used for address configuration in addition to routing, thus "routing prefix" might be too specific. How about something like this: One (or more) IP address prefixes is assigned to a Manet. The IP address autoconfiguration is used to configure addresses from that/those prefixes, and typically the whole Manet is represented externally as a single aggregated route for each of those prefixes. The above definition doesn't preclude different parts ot the Manet to be allocated sub-prefixes or additional prefixes. Such prefixes can be assigned to fixed/wired/static links attached to Manet routers. Erik _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 21 18:24:07 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B530B3A69B1; Fri, 21 Nov 2008 18:24:07 -0800 (PST) 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 43D823A69BF for ; Fri, 21 Nov 2008 18:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.897 X-Spam-Level: X-Spam-Status: No, score=-5.897 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9eajIHnLXue for ; Fri, 21 Nov 2008 18:24:05 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id AA3D33A6971 for ; Fri, 21 Nov 2008 18:24:04 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.56.144]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAM2Eq7M029338; Sat, 22 Nov 2008 02:14:52 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAM2EmoO245550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Nov 2008 18:14:48 -0800 (PST) Message-ID: <49274147.6060607@sun.com> Date: Fri, 21 Nov 2008 15:16:23 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.17 (X11/20081023) MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <1227250017.19012.167.camel@localhost> In-Reply-To: <1227250017.19012.167.camel@localhost> Cc: autoconf@ietf.org Subject: Re: [Autoconf] About MANET Links, subnets, etc 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: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-15"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Carlos Jes=FAs Bernardos Cano wrote: > So, let me try to provide my (current) view on some of the things that > have been discussed. Most of them might have been already proposed by > others, so I'm just taking those pieces from here and there that I'm > happy with. > = > 1. About "MANET Links". I'm not completely sure we really need to > define anything new. I see MANETs as networks composed of a set of > routers that move. These routers have interfaces that belong to links -- > these links being defined by the L2 reachability/radio > coverage/connectivity of the interface. The difference is that these > links are quite dynamic (because the routers move) and might not have > some nice properties, such as transitivity, symmetry, etc (but this is > because of the L2 technology of the interface). Agreed. > 2. About "subnets" and addressing. In my understanding of a MANET, I > see each of the routers of a MANET getting one (or several) unique IPv6 > prefix. Out of that prefix, the MANET router configures and address for > its loopback interface. On the interface over which the MANET router > runs a MANET routing protocol, only a link-local address needs to be > configured. The router may be delegated more than one prefix, to > configure other physical interfaces (regular hosts might attach to these > interfaces, and configure IPv6 address from the delegated prefixes). The > MANET routing protocol takes care of providing reachability within the > MANET, MANET routers do not need to change their IP addresses due to > inner mobility within the MANET. That matches my understanding. > 3. About "links". I think the term "link" should be accompanied by the > layer for which the term "link" is meaningful. There might be L2 links > and L3 links and should not necessarily be the same. I'd say that a "LX > link" is defined by "what can be reached in 1 LX hop". In the case of > IP, an "L3/IP link" would be defined by what can be reached in 1 IP hop, > i.e. without decrementing the IPv6 hop count of the packet. While I agree in principle, I don't think we need to concern ourselves = with anything but "L3 link" (which RFC 2460 has defined as "link"). Furthermore, different L2 SDOs might have differing definitions of "L2 = link" (for instance, IEEE 802 has such a definition) so we are not the = authority on how to design such things. Thus, if possible, I think we = should stay away from defining "L2 link". > 4. About what we should do in the autoconf WG: to define the > mechanism(s) to provide each MANET router with a unique IPv6 prefix > (that could even be a /128). Something that might be tricky is how to > guarantee that configured link-local addresses on the MANET interfaces > are unique within the scope of the link, since that scope is quite > dynamic (members of that link change over time, and even not all the > members of that link may have the same view of the link). Potentially, a > solution would be to ensure that these addresses are unique within the > whole MANET, since that would ensure that they are in the scope of the > link. If you use EUI64-based link-local addresses, or RFC 4941 addresses, the = probability of collisions for the link-local addresses is extremely = small. It might make sense to have safety mechanism where the Manet can = continue to function in the presence of duplicate link-local addresses, = while one or both of the nodes with duplicates might end up being = disabled. But in general it might be hard to detect such duplicates = because you have do have some other distinguishing piece of information = to tell the difference between a node being reachable over two different = paths and two different nodes being identical clones. Erik _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Nov 21 18:24:07 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D958228C0DB; Fri, 21 Nov 2008 18:24:07 -0800 (PST) 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 BF2DA3A6971 for ; Fri, 21 Nov 2008 18:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.908 X-Spam-Level: X-Spam-Status: No, score=-5.908 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjSWmP8UBlEJ for ; Fri, 21 Nov 2008 18:24:05 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 956753A69B1 for ; Fri, 21 Nov 2008 18:24:05 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.56.36]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAM2ErWe029342; Sat, 22 Nov 2008 02:14:53 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAM2Equu245553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Nov 2008 18:14:52 -0800 (PST) Message-ID: <49275006.7010605@sun.com> Date: Fri, 21 Nov 2008 16:19:18 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.17 (X11/20081023) MIME-Version: 1.0 To: scicarus@iname.com References: <4924C84D.5050502@earthlink.net> In-Reply-To: Cc: autoconf@ietf.org Subject: Re: [Autoconf] Subnet definition 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Seung Yi wrote: > "Why was the concept of the "subnet" introduced in the first place?" > > I think the story might be something like this. First, there was an > Ethernet segment (or something similar), which is an L2 concept. One > of the characteristics of an Ethernet segment is, when one node on the > segment sends something, every other nodes on the segment can > hear/receive that. To abstract that concept (that I can reach everyone > by simply relying on L2 facility) in L3, one introduces the concept of > the "subnet". By carefully assigning IP addresses from a subnet range > to all nodes on a single Ethernet segment, one can enable L3 > communication between them without having to run a routing protocol. > So, the concept of the "subnet" seems nothing but an artificial > construct one uses in L3 to abstract underlying L2 connectivity. I went a looked over some old documents. A hopefully not too biased note of what I found: The term "subnet" appears to have been first used in RFC917 and other work that lead to RFC950. That was when the classful (A, B, and C) network numbers were carved up into smaller "subnets" for administrative or technical reasons. RFC1122 depicts the resulting IP address notation as We now summarize the important special cases for Class A, B, and C IP addresses, using the following notation for an IP address: { , } or { , , } The term subnet is also used in CIDR (RFC1519) where "variable-length subnets" is introduced. This is the notion that different pieces of a Class-A/B/C network can have different number of bits in the subnet-number. The IPv6 addressing architecture (starting with RFC 1884 and continuing to RFC4291) defines "subnet prefix" as N leading bits of an IPv6 address, and also states that Currently, IPv6 continues the IPv4 model in that a subnet prefix is associated with one link. Multiple subnet prefixes may be assigned to the same link. Thus there seems to be an assumption that a subnet can not span more than one link, but there doesn't seem to be any statements to that effect any RFCs prior to RFC1884. If we look at the earlier work for IPv4 on what is considered to be "on-link" e.g., for which addresses one would use ARP, it is interesting to note that ARP (RFC826) does not use the term "subnet" at all. Instead it describes things using "next hop": As a packet is sent down through the network layers, routing determines the protocol address of the next hop for the packet and on which piece of hardware it expects to find the station with the immediate target protocol address. In the case of the 10Mbit Ethernet, address resolution is needed and some lower layer (probably the hardware driver) must consult the Address Resolution module (perhaps implemented in the Ethernet support module) to convert the pair to a 48.bit Ethernet address. RFC1122 doesn't use the term "subnet" for the next-hop determination either. Instead section 3.3.1.1 talks about an "address mask" and a "subnet number", that is, "subnet number" remains an address allocation notion. At some point in time the ifconfig command in BSD got a "netmask" subcommand. It is interesting to note that it wasn't called a "subnetmask", even though today it might be casually viewed as such. I don't have the first version of the man page for ifconfig, but this description might be fairly old: Specify how much of the address to reserve for subdividing networks into subnetworks. The mask includes the network part of the local address and the subnet part, which is taken from the host field of the address. At some point folks started assigning multiple subnet prefixes to a single Ethernet. TBD: Find the term that was used for this. When IPv6 was developed the de-facto terminology seemed to be that "subnet" refered to both an address allocation notion and the piece of topology to which a subnet prefix is assigned. That might have been why RFC1883 ended up defining tthe term "link" and RFC1884 defining "subnet prefix". The reason for wanting to keep those separate was that with IPv6 we wanted to codify the existing IPv4 practice of "assigning multiple subnets to a subnet", that is, assigning multiple address prefixes to a link. Neighbor Discovery (RFC1970 through RFC4861) took things one step further by allowing separation of the address prefixes that are viewed as on-link (directly reachable without going through a router) and the address prefixes that can be used for stateless address autoconfiguration. Neighbor Discovery thus allows links to have no on-link prefixes at all (except for the link-local prefix). However, the Duplicate Address Detection functionality only checks for duplicates against the nodes that are on-link. --- Given the old de-facto use of "subnet" to mean both "Data Link subnetwork" (RFC1937) i.e., what we today call "link" and an address prefix, it makes sense to stay away from the unqualified term "subnet". Given the IPv6 addressing architecture seemingly assuming that a "subnet prefix" is on-link ("associated with one link"), perhaps we should not use "subnet prefix" to refer to an address prefix that is assigned to a collection of links, for the same reason that we don't call a /48 prefix a subnet prefix. Erik _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sat Nov 22 09:06:23 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BFEF3A690F; Sat, 22 Nov 2008 09:06:23 -0800 (PST) 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 4D38D3A690F for ; Sat, 22 Nov 2008 09:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 2f+5GDoq3ESn for ; Sat, 22 Nov 2008 09:06:21 -0800 (PST) Received: from hpsmtp-eml18.kpnxchange.com (hpsmtp-eml18.KPNXCHANGE.COM [213.75.38.118]) by core3.amsl.com (Postfix) with ESMTP id 4C3D13A68E1 for ; Sat, 22 Nov 2008 09:06:20 -0800 (PST) Received: from hpsmtp-eml07.kpnxchange.com ([213.75.38.107]) by hpsmtp-eml18.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 22 Nov 2008 18:06:18 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml07.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 22 Nov 2008 18:06:18 +0100 From: "Teco Boot" To: "'Erik Nordmark'" References: <4924C9AD.9030904@sun.com> <005301c94acc$cf862a70$6e927f50$@nl> <49273A3C.60503@sun.com> In-Reply-To: <49273A3C.60503@sun.com> Date: Sat, 22 Nov 2008 18:06:14 +0100 Message-ID: <003601c94cc4$a0392390$e0ab6ab0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclMSBwgMR3ZkPoTS0WdVjhmaGkSjQAd6uSg Content-Language: nl X-OriginalArrivalTime: 22 Nov 2008 17:06:18.0313 (UTC) FILETIME=[A2AA2390:01C94CC4] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Why the link definition? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Erik, > Teco Boot wrote: > > > Just asking: what is the problem with using NS/NA exchanges to > discover the > > L2 addresses with the link defined as a "within radio range"? > > I don't what I said that made you think that is a problem. > Once you know that an address is on-link then there is no problem to > use > NS/NA to find out the L2 address. > But in a Manet in practice you might only end up using this for > link-local address. The reason is that in order to know that a global > address (any address that isn't link-local) is "reachable using one > radio hop", you'd look at the Manet forwarding tables, and those tables > might very well indicate the link-local address which is the IP next- > hop > to send the packet to. Hence you can just do the NS/NA for that > link-local address (if you don't already have a neighbor cache entry > for > it.) Fully agree! The question was more or less a motivation to write down which parts of ND works well and which do not. If we define address-resolution for L2-addresses / link-local addresses in MANETs MUST work and address resolution may work, and we define that MANET Routing Protocols MUST use link-local addresses, we are done. I raised this issue in MANET, but little response at that moment. > > Another question: do we need an "IPv6 Packets over WiFi" RFC? There > are > > expired I-Ds. > > WiFi tries to look like an Ethernet, which means that we can use just > "IPv6 over Ethernet". But that might not be the most efficient way to > do > it. Thus it might be that draft-shelby-6lowpan-nd (as it evolves) will > be something that will be useful for WiFi or even Ethernet in general. I think it is important that IEEE and IETF agrees in how IPv6 is transported over 802.11 links. I have equipment on my desk that is WiFi certified but does not support IPv6. It has to do with bridging and MAC address mappings. Cause could be that IPv6 is missing in IEEE 802.11-2007 tables M.2 and M.3 (WLAN - Ethernet translation). Somebody can work out something for himself, but an RFC would help making sure everything is compatible. Other issues: - MTU size (what happens when 2000 octet frame arrives at access point?) - DAD and duplicate L2 addresses (see I-D.daniel-ipv6-over-wifi). Note that L2 address cloning is quite common in some communities. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sat Nov 22 09:22:10 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD4AD3A6958; Sat, 22 Nov 2008 09:22:10 -0800 (PST) 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 916B23A6958 for ; Sat, 22 Nov 2008 09:22:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 rOGAg31TucgC for ; Sat, 22 Nov 2008 09:22:08 -0800 (PST) Received: from hpsmtp-eml18.kpnxchange.com (hpsmtp-eml18.KPNXCHANGE.COM [213.75.38.118]) by core3.amsl.com (Postfix) with ESMTP id 8E2D13A67F9 for ; Sat, 22 Nov 2008 09:22:08 -0800 (PST) Received: from hpsmtp-eml09.kpnxchange.com ([213.75.38.109]) by hpsmtp-eml18.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 22 Nov 2008 18:22:06 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml09.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 22 Nov 2008 18:22:05 +0100 From: "Teco Boot" To: "'Erik Nordmark'" References: <200811191440.mAJEeRPu017560@cichlid.raleigh.ibm.com> <492442C9.60404@sun.com> <200811191700.mAJH0WeD000999@cichlid.raleigh.ibm.com> <4924A6BB.4070601@sun.com> <004d01c94aac$57b1a4e0$0714eea0$@nl> <4924CA09.7080607@polytechnique.edu> <005501c94ad1$51ab7060$f5025120$@nl> <49273F12.1000908@sun.com> In-Reply-To: <49273F12.1000908@sun.com> Date: Sat, 22 Nov 2008 18:22:01 +0100 Message-ID: <003701c94cc6$d52bc1a0$7f8344e0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclMSBy4ZfFDHZbDSwmNhBpSWjOA5gAfM1HA Content-Language: nl X-OriginalArrivalTime: 22 Nov 2008 17:22:06.0013 (UTC) FILETIME=[D789AED0:01C94CC6] Cc: autoconf@ietf.org Subject: Re: [Autoconf] link definitions 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Erik, > -----Oorspronkelijk bericht----- > Van: Erik Nordmark [mailto:erik.nordmark@sun.com] > Verzonden: zaterdag 22 november 2008 0:07 > Aan: Teco Boot > CC: 'Ulrich Herberg'; autoconf@ietf.org > Onderwerp: Re: [Autoconf] link definitions > > Teco Boot wrote: > > > We are on the same page. But be careful with the term subnet. I > prefer using > > routing prefix if we discuss routing. > > I'm starting to get the feeling we should stay away from "subnet" or > "subnet prefix", since "subnet" has too much historical stuff > associated > with it. > > But the prefix will presumably be used for address configuration in > addition to routing, thus "routing prefix" might be too specific. I don't see that much a problem using "prefix", as the issues were we are working on is handled by routers. Hosts in a MANET (e.g. connected to a MANET Router via Ethernet or infrastructure mode WLAN) MUST be provided a ND service as specified in RFC4861 / RFC4862. Routers shall be able to handle address prefixes, including host prefixes (alias for address, but more related to a router). > How about something like this: > One (or more) IP address prefixes is assigned to a Manet. The IP > address > autoconfiguration is used to configure addresses from that/those > prefixes, and typically the whole Manet is represented externally as a > single aggregated route for each of those prefixes. OK, but I don't agree on "_single_ aggregated route". I think multi-homing SHOULD be supported. And it is not that difficult (here another advertisement for BRDP-Based-Routing). Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sat Nov 22 09:29:48 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF3D63A6958; Sat, 22 Nov 2008 09:29:48 -0800 (PST) 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 1331B3A6958 for ; Sat, 22 Nov 2008 09:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 LU2T1D9f1Ez8 for ; Sat, 22 Nov 2008 09:29:46 -0800 (PST) Received: from hpsmtp-eml12.kpnxchange.com (hpsmtp-eml12.KPNXCHANGE.COM [213.75.38.112]) by core3.amsl.com (Postfix) with ESMTP id 079F03A67F9 for ; Sat, 22 Nov 2008 09:29:45 -0800 (PST) Received: from hpsmtp-eml10.kpnxchange.com ([213.75.38.110]) by hpsmtp-eml12.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 22 Nov 2008 18:29:44 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml10.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 22 Nov 2008 18:29:43 +0100 From: "Teco Boot" To: "'Erik Nordmark'" , References: <1227250017.19012.167.camel@localhost> <49274147.6060607@sun.com> In-Reply-To: <49274147.6060607@sun.com> Date: Sat, 22 Nov 2008 18:29:39 +0100 Message-ID: <003801c94cc7$e6030410$b2090c30$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclMSWbuArI2dET2QlyUR8RdhqbLTgAfbe+g Content-Language: nl X-OriginalArrivalTime: 22 Nov 2008 17:29:43.0791 (UTC) FILETIME=[E8650FF0:01C94CC7] Cc: autoconf@ietf.org Subject: Re: [Autoconf] About MANET Links, subnets, etc 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Erik, cjbc@it.uc3m.es wrote: > > 3. About "links". I think the term "link" should be accompanied > by the > > layer for which the term "link" is meaningful. There might be L2 > links > > and L3 links and should not necessarily be the same. I'd say that a > "LX > > link" is defined by "what can be reached in 1 LX hop". In the case of > > IP, an "L3/IP link" would be defined by what can be reached in 1 IP > hop, > > i.e. without decrementing the IPv6 hop count of the packet. > > While I agree in principle, I don't think we need to concern ourselves > with anything but "L3 link" (which RFC 2460 has defined as "link"). > Furthermore, different L2 SDOs might have differing definitions of "L2 > link" (for instance, IEEE 802 has such a definition) so we are not the > authority on how to design such things. Thus, if possible, I think we > should stay away from defining "L2 link". > > > 4. About what we should do in the autoconf WG: to define the > > mechanism(s) to provide each MANET router with a unique IPv6 prefix > > (that could even be a /128). Something that might be tricky is how to > > guarantee that configured link-local addresses on the MANET > interfaces > > are unique within the scope of the link, since that scope is quite > > dynamic (members of that link change over time, and even not all the > > members of that link may have the same view of the link). > Potentially, a > > solution would be to ensure that these addresses are unique within > the > > whole MANET, since that would ensure that they are in the scope of > the > > link. > > If you use EUI64-based link-local addresses, or RFC 4941 addresses, the > probability of collisions for the link-local addresses is extremely > small. It might make sense to have safety mechanism where the Manet can > continue to function in the presence of duplicate link-local addresses, > while one or both of the nodes with duplicates might end up being > disabled. But in general it might be hard to detect such duplicates > because you have do have some other distinguishing piece of information > to tell the difference between a node being reachable over two > different > paths and two different nodes being identical clones. In fact, IEEE 802.11 itself prevents detecting duplicate MAC addresses (see other posting). But we could think of some kind of detection mechanism, e.g. with help from the MANET routing protocol. I think this has second priority, although it is an interesting topic. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sun Nov 23 16:23:06 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77E503A6A36; Sun, 23 Nov 2008 16:23:06 -0800 (PST) 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 829293A6A36 for ; Sun, 23 Nov 2008 16:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j44-Uu-GHCyW for ; Sun, 23 Nov 2008 16:23:04 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id DB9E93A6846 for ; Sun, 23 Nov 2008 16:23:04 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so2054484wfd.31 for ; Sun, 23 Nov 2008 16:23:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=H/Mle7E6bXwGojkTeyOiuEd+TngnpQweFGRjtuPqhx0=; b=RYNhLg7VfRXRG6L4NR10jXt5X67+oi/trTa1tQWLDBCwjl3GBrVqrLq35w4A/tSi6V O25ajfqOQcA0ntE87PYZZiNocIGa8D7Tfu72kVbEn4HPyDbD2AXU0F417rYlrja1YSOh TUoSINazuvr58ErRP1SbFG/GW4wHBut3bNr4s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=OLBhIxHP8+7fqtR7JJDZnVl5rtJDaoVbI68+wHoYT9XG8eQ+jpVzJgDNdlR+yu7N/W WjNSq6T6wRT69z34oXVDlOCKbdemoKcWFGdKz+C4Odpvq4kdjA9KP+E4f4pCMHsGjc/Z UOPqtJe6t0B/fd12QUt5ZzE71sh/54DOCeSEg= Received: by 10.142.48.14 with SMTP id v14mr1380264wfv.61.1227486182290; Sun, 23 Nov 2008 16:23:02 -0800 (PST) Received: by 10.143.108.9 with HTTP; Sun, 23 Nov 2008 16:23:02 -0800 (PST) Message-ID: Date: Sun, 23 Nov 2008 16:23:02 -0800 From: "Seung Yi" To: "Erik Nordmark" In-Reply-To: <49275006.7010605@sun.com> MIME-Version: 1.0 Content-Disposition: inline References: <4924C84D.5050502@earthlink.net> <49275006.7010605@sun.com> X-Google-Sender-Auth: 54e07ada993541ec Cc: autoconf@ietf.org Subject: Re: [Autoconf] Subnet definition 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Great summary, Erik. This was exactly what I had in mind but didn't have a chance to do myself. I really appreciate your taking time. > The IPv6 addressing architecture (starting with RFC 1884 and continuing to > RFC4291) defines "subnet prefix" as N leading bits of an IPv6 address, and > also states that > Currently, IPv6 continues the IPv4 model in that a subnet prefix is > associated with one link. Multiple subnet prefixes may be assigned > to the same link. > Thus there seems to be an assumption that a subnet can not span more than > one link, but there doesn't seem to be any statements to that effect any > RFCs prior to RFC1884. > So, there are documents that explicitly map a link and a subnet. I'm just curious. Have you run into any document that actually states "IPv4 model" mentioned in above sentence? Thanks, - Seung _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sun Nov 23 16:29:43 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B0FF28C0FE; Sun, 23 Nov 2008 16:29:43 -0800 (PST) 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 172F328C111 for ; Sun, 23 Nov 2008 16:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTO2Kam1LbKL for ; Sun, 23 Nov 2008 16:29:40 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id 5CFFC28C0ED for ; Sun, 23 Nov 2008 16:29:40 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so1787125rvf.49 for ; Sun, 23 Nov 2008 16:29:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=Nt4+iCs3sYLAKMhQOB5DJfNkrQ/PVD9R3/mrHrIQLY4=; b=jyoBpSz5UZfaOwrFsgTNdrWSQRYEjcDorwKFFOJ0N9SMSIh9bIZ9VVzWG5EVwX/1s4 4wnR9vf9ncXYLGwUK1WCChQp8a080TGxHRHZhgMKOf6b7ECvtEkbUylQWnzxFzFupYuH 6lon40uYcDZ/OYwa87siJVJvzNqnB+wxVO9uc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=Spguf43CawNESCxzPqGwgySgI8BJ7Q8lWdtIkWcol3rZIzKQ8rrcL/mzoVL7SU6MLA pfmorpwD6TW1IOpPHkEByHSIPXqiLK4pqEbVdsJGsPM09GvLeEHm03ulaOFsH8mZOu22 hEAaaauRqwXTkOoWTGJRLQAgw+4J2FiHWmq7w= Received: by 10.142.102.5 with SMTP id z5mr1358980wfb.334.1227486578444; Sun, 23 Nov 2008 16:29:38 -0800 (PST) Received: by 10.143.108.9 with HTTP; Sun, 23 Nov 2008 16:29:38 -0800 (PST) Message-ID: Date: Sun, 23 Nov 2008 16:29:38 -0800 From: "Seung Yi" To: "Teco Boot" In-Reply-To: <007301c94b2b$7bfa06b0$73ee1410$@nl> MIME-Version: 1.0 Content-Disposition: inline References: <4924C84D.5050502@earthlink.net> <005601c94ad3$32cfbdc0$986f3940$@nl> <007301c94b2b$7bfa06b0$73ee1410$@nl> X-Google-Sender-Auth: 8512ef79f1665d89 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Subnet definition 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org A bit late reply. :) On Thu, Nov 20, 2008 at 8:17 AM, Teco Boot wrote: >> I actually tried using the loopback interface. It's not as >> straightforward as it seems. For example, binding an application to >> use the address on the loopback is not very simple without modifying >> the app. > > Are we discussing a RFC3484 compliant router? > Well, I was not, actually. Just re-read 3484 and it seems to be addressed in there. Any clue if RFC 3484 is implemented somewhere already? >> By "they", I meant "ND and link-local multicast". I tried to say "ND >> and link-local multicast" cannot be used as MANET-wide communication >> primitives. There is no problem with address assignments. > > You described a problem with MANET-wide communications and problems. > Did you mean that with LL addresses you cannot reach the whole MANET / whole > Internet? > This is by definition. Or am I missing something? > No. You're right that it is according to definition. I was commenting that we might need to provide a MANET-wide replacement for what ND does on a link for various reasons. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sun Nov 23 16:46:32 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED54628C11B; Sun, 23 Nov 2008 16:46:32 -0800 (PST) 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 1961328C11B for ; Sun, 23 Nov 2008 16:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.918 X-Spam-Level: X-Spam-Status: No, score=-5.918 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsjnV-WVXG0T for ; Sun, 23 Nov 2008 16:46:31 -0800 (PST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by core3.amsl.com (Postfix) with ESMTP id 65A5F28C0ED for ; Sun, 23 Nov 2008 16:46:31 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.17.55]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAO0kRub014619; Mon, 24 Nov 2008 00:46:28 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAO0kQwT293499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 23 Nov 2008 16:46:26 -0800 (PST) Message-ID: <4929F962.5070102@sun.com> Date: Sun, 23 Nov 2008 16:46:26 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.17 (X11/20081023) MIME-Version: 1.0 To: Seung Yi References: <4924C84D.5050502@earthlink.net> <49275006.7010605@sun.com> In-Reply-To: Cc: autoconf@ietf.org Subject: Re: [Autoconf] Subnet definition 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Seung Yi wrote: >> The IPv6 addressing architecture (starting with RFC 1884 and continuing to >> RFC4291) defines "subnet prefix" as N leading bits of an IPv6 address, and >> also states that >> Currently, IPv6 continues the IPv4 model in that a subnet prefix is >> associated with one link. Multiple subnet prefixes may be assigned >> to the same link. >> Thus there seems to be an assumption that a subnet can not span more than >> one link, but there doesn't seem to be any statements to that effect any >> RFCs prior to RFC1884. >> > > So, there are documents that explicitly map a link and a subnet. I'm > just curious. Have you run into any document that actually states > "IPv4 model" mentioned in above sentence? I didn't find any RFCs prior to RFC1884 that explictly talked about the IPv4 model. RFC950 does state that the subnets correspond to a "LAN cable" and has an algorithm that is based on comparing whether the destination is part of the local 'address&mask'. The evolution to allow multiple subnet prefixes on a one physical network isn't defined in an RFC AFAICT; it was something that was done in various products. Erik _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sun Nov 23 23:48:16 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 895C83A6AD1; Sun, 23 Nov 2008 23:48:16 -0800 (PST) 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 7E8643A6AD1 for ; Sun, 23 Nov 2008 23:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWfUuauLzu9p for ; Sun, 23 Nov 2008 23:48:13 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 6B5663A6405 for ; Sun, 23 Nov 2008 23:48:12 -0800 (PST) Received: (qmail 22125 invoked from network); 24 Nov 2008 08:48:09 +0100 Received: from unknown (HELO M90Teco) (77.61.241.211) by server9.hosting2go.nl with SMTP; 24 Nov 2008 08:48:09 +0100 From: "Teco Boot" To: "'Seung Yi'" References: <4924C84D.5050502@earthlink.net> <005601c94ad3$32cfbdc0$986f3940$@nl> <007301c94b2b$7bfa06b0$73ee1410$@nl> In-Reply-To: Date: Mon, 24 Nov 2008 08:47:35 +0100 Message-ID: <001501c94e08$fca75760$f5f60620$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclNy72De8RZQ7P0S+CgQ2mVPK5dQwAPAqDg Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] Subnet definition 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Seung, > >> By "they", I meant "ND and link-local multicast". I tried to say "ND > >> and link-local multicast" cannot be used as MANET-wide communication > >> primitives. There is no problem with address assignments. > > > > You described a problem with MANET-wide communications and problems. > > Did you mean that with LL addresses you cannot reach the whole MANET > / whole > > Internet? > > This is by definition. Or am I missing something? > > > > No. You're right that it is according to definition. I was commenting > that we might need to provide a MANET-wide replacement for what ND > does on a link for various reasons. I am not sure to go in that direction. All kind of scoping makes the addressing architecture complex. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 24 00:40:59 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93BC53A67D8; Mon, 24 Nov 2008 00:40:59 -0800 (PST) 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 402D63A67D8 for ; Mon, 24 Nov 2008 00:40:58 -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=[AWL=0.000, 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 0zoLSfTvOEjY for ; Mon, 24 Nov 2008 00:40:57 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.190]) by core3.amsl.com (Postfix) with ESMTP id D46533A67AA for ; Mon, 24 Nov 2008 00:40:56 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id 18so2274910fkq.5 for ; Mon, 24 Nov 2008 00:40:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=ANpYUuKgnNbHBnSWR0gHUtqVYCmEl8LOVWKMUsSb5xA=; b=dTAEgEpHiijBseIuwZhzx6wxYtmi8i7AQhaLbA3CombW75wAXyYzNtCnfQmGG/V355 lH15u2NnsRtISm9WYeo2Chzwlq+mcjPkKWsbgjr+FZH/cFv0LLdnpe/DOP7iPdMmKdr5 AtakOKqpFDJK/75vVp6ngTZz/F/uYOlalNSwc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=VTYh2Y448lkv5oUHcu52i5NT33M+kIGN72noNtJ6oqBWYqEpCg+YFMCXjEK2agQURH e5c6EDIrgWK4TiQjevuJtq/2NgL07IOcs8fk7BM6cY/T0jE1Ge+9AR2jvNx6P3UQqLLD I/EHnjxVpBFfwcqkSlYw3XDj7AUZPsuLRp7eo= Received: by 10.181.11.3 with SMTP id o3mr1041846bki.172.1227516052787; Mon, 24 Nov 2008 00:40:52 -0800 (PST) Received: by 10.181.201.6 with HTTP; Mon, 24 Nov 2008 00:40:52 -0800 (PST) Message-ID: Date: Mon, 24 Nov 2008 09:40:52 +0100 From: "Emmanuel Baccelli" To: autoconf@ietf.org In-Reply-To: <4929F962.5070102@sun.com> MIME-Version: 1.0 References: <4924C84D.5050502@earthlink.net> <49275006.7010605@sun.com> <4929F962.5070102@sun.com> X-Google-Sender-Auth: 7ddcad4b976a7447 Subject: Re: [Autoconf] Subnet definition 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: , Content-Type: multipart/mixed; boundary="===============1763157494==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============1763157494== Content-Type: multipart/alternative; boundary="----=_Part_80738_4506220.1227516052773" ------=_Part_80738_4506220.1227516052773 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Erik, On Mon, Nov 24, 2008 at 1:46 AM, Erik Nordmark wrote: > Seung Yi wrote: > > The IPv6 addressing architecture (starting with RFC 1884 and continuing to >>> RFC4291) defines "subnet prefix" as N leading bits of an IPv6 address, >>> and >>> also states that >>> Currently, IPv6 continues the IPv4 model in that a subnet prefix is >>> associated with one link. Multiple subnet prefixes may be assigned >>> to the same link. >>> Thus there seems to be an assumption that a subnet can not span more than >>> one link, but there doesn't seem to be any statements to that effect any >>> RFCs prior to RFC1884. >>> >>> >> So, there are documents that explicitly map a link and a subnet. I'm >> just curious. Have you run into any document that actually states >> "IPv4 model" mentioned in above sentence? >> > > I didn't find any RFCs prior to RFC1884 that explictly talked about the > IPv4 model. RFC950 does state that the subnets correspond to a "LAN cable" > and has an algorithm that is based on comparing whether the destination is > part of the local 'address&mask'. > > The evolution to allow multiple subnet prefixes on a one physical network > isn't defined in an RFC AFAICT; it was something that was done in various > products. > > Erik > Thanks. So unless someone objects, there is indeed a consensus on the terms below. The only question (raised by Charlie) was about the term "subnet", but it is cleared with pointers to RFC1884 and RFC950 indicated by Erick: - a prefix defines a contiguous range of IP addresses.- a subnet is a set of IP addresses (that may or may not be a prefix) that are on the same link. These addresses are then on-link with respect to this link. All other addresses are off-link. - a link is what lower layers reach without TTL decrement, through a given interface. Let's try these as starting points. cheers Emmanuel ------=_Part_80738_4506220.1227516052773 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Erik,

On Mon, Nov 24, 2008 at 1:46 AM, Erik Nordmark <erik.nordmark@sun.com> wrote:
Seung Yi wrote:

The IPv6 addressing architecture (starting with RFC 1884 and continuing to
RFC4291) defines "subnet prefix" as N leading bits of an IPv6 address, and
also states that
 Currently, IPv6 continues the IPv4 model in that a subnet prefix is
 associated with one link.  Multiple subnet prefixes may be assigned
 to the same link.
Thus there seems to be an assumption that a subnet can not span more than
one link, but there doesn't seem to be any statements to that effect any
RFCs prior to RFC1884.


So, there are documents that explicitly map a link and a subnet. I'm
just curious. Have you run into any document that actually states
"IPv4 model" mentioned in above sentence?

I didn't find any RFCs prior to RFC1884 that explictly talked about the IPv4 model. RFC950 does state that the subnets correspond to a "LAN cable" and has an algorithm that is based on comparing whether the destination is part of the local 'address&mask'.

The evolution to allow multiple subnet prefixes on a one physical network isn't defined in an RFC AFAICT; it was something that was done in various products.

  Erik



Thanks. So unless someone objects, there is indeed a consensus on the terms below. The only question (raised by Charlie) was about the term "subnet", but it is cleared with pointers to RFC1884 and RFC950 indicated by Erick:

- a prefix defines a contiguous range of IP addresses.
- a subnet is a set of IP addresses (that may or may not be a prefix)
that are on the same link. These addresses are then on-link with
respect to this link. All other addresses are off-link.
- a link is what lower layers reach without TTL decrement, through a given interface.

Let's try these as starting points.
cheers
Emmanuel

------=_Part_80738_4506220.1227516052773-- --===============1763157494== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf --===============1763157494==-- From autoconf-bounces@ietf.org Mon Nov 24 01:50:54 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A22273A6B97; Mon, 24 Nov 2008 01:50:54 -0800 (PST) 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 A5BE93A6B97 for ; Mon, 24 Nov 2008 01:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.404 X-Spam-Level: X-Spam-Status: No, score=-1.404 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, 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 NnVCAwn6lfpQ for ; Mon, 24 Nov 2008 01:50:48 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id E86D63A6B78 for ; Mon, 24 Nov 2008 01:50:47 -0800 (PST) Received: (qmail 19806 invoked from network); 24 Nov 2008 10:50:43 +0100 Received: from unknown (HELO M90Teco) (77.61.241.211) by server9.hosting2go.nl with SMTP; 24 Nov 2008 10:50:43 +0100 From: "Teco Boot" To: "'Emmanuel Baccelli'" , References: <4924C84D.5050502@earthlink.net> <49275006.7010605@sun.com> <4929F962.5070102@sun.com> In-Reply-To: Date: Mon, 24 Nov 2008 10:50:13 +0100 Message-ID: <002101c94e1a$1e00e0a0$5a02a1e0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclOEGPxGzfaQ0feT06A45TRMDZo4QABYcTQ Content-Language: nl Subject: Re: [Autoconf] Subnet definition 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: , Content-Type: multipart/mixed; boundary="===============0502366935==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Dit is een meerdelig bericht met een MIME-indeling. --===============0502366935== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01C94E22.7FC548A0" Content-Language: nl Dit is een meerdelig bericht met een MIME-indeling. ------=_NextPart_000_0022_01C94E22.7FC548A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks. So unless someone objects, there is indeed a consensus on the terms below. The only question (raised by Charlie) was about the term "subnet", but it is cleared with pointers to RFC1884 and RFC950 indicated by Erick: - a prefix defines a contiguous range of IP addresses. - a subnet is a set of IP addresses (that may or may not be a prefix) that are on the same link. These addresses are then on-link with respect to this link. All other addresses are off-link. - a link is what lower layers reach without TTL decrement, through a given interface. Let's try these as starting points. OK, but still I think the definitions are vague. For example, the term prefix is has restrictions in range (^2 block). Let's xref to RFC4291 here. And in this RFC (which is Standards Track), "subnet" has a very different meaning than what is often suggested on this ML. On subnet: "may or may not". I think this makes the "definition" extremely vague. Why can't we use RFC2460 / RFC4861 terminology? prefix - a bit string that consists of some number of initial bits of an address. link - a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP. Examples are Ethernets (simple or bridged), PPP links, X.25, Frame Relay, or ATM networks as well as Internet-layer (or higher-layer) "tunnels", such as tunnels over IPv4 or IPv6 itself. interface - a node's attachment to a link. RFC4291 defines what a "subnet prefix" and a "subnet ID" is. Text is somewhat too long to include here. On link, we could borrow from a L2-link definition for 802.11-2007: 3.76 link: In the context of an IEEE 802.11 medium access control (MAC) entity, a physical path consisting of exactly one traversal of the wireless medium (WM) that is used to transfer an MAC service data unit (MSDU) between two stations (STAs). IPv6-link: In the context of IPv6 addressing architecture [RFC4291], a logical path consisting of exactly one traversal of link layer communication facility that is used to transfer an IP packet between two IP nodes without decrementing Lop Limit. Teco. cheers Emmanuel ------=_NextPart_000_0022_01C94E22.7FC548A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

Thanks. So unless someone objects, there is indeed = a consensus on the terms below. The only question (raised by Charlie) was = about the term "subnet", but it is cleared with pointers = to RFC1884 and RFC950 indicated by Erick:

 

- a prefix defines a = contiguous range of IP addresses.

- a subnet is a set = of IP addresses (that may or may not be a prefix)

that are on the same = link. These addresses are then on-link with
respect to this link. All other addresses = are off-link.
- a link is what lower layers reach = without TTL decrement, through a given interface.

 

Let's try these as = starting points.

 

OK, but still I think the definitions are = vague.

For example, the term prefix is has restrictions in range = (^2 block). Let’s xref to RFC4291 here.

And in this RFC (which is Standards Track), = “subnet” has a very different meaning than what is often suggested on this = ML.

 

On subnet: “may or may not”. I think this = makes the “definition” extremely vague.

 

Why can’t we use RFC2460 / RFC4861 = terminology?

   =

 prefix      - a bit string that consists of some number of = initial

         = ;        bits of an address.

  =

  = link        - a communication facility or medium over which nodes = can

         = ;        communicate at the link layer, i.e., the layer

         = ;        immediately below IP.  Examples are Ethernets = (simple

         = ;        or bridged), PPP links, X.25, Frame Relay, or = ATM

         = ;        networks as well as Internet-layer (or = higher-layer)

         = ;        "tunnels", such as tunnels over IPv4 or IPv6 = itself.

 

   interface   - a node's attachment = to a link.

 

RFC4291 defines what a “subnet prefix” and a = “subnet ID” is. Text is somewhat too long to include = here.

 

On link, we could borrow from a L2-link definition for 802.11-2007:

 

3.76 link: In the context of an = IEEE 802.11 medium access control (MAC) entity, a physical path = consisting

of exactly one traversal of the wireless medium (WM) that is used to transfer an MAC service data = unit

(MSDU) between two stations = (STAs).

 

 

IPv6-link: In the context of = IPv6 addressing architecture [RFC4291], a logical path = consisting

of exactly one traversal of = link layer communication facility that is used to transfer an IP packet between two = IP nodes without decrementing Lop Limit.

 

 

Teco.

 

cheers

Emmanuel

 

------=_NextPart_000_0022_01C94E22.7FC548A0-- --===============0502366935== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf --===============0502366935==-- From autoconf-bounces@ietf.org Mon Nov 24 02:50:52 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 701F53A67D0; Mon, 24 Nov 2008 02:50:52 -0800 (PST) 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 952943A67D0 for ; Mon, 24 Nov 2008 02:50:51 -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 1EAHqMY1Gmq9 for ; Mon, 24 Nov 2008 02:50:50 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id E0D883A67B3 for ; Mon, 24 Nov 2008 02:50:49 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id d23so1625627fga.41 for ; Mon, 24 Nov 2008 02:50:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=+JjX0dZpbf6D7zcALK0skHsRGrJbKoIkibR5E7/4e+4=; b=Qy4Mv1bdriGTwahYIIg1Q4awPO5MBOwflF8/BXZ36cD3aCfWAezKI5OW0ofK4GR/KB vHwy6+JgLeOmSmi2F3J4fsWH0a2WwCsMh3lowwbvb9KMLBsNJK1MxGMnQvFnYpt+PpBy T8kD1JWROwH4y5Nbdk5YEMqVHrl9R+n/K0arA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=m3HpGQ39TQXyBWaESte5RhWa5yUUHLYQiIlfQ2NLyFJw2hP4o+RasLNGF4GlJj4xDM XjUGvyGelpzt5BhGjhNgt9Mt1EC7U3MuIQ3ueRDyOGpeZgQXlQGRq6cesEvkuQ/gFkMW ydg/yDTXhSsPOlvvPoEm5d8N2RXfGO4ayxf2E= Received: by 10.180.255.1 with SMTP id c1mr1094862bki.36.1227523845951; Mon, 24 Nov 2008 02:50:45 -0800 (PST) Received: by 10.181.201.6 with HTTP; Mon, 24 Nov 2008 02:50:45 -0800 (PST) Message-ID: Date: Mon, 24 Nov 2008 11:50:45 +0100 From: "Emmanuel Baccelli" To: autoconf@ietf.org In-Reply-To: <002101c94e1a$1e00e0a0$5a02a1e0$@nl> MIME-Version: 1.0 References: <4924C84D.5050502@earthlink.net> <49275006.7010605@sun.com> <4929F962.5070102@sun.com> <002101c94e1a$1e00e0a0$5a02a1e0$@nl> X-Google-Sender-Auth: 7e7b22251e221401 Subject: Re: [Autoconf] Subnet definition 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: , Content-Type: multipart/mixed; boundary="===============0861297853==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============0861297853== Content-Type: multipart/alternative; boundary="----=_Part_82110_28835603.1227523845943" ------=_Part_82110_28835603.1227523845943 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Teco, OK Let's refine. On Mon, Nov 24, 2008 at 10:50 AM, Teco Boot wrote > > *On subnet: "may or may not". I think this makes the "definition" > extremely vague.* > > * * > I agree, let's remove it. > ** > > *Why can't we use RFC2460 / RFC4861 terminology?* > > * * > > * prefix - a bit string that consists of some number of initial* > > * bits of an address.* > > * * > > * link - a communication facility or medium over which nodes can* > > * communicate at the link layer, i.e., the layer* > > * immediately below IP. Examples are Ethernets (simple* > > * or bridged), PPP links, X.25, Frame Relay, or ATM* > > * networks as well as Internet-layer (or higher-layer)* > > * "tunnels", such as tunnels over IPv4 or IPv6 itself.* > > * * > > * interface - a node's attachment to a link.* > > * * > > *RFC4291 defines what a "subnet prefix" and a "subnet ID" is. Text is > somewhat too long to include here.* > > * * > Yes. This is too vague compared to the earlier references pointed out by Erick (RFC1884 and RFC950). I think we have to be clear on this, so I'd rather stick with we have for now. > ** > > *On link, we could borrow from a L2-link definition for 802.11-2007:* > > *IPv6-link: In the context of IPv6 addressing architecture [RFC4291], a > logical path consisting* > > *of exactly one traversal of link layer communication facility that is > used to transfer an IP packet between two IP nodes without decrementing Lop > Limit.* > > * * > > *Teco * > I guess this is a routing-based definition, talking about a path. We are rather trying to have a definition based on the addressing scheme, so maybe we could talk about a scope instead? We would then have the following: - a prefix defines a contiguous range of IP addresses, represented by the initial bit string common to all these addresses (as per RFC4291). - a subnet is a set of IP addresses that are on the same link (as per RFC1884 and RFC950). These addresses are then on-link with respect to this link. All other addresses are off-link. - a link is the logical scope that layer 2 provides, for IP packet transfer without TTL decrement, through a given interface. - an interface is a node's attachment to a link (as per RFC4861). Emmanuel ------=_Part_82110_28835603.1227523845943 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Teco, 

OK Let's refine.


On Mon, Nov 24, 2008 at 10:50 AM, Teco Boot <teco@inf-net.nl> wrote 

On subnet: "may or may not". I think this makes the "definition" extremely vague.

 

I agree, let's remove it.
 

Why can't we use RFC2460 / RFC4861 terminology?

  

 prefix      - a bit string that consists of some number of initial

                 bits of an address.

 

  link        - a communication facility or medium over which nodes can

                 communicate at the link layer, i.e., the layer

                 immediately below IP.  Examples are Ethernets (simple

                 or bridged), PPP links, X.25, Frame Relay, or ATM

                 networks as well as Internet-layer (or higher-layer)

                 "tunnels", such as tunnels over IPv4 or IPv6 itself.

 

   interface   - a node's attachment to a link.

 

RFC4291 defines what a "subnet prefix" and a "subnet ID" is. Text is somewhat too long to include here.

 


Yes. This is too vague compared to the earlier references pointed out by Erick (RFC1884 and RFC950). I think we have to be clear on this, so I'd rather stick with we have for now.
 

On link, we could borrow from a L2-link definition for 802.11-2007:

IPv6-link: In the context of IPv6 addressing architecture [RFC4291], a logical path consisting

of exactly one traversal of link layer communication facility that is used to transfer an IP packet between two IP nodes without decrementing Lop Limit.

 

Teco 


I guess this is a routing-based definition, talking about a path. We are rather trying to have a definition based on the addressing scheme, so maybe we could talk about a scope instead? We would then have the following:

- a prefix defines a contiguous range of IP addresses, represented by the initial bit string common to all these addresses (as per RFC4291).

- a subnet is a set of IP addresses that are on the same link (as per RFC1884 and RFC950). These addresses are then on-link with respect to this link. All other addresses are off-link.

- a link is the logical scope that layer 2 provides, for IP packet transfer without TTL decrement, through a given interface.

- an interface is a node's attachment to a link (as per RFC4861).



Emmanuel


------=_Part_82110_28835603.1227523845943-- --===============0861297853== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf --===============0861297853==-- From autoconf-bounces@ietf.org Mon Nov 24 03:17:55 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3467C3A6880; Mon, 24 Nov 2008 03:17:55 -0800 (PST) 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 576693A6880 for ; Mon, 24 Nov 2008 03:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[AWL=-0.855, BAYES_20=-0.74, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, 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 0rZua1pgj6bN for ; Mon, 24 Nov 2008 03:17:53 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 493B83A683A for ; Mon, 24 Nov 2008 03:17:52 -0800 (PST) Received: (qmail 6424 invoked from network); 24 Nov 2008 12:17:48 +0100 Received: from unknown (HELO M90Teco) (77.61.241.211) by server9.hosting2go.nl with SMTP; 24 Nov 2008 12:17:48 +0100 From: "Teco Boot" To: "'Emmanuel Baccelli'" , References: <4924C84D.5050502@earthlink.net> <49275006.7010605@sun.com> <4929F962.5070102@sun.com> <002101c94e1a$1e00e0a0$5a02a1e0$@nl> In-Reply-To: Date: Mon, 24 Nov 2008 12:17:18 +0100 Message-ID: <004001c94e26$487e72a0$d97b57e0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclOIomHQI/JTj7pRPuZwgRcLbIFqAAAfYRg Content-Language: nl Subject: Re: [Autoconf] Subnet definition 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: , Content-Type: multipart/mixed; boundary="===============0037960823==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Dit is een meerdelig bericht met een MIME-indeling. --===============0037960823== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0041_01C94E2E.AA42DAA0" Content-Language: nl Dit is een meerdelig bericht met een MIME-indeling. ------=_NextPart_000_0041_01C94E2E.AA42DAA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit - a subnet is a set of IP addresses that are on the same link (as per RFC1884 and RFC950). These addresses are then on-link with respect to this link. All other addresses are off-link. [Teco:] RFC1884 is historic. RFC4291 is the current IPv6 Addressing Architecture. Think about RFC3775 / 4887 and 4903 discussing the issues. Do you think home addresses that are not on the home link are not part of the subnet? Teco. ------=_NextPart_000_0041_01C94E2E.AA42DAA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

- a subnet is a set of IP = addresses that are on the = same link (as per RFC1884 and RFC950). These addresses are then on-link with respect to this link. All other addresses are = off-link.

[Teco:] RFC1884 is historic. RFC4291 is = the current IPv6 Addressing Architecture.

 

Think about RFC3775  / 4887 and 4903 discussing the = issues.

Do you think home addresses that are not on the home link = are not part of the subnet?

Teco.

 

------=_NextPart_000_0041_01C94E2E.AA42DAA0-- --===============0037960823== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf --===============0037960823==-- From autoconf-bounces@ietf.org Mon Nov 24 11:01:27 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41A463A6B6C; Mon, 24 Nov 2008 11:01:27 -0800 (PST) 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 998393A679C for ; Mon, 24 Nov 2008 11:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.927 X-Spam-Level: X-Spam-Status: No, score=-5.927 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5SWYAyEj2jK for ; Mon, 24 Nov 2008 11:01:25 -0800 (PST) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id 5BC1A3A6BC1 for ; Mon, 24 Nov 2008 11:01:16 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.106.31]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAOJ18QF022639; Mon, 24 Nov 2008 19:01:08 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAOJ17Ci361210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Nov 2008 11:01:08 -0800 (PST) Message-ID: <492AF9F3.6080905@sun.com> Date: Mon, 24 Nov 2008 11:01:07 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.17 (X11/20081023) MIME-Version: 1.0 To: Teco Boot References: <49259096.7080709@inria.fr> <00a001c94b40$cf06cf90$6d146eb0$@nl> In-Reply-To: <00a001c94b40$cf06cf90$6d146eb0$@nl> Cc: autoconf@ietf.org, 'Emmanuel Baccelli' Subject: Re: [Autoconf] Subnet definition 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Teco Boot wrote: > Somewhat more important: Is a IP addresses within a prefix, that is assigned > & configured on an interface, but that is not on-link, part of a subnet? If > not, I think somewhat should write this down. 6MAN? I think that is a key thing to get clarified. 6MAN might be the best place to do so. My take is that an address that is drawn from a prefix that isn't on-link on any link does not have to be part of a subnet. Erik _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 24 11:01:30 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AB7C3A6A7D; Mon, 24 Nov 2008 11:01:30 -0800 (PST) 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 46D643A6B7D for ; Mon, 24 Nov 2008 11:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.934 X-Spam-Level: X-Spam-Status: No, score=-5.934 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-0Kg3XN7J2G for ; Mon, 24 Nov 2008 11:01:28 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id A91F53A6A06 for ; Mon, 24 Nov 2008 11:01:23 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.224.31]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mAOJ12tc008370; Mon, 24 Nov 2008 19:01:02 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAOJ0wdG361200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Nov 2008 11:00:59 -0800 (PST) Message-ID: <492AF9EA.1060406@sun.com> Date: Mon, 24 Nov 2008 11:00:58 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.17 (X11/20081023) MIME-Version: 1.0 To: Teco Boot References: <4924C9AD.9030904@sun.com> <005301c94acc$cf862a70$6e927f50$@nl> <49273A3C.60503@sun.com> <003601c94cc4$a0392390$e0ab6ab0$@nl> In-Reply-To: <003601c94cc4$a0392390$e0ab6ab0$@nl> Cc: autoconf@ietf.org Subject: Re: [Autoconf] Why the link definition? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Teco Boot wrote: > I think it is important that IEEE and IETF agrees in how IPv6 is transported > over 802.11 links. I have equipment on my desk that is WiFi certified but > does not support IPv6. It has to do with bridging and MAC address mappings. > Cause could be that IPv6 is missing in IEEE 802.11-2007 tables M.2 and M.3 > (WLAN - Ethernet translation). Somebody can work out something for himself, > but an RFC would help making sure everything is compatible. I've been assuming that RFC2484 is sufficient even though it limits its scope to ISO/IEC 8802-3. The reason I think it is sufficient is that 802.11 is normally bridged to 802.3 hence it better provide the same service model as 802.3. > Other issues: > - MTU size (what happens when 2000 octet frame arrives at access point?) If 802.3 and 8702.11 are bridged together then IEEE 802 better have an answer. If there is a router between them then standard IP routing as defined by the IETF applies. > - DAD and duplicate L2 addresses (see I-D.daniel-ipv6-over-wifi). I can see that detecting duplicate L2 addresses is problematic. But one can still detect duplicate IP addresses when the L2 addresses are unique. But I wonder why the IPv6 WG didn't do anything with that draft. Erik > Note that L2 address cloning is quite common in some communities. > > > Teco. > > > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 24 11:24:54 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 229573A6AAF; Mon, 24 Nov 2008 11:24:54 -0800 (PST) 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 AE5333A6A28 for ; Mon, 24 Nov 2008 11:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.941 X-Spam-Level: X-Spam-Status: No, score=-5.941 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id heNWMUidNOJu for ; Mon, 24 Nov 2008 11:24:52 -0800 (PST) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 0F1FD3A6AAF for ; Mon, 24 Nov 2008 11:24:52 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.58.166]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAOJOo6Q026777; Mon, 24 Nov 2008 19:24:50 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAOJOnbP362558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Nov 2008 11:24:49 -0800 (PST) Message-ID: <492AFF7D.2070103@sun.com> Date: Mon, 24 Nov 2008 11:24:45 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.17 (X11/20081023) MIME-Version: 1.0 To: Emmanuel Baccelli References: <4924C84D.5050502@earthlink.net> <49275006.7010605@sun.com> <4929F962.5070102@sun.com> In-Reply-To: Cc: autoconf@ietf.org Subject: Re: [Autoconf] Subnet definition 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Emmanuel Baccelli wrote: > Thanks. So unless someone objects, there is indeed a consensus on the > terms below. The only question (raised by Charlie) was about the term > "subnet", but it is cleared with pointers to RFC1884 and RFC950 > indicated by Erick: > > - a prefix defines a contiguous range of IP addresses. > - a subnet is a set of IP addresses (that may or may not be a prefix) > that are on the same link. These addresses are then on-link with > respect to this link. All other addresses are off-link. > - a link is what lower layers reach without TTL decrement, through a > given interface. I think the usage of "subnet" in RFC950 assumes it is a prefix since it describes things using a bitmask. But I don't think we actually need to refer to a definition of "subnet" for autoconf; that is important is that the prefix(es) from which addresses are configured are not on-link on any link. Erik _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 24 11:28:18 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D29E3A6A28; Mon, 24 Nov 2008 11:28:18 -0800 (PST) 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 BE5533A6A28 for ; Mon, 24 Nov 2008 11:28:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.947 X-Spam-Level: X-Spam-Status: No, score=-5.947 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 959W3qyrjK6M for ; Mon, 24 Nov 2008 11:28:16 -0800 (PST) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 84DFA3A67DA for ; Mon, 24 Nov 2008 11:28:16 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.228.31]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAOJS9Gx029309; Mon, 24 Nov 2008 19:28:09 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAOJS8hd362750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Nov 2008 11:28:09 -0800 (PST) Message-ID: <492B0048.3020708@sun.com> Date: Mon, 24 Nov 2008 11:28:08 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.17 (X11/20081023) MIME-Version: 1.0 To: Teco Boot References: <4924C84D.5050502@earthlink.net> <49275006.7010605@sun.com> <4929F962.5070102@sun.com> <002101c94e1a$1e00e0a0$5a02a1e0$@nl> In-Reply-To: <002101c94e1a$1e00e0a0$5a02a1e0$@nl> Cc: autoconf@ietf.org, 'Emmanuel Baccelli' Subject: Re: [Autoconf] Subnet definition 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Teco Boot wrote: > *On link, we could borrow from a L2-link definition for 802.11-2007:* > > * * > > *3.76 link: In the context of an IEEE 802.11 medium access control (MAC) > entity, a physical path consisting* > > *of exactly one traversal of the wireless medium (WM) that is used to > transfer an MAC service data unit* > > *(MSDU) between two stations (STAs).* The IEEE 802 definition of a "link" is quite different than the definition in RFC 2460. For example, if I have a host using 802.11 and it sends a packet via the AP onto an Ethernet and it passes via a 802.1D bridge before reaching the L2 destination, then it has traversed three "802 links"; one to get to the AP, one between the AP and the bridge, and one from the bridge to the L2 destination. Erik _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 24 11:32:26 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6DA43A6875; Mon, 24 Nov 2008 11:32:26 -0800 (PST) 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 D45E73A6875 for ; Mon, 24 Nov 2008 11:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.952 X-Spam-Level: X-Spam-Status: No, score=-5.952 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsTMEsCEheMp for ; Mon, 24 Nov 2008 11:32:24 -0800 (PST) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id 333C43A6452 for ; Mon, 24 Nov 2008 11:32:24 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.17.55]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAOJWMea005914; Mon, 24 Nov 2008 19:32:22 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAOJWLXG362887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Nov 2008 11:32:22 -0800 (PST) Message-ID: <492B0145.5080803@sun.com> Date: Mon, 24 Nov 2008 11:32:21 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.17 (X11/20081023) MIME-Version: 1.0 To: Teco Boot References: <49259096.7080709@inria.fr> <00a001c94b40$cf06cf90$6d146eb0$@nl> <00a701c94b4a$d555e890$8001b9b0$@nl> In-Reply-To: <00a701c94b4a$d555e890$8001b9b0$@nl> Cc: autoconf@ietf.org, 'Emmanuel Baccelli' Subject: Re: [Autoconf] Subnet definition 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Teco Boot wrote: > draft-ietf-6man-ipv6-subnet-model-02 (IPv6 Subnet Model: the Relationship > between Links and Subnet Prefixes) discusses this. > Can we conclude that "IPv6 subnet" equals "IPv6 on-link prefix" equals "IPv6 > subnet prefix" as described in this I-D? (I added IPv6 as context qualifier) > > I had the impression that some intended that a subnet is a set of on-link > addresses, which typically would not be contiguous. > Why not using the aliases as above? > If not, post this as issue on the 6man draft? > If so, let's follow the 6man draft terminology and use subnet as alias for > on-link prefix. Maybe prefer on-link prefix to keep in line with the 6man > I-D. My personal take is that "on-link prefix" is more specific than "subnet" or "subnet prefix" (having co-authored both RFC 4861 and the above draft.) But it might be that the above draft could use some crisper use of terminology. Thus suggestions for improvements are welcome. Erik _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 24 14:56:22 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CC5D3A6BAC; Mon, 24 Nov 2008 14:56:22 -0800 (PST) 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 BE7473A6BAC for ; Mon, 24 Nov 2008 14:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.957 X-Spam-Level: X-Spam-Status: No, score=-5.957 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MXn+lL0do0c for ; Mon, 24 Nov 2008 14:56:20 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 031E73A6A6E for ; Mon, 24 Nov 2008 14:56:19 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.228.31]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAOMuE1V023244; Mon, 24 Nov 2008 22:56:15 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAOMuEmK368918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Nov 2008 14:56:14 -0800 (PST) Message-ID: <492B310A.3040209@sun.com> Date: Mon, 24 Nov 2008 14:56:10 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.17 (X11/20081023) MIME-Version: 1.0 To: Teco Boot References: <200811191440.mAJEeRPu017560@cichlid.raleigh.ibm.com> <492442C9.60404@sun.com> <200811191700.mAJH0WeD000999@cichlid.raleigh.ibm.com> <4924A6BB.4070601@sun.com> <004d01c94aac$57b1a4e0$0714eea0$@nl> <4924CA09.7080607@polytechnique.edu> <005501c94ad1$51ab7060$f5025120$@nl> <49273F12.1000908@sun.com> <003701c94cc6$d52bc1a0$7f8344e0$@nl> In-Reply-To: <003701c94cc6$d52bc1a0$7f8344e0$@nl> Cc: autoconf@ietf.org Subject: Re: [Autoconf] link definitions 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Teco Boot wrote: > Hi Erik, >> I'm starting to get the feeling we should stay away from "subnet" or >> "subnet prefix", since "subnet" has too much historical stuff >> associated >> with it. >> >> But the prefix will presumably be used for address configuration in >> addition to routing, thus "routing prefix" might be too specific. > > I don't see that much a problem using "prefix", as the issues were we are > working on is handled by routers. Hosts in a MANET (e.g. connected to a > MANET Router via Ethernet or infrastructure mode WLAN) MUST be provided a ND > service as specified in RFC4861 / RFC4862. > > Routers shall be able to handle address prefixes, including host prefixes > (alias for address, but more related to a router). I agree that "prefix" is ok; I think "routing prefix" might be too specific. So I think we are in agreement. >> How about something like this: >> One (or more) IP address prefixes is assigned to a Manet. The IP >> address >> autoconfiguration is used to configure addresses from that/those >> prefixes, and typically the whole Manet is represented externally as a >> single aggregated route for each of those prefixes. > > OK, but I don't agree on "_single_ aggregated route". > I think multi-homing SHOULD be supported. Sure. What I meant is that all the addresses that fall in a given prefix is normally represented externally as a single route. That doesn't prevent 1) addresses being allocated from multiple prefixes (resulting in multiple routes being advertised), or 2) multiple routers (at the "edge" of the Manet) announcing that/those route(s) Erik _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 24 15:03:02 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 723E53A6BCB; Mon, 24 Nov 2008 15:03:02 -0800 (PST) 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 3F06F3A6A6E for ; Mon, 24 Nov 2008 15:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.961 X-Spam-Level: X-Spam-Status: No, score=-5.961 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3qtuWCEGd-f for ; Mon, 24 Nov 2008 15:03:00 -0800 (PST) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id 739D83A6BCB for ; Mon, 24 Nov 2008 15:03:00 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.68.36]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAON2vcn021647; Mon, 24 Nov 2008 23:02:57 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAON2vY7369199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Nov 2008 15:02:57 -0800 (PST) Message-ID: <492B32A1.4070101@sun.com> Date: Mon, 24 Nov 2008 15:02:57 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.17 (X11/20081023) MIME-Version: 1.0 To: "Charles E. Perkins" References: <00c801c94b65$f3af1e90$db0d5bb0$@nl> <4925FF7D.5050900@earthlink.net> In-Reply-To: <4925FF7D.5050900@earthlink.net> Cc: autoconf@ietf.org Subject: Re: [Autoconf] Try to eliminate term subnet? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Charles E. Perkins wrote: > > Hello folks, > > I am very nervous about not having a definition for the > term "subnet" for two reasons: > > - If we don't define it, we must constantly be on watch to > make sure it is not used, and to explain why it is not > used. This will be a battle of perpetual weariness. The best way to handle that is to get community consensus around the fact that we have cases when there is an address prefix which isn't on-link for any link, hence we don't have "subnet prefixes". If it is helpful I can draft a short I-D for the 6man WG on this. > - As difficult as it may be, a subnet would naturally be > the unit of address allocation. And, that's what we > are tasked with doing in [autoconf]. Of course we > could allocate addresses out of some random grab > bag of addresses, but I'm willing to bet people would > not like that. A think a prefix (or set of prefixes) is the natural unit of address allocation. RFC950 defines a "subnet" as both being a unit of address allocation and part of the mechanism to determine what is on-link. (It doesn't use the term on-link, but the actual description is what RFC4862 calls on-link; can deliver packet at L2.) Given that is how "subnet" is used it doesn't make sense to reuse that term to be the prefix for address allocation across a collection of links, since that would conflict with the on-link property. Thus from a terminology perspective we can't reuse "subnet" to be the prefix from which autoconf allocates addresses. Erik _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 24 15:15:28 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 446A63A689E; Mon, 24 Nov 2008 15:15:28 -0800 (PST) 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 6BA603A689E for ; Mon, 24 Nov 2008 15:15:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.303 X-Spam-Level: X-Spam-Status: No, score=-4.303 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8hfMt-VAFBx for ; Mon, 24 Nov 2008 15:15:26 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 2FB723A6876 for ; Mon, 24 Nov 2008 15:15:25 -0800 (PST) Received: from [192.168.0.12] (82.159.25.132.dyn.user.ono.com [82.159.25.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 27992ACB118; Tue, 25 Nov 2008 00:15:22 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Erik Nordmark In-Reply-To: <49274147.6060607@sun.com> References: <1227250017.19012.167.camel@localhost> <49274147.6060607@sun.com> Organization: Universidad Carlos III de Madrid Date: Tue, 25 Nov 2008 00:15:21 +0100 Message-Id: <1227568521.4973.4.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: autoconf@ietf.org Subject: Re: [Autoconf] About MANET Links, subnets, etc X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0598070865==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============0598070865== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-j4T8Oly/B6DM5Lr8AqPO" --=-j4T8Oly/B6DM5Lr8AqPO Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Erik, all, El vie, 21-11-2008 a las 15:16 -0800, Erik Nordmark escribi=F3: > Carlos Jes=FAs Bernardos Cano wrote: >=20 > > So, let me try to provide my (current) view on some of the things that > > have been discussed. Most of them might have been already proposed by > > others, so I'm just taking those pieces from here and there that I'm > > happy with. > >=20 > > 1. About "MANET Links". I'm not completely sure we really need to > > define anything new. I see MANETs as networks composed of a set of > > routers that move. These routers have interfaces that belong to links -= - > > these links being defined by the L2 reachability/radio > > coverage/connectivity of the interface. The difference is that these > > links are quite dynamic (because the routers move) and might not have > > some nice properties, such as transitivity, symmetry, etc (but this is > > because of the L2 technology of the interface). >=20 > Agreed. >=20 > > 2. About "subnets" and addressing. In my understanding of a MANET, I > > see each of the routers of a MANET getting one (or several) unique IPv6 > > prefix. Out of that prefix, the MANET router configures and address for > > its loopback interface. On the interface over which the MANET router > > runs a MANET routing protocol, only a link-local address needs to be > > configured. The router may be delegated more than one prefix, to > > configure other physical interfaces (regular hosts might attach to thes= e > > interfaces, and configure IPv6 address from the delegated prefixes). Th= e > > MANET routing protocol takes care of providing reachability within the > > MANET, MANET routers do not need to change their IP addresses due to > > inner mobility within the MANET. >=20 > That matches my understanding. >=20 > > 3. About "links". I think the term "link" should be accompanied by the > > layer for which the term "link" is meaningful. There might be L2 links > > and L3 links and should not necessarily be the same. I'd say that a "LX > > link" is defined by "what can be reached in 1 LX hop". In the case of > > IP, an "L3/IP link" would be defined by what can be reached in 1 IP hop= , > > i.e. without decrementing the IPv6 hop count of the packet. >=20 > While I agree in principle, I don't think we need to concern ourselves=20 > with anything but "L3 link" (which RFC 2460 has defined as "link"). > Furthermore, different L2 SDOs might have differing definitions of "L2=20 > link" (for instance, IEEE 802 has such a definition) so we are not the=20 > authority on how to design such things. Thus, if possible, I think we=20 > should stay away from defining "L2 link". Agree, I just wanted to point out that the term "link" may mean different things. Fully agree we should only consider L3 links. >=20 > > 4. About what we should do in the autoconf WG: to define the > > mechanism(s) to provide each MANET router with a unique IPv6 prefix > > (that could even be a /128). Something that might be tricky is how to > > guarantee that configured link-local addresses on the MANET interfaces > > are unique within the scope of the link, since that scope is quite > > dynamic (members of that link change over time, and even not all the > > members of that link may have the same view of the link). Potentially, = a > > solution would be to ensure that these addresses are unique within the > > whole MANET, since that would ensure that they are in the scope of the > > link. >=20 > If you use EUI64-based link-local addresses, or RFC 4941 addresses, the=20 > probability of collisions for the link-local addresses is extremely=20 > small. It might make sense to have safety mechanism where the Manet can=20 > continue to function in the presence of duplicate link-local addresses,=20 > while one or both of the nodes with duplicates might end up being=20 > disabled. But in general it might be hard to detect such duplicates=20 > because you have do have some other distinguishing piece of information=20 > to tell the difference between a node being reachable over two different=20 > paths and two different nodes being identical clones. Also agree. Carlos >=20 > Erik >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2009: 2nd Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-j4T8Oly/B6DM5Lr8AqPO Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkkrNYkACgkQNdy6TdFwT2e7XACgynHumuD43rk31VnkEyqV4vt3 1lEAoLzJ1rlXW5fyunFoF6qMVqwNeh5x =YTMC -----END PGP SIGNATURE----- --=-j4T8Oly/B6DM5Lr8AqPO-- --===============0598070865== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf --===============0598070865==-- From autoconf-bounces@ietf.org Mon Nov 24 15:36:20 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32B543A6826; Mon, 24 Nov 2008 15:36:20 -0800 (PST) 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 1E8233A6826 for ; Mon, 24 Nov 2008 15:36:19 -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 WZo61L0iawHL for ; Mon, 24 Nov 2008 15:36:18 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 5FEC03A681D for ; Mon, 24 Nov 2008 15:36:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=f7GGaq1pEzA26ZB6aeFscvYMjwATc8iW6Idv6aEkZTJwetsS1ddqgBPg4vyp25dv; 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 [75.26.137.116] (helo=[10.166.254.37]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L4kyP-00070F-0y; Mon, 24 Nov 2008 18:36:09 -0500 Message-ID: <492B3A67.7020900@earthlink.net> Date: Mon, 24 Nov 2008 15:36:07 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Erik Nordmark References: <1227250017.19012.167.camel@localhost> <49274147.6060607@sun.com> In-Reply-To: <49274147.6060607@sun.com> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52c783efc2b4bfdb133368af95d7162b96350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Cc: autoconf@ietf.org Subject: Re: [Autoconf] About MANET Links, subnets, etc 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello Erik, I'm somewhat behind on the discussion... Erik Nordmark wrote: > > > While I agree in principle, I don't think we need to concern ourselves > with anything but "L3 link" (which RFC 2460 has defined as "link"). Do you think it is possible to have a "L3 link" between nodes that are not on the same subnet? How about if they are on different subnets, but not advertising reachability for those subnets? If these are legitimate operations in your view, and if it "L3 link" is then seen to be quite distinct from "subnet", then maybe it is the concept we need. > Furthermore, different L2 SDOs might have differing definitions of "L2 > link" (for instance, IEEE 802 has such a definition) so we are not the > authority on how to design such things. Thus, if possible, I think we > should stay away from defining "L2 link". If "L3 link" will do the job for MANET, I agree. Otherwise (and only if "L3 link" won't do), we might set about defining something called a "MANET link". Regards, Charlie P. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 24 15:50:53 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3B603A69C1; Mon, 24 Nov 2008 15:50:53 -0800 (PST) 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 5EFCB3A6A4C for ; Mon, 24 Nov 2008 15:50:52 -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 TCWZ2kGHCeMb for ; Mon, 24 Nov 2008 15:50:51 -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 A1EE03A69C1 for ; Mon, 24 Nov 2008 15:50:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Kf+wkmd5/rT5NnAcTKv0p9tOLfQU4IuvNOsyzxzMa9FvH9lf9NArECC/xI5PLotg; 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 [75.26.137.116] (helo=[10.166.254.37]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L4lCb-0003uG-CC; Mon, 24 Nov 2008 18:50:49 -0500 Message-ID: <492B3DD6.1010906@earthlink.net> Date: Mon, 24 Nov 2008 15:50:46 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Erik Nordmark References: <4924C84D.5050502@earthlink.net> <49275006.7010605@sun.com> In-Reply-To: <49275006.7010605@sun.com> X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52c74fe5f8735158478dabc123ac564e59350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.26.137.116 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Subnet definition 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hello Erik, One more note related to the saga of "netmask". Erik Nordmark wrote: > > At some point in time the ifconfig command in BSD got a "netmask" > subcommand. It is interesting to note that it wasn't called a > "subnetmask", even though today it might be casually viewed as such. I > don't have the first version of the man page for ifconfig, but this > description might be fairly old: > Specify how much of the address to > reserve for subdividing networks into subnetworks. The > mask includes the network part of the local address and > the subnet part, which is taken from the host field of > the address. I think there was an older definition for "netmask", because as I recall it was possible for the netmask to specify noncontiguous bits of the address space. Fortunately, it seemed that no sane person ever really tried to use it this way, and the feature was subsequently deleted. Surely there's some BSDv3 man pages out there somewhere :-) (but I could not find them in the limited time I've had to look). Regards, Charlie P. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Nov 24 17:01:14 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F35883A6B88; Mon, 24 Nov 2008 17:01:13 -0800 (PST) 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 3A90D3A6B88 for ; Mon, 24 Nov 2008 17:01:13 -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 RGNe+Ubm8uP4 for ; Mon, 24 Nov 2008 17:01:12 -0800 (PST) Received: from maili.marvell.com (host2.marvell.com [65.219.4.2]) by core3.amsl.com (Postfix) with ESMTP id 806023A6BD3 for ; Mon, 24 Nov 2008 17:01:12 -0800 (PST) Received: from MSI-MTA.marvell.com (msi-mta.marvell.com [10.68.76.91]) by maili.marvell.com (Postfix) with ESMTP id 545085E61F; Mon, 24 Nov 2008 17:01:10 -0800 (PST) Received: from sc-owa01.marvell.com ([10.93.76.21]) by MSI-MTA.marvell.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Nov 2008 17:01:10 -0800 Received: from sc-owa02.marvell.com (10.93.76.22) by sc-owa01.marvell.com (10.93.76.21) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 24 Nov 2008 17:01:09 -0800 Received: from SC-EXCH1.marvell.com ([10.93.76.25]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Mon, 24 Nov 2008 17:01:09 -0800 From: Paul Lambert To: "Charles E. Perkins" Date: Mon, 24 Nov 2008 17:01:07 -0800 Thread-Topic: [Autoconf] Alternative IP Address Assignment Mechanisms for Ad Hoc Wireless-> was RE: what if there's no DHCP Server around? Thread-Index: AclMRzqR4IJh/+vORCS5E0zPsOFarACTH/sg Message-ID: <5A22FB9EDAA74547916480634CCC743817AD0BBD15@SC-EXCH1.marvell.com> References: <00c801c94b65$f3af1e90$db0d5bb0$@nl><4925FF7D.5050900@earthlink.net> <39C363776A4E8C4A94691D2BD9D1C9A1053EF3CF@XCH-NW-7V2.nw.nos.boeing.com> <4926122A.4000501@earthlink.net> <00db01c94b8b$eed566b0$cc803410$@nl> <492648FD.8060004@earthlink.net> <49269BCF.10402@gmail.com> <4926BD40.3000201@polytechnique.edu> <4926C170.40707@gmail.com> <5A22FB9EDAA74547916480634CCC743817AD0BBCCD@SC-EXCH1.marvell.com> <492769A1.1010702@earthlink.net> In-Reply-To: <492769A1.1010702@earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 25 Nov 2008 01:01:10.0414 (UTC) FILETIME=[4E1B3AE0:01C94E99] Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Alternative IP Address Assignment Mechanisms for Ad Hoc Wireless-> was RE: what if there's no DHCP Server around? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Charlie, Glad to hear from you that there are some viable worked solutions. As a recent lurker to the group, it's hard to tell where to start to build a real product so your guidance is really appreciated I'm looking largely at single hop mesh and single direct connect ad hoc. Routing is not so important as basic services between devices for the use case I'm pursuing: So given this use case ... I see that forwarded multicast might be useful: draft-ietf-manet-smf-08.txt This requires you to discover your neighbors: draft-ietf-manet-nhdp-07.txt Now you still need an IP address. Is forwarded mulicast to support existing mechanisms enough or is something else needed? I've seen a few proposals (expired RFCs) ... is there consensous in the group on a particular approach > -----Original Message----- > From: Charles E. Perkins [mailto:charles.perkins@earthlink.net] > > > Hello Paul, > > > Paul Lambert wrote: > > ... clip > Yes! We've been arguing about subnets and links for so long, > maybe people forgot why the working group was formed! > > There are some very interesting and some very straightforward > approaches. These systems have been built and tested and found > to be worthwhile. That was why we started the group, in the > belief that a standard approach would create new markets for > ad hoc networks, as well as providing new insights. Ryuji and I > published what I thought was a very valuable approach lo these > many years ago. > > I do not want to sound bitter, but the people complaining the > most about lack of architecture do not seem to have contributed > any of their solutions or experience with implementations. I do agree that the pace appears to be slow ... I suspect it's not this forum, but the industry as a whole that has been slow to adopt useable "ad hoc" solutions. Ad hoc has been overshadowed by more simple star topologies. I'm hoping that there is still a window to get out a ad hoc products :-) Regards, Paul _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 25 01:56:45 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8B033A6B03; Tue, 25 Nov 2008 01:56:45 -0800 (PST) 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 D5D873A6ACD for ; Tue, 25 Nov 2008 01:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 e6CF1Qhqao36 for ; Tue, 25 Nov 2008 01:56:43 -0800 (PST) Received: from hpsmtp-eml18.kpnxchange.com (hpsmtp-eml18.KPNXCHANGE.COM [213.75.38.118]) by core3.amsl.com (Postfix) with ESMTP id DEA693A6B03 for ; Tue, 25 Nov 2008 01:56:42 -0800 (PST) Received: from hpsmtp-eml04.kpnxchange.com ([213.75.38.104]) by hpsmtp-eml18.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Nov 2008 10:56:37 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml04.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Nov 2008 10:56:36 +0100 From: "Teco Boot" To: "'Erik Nordmark'" References: <4924C9AD.9030904@sun.com> <005301c94acc$cf862a70$6e927f50$@nl> <49273A3C.60503@sun.com> <003601c94cc4$a0392390$e0ab6ab0$@nl> <492AF9EA.1060406@sun.com> In-Reply-To: <492AF9EA.1060406@sun.com> Date: Tue, 25 Nov 2008 10:56:35 +0100 Message-ID: <000101c94ee4$1a1fee20$4e5fca60$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclOZw/FJRJRyE03S+6j1UAB6Fi+GgAbOejw Content-Language: nl X-OriginalArrivalTime: 25 Nov 2008 09:56:36.0711 (UTC) FILETIME=[1ADF1F70:01C94EE4] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Why the link definition? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Eric, > > I think it is important that IEEE and IETF agrees in how IPv6 is > transported > > over 802.11 links. I have equipment on my desk that is WiFi certified > but > > does not support IPv6. It has to do with bridging and MAC address > mappings. > > Cause could be that IPv6 is missing in IEEE 802.11-2007 tables M.2 > and M.3 > > (WLAN - Ethernet translation). Somebody can work out something for > himself, > > but an RFC would help making sure everything is compatible. > > I've been assuming that RFC2484 is sufficient even though it limits its > scope to ISO/IEC 8802-3. The reason I think it is sufficient is that > 802.11 is normally bridged to 802.3 hence it better provide the same > service model as 802.3. With 802.11 in infrastructure mode, I think I can agree. Although there are issues like MTU. > > Other issues: > > - MTU size (what happens when 2000 octet frame arrives at access > point?) > > If 802.3 and 802.11 are bridged together then IEEE 802 better have an > answer. > If there is a router between them then standard IP routing as defined > by > the IETF applies. OK, but I see two issues (at least): 1 - 802.1D-2004 6.3.8 Maximum Service Data Unit Size >>>> No attempt is made by a Bridge to relay a frame to a LAN >>>> that does not support the size of Service Data Unit conveyed >>>> by that frame. Maximum Service Data Unit Size on 802.3 and 802.11 are different (1500 vs. 2304). How can we make sure IPv6 can be used on WiFi networks, without bothering users with all kind of MTU / MaxSDU size problems? We could _assume_ RFC2464's 1500 default MTU size SHOULD be used on other 802 networks. But with Dave Thaler his talk in mind, we could better specify our assumptions. We could think of using a MUST here. RA MTU option would be a method to solve problems. We could specify a router that has a link connected to a heterogeneous LAN with 802.3 and 802.11 SHOULD send MTU options with MTU 1500. 2 - 802.1D-2004 6.5.4 Support by IEEE Std 802.11 (Wireless LANs): >>>> A bridge shall not connect to an IEEE 802.11 Independent BSS. I think this is important for MANETs, a router cannot be attached to an IBSS WLAN bridge via an Ethernet link. There are methods to solve problems here, e.g. using 4-address mode (DS To DS: 1 From DS: 1). This is to be addressed in IEEE, IETF is not primary responsible. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 25 02:12:37 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE0573A6B03; Tue, 25 Nov 2008 02:12:37 -0800 (PST) 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 56D5C3A6B03 for ; Tue, 25 Nov 2008 02:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 AZD+gZNIRqRe for ; Tue, 25 Nov 2008 02:12:36 -0800 (PST) Received: from cpsmtpo-eml06.kpnxchange.com (cpsmtpo-eml06.KPNXCHANGE.COM [213.75.38.155]) by core3.amsl.com (Postfix) with ESMTP id 5CBEB3A68EB for ; Tue, 25 Nov 2008 02:12:35 -0800 (PST) Received: from hpsmtp-eml07.kpnxchange.com ([213.75.38.107]) by cpsmtpo-eml06.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Nov 2008 11:12:32 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml07.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Nov 2008 11:12:32 +0100 From: "Teco Boot" To: "'Erik Nordmark'" References: <4924C84D.5050502@earthlink.net> <49275006.7010605@sun.com> <4929F962.5070102@sun.com> <002101c94e1a$1e00e0a0$5a02a1e0$@nl> <492B0048.3020708@sun.com> In-Reply-To: <492B0048.3020708@sun.com> Date: Tue, 25 Nov 2008 11:12:28 +0100 Message-ID: <000801c94ee6$53b2ef50$fb18cdf0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclOasxtfe6E9RsfQ6CwCxjM9lzyCwAevFXg Content-Language: nl X-OriginalArrivalTime: 25 Nov 2008 10:12:32.0663 (UTC) FILETIME=[54A9D270:01C94EE6] Cc: autoconf@ietf.org, 'Emmanuel Baccelli' Subject: Re: [Autoconf] Subnet definition 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Erik, > Teco Boot wrote: > > > *On link, we could borrow from a L2-link definition for 802.11-2007:* > > > > * * > > > > *3.76 link: In the context of an IEEE 802.11 medium access control > (MAC) > > entity, a physical path consisting* > > > > *of exactly one traversal of the wireless medium (WM) that is used to > > transfer an MAC service data unit* > > > > *(MSDU) between two stations (STAs).* > > > The IEEE 802 definition of a "link" is quite different than the > definition in RFC 2460. > > For example, if I have a host using 802.11 and it sends a packet via > the > AP onto an Ethernet and it passes via a 802.1D bridge before reaching > the L2 destination, then it has traversed three "802 links"; one to get > to the AP, one between the AP and the bridge, and one from the bridge > to > the L2 destination. Agreed. For addressing, it doesn't matter how many lower layer links are passed between the on-link IPv6 nodes. But for MANET protocols, this is important. Question is, do we produce a MANET Architecture for both MANET and Autoconf WGs? Or just for Autoconf? If its usage is solely for Autoconf and not for MANET, let's rename the document to something else than MANET Architecture, as it could be very confusing. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 25 03:20:51 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF4583A6A49; Tue, 25 Nov 2008 03:20:51 -0800 (PST) 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 6E4283A698D for ; Tue, 25 Nov 2008 03:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 UnNx4yRNwO1L for ; Tue, 25 Nov 2008 03:20:49 -0800 (PST) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id 8A9FA3A6A49 for ; Tue, 25 Nov 2008 03:20:49 -0800 (PST) Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id mAPBKjds001067 for ; Tue, 25 Nov 2008 11:20:45 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id mAPBKjXP002012 for ; Tue, 25 Nov 2008 11:20:45 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 25 Nov 2008 11:20:45 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Tue, 25 Nov 2008 11:20:44 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Nov 2008 11:20:42 -0000 Message-ID: In-Reply-To: <000101c94ee4$1a1fee20$4e5fca60$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Why the link definition? Thread-Index: AclOZw/FJRJRyE03S+6j1UAB6Fi+GgAbOejwAAbiNqA= References: <4924C9AD.9030904@sun.com> <005301c94acc$cf862a70$6e927f50$@nl><49273A3C.60503@sun.com> <003601c94cc4$a0392390$e0ab6ab0$@nl><492AF9EA.1060406@sun.com> <000101c94ee4$1a1fee20$4e5fca60$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Erik Nordmark" X-OriginalArrivalTime: 25 Nov 2008 11:20:44.0761 (UTC) FILETIME=[DBBE6C90:01C94EEF] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Why the link definition? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Teco Boot > Erik Nordmark >> The reason I think it is sufficient is that >> 802.11 is normally bridged to 802.3 hence it better provide the same >> service model as 802.3. > With 802.11 in infrastructure mode, I think I can agree. Of course for a MANET, we may (are more likely to?) use 802.11 ad hoc mode, and we need a model that will handle that. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Nov 25 03:26:34 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06CE03A69EE; Tue, 25 Nov 2008 03:26:34 -0800 (PST) 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 61ABE3A69EE for ; Tue, 25 Nov 2008 03:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.339 X-Spam-Level: X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 UQQsSDv4CYss for ; Tue, 25 Nov 2008 03:26:31 -0800 (PST) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id 618C43A698D for ; Tue, 25 Nov 2008 03:26:31 -0800 (PST) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id mAPBQQ4r003378 for ; Tue, 25 Nov 2008 11:26:26 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id mAPBQOjT006187 for ; Tue, 25 Nov 2008 11:26:24 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 25 Nov 2008 11:26:24 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Tue, 25 Nov 2008 11:26:24 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Nov 2008 11:26:22 -0000 Message-ID: In-Reply-To: <000801c94ee6$53b2ef50$fb18cdf0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Subnet definition Thread-Index: AclOasxtfe6E9RsfQ6CwCxjM9lzyCwAevFXgAAKPV1A= References: <4924C84D.5050502@earthlink.net><49275006.7010605@sun.com><4929F962.5070102@sun.com><002101c94e1a$1e00e0a0$5a02a1e0$@nl> <492B0048.3020708@sun.com> <000801c94ee6$53b2ef50$fb18cdf0$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Erik Nordmark" X-OriginalArrivalTime: 25 Nov 2008 11:26:24.0185 (UTC) FILETIME=[A60E6A90:01C94EF0] Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] Subnet definition 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > Question is, do we produce a MANET Architecture for both MANET and Autoconf > WGs? Or just for Autoconf? Absolutely definitely the former. Or rather, not for the WGs, but to define the architecture of a MANET, in which routing will use a MANET routing protocol (as developed in the MANET WG) and address autoconfiguration, when needed, will use a suitable protocol (specified by - it's an officially open question whether new protocols are needed - the Autoconf WG). ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sun Nov 30 18:10:43 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2BDB3A682C; Sun, 30 Nov 2008 18:10:43 -0800 (PST) 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 B12E728C19D for ; Sun, 30 Nov 2008 18:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.965 X-Spam-Level: X-Spam-Status: No, score=-5.965 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLWJYOQzN4jz for ; Sun, 30 Nov 2008 18:10:40 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 0BEB328C19B for ; Sun, 30 Nov 2008 18:10:39 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.108.38]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mB12AYvG012342; Mon, 1 Dec 2008 02:10:35 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mB12AT6L545622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Nov 2008 18:10:34 -0800 (PST) Message-ID: <49334791.2000808@sun.com> Date: Sun, 30 Nov 2008 18:10:25 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.17 (X11/20081023) MIME-Version: 1.0 To: "Charles E. Perkins" References: <1227250017.19012.167.camel@localhost> <49274147.6060607@sun.com> <492B3A67.7020900@earthlink.net> In-Reply-To: <492B3A67.7020900@earthlink.net> Cc: autoconf@ietf.org Subject: Re: [Autoconf] About MANET Links, subnets, etc 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Charles E. Perkins wrote: > > Hello Erik, > > I'm somewhat behind on the discussion... So am I. > Erik Nordmark wrote: >> >> >> While I agree in principle, I don't think we need to concern ourselves >> with anything but "L3 link" (which RFC 2460 has defined as "link"). > > Do you think it is possible to have a "L3 link" between nodes that are > not on the same subnet? How about if they are on different subnets, > but not advertising reachability for those subnets? Existing operation practice sometimes handles point-to-point links between routers that way; each router has an IP address from the prefix assigned to the ISP owning that router. And in principle I don't see why one couldn't do that for links that are not point-to-point. There is a potential inefficiency if IPv4 hosts are attached to such a link since they might send packets to a suboptimal 1st hop router, and there is no way the router can send an acceptable redirect. > If these are legitimate operations in your view, and if it "L3 link" is > then seen to be quite distinct from "subnet", then maybe it is the > concept we need. Good. Erik >> Furthermore, different L2 SDOs might have differing definitions of "L2 >> link" (for instance, IEEE 802 has such a definition) so we are not the >> authority on how to design such things. Thus, if possible, I think we >> should stay away from defining "L2 link". > > If "L3 link" will do the job for MANET, I agree. Otherwise (and > only if "L3 link" won't do), we might set about defining something > called a "MANET link". > > > Regards, > Charlie P. > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sun Nov 30 18:13:21 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5899028C19D; Sun, 30 Nov 2008 18:13:21 -0800 (PST) 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 AB52228C19D for ; Sun, 30 Nov 2008 18:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.968 X-Spam-Level: X-Spam-Status: No, score=-5.968 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBQio4Qvee1C for ; Sun, 30 Nov 2008 18:13:19 -0800 (PST) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id E35BF28C19B for ; Sun, 30 Nov 2008 18:13:19 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.106.105]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mB12DFNh008062; Mon, 1 Dec 2008 02:13:15 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mB12DECl545647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Nov 2008 18:13:15 -0800 (PST) Message-ID: <4933483A.9080403@sun.com> Date: Sun, 30 Nov 2008 18:13:14 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.17 (X11/20081023) MIME-Version: 1.0 To: "Charles E. Perkins" References: <4924C84D.5050502@earthlink.net> <49275006.7010605@sun.com> <492B3DD6.1010906@earthlink.net> In-Reply-To: <492B3DD6.1010906@earthlink.net> Cc: autoconf@ietf.org Subject: Re: [Autoconf] Subnet definition 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Charles E. Perkins wrote: > > Hello Erik, > > One more note related to the saga of "netmask". > > Erik Nordmark wrote: >> >> At some point in time the ifconfig command in BSD got a "netmask" >> subcommand. It is interesting to note that it wasn't called a >> "subnetmask", even though today it might be casually viewed as such. I >> don't have the first version of the man page for ifconfig, but this >> description might be fairly old: >> Specify how much of the address to >> reserve for subdividing networks into subnetworks. The >> mask includes the network part of the local address and >> the subnet part, which is taken from the host field of >> the address. > > I think there was an older definition for "netmask", because as I recall > it was > possible for the netmask to specify noncontiguous bits of the address > space. > Fortunately, it seemed that no sane person ever really tried to use it this > way, and the feature was subsequently deleted. Yes, but I don't think all support for non-contig netmasks have been purged from neither the standards nor the implementation. But since they've been removed in some places the effect of trying to use them would be quite unpredictable. In any case, they aren't useful. Erik _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sun Nov 30 18:20:54 2008 Return-Path: X-Original-To: autoconf-archive@megatron.ietf.org Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67D883A6AAC; Sun, 30 Nov 2008 18:20:54 -0800 (PST) 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 1C77528C1A1 for ; Sun, 30 Nov 2008 18:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.971 X-Spam-Level: X-Spam-Status: No, score=-5.971 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2InpTjlEKm2 for ; Sun, 30 Nov 2008 18:20:52 -0800 (PST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by core3.amsl.com (Postfix) with ESMTP id 10BF13A67EE for ; Sun, 30 Nov 2008 18:20:52 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.56.36]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mB12Kl9f010650; Mon, 1 Dec 2008 02:20:47 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mB12KcHi545709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Nov 2008 18:20:38 -0800 (PST) Message-ID: <493349F6.7080703@sun.com> Date: Sun, 30 Nov 2008 18:20:38 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.17 (X11/20081023) MIME-Version: 1.0 To: Teco Boot References: <4924C9AD.9030904@sun.com> <005301c94acc$cf862a70$6e927f50$@nl> <49273A3C.60503@sun.com> <003601c94cc4$a0392390$e0ab6ab0$@nl> <492AF9EA.1060406@sun.com> <000101c94ee4$1a1fee20$4e5fca60$@nl> In-Reply-To: <000101c94ee4$1a1fee20$4e5fca60$@nl> Cc: autoconf@ietf.org Subject: Re: [Autoconf] Why the link definition? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Teco Boot wrote: > Hi Eric, > >>> I think it is important that IEEE and IETF agrees in how IPv6 is >> transported >>> over 802.11 links. I have equipment on my desk that is WiFi certified >> but >>> does not support IPv6. It has to do with bridging and MAC address >> mappings. >>> Cause could be that IPv6 is missing in IEEE 802.11-2007 tables M.2 >> and M.3 >>> (WLAN - Ethernet translation). Somebody can work out something for >> himself, >>> but an RFC would help making sure everything is compatible. >> I've been assuming that RFC2484 is sufficient even though it limits its >> scope to ISO/IEC 8802-3. The reason I think it is sufficient is that >> 802.11 is normally bridged to 802.3 hence it better provide the same >> service model as 802.3. > > With 802.11 in infrastructure mode, I think I can agree. Although there are > issues like MTU. I haven't tried with the implementation of WiFi I use, but I suspect because of the infrastructure mode being bridged to Ethernet, that the device driver reports the MTU as 1500 even if I'm in ad-hoc mode. But this would be a good thing for an IPv4/6-over-802.11 document to specify. > OK, but I see two issues (at least): > 1 - 802.1D-2004 6.3.8 Maximum Service Data Unit Size >>>>> No attempt is made by a Bridge to relay a frame to a LAN >>>>> that does not support the size of Service Data Unit conveyed >>>>> by that frame. > > Maximum Service Data Unit Size on 802.3 and 802.11 are different (1500 vs. > 2304). > How can we make sure IPv6 can be used on WiFi networks, without bothering > users with all kind of MTU / MaxSDU size problems? > We could _assume_ RFC2464's 1500 default MTU size SHOULD be used on other > 802 networks. > But with Dave Thaler his talk in mind, we could better specify our > assumptions. Yes, it would be good to have this written down. > We could think of using a MUST here. > > RA MTU option would be a method to solve problems. Sure, but there isn't a counterpart for IPv4 and in many cases folks want to make IPv4 as well as IPv6 work. > We could specify a router that has a link connected to a heterogeneous LAN > with 802.3 and 802.11 SHOULD send MTU options with MTU 1500. But the router might not even know that the Ethernet is bridged to 802.11. What we could recommend is that the administrator should configure such a router to send MTU options with 1500. Erik > 2 - 802.1D-2004 6.5.4 Support by IEEE Std 802.11 (Wireless LANs): >>>>> A bridge shall not connect to an IEEE 802.11 Independent BSS. > > I think this is important for MANETs, a router cannot be attached to an IBSS > WLAN bridge via an Ethernet link. > There are methods to solve problems here, e.g. using 4-address mode (DS To > DS: 1 From DS: 1). > This is to be addressed in IEEE, IETF is not primary responsible. > > > Teco. > > > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf