From teco@inf-net.nl Mon Mar 2 01:11:38 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 071953A699C for ; Mon, 2 Mar 2009 01:11:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.296 X-Spam-Level: X-Spam-Status: No, score=0.296 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, J_CHICKENPOX_35=0.6, J_CHICKENPOX_45=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 7INJxKNWF517 for ; Mon, 2 Mar 2009 01:11:36 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id AFD413A6A99 for ; Mon, 2 Mar 2009 01:11:35 -0800 (PST) Received: (qmail 31756 invoked from network); 2 Mar 2009 10:11:57 +0100 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 2 Mar 2009 10:11:57 +0100 From: "Teco Boot" To: References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <1235828619.6096.24.camel@localhost> In-Reply-To: <1235828619.6096.24.camel@localhost> Date: Mon, 2 Mar 2009 10:11:29 +0100 Message-ID: <001c01c99b16$f12b1c90$d38155b0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmZqpFrqfo98c4GSkiP+5kwRfyxmwBaJ9zw Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Mon, 02 Mar 2009 09:11:38 -0000 Hi Carlos, |While I think this is also much in line with my thinking, I think it's |better to focus on the simplest cases before. You placed this comment just below a figure with just one Internet = access and three MANET Routers. I think this is the simple case. Maybe you intended to say "focus on single-homing and leave multi-homing = for future enhancements". If so, I do not agree. In my use case (tactical networks), multi-homing = is an important requirement. I think it applies also for public safety / disaster relief networks. More important, if we leave multi-homing out-of-scope, we may easily make wrong decisions and block support for multi-homing or it may not be optimal. It is not that difficult to support multi-homing. Fred Templin VET = solution uses map&encap approach, as my NEMO4MANET idea (both IRTF RRG strategy = A). BRDP based routing use "source address based routing" to the border = router (IRTF RRG strategy B). =20 I think the routing aspect of multi-homing is more a [MANET WG] topic, = and [Autoconf WG] could ask [MANET WG] to work on solutions for it, based on = a defined addressing model. Regards, Teco |-----Oorspronkelijk bericht----- |Van: Carlos Jes=FAs Bernardos Cano [mailto:cjbc@it.uc3m.es] |Verzonden: zaterdag 28 februari 2009 14:44 |Aan: Teco Boot |CC: autoconf@ietf.org; 'Alexandru Petrescu' |Onderwerp: Re: Autoconf addressing model | |Hi Teco, | |El vie, 27-02-2009 a las 10:41 +0100, Teco Boot escribi=F3: |> All, |> |> Here my opinion on the to be defined addressing model for MANETs / |Autoconf. |> I opened a separate thread, as I think (and hope) there will be an |intensive |> and productive discussion. |> |> Some of us like an address model with /32 (IPv4) or /128 (IPv6) |> prefix-length addresses attached to an interface to a multi-access |link. |> These addresses do not have an Interface-ID. |> |> Such a model excludes usage of /64 "prefix swapping", which is IMHO = an |> extremely important attribute of IPv6. And it is specified as |mandatory in |> some standard track RFCs (e.g. RFC2464). |> |> We could discuss and analyze the effect of adopting the /128 (or /32) |prefix |> lengths for MANET interfaces, but I prefer taking this option as last |> resort. I think there is a much more obvious option, using the = RFC2464 |model |> for the MANET interface and /128 (or /32) for loopback interfaces. |Both |> would use high probability globally unique Interface IDs like EUI-64 |> (Extended Unique Identifier). | |Agree, this is also my understanding. | |> |> RFC4291 2.1. Addressing Model: |> All interfaces are required to have at least one Link-Local unicast |> address (see Section 2.8 for additional required addresses). A |> single interface may also have multiple IPv6 addresses of any type |> (unicast, anycast, and multicast) or scope. Unicast addresses with = a |> scope greater than link-scope are not needed for interfaces that are |> not used as the origin or destination of any IPv6 packets to or from |> non-neighbors. This is sometimes convenient for point-to-point |> interfaces. |> |> RFC2464 4. Stateless Autoconfiguration: |> An IPv6 address prefix used for stateless autoconfiguration [ACONF] |> of an Ethernet interface must have a length of 64 bits. |> |> It is not only because the RFC texts that I dislike the /128 in MANET |> interfaces, it is also backward compatibility with current IP stacks |(and |> probably many applications). I think an interface with /128 is stub, |and |> thus protocols may assume that there is no other node on this link in |the |> same subnet. Think of ARP and routing protocols. I verified this with |some |> product, the outcome confirmed my assumption. I was able to adjust = the |> configuration on one platform so that it worked (Linux), but still = the |> indication is that the model has a high impact. |> |> I think using /128 for loopback interfaces fits the requirements for |the |> addressing model. If a loopback interface is used, MANET interfaces = do |not |> require a globally unique address. RFC4291 once more (out of section, |also |> cited above): |> Unicast addresses with a |> scope greater than link-scope are not needed for interfaces that are |> not used as the origin or destination of any IPv6 packets to or from |> non-neighbors. |> So "host functionality" can be provided using the globally (or MANET |local) |> unique address assigned to a loopback address, or another non-MANET |> interface. |> |> This results in the following addressing model, where all nodes are |routers: |> |> +-------+ wifi "adhoc1" +-------+ wifi "adhoc2" +-------+ |> |Router1|>-------------<|Router2|>-------------<|Router3| |> +---L---+ LL1 LL21 +---L---+ LL22 LL3 +---L---+ |> |M1 |M2 |M3 |> |> "adhoc1" and "adhoc2": 802.11 SSIDs in "IBSS" mode. |> Each IBSS is an IPv6 subnet. |> |> L: Loopback interface. |> |> >, <: MANET interface. |> |> LL1, LL21, LL22, LL3: IPv6 link-local addresses. |> Self-formed according to rfc2464. |> |> M1, M2, M3: IPv6 MANET local addresses, for example |> FD01:db8::1/128, FD01:db8::2/128 and FD01:db8::3/128. |> Manually assigned, or pre-configured (e.g. with SNMP) |> or formed according to a to be defined [Autoconf for MANETs] |> protocol, with a to-be-defined prefix (e.g. ULA, RFC4193). |> |> Although all nodes are marked as router, this does not imply all = nodes |> forward packets. All nodes run a MANET routing protocol for learning |the |> MANET topology. |> |I think I'm also agree here. |> |> In case one of the routers is connected to the Internet or private |network, |> this router can advertize a prefix in the MANET, and this information |is |> distributed in the MANET with an [Autoconf for MANETs] protocol. |> |> |> Internet |> | |> | |> +-------+-------+ |> | Access Router | |> +-------+-------+ |> | |> | | Prefix information |> | V |> | |> +-------+ wifi "adhoc1" +---+---+ wifi "adhoc2" +-------+ |> |Router1|>-------------<|Router2|>-------------<|Router3| |> +---L---+ LL1 LL21 +---L---+ LL22 LL3 +---L---+ |> |M1 |M2 |M3 |> |G1 |G2 |G3 |> <------- -------> |> Prefix information Prefix information |> |> |> G1, G2, G3: IPv6 globally unique addresses, for example |> 2001:db8:G:1/128, 2001:db8:G:2/128 and 2001:db8:G:3/128. |> Formed according to a to be defined [Autoconf for MANETs] |> protocol, with the prefix provided by (via) the Access Router. |> |> |> Multi-homing can easily be supported: |> |> ---+-------Internet--------+--- |> | | |> | | |> +-------+-------+ +-------+-------+ |> |Access Router H| |Access Router G| |> +-------+-------+ +-------+-------+ |> | | |> ||Prefix information H | |Prefix information G |> |V | V |> | | |> +---+---+ wifi "adhoc1" +---+---+ wifi "adhoc2" +-------+ |> |Router1|>-------------<|Router2|>-------------<|Router3| |> +---L---+ LL1 LL21 +---L---+ LL22 LL3 +---L---+ |> |M1 |M2 |M3 |> |G1 |G2 |G3 |> |H1 |H2 |H3 |> <------- -------> |> Prefix information G Prefix information G, H |> ---------> |> Prefix information H |> |> H1, H2, H3: IPv6 globally unique addresses, for example |> 2001:db8:H:1/128, 2001:db8:H:2/128 and 2001:db8:H:3/128. |> Formed according to a to be defined [Autoconf for MANETs] |> protocol, with the prefix provided by (via) Access Router H. |> |> |> Note that the impact of the number of interfaces is minimal, the |address |> configuration of Router2 is very similar to Router1 and Router3. = Also, |the |> status of the MANET interface has no impact on communication in case |of |> multi-homing and redundant paths. (OK, we might need MIP6 / HIP / |SHIM6 or |> application layer address swapping mechanisms). |> |> It doesn't matter how many ad hoc segments there are. In the = following |> scenario, the link to Access router G disappeared, Router 3 |disappeared and |> a Router4 joined IBSS "adhoc1". |> |> |> |> ---+-------Internet------ |> | |> | |> +-------+-------+ |> |Access Router H| |> +-------+-------+ |> | |> ||Prefix information H |> |V wifi "adhoc1" |> | <---------------------------v--------> |> <------|--v----------------------> | |> |<-|--------------------v-----------------------|---> |> | | | | |> +---+--'+ +---'---+ +---'---+ |> |Router1|>-------------<|Router2|>-------------<|Router4| |> +---L---+ LL1 LL21 +---L---+ LL22 LL4 +---L---+ |> |M1 |M2 |M4 |> |H1 |H2 |H4 |> |> ---------> ---------> |> Prefix information H Prefix information H |> |> |> Now, Router2 acts as a relay for Router4, so Router4 can reach = Router1 |and |> the Internet. Router1 acts as Border Router for all nodes in the |MANET. |> | |While I think this is also much in linee with my thinking, I think it's |better to focus on the simplest cases before. | |Thanks, | |Carlos | |> |> I have some thoughts on IPv4 supports. Of course IPv4 misses lots of |> flexibility that is used in above model. But there are ways to = support |it, |> e.g. IPv4 link local (RFC3927) accompanied by some extended form of |> duplicate address detection (passive checking routing tables). For |globally |> unique address assignment I think of DHCP-IPv4 over an IPv6 path, |provided |> as described above. (e.g. Router4 gets its /32 address for its |loopback |> interface from/via Access Router H, using M4 or H4 address and the |IPv6 |> MANET protocol. |> |> |> Any comments? |> Teco. |> |> |> |> |-----Oorspronkelijk bericht----- |> |Van: Carlos Jes=FAs Bernardos Cano [mailto:cjbc@it.uc3m.es] |> |Verzonden: donderdag 26 februari 2009 21:41 |> |Aan: Alexandru Petrescu |> |CC: Teco Boot; autoconf@ietf.org |> |Onderwerp: Re: [Autoconf] new charter |> | |> |Hi Alex: |> | |> | One question below. |> | |> |El jue, 26-02-2009 a las 20:44 +0100, Alexandru Petrescu escribi=F3: |> |> Sorry, I made an error indeed putting same prefix. How about this |> |> updated picture with the prefixes being distinct: |> |> |> |> |> |> ----- wifi "adhoc1" ------ wifi "adhoc2" ----- |> |> |Host1|---------------|Router|---------------|Host2| |> |> ----- LL1 LL2 ------ LL3 LL4 ----- |> |> G1 G4 |> |> |> |> |> |> "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode. |> |> Each is an IPv6 subnet. |> |> LL1...4: IPv6 link-local addresses. |> |> Self-formed according to rfc2464. |> |> G1, G4: IPv6 global addresses, for example |> |> 2001:db8:1::1/64 and |> |> 2001:db8:2::4/64 |> |> Manually assigned, or pre-configured with SNMP |> |> or formed according to stateless autoconf = rfc4862; |> |> the prefixes are advertised by Router in RAs. |> |> |> | |> |Does this model only apply to Host-Router-Host scenarios? I mean, |does |> |this model apply for Router-Router-Router scenarios? I fully agree |the |> |model fits the first scenario, but I don't for the second, since |> |routers' mobility within the ad-hoc network would force them to |change |> |prefixes often, I guess. For those scenarios it might be better to |think |> |of addressing models in which MANET routers are configured with /128 |> |(or /32 for IPv4) addresses, so they don't need to change their |> |addresses as a result of link changes. |> | |> |Kind Regards, |> | |> |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/ |> |++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |> |-- | 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/ |++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From cjbc@it.uc3m.es Mon Mar 2 02:57:16 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 377FC3A6C10 for ; Mon, 2 Mar 2009 02:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.866 X-Spam-Level: X-Spam-Status: No, score=-4.866 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_45=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 VUo-B7xwDJW4 for ; Mon, 2 Mar 2009 02:57:14 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id F34613A682B for ; Mon, 2 Mar 2009 02:57:13 -0800 (PST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Teco Boot In-Reply-To: <001c01c99b16$f12b1c90$d38155b0$@nl> References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <1235828619.6096.24.camel@localhost> <001c01c99b16$f12b1c90$d38155b0$@nl> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-BTPLL01Mcsen0rjWa2me" Organization: Universidad Carlos III de Madrid Date: Mon, 02 Mar 2009 11:57:37 +0100 Message-Id: <1235991457.5456.10.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16494.006 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 10:57:16 -0000 --=-BTPLL01Mcsen0rjWa2me Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Teco, El lun, 02-03-2009 a las 10:11 +0100, Teco Boot escribi=F3: > Hi Carlos, >=20 > |While I think this is also much in line with my thinking, I think it's > |better to focus on the simplest cases before. >=20 > You placed this comment just below a figure with just one Internet access > and three MANET Routers. > I think this is the simple case. >=20 > Maybe you intended to say "focus on single-homing and leave multi-homing = for > future enhancements". I meant something similar: "focus on single-homing first, to agree on the basics of the addressing model arquitecture, and leave the rest for a little bit later (not for future enhancements). > If so, I do not agree. In my use case (tactical networks), multi-homing i= s > an important requirement. I think it applies also for public safety / > disaster relief networks. More important, if we leave multi-homing > out-of-scope, we may easily make wrong decisions and block support for > multi-homing or it may not be optimal. I didn't mean out-of-the-scope. I just meant that there are very basic things we haven't agreed yet. Better to solve that first..., IMHO. >=20 > It is not that difficult to support multi-homing. Fred Templin VET soluti= on > uses map&encap approach, as my NEMO4MANET idea (both IRTF RRG strategy A)= . > BRDP based routing use "source address based routing" to the border route= r > (IRTF RRG strategy B). =20 >=20 > I think the routing aspect of multi-homing is more a [MANET WG] topic, an= d > [Autoconf WG] could ask [MANET WG] to work on solutions for it, based on = a > defined addressing model. Fully agree. Regards, Carlos >=20 > Regards, Teco >=20 >=20 >=20 > |-----Oorspronkelijk bericht----- > |Van: Carlos Jes=FAs Bernardos Cano [mailto:cjbc@it.uc3m.es] > |Verzonden: zaterdag 28 februari 2009 14:44 > |Aan: Teco Boot > |CC: autoconf@ietf.org; 'Alexandru Petrescu' > |Onderwerp: Re: Autoconf addressing model > | > |Hi Teco, > | > |El vie, 27-02-2009 a las 10:41 +0100, Teco Boot escribi=F3: > |> All, > |> > |> Here my opinion on the to be defined addressing model for MANETs / > |Autoconf. > |> I opened a separate thread, as I think (and hope) there will be an > |intensive > |> and productive discussion. > |> > |> Some of us like an address model with /32 (IPv4) or /128 (IPv6) > |> prefix-length addresses attached to an interface to a multi-access > |link. > |> These addresses do not have an Interface-ID. > |> > |> Such a model excludes usage of /64 "prefix swapping", which is IMHO an > |> extremely important attribute of IPv6. And it is specified as > |mandatory in > |> some standard track RFCs (e.g. RFC2464). > |> > |> We could discuss and analyze the effect of adopting the /128 (or /32) > |prefix > |> lengths for MANET interfaces, but I prefer taking this option as last > |> resort. I think there is a much more obvious option, using the RFC2464 > |model > |> for the MANET interface and /128 (or /32) for loopback interfaces. > |Both > |> would use high probability globally unique Interface IDs like EUI-64 > |> (Extended Unique Identifier). > | > |Agree, this is also my understanding. > | > |> > |> RFC4291 2.1. Addressing Model: > |> All interfaces are required to have at least one Link-Local unicast > |> address (see Section 2.8 for additional required addresses). A > |> single interface may also have multiple IPv6 addresses of any type > |> (unicast, anycast, and multicast) or scope. Unicast addresses with a > |> scope greater than link-scope are not needed for interfaces that are > |> not used as the origin or destination of any IPv6 packets to or from > |> non-neighbors. This is sometimes convenient for point-to-point > |> interfaces. > |> > |> RFC2464 4. Stateless Autoconfiguration: > |> An IPv6 address prefix used for stateless autoconfiguration [ACONF] > |> of an Ethernet interface must have a length of 64 bits. > |> > |> It is not only because the RFC texts that I dislike the /128 in MANET > |> interfaces, it is also backward compatibility with current IP stacks > |(and > |> probably many applications). I think an interface with /128 is stub, > |and > |> thus protocols may assume that there is no other node on this link in > |the > |> same subnet. Think of ARP and routing protocols. I verified this with > |some > |> product, the outcome confirmed my assumption. I was able to adjust the > |> configuration on one platform so that it worked (Linux), but still the > |> indication is that the model has a high impact. > |> > |> I think using /128 for loopback interfaces fits the requirements for > |the > |> addressing model. If a loopback interface is used, MANET interfaces do > |not > |> require a globally unique address. RFC4291 once more (out of section, > |also > |> cited above): > |> Unicast addresses with a > |> scope greater than link-scope are not needed for interfaces that are > |> not used as the origin or destination of any IPv6 packets to or from > |> non-neighbors. > |> So "host functionality" can be provided using the globally (or MANET > |local) > |> unique address assigned to a loopback address, or another non-MANET > |> interface. > |> > |> This results in the following addressing model, where all nodes are > |routers: > |> > |> +-------+ wifi "adhoc1" +-------+ wifi "adhoc2" +-------+ > |> |Router1|>-------------<|Router2|>-------------<|Router3| > |> +---L---+ LL1 LL21 +---L---+ LL22 LL3 +---L---+ > |> |M1 |M2 |M3 > |> > |> "adhoc1" and "adhoc2": 802.11 SSIDs in "IBSS" mode. > |> Each IBSS is an IPv6 subnet. > |> > |> L: Loopback interface. > |> > |> >, <: MANET interface. > |> > |> LL1, LL21, LL22, LL3: IPv6 link-local addresses. > |> Self-formed according to rfc2464. > |> > |> M1, M2, M3: IPv6 MANET local addresses, for example > |> FD01:db8::1/128, FD01:db8::2/128 and FD01:db8::3/128. > |> Manually assigned, or pre-configured (e.g. with SNMP) > |> or formed according to a to be defined [Autoconf for MANETs] > |> protocol, with a to-be-defined prefix (e.g. ULA, RFC4193). > |> > |> Although all nodes are marked as router, this does not imply all nodes > |> forward packets. All nodes run a MANET routing protocol for learning > |the > |> MANET topology. > |> > |I think I'm also agree here. > |> > |> In case one of the routers is connected to the Internet or private > |network, > |> this router can advertize a prefix in the MANET, and this information > |is > |> distributed in the MANET with an [Autoconf for MANETs] protocol. > |> > |> > |> Internet > |> | > |> | > |> +-------+-------+ > |> | Access Router | > |> +-------+-------+ > |> | > |> | | Prefix information > |> | V > |> | > |> +-------+ wifi "adhoc1" +---+---+ wifi "adhoc2" +-------+ > |> |Router1|>-------------<|Router2|>-------------<|Router3| > |> +---L---+ LL1 LL21 +---L---+ LL22 LL3 +---L---+ > |> |M1 |M2 |M3 > |> |G1 |G2 |G3 > |> <------- -------> > |> Prefix information Prefix information > |> > |> > |> G1, G2, G3: IPv6 globally unique addresses, for example > |> 2001:db8:G:1/128, 2001:db8:G:2/128 and 2001:db8:G:3/128. > |> Formed according to a to be defined [Autoconf for MANETs] > |> protocol, with the prefix provided by (via) the Access Router. > |> > |> > |> Multi-homing can easily be supported: > |> > |> ---+-------Internet--------+--- > |> | | > |> | | > |> +-------+-------+ +-------+-------+ > |> |Access Router H| |Access Router G| > |> +-------+-------+ +-------+-------+ > |> | | > |> ||Prefix information H | |Prefix information G > |> |V | V > |> | | > |> +---+---+ wifi "adhoc1" +---+---+ wifi "adhoc2" +-------+ > |> |Router1|>-------------<|Router2|>-------------<|Router3| > |> +---L---+ LL1 LL21 +---L---+ LL22 LL3 +---L---+ > |> |M1 |M2 |M3 > |> |G1 |G2 |G3 > |> |H1 |H2 |H3 > |> <------- -------> > |> Prefix information G Prefix information G, H > |> ---------> > |> Prefix information H > |> > |> H1, H2, H3: IPv6 globally unique addresses, for example > |> 2001:db8:H:1/128, 2001:db8:H:2/128 and 2001:db8:H:3/128. > |> Formed according to a to be defined [Autoconf for MANETs] > |> protocol, with the prefix provided by (via) Access Router H. > |> > |> > |> Note that the impact of the number of interfaces is minimal, the > |address > |> configuration of Router2 is very similar to Router1 and Router3. Also, > |the > |> status of the MANET interface has no impact on communication in case > |of > |> multi-homing and redundant paths. (OK, we might need MIP6 / HIP / > |SHIM6 or > |> application layer address swapping mechanisms). > |> > |> It doesn't matter how many ad hoc segments there are. In the following > |> scenario, the link to Access router G disappeared, Router 3 > |disappeared and > |> a Router4 joined IBSS "adhoc1". > |> > |> > |> > |> ---+-------Internet------ > |> | > |> | > |> +-------+-------+ > |> |Access Router H| > |> +-------+-------+ > |> | > |> ||Prefix information H > |> |V wifi "adhoc1" > |> | <---------------------------v--------> > |> <------|--v----------------------> | > |> |<-|--------------------v-----------------------|---> > |> | | | | > |> +---+--'+ +---'---+ +---'---+ > |> |Router1|>-------------<|Router2|>-------------<|Router4| > |> +---L---+ LL1 LL21 +---L---+ LL22 LL4 +---L---+ > |> |M1 |M2 |M4 > |> |H1 |H2 |H4 > |> > |> ---------> ---------> > |> Prefix information H Prefix information H > |> > |> > |> Now, Router2 acts as a relay for Router4, so Router4 can reach Router1 > |and > |> the Internet. Router1 acts as Border Router for all nodes in the > |MANET. > |> > | > |While I think this is also much in linee with my thinking, I think it's > |better to focus on the simplest cases before. > | > |Thanks, > | > |Carlos > | > |> > |> I have some thoughts on IPv4 supports. Of course IPv4 misses lots of > |> flexibility that is used in above model. But there are ways to support > |it, > |> e.g. IPv4 link local (RFC3927) accompanied by some extended form of > |> duplicate address detection (passive checking routing tables). For > |globally > |> unique address assignment I think of DHCP-IPv4 over an IPv6 path, > |provided > |> as described above. (e.g. Router4 gets its /32 address for its > |loopback > |> interface from/via Access Router H, using M4 or H4 address and the > |IPv6 > |> MANET protocol. > |> > |> > |> Any comments? > |> Teco. > |> > |> > |> > |> |-----Oorspronkelijk bericht----- > |> |Van: Carlos Jes=FAs Bernardos Cano [mailto:cjbc@it.uc3m.es] > |> |Verzonden: donderdag 26 februari 2009 21:41 > |> |Aan: Alexandru Petrescu > |> |CC: Teco Boot; autoconf@ietf.org > |> |Onderwerp: Re: [Autoconf] new charter > |> | > |> |Hi Alex: > |> | > |> | One question below. > |> | > |> |El jue, 26-02-2009 a las 20:44 +0100, Alexandru Petrescu escribi=F3: > |> |> Sorry, I made an error indeed putting same prefix. How about this > |> |> updated picture with the prefixes being distinct: > |> |> > |> |> > |> |> ----- wifi "adhoc1" ------ wifi "adhoc2" ----- > |> |> |Host1|---------------|Router|---------------|Host2| > |> |> ----- LL1 LL2 ------ LL3 LL4 ----- > |> |> G1 G4 > |> |> > |> |> > |> |> "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode. > |> |> Each is an IPv6 subnet. > |> |> LL1...4: IPv6 link-local addresses. > |> |> Self-formed according to rfc2464. > |> |> G1, G4: IPv6 global addresses, for example > |> |> 2001:db8:1::1/64 and > |> |> 2001:db8:2::4/64 > |> |> Manually assigned, or pre-configured with SNMP > |> |> or formed according to stateless autoconf rfc4862; > |> |> the prefixes are advertised by Router in RAs. > |> |> > |> | > |> |Does this model only apply to Host-Router-Host scenarios? I mean, > |does > |> |this model apply for Router-Router-Router scenarios? I fully agree > |the > |> |model fits the first scenario, but I don't for the second, since > |> |routers' mobility within the ad-hoc network would force them to > |change > |> |prefixes often, I guess. For those scenarios it might be better to > |think > |> |of addressing models in which MANET routers are configured with /128 > |> |(or /32 for IPv4) addresses, so they don't need to change their > |> |addresses as a result of link changes. > |> | > |> |Kind Regards, > |> | > |> |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/ > |> |++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > |> > |-- > | 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/ > |++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >=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/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-BTPLL01Mcsen0rjWa2me 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) iEYEABECAAYFAkmru6EACgkQNdy6TdFwT2f7aQCgmuri9hpi4ig1vreHs8bmfsLk egQAoNxRMVDwyI1lYorm13VBOGTcmDyI =Bfrw -----END PGP SIGNATURE----- --=-BTPLL01Mcsen0rjWa2me-- From cjbc@it.uc3m.es Mon Mar 2 03:00:51 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28CF83A6AEB for ; Mon, 2 Mar 2009 03:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.375 X-Spam-Level: X-Spam-Status: No, score=-5.375 tagged_above=-999 required=5 tests=[AWL=0.325, 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 pS6KIcRr9F8B for ; Mon, 2 Mar 2009 03:00:50 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id CEA483A6994 for ; Mon, 2 Mar 2009 03:00:49 -0800 (PST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: HyungJin Lim In-Reply-To: <7e8d02d40902281906k3fd36f03ud329c1db2738221e@mail.gmail.com> References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <1235828619.6096.24.camel@localhost> <49A94589.9050203@gmail.com> <7e8d02d40902281906k3fd36f03ud329c1db2738221e@mail.gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-FlVs0DmgXNdSvfmJrTOk" Organization: Universidad Carlos III de Madrid Date: Mon, 02 Mar 2009 12:01:13 +0100 Message-Id: <1235991673.5456.13.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16494.006 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 11:00:51 -0000 --=-FlVs0DmgXNdSvfmJrTOk Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi, I think we should address both the MANET connected and MANET disconnected scenarios. Whether there are NEMOs involved or not (MANEMO issues) is probably a topic that can be addressed later, once we have a clear picture of the simplest cases, IMHO (I agree MANEMO is an interesting topic). Regards, Carlos El dom, 01-03-2009 a las 12:06 +0900, HyungJin Lim escribi=F3: > inline.. >=20 > 2009/2/28, Alexandru Petrescu :=20 > Carlos Jes=FAs Bernardos Cano a =E9crit : > [...] > It doesn't matter how many ad hoc segments > there are. In the following > scenario, the link to Access router G > disappeared, Router 3 disappeared and > a Router4 joined IBSS "adhoc1". > =20 > =20 > =20 > ---+-------Internet------ > | | > +-------+-------+ |Access Router H| > +-------+-------+ | > ||Prefix information H > |V wifi "adhoc1" > | > <---------------------------v--------> > <------|--v----------------------> > | > |<-|--------------------v-----------------------= |---> > | | | > | > +---+--'+ +---'---+ > +---'---+ > |Router1|>-------------<|Router2| > >-------------<|Router4| > +---L---+ LL1 LL21 +---L---+ LL22 > LL4 +---L---+ > |M1 |M2 > |M4 > |H1 |H2 > |H4 > =20 > ---------> > ---------> > Prefix information H Prefix > information H > =20 > =20 > Now, Router2 acts as a relay for Router4, so > Router4 can reach Router1 and > the Internet. Router1 acts as Border Router > for all nodes in the MANET. > =20 > =20 > While I think this is also much in linee with my > thinking, I think it's > better to focus on the simplest cases before. > =20 > What are the simplest cases?=20 > =20 > I think we can divided into two category in MANET scenario as > follows. > =20 > Category 1=20 > Scenario 1: "MANET to Internet", in case, depths of nested > routers(NEMO) is under three levels. > This is practical case in real world (i.e., > most scenarios in real world) > Scenario 2: "MANET to Internet", depths of nested routers is > more than three levels. > (i.e., perhaps disaster situation, > etc.. ) > =20 > Category 2 (scenario 3)=20 > : "Only MANET", in case, the network does > not has a connectivity to Internet. > (i.e., peer-to-peer network, etc..) > =20 > Requirement of address model we need is different according with > considered scenario I think. > Then some scenarios included in category 2 not needs topological > meaningful address.=20 > =20 > Which area is AUTOCONF want to pinpoint ?=20 > =20 > I think AUTOCONF should satisfy requirements between pure MANET, > NEMO and MANEMO=20 > that can compose of mesh network, although we discussed about > the difference between MANET, NEMO and MANEMO > =20 > Moreover, these networks can has some impacts due to mobility > pattern, wireless coverage and any other situations. AUTOCONF > Addressing model can make a important role to efficient and secure > aspects. > =20 > What do you think about my comments ? > =20 > Hyung-Jin, Lim > =20 > Alex > =20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > =20 >=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/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-FlVs0DmgXNdSvfmJrTOk 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) iEYEABECAAYFAkmrvHkACgkQNdy6TdFwT2cDtwCeI1TbH3cuPgOSUQRA5vG+To+u 7rMAnRz43Gd/B+/ovkDaj+Ny9wvzk71t =DLP6 -----END PGP SIGNATURE----- --=-FlVs0DmgXNdSvfmJrTOk-- From teco@inf-net.nl Mon Mar 2 03:46:57 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C5F228C223 for ; Mon, 2 Mar 2009 03:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.996 X-Spam-Level: * X-Spam-Status: No, score=1.996 tagged_above=-999 required=5 tests=[AWL=-1.700, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_13=0.6, MANGLED_LIST=2.3, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6x0F0S2+YrX for ; Mon, 2 Mar 2009 03:46:56 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 6C47A28C215 for ; Mon, 2 Mar 2009 03:46:54 -0800 (PST) Received: (qmail 15488 invoked from network); 2 Mar 2009 12:47:17 +0100 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 2 Mar 2009 12:47:17 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl> <49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl> <49A944FF.9000102@gmail.com> In-Reply-To: <49A944FF.9000102@gmail.com> Date: Mon, 2 Mar 2009 12:46:48 +0100 Message-ID: <003001c99b2c$a3fcf4a0$ebf6dde0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmZreP63KOEox2JTDSgiOwp9x9iRgBdoqdQ Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Mon, 02 Mar 2009 11:46:57 -0000 Hi Alex, More on "loopback interface". And more on non-blocking obstacles. |> Check for example ISP BCP, rfc5375 | |Checked. The fact that Cisco uses 'loopback interface' to be something |completely different than the interface holding the loopback address |doesn't mean I should too. I disagree with Cisco on this particular |point. RFC5373 is not a "Cisco document". It is a IETF product, produced by v6ops. V6ops produces informational or BCP RFCs only. Many router vendors support loopback interfaces. Do you disagree with the v6ops document, best practices of most (all?) ISPs and most router vendors? ID.autoconf-manetarch-07 section 5.1 also suggests using the loopback interface for binding a globally unique address. My suggestion is using the loopback interface for the /128 (or /32) address(es), not the MANET Interface(s) as suggested in 5.2. |> The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. |> It may be used by a node to send an IPv6 packet to itself. It must |> not be assigned to any physical interface. It is treated as having |> Link-Local scope, and may be thought of as the Link-Local unicast |> address of a virtual interface (typically called the "loopback |> interface") to an imaginary link that goes nowhere. |> |> Note the wording "may be". | |Note the status of that rfc compared to the two rfcs you cited |previously calling the loopback interface a virtual interface. Yes. A loopback interface is a virtual interface. A virtual interface is NOT a loopback interface. Another example of non-transitivity. |> Assigning non-"loopback addresses" on the loopback interfaces is |permitted. | |YEs, it is permitted, I agree. | |But why should one do it? I came up with a handful advantages already: o Lower overhead. If each MANET interface would use a [MANET local] and optionally a set of globally unique addresses, more addresses are used and load on the MANET (and other) protocols is higher. o No address swap needed when session swaps from one interface to the other. Protocols like MIP6, HIP and SHIM6 could repair the issue in some cases, in other cases they cannot. How to reach a MIP6 HA in a disconnected MANET?) o If a MANET interfaces goes up and down (e.g. single neighbor flapping), the application may get affected. Using a virtual interface (typically the loopback interface), application layer recovery is circumvented. |> Your assumption is single hop communication and no MANET routing |protocol. I |> am interested in the more complex topologies. | |The pictures I drawn are multihop. And indeed I don't assume a MANET |routing protocol. Neither does the charter. And that's ok. Sorry, I missed this. Do you mean that host - router is multi-hop? Who is forwarding? Let's use figure 1-2 below. Is there connectivity between B and C, via A? |> There is no "essid" in ad hoc mode. It is the "ssid" of the IBSS. Only |ESS |> has essid. |> Let's try to be accurate. | |iwconfig essid "adhoc1" mode ad-hoc |is also accurate. Please use terms as standardized. ESSID stands for the name of an extended service set (ESS). An ESS is a set of basic service sets, connected over a distribution service. ESS is far from IBSS (more or less the opposite). I can't help the Linux iwconfig syntax uses essid for what should be the well defined 802.11 SSID. |> What about this scenario: here, the obstacle is moving: |> |> (802.11 term: STA is station) |> |> +------------------------+ +------------------------+ |> | | | | |> | ____STA-B | | ____STA-B | |> | ___/ | | | ___/ | |> | STA-A | | | STA-A OBSTACLE | |> | '--_ | | | '--_ | |> | '----STA-C | | '----STA-C | |> | OBSTACLE | | | |> +------------------------+ +------------------------+ |> 1-1: No hindrance 1-2: B-C blocked |> |> +------------------------+ +------------------------+ |> | | | O | |> | ____STA-B | | B STA-B | |> | ___/ | | | S | | |> | STA-A OB | | | STA-A T | | |> | ST | | | A | | |> | AC STA-C | | C STA-C | |> | LE | | LE | |> +------------------------+ +------------------------+ |> 1-3: A-C blocked 1-4: A-B & A-C blocked |> |> MANET Scenarios with blocking obstacle | |This is absolutely wonderful. I set it aside. | |> Compare with this one: |> |> (802.11 term: AP is access point) |> |> +------------------------+ +------------------------+ |> | | | | |> | ____STA-B | | ____STA-B | |> | ___/ | | ___/ | |> | AP-A | | AP-A OBSTACLE | |> | '--_ | | '--_ | |> | '----STA-C | | '----STA-C | |> | OBSTACLE | | | |> +------------------------+ +------------------------+ |> 4-1: No hindrance 4-2: No hindrance |> |> +------------------------+ +------------------------+ |> | | | O | |> | ____STA-B | | B STA-B | |> | ___/ | | S | |> | AP-A OB | | AP-A T | |> | ST | | A | |> | AC STA-C | | C STA-C | |> | LE | | LE | |> +------------------------+ +------------------------+ |> 4-3: A-C & B-C blocked 4-4: All blocked |> |> 802.11 BSS L2 topology with blocking obstacle |> |> |> In these scenario's, the MANET model provides better connectivity. I |won't |> say more bandwidth, lower loss or other link quality metrics, but for |high |> availability the MANET model definitely wins. | |I set this aside too. | |HAving them pictured, may I ask you: do you think anything will ever be |able to communicate through Obstacles? Yes, of course. +------------------------+ +------------------------+ | | | | | ____STA-B | | ____STA-B | | ___/ 1 | | | ___/ 1 . | | STA-A | 1 | | STA-A obstacle 5 | | '--_ 1 | | | '--_ 1 . | | '----STA-C | | '----STA-C | | obstacle | | | +------------------------+ +------------------------+ 2-1: No hindrance 2-2: B-C degraded +------------------------+ +------------------------+ | | | o | | ____STA-B | | 5 b ...STA-B | | ___/ 1 | | | ...s. | | | STA-A ob | 1 | | STA-A t | 1 | | ... st | | | ...a. | | | 5 .ac..STA-C | | 5 c ...STA-C | | le | | le | +------------------------+ +------------------------+ 2-3: A-C degraded 2-4: A-B & A-C degraded Scenarios with degrading obstacle I depicted the metrics: 1 is good, 5 is degraded. Here the routing tables, with metrics: ROUTER DEST NEXTHOP METRIC ROUTER DEST NEXTHOP METRIC +-------+-------+-------+------+ +-------+-------+-------+------+ | A | B | B | 1 | | A | B | B | 1 | | | C | C | 1 | | | C | C | 1 | +-------+-------+-------+------+ +-------+-------+-------+------+ | B | A | A | 1 | | B | A | A | 1 | | | C | C | 1 | | | C | C | 5 | +-------+-------+-------+------+ +-------+-------+-------+------+ | C | A | A | 1 | | C | A | A | 1 | | | B | B | 1 | | | B | B | 5 | +-------+-------+-------+------+ +-------+-------+-------+------+ 11-1: No hindrance 11-2: B-C is degraded +-------+-------+-------+------+ +-------+-------+-------+------+ | A | B | B | 1 | | A | B | B | 5 | | | C | C | 5 | | | C | C | 5 | +-------+-------+-------+------+ +-------+-------+-------+------+ | B | A | A | 1 | | B | A | A | 5 | | | C | C | 1 | | | C | C | 1 | +-------+-------+-------+------+ +-------+-------+-------+------+ | C | A | A | 5 | | C | A | A | 5 | | | B | B | 1 | | | B | B | 1 | +-------+-------+-------+------+ +-------+-------+-------+------+ 11-3: A-C degraded 11-4: A-B & A-C degraded This is for the MANET scenario. I can provide this for infrastructure mode also, if you want me to. Teco. |Alex From teco@inf-net.nl Mon Mar 2 04:01:32 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAEC23A6C38 for ; Mon, 2 Mar 2009 04:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.246 X-Spam-Level: X-Spam-Status: No, score=0.246 tagged_above=-999 required=5 tests=[AWL=1.750, 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 frtOUunEUuV7 for ; Mon, 2 Mar 2009 04:01:32 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 9EA363A6BFB for ; Mon, 2 Mar 2009 04:01:31 -0800 (PST) Received: (qmail 32419 invoked from network); 2 Mar 2009 13:01:55 +0100 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 2 Mar 2009 13:01:55 +0100 From: "Teco Boot" To: "'HyungJin Lim'" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <1235828619.6096.24.camel@localhost> <49A94589.9050203@gmail.com> <7e8d02d40902281906k3fd36f03ud329c1db2738221e@mail.gmail.com> In-Reply-To: <7e8d02d40902281906k3fd36f03ud329c1db2738221e@mail.gmail.com> Date: Mon, 2 Mar 2009 13:01:25 +0100 Message-ID: <003701c99b2e$af2d43f0$0d87cbd0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmaGqoTHJvJbYbRTTW0cmvuJK/2kwBEjmTw Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Mon, 02 Mar 2009 12:01:32 -0000 Hi, I think nested-NEMO is handled by MEXT. As soon as the NEMO-RO = requirement documents are finalized we could check how MANET protocols fit and if = there is a need for an optimized MANET protocol for NEMO (e.g. MANEMO). For the nested-NEMO addressing model, I am not aware of problems.=20 Problems are introduced when the Mobile Network is a MANET, where nodes = come and go and prefix information is sent to (multiple) home agents = dynamically. The MANET Routing protocol may run over the MRHA tunnel, but this could introduce high overhead, especially if metrics are introduced and = metrics dampening & hysteresis is not implemented.=20 There could be some issues with MANET + NEMO + multi-homing. Regards, Teco =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Van: HyungJin Lim [mailto:dream.hjlim@gmail.com]=20 Verzonden: zondag 1 maart 2009 4:06 Aan: Alexandru Petrescu CC: cjbc@it.uc3m.es; teco@inf-net.nl; autoconf@ietf.org Onderwerp: Re: [Autoconf] Autoconf addressing model inline.. 2009/2/28, Alexandru Petrescu :=20 Carlos Jes=FAs Bernardos Cano a =E9crit : [...] It doesn't matter how many ad hoc segments there are. In the following scenario, the link to Access router G disappeared, Router 3 disappeared = and a Router4 joined IBSS "adhoc1". =A0 =A0 ---+-------Internet------ =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| =A0 =A0 =A0 =A0 =A0 +-------+-------+ =A0 =A0 =A0|Access Router H| =A0 =A0 =A0 +-------+-------+ =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0||Prefix information H =A0 =A0 =A0 =A0 =A0|V = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 wifi "adhoc1" =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = <---------------------------v--------> =A0<------|--v----------------------> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 | =A0 =A0 =A0 =A0|<-|--------------------v-----------------------|---> =A0 =A0 =A0 =A0| =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0+---+--'+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 +---'---+ =A0 =A0 =A0 =A0 = =A0 =A0 =A0 +---'---+ =A0 =A0|Router1|>-------------<|Router2|>-------------<|Router4| =A0 =A0+---L---+ LL1 =A0 =A0 =A0LL21 +---L---+ LL22 =A0 =A0 =A0LL4 = +---L---+ =A0 =A0 =A0 =A0|M1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |M2 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |M4 =A0 =A0 =A0 =A0|H1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |H2 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |H4 =A0 =A0 =A0 =A0 =A0 =A0 =A0---------> =A0 =A0 =A0 =A0 =A0 =A0 =A0 = ---------> =A0 =A0 =A0 =A0 =A0 =A0 =A0Prefix information H =A0 =A0 Prefix = information H Now, Router2 acts as a relay for Router4, so Router4 can reach Router1 = and the Internet. Router1 acts as Border Router for all nodes in the MANET. While I think this is also much in linee with my thinking, I think it's better to focus on the simplest cases before. What are the simplest cases?=20 =A0 =A0=A0 I think we can divided into two category in MANET scenario as = follows. =A0 =A0=A0=A0=A0=A0=A0 =A0Category 1=20 =A0=A0 =A0=A0=A0=A0 =A0=A0=A0 Scenario 1: "MANET to=A0Internet", in = case,=A0depths of nested routers(NEMO) =A0is under three levels. =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0This is practical case = in real world (i.e., most=A0scenarios in real world) =A0=A0=A0=A0=A0=A0=A0=A0 Scenario 2: "MANET to Internet", depths of = nested routers is more than three levels. =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 (i.e., perhaps disaster situation, etc..=A0) =A0 =A0=A0=A0=A0=A0 =A0Category=A02 (scenario 3)=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 : "Only MANET", in case, the network does not has a connectivity to Internet. =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 (i.e., peer-to-peer network, etc..) =A0=A0=A0 =A0=A0=A0=A0=A0Requirement of address model we need=A0is different = according with considered scenario I think. =A0=A0=A0=A0 Then=A0some scenarios included in category 2 not needs = topological meaningful address.=A0 =A0 =A0=A0=A0=A0=A0=A0Which area=A0is AUTOCONF want to pinpoint ?=20 =A0 =A0 =A0=A0=A0 I think AUTOCONF should satisfy requirements=A0between = pure MANET, NEMO and=A0MANEMO=20 =A0=A0=A0=A0=A0=A0that can compose of=A0mesh network, although we = discussed about the difference=A0between MANET, NEMO and=A0MANEMO =A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0Moreover,=A0these networks can has some impacts=A0due = to mobility pattern, wireless coverage and any other situations.=A0AUTOCONF Addressing=A0model=A0can=A0make a important role=A0to efficient = and=A0secure aspects. =A0 =A0=A0=A0=A0 What do you think about my comments ? =A0=A0=A0=A0=20 =A0=A0 Hyung-Jin, Lim =A0 Alex _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From dream.hjlim@gmail.com Mon Mar 2 04:25:02 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4070328C0DE for ; Mon, 2 Mar 2009 04:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.050, 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 TRo1qTCxz+DR for ; Mon, 2 Mar 2009 04:25:00 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.186]) by core3.amsl.com (Postfix) with ESMTP id 4A25F3A68E6 for ; Mon, 2 Mar 2009 04:25:00 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id 11so2761070tim.25 for ; Mon, 02 Mar 2009 04:25:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ntyRN8kvZy/ZhDTuhM2LNcSs4w3Sag6NgjPV4qEYPLg=; b=Aes8KjcgaOT5psnDD7Ajkh3FHobWpZo/hDGC+pb3pdM743ytjuziUxS+/38VF9yka4 XSf++b/599iHS5D/jea1KjGpMOLKl3y/QHhTmc9Im/HxAsrdIXl8M6XTcA4Egk2iSUx1 ePV6DL2RvVd55CFeTa3IlXUbR2nh9GOamh6k8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kZpD0be7hQenLvaHWSNdM2GNhmXEaoyzplGE+LXVPaioxWZw45bwmwGQI26+B5r2QG lV4RELNmrLZTlEeGwS8Klv0XOQQu3G0gpRend38cSqqOlNbCYjXg1rJ3JcaQ1hs8cnD4 R+Dnm4KXGeYcoIQ4moBZzKeAitSx0MARHc/iM= MIME-Version: 1.0 Received: by 10.110.61.16 with SMTP id j16mr3325416tia.23.1235996725215; Mon, 02 Mar 2009 04:25:25 -0800 (PST) In-Reply-To: <003701c99b2e$af2d43f0$0d87cbd0$@nl> References: <499F0BA7.90501@piuha.net> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <1235828619.6096.24.camel@localhost> <49A94589.9050203@gmail.com> <7e8d02d40902281906k3fd36f03ud329c1db2738221e@mail.gmail.com> <003701c99b2e$af2d43f0$0d87cbd0$@nl> Date: Mon, 2 Mar 2009 21:25:25 +0900 Message-ID: <7e8d02d40903020425g8ea4893sd7ac9773378bb600@mail.gmail.com> From: HyungJin Lim To: Teco Boot Content-Type: multipart/alternative; boundary=001485f01e5ec00238046421e92d Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Mon, 02 Mar 2009 12:25:02 -0000 --001485f01e5ec00238046421e92d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi See inline 2009/3/2 Teco Boot > Hi, > > I think nested-NEMO is handled by MEXT. As soon as the NEMO-RO requiremen= t > documents are finalized we could check how MANET protocols fit and if the= re > is a need for an optimized MANET protocol for NEMO (e.g. MANEMO). > I see !! I will expect the phase you address, in MEXT. > > For the nested-NEMO addressing model, I am not aware of problems. > Problems are introduced when the Mobile Network is a MANET, where nodes > come > and go and prefix information is sent to (multiple) home agents > dynamically. Right ! > > The MANET Routing protocol may run over the MRHA tunnel, but this could > introduce high overhead, especially if metrics are introduced and metrics > dampening & hysteresis is not implemented. From this point you are describing, there are some issues in relation to address strategy, packet forwarding/routing, and etc. Then MANET routing protocol can make a proper role in those situation I think. > > There could be some issues with MANET + NEMO + multi-homing. > I agree. Your this comment is the one of major issues we should resolve. I think address configuration strategy will affect on these situations. At that time, if I need, I will participate to this discussion. Thanks for your comment. > > Regards, Teco > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Van: HyungJin Lim [mailto:dream.hjlim@gmail.com] > Verzonden: zondag 1 maart 2009 4:06 > Aan: Alexandru Petrescu > CC: cjbc@it.uc3m.es; teco@inf-net.nl; autoconf@ietf.org > Onderwerp: Re: [Autoconf] Autoconf addressing model > > inline.. > 2009/2/28, Alexandru Petrescu : > Carlos Jes=FAs Bernardos Cano a =E9crit : > [...] > It doesn't matter how many ad hoc segments there are. In the following > scenario, the link to Access router G disappeared, Router 3 disappeared a= nd > a Router4 joined IBSS "adhoc1". > > > > ---+-------Internet------ > | | +-------+-------+ > |Access Router H| +-------+-------+ | > ||Prefix information H |V wifi > "adhoc1" > | <---------------------------v--------> > <------|--v----------------------> | > |<-|--------------------v-----------------------|---> > | | | | > +---+--'+ +---'---+ +---'---+ > |Router1|>-------------<|Router2|>-------------<|Router4| > +---L---+ LL1 LL21 +---L---+ LL22 LL4 +---L---+ > |M1 |M2 |M4 > |H1 |H2 |H4 > > ---------> ---------> > Prefix information H Prefix information H > > > Now, Router2 acts as a relay for Router4, so Router4 can reach Router1 an= d > the Internet. Router1 acts as Border Router for all nodes in the MANET. > > While I think this is also much in linee with my thinking, I think it's > better to focus on the simplest cases before. > > What are the simplest cases? > > I think we can divided into two category in MANET scenario as follows. > > Category 1 > Scenario 1: "MANET to Internet", in case, depths of nested > routers(NEMO) is under three levels. > This is practical case in real world (i.e., > most scenarios in real world) > Scenario 2: "MANET to Internet", depths of nested routers is mor= e > than three levels. > (i.e., perhaps disaster situation, etc.. ) > > Category 2 (scenario 3) > : "Only MANET", in case, the network does not > has > a connectivity to Internet. > (i.e., peer-to-peer network, etc..) > > Requirement of address model we need is different according with > considered scenario I think. > Then some scenarios included in category 2 not needs topological > meaningful address. > > Which area is AUTOCONF want to pinpoint ? > > I think AUTOCONF should satisfy requirements between pure MANET, NE= MO > and MANEMO > that can compose of mesh network, although we discussed about the > difference between MANET, NEMO and MANEMO > > Moreover, these networks can has some impacts due to mobility > pattern, > wireless coverage and any other situations. AUTOCONF > Addressing model can make a important role to efficient and secure aspect= s. > > What do you think about my comments ? > > Hyung-Jin, Lim > > Alex > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > > > --001485f01e5ec00238046421e92d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi
See inline
2009/3/2 Teco Boot <teco@inf-net.nl>
Hi,

I think nested-NEMO i= s handled by MEXT. As soon as the NEMO-RO requirement
documents are fina= lized we could check how MANET protocols fit and if there
is a need for an optimized MANET protocol for NEMO (e.g. MANEMO).
=A0
I see !! I will expect the phase you address, in MEXT.

For the= nested-NEMO addressing model, I am not aware of problems.
Problems are = introduced when the Mobile Network is a MANET, where nodes come
and go and prefix information is sent to (multiple) home agents dynamically= .
=A0
=A0=A0 Right !

The MAN= ET Routing protocol may run over the MRHA tunnel, but this could
introdu= ce high overhead, especially if metrics are introduced and metrics
dampening & hysteresis is not implemented.
=A0
=A0 From this point you are describing, there are some issues in relat= ion to address strategy, packet forwarding/routing, and etc. Then MANET rou= ting protocol can make a proper role in those situation I think.
=A0

There c= ould be some issues with MANET + NEMO + multi-homing.
=A0
I agree.=A0=A0Your=A0this comment is=A0the one of=A0major issues we sh= ould resolve.
I think address configuration strategy will affect on these situations= .
=A0
At that time, if I need, I will participate to this discussion.
=A0
Thanks for your comment.
=A0

Regards= , Teco




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
= Van: HyungJin Lim [mailto:dream.hj= lim@gmail.com]
Verzonden: zondag 1 maart 2009 4:06
Aan: Alexandru Petrescu
CC: cjbc@it.uc3m.es; teco@inf-net.nl; autoco= nf@ietf.org
Onderwerp: Re: [Autoconf] Autoconf addressing model

inline..
2009= /2/28, Alexandru Petrescu <alexandru.petrescu@gmail.com>:
Carlos Jes=FAs Bernardos Cano a= =E9crit :
[...]
It doesn't matter how many ad hoc segments there are. In the f= ollowing
scenario, the link to Access router G disappeared, Router 3 dis= appeared and
a Router4 joined IBSS "adhoc1".



=A0 =A0 ---+-------Internet------
=A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 +-------+-------+ = =A0 =A0
=A0|Access Router H| =A0 =A0 =A0 +-------+-------+ =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
=A0 =A0 =A0 =A0 =A0= =A0 =A0||Prefix information H =A0 =A0 =A0 =A0 =A0|V =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 wifi
"adhoc1"
=A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = <---------------------------v-------->
=A0<------|--v----------= ------------> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0
= =A0|<-|--------------------v-----------------------|--->
=A0 =A0 =A0 =A0| =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0+---+--'+ =A0 =A0 =A0 =A0 = =A0 =A0 =A0 +---'---+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 +---'---+
=A0 = =A0|Router1|>-------------<|Router2|>-------------<|Router4|=A0 =A0+---L---+ LL1 =A0 =A0 =A0LL21 +---L---+ LL22 =A0 =A0 =A0LL4 +---L--= -+
=A0 =A0 =A0 =A0|M1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |M2 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 |M4
=A0 =A0 =A0 =A0|H1 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 |H2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |H4

= =A0 =A0 =A0 =A0 =A0 =A0 =A0---------> =A0 =A0 =A0 =A0 =A0 =A0 =A0 ------= --->
=A0 =A0 =A0 =A0 =A0 =A0 =A0Prefix information H =A0 =A0 Prefix i= nformation H


Now, Router2 acts as a relay for Router4, so Router4 can reach Rout= er1 and
the Internet. Router1 acts as Border Router for all nodes in the= MANET.

While I think this is also much in linee with my thinking, I= think it's
better to focus on the simplest cases before.

What are the simplest = cases?
=A0
=A0=A0 I think we can divided into two category in MANET s= cenario as follows.
=A0
=A0=A0=A0=A0=A0=A0 =A0Category 1
=A0=A0 = =A0=A0=A0=A0 =A0=A0=A0 Scenario 1: "MANET to=A0Internet", in case= ,=A0depths of nested
routers(NEMO) =A0is under three levels.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0This is practical case in r= eal world (i.e.,
most=A0scenarios in real world)
=A0=A0=A0=A0=A0=A0= =A0=A0 Scenario 2: "MANET to Internet", depths of nested routers = is more
than three levels.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (i.e., perhaps disaster situation, etc..= =A0)
=A0
=A0=A0=A0=A0=A0 =A0Category=A02 (scenario 3)=A0
=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : &qu= ot;Only MANET", in case, the network does not has
a connectivity to Internet.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (i.e., peer-to-peer network, etc= ..)
=A0=A0=A0
=A0=A0=A0=A0=A0Requirement of address model we need=A0i= s different according with
considered scenario I think.
=A0=A0=A0=A0 = Then=A0some scenarios included in category 2 not needs topological
meaningful address.=A0
=A0
=A0=A0=A0=A0=A0=A0Which area=A0is AUTOCONF= want to pinpoint ?
=A0
=A0 =A0=A0=A0 I think AUTOCONF should satisfy= requirements=A0between pure MANET, NEMO
and=A0MANEMO
=A0=A0=A0=A0=A0= =A0that can compose of=A0mesh network, although we discussed about the
difference=A0between MANET, NEMO and=A0MANEMO
=A0=A0=A0=A0
=A0=A0=A0= =A0=A0=A0Moreover,=A0these networks can has some impacts=A0due to mobility = pattern,
wireless coverage and any other situations.=A0AUTOCONF
Addre= ssing=A0model=A0can=A0make a important role=A0to efficient and=A0secure asp= ects.
=A0
=A0=A0=A0=A0 What do you think about my comments ?
=A0=A0=A0=A0=A0=A0 Hyung-Jin, Lim
=A0
Alex

_____________________________= __________________
Autoconf mailing list
Autoconf@ietf.org
https://www.ietf.org/mailman/listinfo/autoconf



--001485f01e5ec00238046421e92d-- From dream.hjlim@gmail.com Mon Mar 2 04:44:13 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 344173A6AC3 for ; Mon, 2 Mar 2009 04:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 DnuD7iwAUodf for ; Mon, 2 Mar 2009 04:44:11 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.185]) by core3.amsl.com (Postfix) with ESMTP id 573B83A6BF6 for ; Mon, 2 Mar 2009 04:44:08 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id 11so2765627tim.25 for ; Mon, 02 Mar 2009 04:44:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=hKa52uRyGBPQ3vL6I00h27qW4lDP3oV25ZVh+YNmFqc=; b=m7UyQsAQya/VVcudi4Zrr1tSMhckOlxFDadv2friSygmxrDpLprdrYzf2nTbfQ8ZlD d2qUHV7Ukw9tqE7V2vskQ/6YNqkRmJhClCu1ossfos1taqahV13aX9vTHEGNmn5iLQZ9 U9Z/oAYfpfw9qICyhp81M4bcbQpHsb5dxDr6w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=s69OrvER1PBFaJVq/Tp1rIZHL7V1v4dz5UV1p3vjxxbHc+95NFCHRQXbOL/lxAEgJQ unPHvWvFEZDvPtFAs+qnQodGwLAFJlhyxxqidMvRBZZoxxBJWw930lMG3UUoJivNhaHQ g3pcx5lquIxjxMNmH3WXp4vRCApQ+c8ii8jFs= MIME-Version: 1.0 Received: by 10.110.3.15 with SMTP id 15mr8675598tic.0.1235997873628; Mon, 02 Mar 2009 04:44:33 -0800 (PST) In-Reply-To: <1235991673.5456.13.camel@localhost> References: <499F0BA7.90501@piuha.net> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <1235828619.6096.24.camel@localhost> <49A94589.9050203@gmail.com> <7e8d02d40902281906k3fd36f03ud329c1db2738221e@mail.gmail.com> <1235991673.5456.13.camel@localhost> Date: Mon, 2 Mar 2009 21:44:33 +0900 Message-ID: <7e8d02d40903020444p2c4baea4qf94318444b08d6a9@mail.gmail.com> From: HyungJin Lim To: cjbc@it.uc3m.es Content-Type: multipart/alternative; boundary=001485f4225e3365880464222ea3 Cc: Autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Mon, 02 Mar 2009 12:44:13 -0000 --001485f4225e3365880464222ea3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, ...inline.. 2009/3/2 Carlos Jes=FAs Bernardos Cano > Hi, > > I think we should address both the MANET connected and MANET > disconnected scenarios. Okey !! If need, I also will participate on this discussion for MANET and MANEMO. > Whether there are NEMOs involved or not (MANEMO > issues) is probably a topic that can be addressed later, once we have a > clear picture of the simplest cases, IMHO (I agree MANEMO is an > interesting topic). > Thanks, Hyung-Jin, Lim Regards, Carlos El dom, 01-03-2009 a las 12:06 +0900, HyungJin Lim escribi=F3: > > inline.. > > > > 2009/2/28, Alexandru Petrescu : > > Carlos Jes=FAs Bernardos Cano a =E9crit : > > [...] > > It doesn't matter how many ad hoc segments > > there are. In the following > > scenario, the link to Access router G > > disappeared, Router 3 disappeared and > > a Router4 joined IBSS "adhoc1". > > > > > > > > ---+-------Internet------ > > | | > > +-------+-------+ |Access Router H| > > +-------+-------+ | > > ||Prefix information H > > |V wifi "adhoc1" > > | > > <---------------------------v--------> > > <------|--v----------------------> > > | > > > |<-|--------------------v-----------------------|---> > > | | | > > | > > +---+--'+ +---'---+ > > +---'---+ > > |Router1|>-------------<|Router2| > > >-------------<|Router4| > > +---L---+ LL1 LL21 +---L---+ LL22 > > LL4 +---L---+ > > |M1 |M2 > > |M4 > > |H1 |H2 > > |H4 > > > > ---------> > > ---------> > > Prefix information H Prefix > > information H > > > > > > Now, Router2 acts as a relay for Router4, so > > Router4 can reach Router1 and > > the Internet. Router1 acts as Border Router > > for all nodes in the MANET. > > > > > > While I think this is also much in linee with my > > thinking, I think it's > > better to focus on the simplest cases before. > > > > What are the simplest cases? > > > > I think we can divided into two category in MANET scenario as > > follows. > > > > Category 1 > > Scenario 1: "MANET to Internet", in case, depths of nested > > routers(NEMO) is under three levels. > > This is practical case in real world (i.e., > > most scenarios in real world) > > Scenario 2: "MANET to Internet", depths of nested routers is > > more than three levels. > > (i.e., perhaps disaster situation, > > etc.. ) > > > > Category 2 (scenario 3) > > : "Only MANET", in case, the network does > > not has a connectivity to Internet. > > (i.e., peer-to-peer network, etc..) > > > > Requirement of address model we need is different according with > > considered scenario I think. > > Then some scenarios included in category 2 not needs topological > > meaningful address. > > > > Which area is AUTOCONF want to pinpoint ? > > > > I think AUTOCONF should satisfy requirements between pure MANET, > > NEMO and MANEMO > > that can compose of mesh network, although we discussed about > > the difference between MANET, NEMO and MANEMO > > > > Moreover, these networks can has some impacts due to mobility > > pattern, wireless coverage and any other situations. AUTOCONF > > Addressing model can make a important role to efficient and secure > > aspects. > > > > What do you think about my comments ? > > > > Hyung-Jin, Lim > > > > Alex > > > > _______________________________________________ > > 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/ > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > --001485f4225e3365880464222ea3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=A0
...inline..

2009/3/2 Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es>
Hi,

=A0 =A0 =A0 =A0I thin= k we should address both the MANET connected and MANET
disconnected scen= arios.
=A0
=A0=A0Okey !!
=A0 If need, I also will participate on this discussion for MANET and = MANEMO.
=A0
Whether the= re are NEMOs involved or not (MANEMO
issues) is probably a topic that ca= n be addressed later, once we have a
clear picture of the simplest cases, IMHO (I agree MANEMO is an
interest= ing topic).
=A0
Thanks,
Hyung-Jin, Lim

=A0=A0=A0=A0=A0=A0=A0Regards,

=A0 =A0 =A0 =A0Carlos

= El dom, 01-03-2009 a las 12:06 +0900, HyungJin Lim escribi=F3:
> inline..
>
> 2009/2/28, Alexandru Pe= trescu <alexandru.petres= cu@gmail.com>:
> =A0 =A0 =A0 =A0 Carlos Jes=FAs Bernardos Cano= a =E9crit :
> =A0 =A0 =A0 =A0 [...]
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 It doesn't matter how many ad hoc segments
> =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 there are. In the following
> =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 scenario, the link to Access r= outer G
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 disappeared, Router 3 = disappeared and
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 a R= outer4 joined IBSS "adhoc1".
>
>
>
> =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ---+-------Internet----= --
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
> =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +-------+-------+ =A0 =A0 =A0|Access Ro= uter H|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +-------+--= -----+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0||Prefix inform= ation H
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|V =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 wifi "adhoc1"
> =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
> =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <---------------------------v-------= ->
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<------= |--v---------------------->
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|<-|--------------------v--------= ---------------|--->
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0| =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+---+--'+ = =A0 =A0 =A0 =A0 =A0 =A0 =A0 +---'---+
> =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 +---'---+
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0|Router1|>-------------<|Router2|
> = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >-------------<|Route= r4|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+---L---+ LL1 = =A0 =A0 =A0LL21 +---L---+ LL22
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0LL4 +---L---+
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0|M1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |M2<= br>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |M4
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|H1 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |H2
> =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 |H4
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0--------->
> =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 --------->
> =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Prefix infor= mation H =A0 =A0 Prefix
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 information H
><= br>>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Now, Router= 2 acts as a relay for Router4, so
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 Router4 can reach Router1 and
> =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 the Internet. Router1 acts as Border Router
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 for all nodes in the M= ANET.
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 While I think= this is also much in linee with my
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= thinking, I think it's
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 better = to focus on the simplest cases before.
>
> =A0 =A0 =A0 =A0 What are the simplest cases?
>
> = =A0 =A0I think we can divided into two category in MANET scenario as
>= ; follows.
>
> =A0 =A0 =A0 =A0 Category 1
> =A0 =A0 =A0 = =A0 =A0 =A0 Scenario 1: "MANET to Internet", in case, depths of n= ested
> routers(NEMO) =A0is under three levels.
> =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0This is practical case in real world (i.= e.,
> most scenarios in real world)
> =A0 =A0 =A0 =A0 =A0Scenar= io 2: "MANET to Internet", depths of nested routers is
> more than three levels.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0(i.e., perhaps disaster situation,
> etc.. )>
> =A0 =A0 =A0 =A0Category 2 (scenario 3)
> =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: "Only MANET", in cas= e, the network does
> not has a connectivity to Internet.
> =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(i.e., peer-to-peer network, etc..)
&= gt;
> =A0 =A0 =A0Requirement of address model we need is different ac= cording with
> considered scenario I think.
> =A0 =A0 =A0Then some scenarios included in category 2 not needs topolo= gical
> meaningful address.
>
> =A0 =A0 =A0 Which area is= AUTOCONF want to pinpoint ?
>
> =A0 =A0 =A0 I think AUTOCONF s= hould satisfy requirements between pure MANET,
> NEMO and MANEMO
> =A0 =A0 =A0 that can compose of mesh network, = although we discussed about
> the difference between MANET, NEMO and = MANEMO
>
> =A0 =A0 =A0 Moreover, these networks can has some im= pacts due to mobility
> pattern, wireless coverage and any other situations. AUTOCONF
> = Addressing model can make a important role to efficient and secure
> = aspects.
>
> =A0 =A0 =A0What do you think about my comments ? >
> =A0 =A0Hyung-Jin, Lim
>
> =A0 =A0 =A0 =A0 Alex
= >
> =A0 =A0 =A0 =A0 ______________________________________________= _
> =A0 =A0 =A0 =A0 Autoconf mailing list
> =A0 =A0 =A0 =A0 Autoconf@ietf.org
> =A0 =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/autoconf>
>
--
=A0Carlos Jes=FAs Bernardos Cano =A0 =A0 http://www.netcoms.net
=A0= GPG FP: D29B 0A6A 639A A561 93CA =A04D55 35DC BA4D D170 4F67
+++++++++++= +++++++++++++++++++++++++++++++++++++++++++++++++
=A0WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
=A0 =A0 =A0 = =A0Deployment Experiences on Vehicular networks
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0http://www.= weedev.org/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++= ++++

--001485f4225e3365880464222ea3-- From chris.dearlove@baesystems.com Mon Mar 2 06:52:31 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91AFF3A68B8 for ; Mon, 2 Mar 2009 06:52: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=[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 FJ92sXLGPN3T for ; Mon, 2 Mar 2009 06:52:30 -0800 (PST) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id 464D43A6818 for ; Mon, 2 Mar 2009 06:52:30 -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 n22EqseW029888 for ; Mon, 2 Mar 2009 14:52:54 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 n22Eqs76026201 for ; Mon, 2 Mar 2009 14:52:54 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 02 Mar 2009 14:52:54 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 2 Mar 2009 14:52:53 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Mar 2009 14:52:52 -0000 Message-ID: In-Reply-To: <7FB7EE0A621BA44B8B69E5F0A09DC76407AD0C48@xmb-rtp-208.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] new charter Thread-Index: AcmZA4D7GvOj98TgRN+fRurNRpYVsAAA95NwAI+ZrRA= References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com><000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com><1235680887.4585.5.camel@localhost><49A7BB89.5040807@gmail.com><003901c998cb$42b71e90$c8255bb0$@nl><49A7E97A.2010503@gmail.com><006801c998fd$06c5bd60$14513820$@nl> <49A8272D.2060400@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407AD0C48@xmb-rtp-208.amer.cisco.com> From: "Dearlove, Christopher (UK)" To: "Stan Ratliff (sratliff)" , "Alexandru Petrescu" , "Teco Boot" X-OriginalArrivalTime: 02 Mar 2009 14:52:53.0919 (UTC) FILETIME=[90FB8AF0:01C99B46] Cc: autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 14:52:31 -0000 Stan Ratliff > And I'll have to disagree with the "25m subnets". I regularly deal with > line-of-sight radio links that are in excess of 25km. We can't limit > ourselves to short-range technologies (e.g. Commercial 802.11, > Bluetooth, Zigbee, etc). I don't believe a distance should be explicitly > stated in the charter, rather, some verbiage that talks about "radio > neighbors in range" should be sufficient. Agreed. There has to be a good reason to limit consideration of what bearers to use, and the default without such a good reason (which I am not aware of) is anything that works. Which means that actually it doesn't even have to be a radio bearer. If in an ad hoc network some links are wired, it may still be convenient to treat them as ad hoc links. (And that also is not just keeping options open for the sake of doing so.) ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From chris.dearlove@baesystems.com Mon Mar 2 07:15:24 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EC5A3A6A79 for ; Mon, 2 Mar 2009 07:15:24 -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 CcFhFtuD4fqd for ; Mon, 2 Mar 2009 07:15:23 -0800 (PST) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id 1B0033A695D for ; Mon, 2 Mar 2009 07:15:22 -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 n22FFkUu026997 for ; Mon, 2 Mar 2009 15:15:46 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 n22FFh2c032504 for ; Mon, 2 Mar 2009 15:15:43 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 02 Mar 2009 15:15:44 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 2 Mar 2009 15:15:44 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Mar 2009 15:15:43 -0000 Message-ID: In-Reply-To: <49A83172.70105@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] new charter Thread-Index: AcmZCaoK/eaj5vVnSKWwVWjxmH63FACP6sVw References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com><000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com><1235680887.4585.5.camel@localhost><49A7BB89.5040807@gmail.com><003901c998cb$42b71e90$c8255bb0$@nl><49A7E97A.2010503@gmail.com><006801c998fd$06c5bd60$14513820$@nl> <49A8272D.2060400@gmail.com><7FB7EE0A621BA44B8B69E5F0A09DC76407AD0C48@xmb-rtp-208.amer.cisco.com> <49A83172.70105@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" , "Stan Ratliff (sratliff)" X-OriginalArrivalTime: 02 Mar 2009 15:15:44.0357 (UTC) FILETIME=[C1D3C950:01C99B49] Cc: autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 15:15:24 -0000 Alexander Petrescu > But I would disagree with a Charter saying we deal with all wireless > links ranging from personal area to sattellite and everything in between > and the generic addressing model is the following... Why? I think the onus is on you to provide a good technical reason why this wouldn't work. (I stress technical, as motivationally, Stan Ratliff and others have the motivation, so there is a good reason to do it if we can.) ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From alexandru.petrescu@gmail.com Mon Mar 2 08:04:02 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ACF33A6452 for ; Mon, 2 Mar 2009 08:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.194 X-Spam-Level: X-Spam-Status: No, score=-2.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 WLFJ55drEOcg for ; Mon, 2 Mar 2009 08:04:00 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 9BCA13A694A for ; Mon, 2 Mar 2009 08:04:00 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n22G4Jps019345; Mon, 2 Mar 2009 17:04:19 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n22G4JG6031171; Mon, 2 Mar 2009 17:04:19 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n22G4Isj025332; Mon, 2 Mar 2009 17:04:18 +0100 Message-ID: <49AC0382.3060205@gmail.com> Date: Mon, 02 Mar 2009 17:04:18 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com><000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com><1235680887.4585.5.camel@localhost><49A7BB89.5040807@gmail.com><003901c998cb$42b71e90$c8255bb0$@nl><49A7E97A.2010503@gmail.com><006801c998fd$06c5bd60$14513820$@nl> <49A8272D.2060400@gmail.com><7FB7EE0A621BA44B8B69E5F0A09DC76407AD0C48@xmb-rtp-208.amer.cisco.com> <49A83172.70105@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 16:04:02 -0000 Dearlove, Christopher (UK) a écrit : > Alexander Petrescu >> But I would disagree with a Charter saying we deal with all >> wireless links ranging from personal area to sattellite and >> everything in between and the generic addressing model is the >> following... > > Why? > > I think the onus is on you to provide a good technical reason why > this wouldn't work. (I stress technical, as motivationally, Stan > Ratliff and others have the motivation, so there is a good reason to > do it if we can.) Not sure which argumentation is expected from me. In general, wireless links differ largely in the way they form their IPv6 link-local addresses, depending on whether they're ptp or shared. An IPv6 addressing scheme designed for WiFi wouldn't work for WMAN 802.16 for example. Also, some wireless links use some address autoconf mechanisms which aren't provided by others (e.g. IPv6-over-802154 has a fancy means to assign an IPv6 address with RR/RC (Router Reg/Router Conf'n)). Alex From joseph.macker@nrl.navy.mil Mon Mar 2 08:21:33 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10B2D3A6B23 for ; Mon, 2 Mar 2009 08:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.15 X-Spam-Level: X-Spam-Status: No, score=-5.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, 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 Otz8u81ptq1L for ; Mon, 2 Mar 2009 08:21:32 -0800 (PST) Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by core3.amsl.com (Postfix) with ESMTP id 20F793A690F for ; Mon, 2 Mar 2009 08:21:32 -0800 (PST) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id n22GL22c011651; Mon, 2 Mar 2009 11:21:02 -0500 Received: (from sextant [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2009030211210203795 ; Mon, 02 Mar 2009 11:21:02 -0500 From: "Joe Macker" To: "'Dearlove, Christopher \(UK\)'" , "'Stan Ratliff \(sratliff\)'" , "'Alexandru Petrescu'" , "'Teco Boot'" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com><000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com><1235680887.4585.5.camel@localhost><49A7BB89.5040807@gmail.com><003901c998cb$42b71e90$c8255bb0$@nl><49A7E97A.2010503@gmail.com><006801c998fd$06c5bd60$14513820$@nl> <49A8272D.2060400@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407AD0C48@xmb-rtp-208.amer.cisco.com> In-Reply-To: Date: Mon, 2 Mar 2009 11:20:59 -0500 Message-ID: <001001c99b52$dfb4a030$9f1de090$@macker@nrl.navy.mil> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmZA4D7GvOj98TgRN+fRurNRpYVsAAA95NwAI+ZrRAAAyKNcA== Content-Language: en-us Cc: autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 16:21:33 -0000 I would agree with these comments. - Range seems artificially limiting. Wireless neighbor should suffice. - Domain may extend into some wired links. -Joe > -----Original Message----- > From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On Behalf Of Dearlove, Christopher (UK) > Sent: Monday, March 02, 2009 9:53 AM > To: Stan Ratliff (sratliff); Alexandru Petrescu; Teco Boot > Cc: autoconf@ietf.org > Subject: Re: [Autoconf] new charter > > > Stan Ratliff > > And I'll have to disagree with the "25m subnets". I regularly deal > with > > line-of-sight radio links that are in excess of 25km. We can't limit > > ourselves to short-range technologies (e.g. Commercial 802.11, > > Bluetooth, Zigbee, etc). I don't believe a distance should be > explicitly > > stated in the charter, rather, some verbiage that talks about "radio > > neighbors in range" should be sufficient. > > Agreed. There has to be a good reason to limit consideration of > what bearers to use, and the default without such a good reason > (which I am not aware of) is anything that works. Which means > that actually it doesn't even have to be a radio bearer. If in > an ad hoc network some links are wired, it may still be convenient > to treat them as ad hoc links. (And that also is not just keeping > options open for the sake of doing so.) > > ******************************************************************** > 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 chris.dearlove@baesystems.com Mon Mar 2 08:39:37 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC7B13A6B13 for ; Mon, 2 Mar 2009 08:39: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=[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 kFnCzU9MyU4d for ; Mon, 2 Mar 2009 08:39:37 -0800 (PST) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id D72F33A6AE7 for ; Mon, 2 Mar 2009 08:39:36 -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 n22Ge05c010950 for ; Mon, 2 Mar 2009 16:40: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 n22Ge0Wn024001 for ; Mon, 2 Mar 2009 16:40:00 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 02 Mar 2009 16:39:59 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 2 Mar 2009 16:39:59 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Mar 2009 16:39:58 -0000 Message-ID: In-Reply-To: <49A8531A.3020404@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] new charter Thread-Index: AcmZHbjFXd815bFFSnG56hmYowQZVQCNsk4g References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost><49A7BB89.5040807@gmail.com> <003901c998cb$42b71e90$c8255bb0$@nl><49A7E97A.2010503@gmail.com> <006801c998fd$06c5bd60$14513820$@nl><49A8272D.2060400@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407AD0C48@xmb-rtp-208.amer.cisco.com> <49A83172.70105@gmail.com><7FB7EE0A621BA44B8B69E5F0A09DC76407AD0C70@xmb-rtp-208.amer.cisco.com><49A84285.5030103@nps.navy.mil> <49A8531A.3020404@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" , "Rex Buddenberg" X-OriginalArrivalTime: 02 Mar 2009 16:39:59.0388 (UTC) FILETIME=[86DC4DC0:01C99B55] Cc: autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 16:39:37 -0000 Alexander Petrescu > 802.11-specific because that's what many people actually mean. No one, with the apparent exception of yourself in some postings, intends the work in MANET and Autoconf to be limited to 802.11. Of course many ad hoc networks use 802.11 for reasons of cost, convenience, availability and so on, any general solution must be able to be used with 802.11, and 802.11 often provides good examples (but not all examples). But that's a long way from 802.11 specific, and should stay that way. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From sonia.gammar@ensi.rnu.tn Mon Mar 2 09:00:04 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B92C28C247 for ; Mon, 2 Mar 2009 09:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.67 X-Spam-Level: *** X-Spam-Status: No, score=3.67 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InS5d3dDblz8 for ; Mon, 2 Mar 2009 09:00:02 -0800 (PST) Received: from topnetmail3.outgw.tn (topnetmail3.outgw.tn [193.95.97.76]) by core3.amsl.com (Postfix) with ESMTP id 31A523A6879 for ; Mon, 2 Mar 2009 09:00:02 -0800 (PST) Received: from pop10.topnet.tn (smtp.topnet.tn [213.150.176.204]) by tounes-27.ati.tn (Postfix) with SMTP id 4B26725B01ED for ; Mon, 2 Mar 2009 18:00:27 +0100 (CET) Received: (qmail 28774 invoked by uid 89); 2 Mar 2009 17:00:27 -0000 Received: from unknown (HELO mail1.topnet.tn) (213.150.176.204) by pop10.topnet.tn with SMTP; 2 Mar 2009 17:00:27 -0000 Received: (qmail 20571 invoked by uid 89); 2 Mar 2009 17:00:27 -0000 Received: from unknown (HELO sonia) (41.226.35.69) by mail1 with ESMTP; 2 Mar 2009 17:00:27 -0000 From: "Sonia Mettali Gammar" To: Date: Mon, 2 Mar 2009 18:00:17 +0100 Message-ID: <002001c99b58$5d845230$188cf690$@gammar@ensi.rnu.tn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01C99B60.BF48BA30" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmbWFyC63hSpPIiT2qdhQbuXQhLVg== Content-Language: fr Subject: [Autoconf] unsubscribe X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 17:00:04 -0000 Il s'agit d'un message à parties multiples au format MIME. ------=_NextPart_000_0021_01C99B60.BF48BA30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Unsubscribe Autoconf@ietf.org ------=_NextPart_000_0021_01C99B60.BF48BA30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Unsubscribe Autoconf@ietf.org

------=_NextPart_000_0021_01C99B60.BF48BA30-- From chris.dearlove@baesystems.com Tue Mar 3 02:09:52 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 057B23A6C05 for ; Tue, 3 Mar 2009 02:09: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=[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 Myi3iLRhfV2I for ; Tue, 3 Mar 2009 02:09:51 -0800 (PST) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id 0E5DE3A6BFF for ; Tue, 3 Mar 2009 02:09:50 -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 n23AAFRl014977 for ; Tue, 3 Mar 2009 10:10:15 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 n23AAExO009901 for ; Tue, 3 Mar 2009 10:10:14 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 03 Mar 2009 10:10:04 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Tue, 3 Mar 2009 10:10:04 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Mar 2009 10:10:03 -0000 Message-ID: In-Reply-To: <49A84912.9060107@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] radio neighbors in range Thread-Index: AcmZF72YqRIg0ad9RXCflQaN1gyBzgC0AoPw References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com><000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com><1235680887.4585.5.camel@localhost><49A7BB89.5040807@gmail.com><003901c998cb$42b71e90$c8255bb0$@nl><49A7E97A.2010503@gmail.com><006801c998fd$06c5bd60$14513820$@nl> <49A8272D.2060400@gmail.com><7FB7EE0A621BA44B8B69E5F0A09DC76407AD0C48@xmb-rtp-208.amer.cisco.com><49A83172.70105@gmail.com> <49A832DF.4040805@gmail.com><007e01c99915$10eb9f90$32c2deb0$@nl> <49A84912.9060107@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" , "Teco Boot" X-OriginalArrivalTime: 03 Mar 2009 10:10:04.0676 (UTC) FILETIME=[38F04C40:01C99BE8] Cc: autoconf@ietf.org Subject: Re: [Autoconf] radio neighbors in range X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 10:09:52 -0000 Alexandru Petrescu > Teco Boot >> Any idea how to enforce such a restriction to the MANET users? > By writing user manuals with specific tags: 25m no more. Within that=20 > range terminals are exposed and range is transitive. Complete non-starter as a solution. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From alexandru.petrescu@gmail.com Tue Mar 3 07:32:12 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D0FD3A6938 for ; Tue, 3 Mar 2009 07:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.195 X-Spam-Level: X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=0.054, 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 ncBHYc+TniZT for ; Tue, 3 Mar 2009 07:32:11 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 8F0843A68C3 for ; Tue, 3 Mar 2009 07:32:11 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n23FWZEP000539; Tue, 3 Mar 2009 16:32:35 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n23FWT9d000753; Tue, 3 Mar 2009 16:32:30 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n23FWTe3009175; Tue, 3 Mar 2009 16:32:29 +0100 Message-ID: <49AD4D8D.7070403@gmail.com> Date: Tue, 03 Mar 2009 16:32:29 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: HyungJin Lim References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <1235828619.6096.24.camel@localhost> <49A94589.9050203@gmail.com> <7e8d02d40902281906k3fd36f03ud329c1db2738221e@mail.gmail.com> In-Reply-To: <7e8d02d40902281906k3fd36f03ud329c1db2738221e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Tue, 03 Mar 2009 15:32:12 -0000 Hello Hyung-Jin, HyungJin Lim a écrit : >> What are the simplest cases? > > > I think we can divided into two category in MANET scenario as > follows. > > Category 1 Scenario 1: "MANET to Internet", in case, depths of nested > routers(NEMO) is under three levels. This is practical case in real > world (i.e., most scenarios in real world) Scenario 2: "MANET to > Internet", depths of nested routers is more than three levels. (i.e., > perhaps disaster situation, etc.. ) > > Category 2 (scenario 3) : "Only MANET", in case, the network does not > has a connectivity to Internet. (i.e., peer-to-peer network, etc..) > > Requirement of address model we need is different according with > considered scenario I think. Then some scenarios included in category > 2 not needs topological meaningful address. > > Which area is AUTOCONF want to pinpoint ? > > I think AUTOCONF should satisfy requirements between pure MANET, NEMO > and MANEMO that can compose of mesh network, although we discussed > about the difference between MANET, NEMO and MANEMO > > Moreover, these networks can has some impacts due to mobility > pattern, wireless coverage and any other situations. AUTOCONF > Addressing model can make a important role to efficient and secure > aspects. > > What do you think about my comments ? I think I can understand the classification you made above: -only-MANET -MANET-to-Internet and -MANET-to-MANET-to-Internet (three or more levels) Alex > > Hyung-Jin, Lim > > > Alex > > _______________________________________________ Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > > From sratliff@cisco.com Tue Mar 3 07:35:42 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEEBD3A695C for ; Tue, 3 Mar 2009 07:35: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.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 2gXiqrCAcmaD for ; Tue, 3 Mar 2009 07:35:41 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 462103A680A for ; Tue, 3 Mar 2009 07:35:41 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,296,1233532800"; d="scan'208";a="260240983" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-6.cisco.com with ESMTP; 03 Mar 2009 15:36:08 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n23Fa7X1016213; Tue, 3 Mar 2009 10:36:07 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n23Fa7jc014751; Tue, 3 Mar 2009 15:36:07 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Mar 2009 10:36:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Mar 2009 10:36:07 -0500 Message-ID: <7FB7EE0A621BA44B8B69E5F0A09DC76407AD158A@xmb-rtp-208.amer.cisco.com> In-Reply-To: <49AD4D8D.7070403@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Autoconf addressing model Thread-Index: AcmcFVDHHDEEtVvZQ6usK4Tv+WtiBgAAE8kg References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <1235828619.6096.24.camel@localhost> <49A94589.9050203@gmail.com><7e8d02d40902281906k3fd36f03ud329c1db2738221e@mail.gmail.com> <49AD4D8D.7070403@gmail.com> From: "Stan Ratliff (sratliff)" To: "Alexandru Petrescu" , "HyungJin Lim" X-OriginalArrivalTime: 03 Mar 2009 15:36:07.0746 (UTC) FILETIME=[C56FE220:01C99C15] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2579; t=1236094567; x=1236958567; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20=22Stan=20Ratliff=20(sratliff)=22=20 |Subject:=20RE=3A=20[Autoconf]=20Autoconf=20addressing=20mo del |Sender:=20 |To:=20=22Alexandru=20Petrescu=22=20,=0A=20=20=20=20=20=20=20=20=22HyungJin=20Lim=22=20; bh=tGAGrZftBnxuQYrT508T8M1BABeWrRmeQ9G/njc2LSk=; b=GXxSeM9F1ievhUewpZtumBBnD8dj2f6lx262ZV85lBTHOVuJCX6Qg0MZWq HrtQbF1A97HGdKHHXRQF/toUcOt193kmN2JyheOmux7pphT/hj83JgN2uJp7 +S5olGmX0U; Authentication-Results: rtp-dkim-1; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Tue, 03 Mar 2009 15:35:42 -0000 =20 > -----Original Message----- > From: autoconf-bounces@ietf.org=20 > [mailto:autoconf-bounces@ietf.org] On Behalf Of Alexandru Petrescu > Sent: Tuesday, March 03, 2009 10:32 AM > To: HyungJin Lim > Cc: autoconf@ietf.org > Subject: Re: [Autoconf] Autoconf addressing model >=20 > Hello Hyung-Jin, >=20 > HyungJin Lim a =E9crit : > >> What are the simplest cases? > >=20 > >=20 > > I think we can divided into two category in MANET scenario=20 > as follows. > >=20 > > Category 1 Scenario 1: "MANET to Internet", in case, depths=20 > of nested > > routers(NEMO) is under three levels. This is practical=20 > case in real =20 > > world (i.e., most scenarios in real world) Scenario 2: "MANET to=20 > > Internet", depths of nested routers is more than three=20 > levels. (i.e., =20 > > perhaps disaster situation, etc.. ) > >=20 > > Category 2 (scenario 3) : "Only MANET", in case, the=20 > network does not =20 > > has a connectivity to Internet. (i.e., peer-to-peer network, etc..) > >=20 > > Requirement of address model we need is different according with=20 > > considered scenario I think. Then some scenarios included=20 > in category > > 2 not needs topological meaningful address. > >=20 > > Which area is AUTOCONF want to pinpoint ? > >=20 > > I think AUTOCONF should satisfy requirements between pure=20 > MANET, NEMO =20 > > and MANEMO that can compose of mesh network, although we discussed=20 > > about the difference between MANET, NEMO and MANEMO > >=20 > > Moreover, these networks can has some impacts due to=20 > mobility pattern,=20 > > wireless coverage and any other situations. AUTOCONF=20 > Addressing model=20 > > can make a important role to efficient and secure aspects. > >=20 > > What do you think about my comments ? >=20 > I think I can understand the classification you made above: > -only-MANET > -MANET-to-Internet and > -MANET-to-MANET-to-Internet (three or more levels) >=20 How about a fourth classification?=20 =20 MANET-to-Internet-to-MANET It is useful in some scenarios.=20 Regards, Stan > Alex >=20 > >=20 > > Hyung-Jin, Lim > >=20 > >=20 > > Alex > >=20 > > _______________________________________________ Autoconf=20 > mailing list =20 > > Autoconf@ietf.org =20 > > https://www.ietf.org/mailman/listinfo/autoconf > >=20 > >=20 >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf >=20 From alexandru.petrescu@gmail.com Tue Mar 3 07:49:00 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 061723A67BD for ; Tue, 3 Mar 2009 07:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=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 C-THVU86R8ZO for ; Tue, 3 Mar 2009 07:48:59 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id A7CBA3A6452 for ; Tue, 3 Mar 2009 07:48:58 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n23FnOGD006065; Tue, 3 Mar 2009 16:49:24 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n23FnOiF025871; Tue, 3 Mar 2009 16:49:24 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n23FnOBV002825; Tue, 3 Mar 2009 16:49:24 +0100 Message-ID: <49AD5184.6080300@gmail.com> Date: Tue, 03 Mar 2009 16:49:24 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Teco Boot References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl> <49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl> <49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl> In-Reply-To: <003001c99b2c$a3fcf4a0$ebf6dde0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Tue, 03 Mar 2009 15:49:00 -0000 Teco Boot a écrit : > Hi Alex, > > More on "loopback interface". > And more on non-blocking obstacles. > > > > |> Check for example ISP BCP, rfc5375 > | > |Checked. The fact that Cisco uses 'loopback interface' to be something > |completely different than the interface holding the loopback address > |doesn't mean I should too. I disagree with Cisco on this particular > |point. > > RFC5373 is not a "Cisco document". It is a IETF product, produced by v6ops. > V6ops produces informational or BCP RFCs only. > Many router vendors support loopback interfaces. > Do you disagree with the v6ops document, best practices of most (all?) ISPs > and most router vendors? rfc5373 is not a BCP. Besides, it is a Request for Comments, so my comment is that a loopback interface is not good for what we plan to do here. > ID.autoconf-manetarch-07 section 5.1 also suggests using the loopback > interface for binding a globally unique address. My comment to this suggestion is the following: the usage of host-based routes effectively limits the size of the domain where that is manageable; depending on the link-layer type, it could be less than 25meters large. That may exclude connecting to the wider Internet. > My suggestion is using the loopback interface for the /128 (or /32) > address(es), not the MANET Interface(s) as suggested in 5.2. I disagree using /128 host-based routes on the surronding neighbors provided we don't have good reason to do so. And provided /64 routes could work as well. > |> Assigning non-"loopback addresses" on the loopback interfaces is > |permitted. > | > |YEs, it is permitted, I agree. > | > |But why should one do it? > > I came up with a handful advantages already: > o Lower overhead. If each MANET interface would use a [MANET local] > and optionally a set of globally unique addresses, more addresses > are used and load on the MANET (and other) protocols is higher. I don't understand why you think load on protocols is higher if there are several global addresses assigned to a router having several interfaces. > o No address swap needed when session swaps from one interface to the > other. Protocols like MIP6, HIP and SHIM6 could repair the issue in > some cases, in other cases they cannot. How to reach a MIP6 HA in > a disconnected MANET?) If a Router has two interfaces, and two global addresses (one for each interface), and if host-based routes surround this router, then there's not a need for address swap either. Thus I don't understand why is there a need to have a single address for a Router having two interfaces. > o If a MANET interfaces goes up and down (e.g. single neighbor flapping), > the application may get affected. Using a virtual interface (typically > the loopback interface), application layer recovery is circumvented. If a Router has a single real interface then no amount of virtual interfaces can make it more reliable. If a Router has two real interfaces then any additional amount of virtual interfaces will not contribute anything to reliability. If a Router has a single Real interface, and the implementation of the particular routing protocol breaks when that interface is WiFi and its driver puts it down when disassociating, then yes, it's better to have that implementation of that routing protocol to run over a virtual interface, and maybe the loopback interface. But better upgrade to a better implementation of either the wifi driver or of the routing protocol. > |> Your assumption is single hop communication and no MANET routing > |> protocol. I > |> am interested in the more complex topologies. > | > |The pictures I drawn are multihop. And indeed I don't assume a MANET > |routing protocol. Neither does the charter. And that's ok. > > Sorry, I missed this. Do you mean that host - router is multi-hop? Who is > forwarding? The picture I posted initially had Host-Router-Host with two different subnets and Router with a routing table and forwarding process. > Let's use figure 1-2 below. Is there connectivity between B and C, via A? > |> +------------------------+ +------------------------+ > |> | | | | > |> | ____STA-B | | ____STA-B | > |> | ___/ | | | ___/ | > |> | STA-A | | | STA-A OBSTACLE | > |> | '--_ | | | '--_ | > |> | '----STA-C | | '----STA-C | > |> | OBSTACLE | | | > |> +------------------------+ +------------------------+ > |> 1-1: No hindrance 1-2: B-C blocked Yes, there is. If STA-A is WiFi then link layer ensures repeating the packets. If STA-A is WiMax then it will forward packets (router). > |> There is no "essid" in ad hoc mode. It is the "ssid" of the IBSS. Only > |> ESS > |> has essid. > |> Let's try to be accurate. > | > |iwconfig essid "adhoc1" mode ad-hoc > |is also accurate. > > Please use terms as standardized. > ESSID stands for the name of an extended service set (ESS). An ESS is a set > of basic service sets, connected over a distribution service. ESS is far > from IBSS (more or less the opposite). I can't help the Linux iwconfig > syntax uses essid for what should be the well defined 802.11 SSID. What's the Cisco equivalent for iwconfig? Alex From alexandru.petrescu@gmail.com Tue Mar 3 08:06:43 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2CB23A68BD for ; Tue, 3 Mar 2009 08:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.041 X-Spam-Level: X-Spam-Status: No, score=-1.041 tagged_above=-999 required=5 tests=[AWL=-1.092, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_LIST=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ur0J5jpykT5a for ; Tue, 3 Mar 2009 08:06:42 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id EDFB43A679C for ; Tue, 3 Mar 2009 08:06:41 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n23G5MWS021433 for ; Tue, 3 Mar 2009 17:05:22 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n23G77dT028268 for ; Tue, 3 Mar 2009 17:07:07 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n23G77Ca008983 for ; Tue, 3 Mar 2009 17:07:07 +0100 Message-ID: <49AD55AB.5040304@gmail.com> Date: Tue, 03 Mar 2009 17:07:07 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: autoconf@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Autoconf] Summary of topologies and addressing discussed recently X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 16:06:43 -0000 Dear AUTOCONFers, Recently there was discussion on the mailing list about topologies and addressing for AUTOCONF. Some topologies for AUTOCONF were named and classified as: -only-MANET -MANET-to-Internet and -MANET-to-MANET-to-Internet (three or more levels) -MANET-to-Internet-to-MANET Some topologies were pictured in more detail - they're listed below as a summary. Some participants seemed to agree on these topologies or on some of their variations. A simple topology: ----- wifi "adhoc1" ------ wifi "adhoc2" ----- |Host1|---------------|Router|---------------|Host2| ----- LL1 LL2 ------ LL3 LL4 ----- G1 G4 "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode. Each is an IPv6 subnet. LL1...4: IPv6 link-local addresses. Self-formed according to rfc2464. G1, G4: IPv6 global addresses, for example 2001:db8:1::1/64 and 2001:db8:2::4/64 Manually assigned, or pre-configured with SNMP or formed according to stateless autoconf rfc4862; the prefixes are advertised by Router in RAs. A simple topology with Routers: ------- wifi "adhoc1" ------- wifi "adhoc2" ------- |Router1|---------------|Router2|---------------|Router3| ------ LL1 LL2 -------LL3 LL4 ------- G1 G4 G1, G4: ? More details on the simple topology with Routers, /64 prefixes and /128 addresses: ----- wifi "adhoc1" ------ wifi "adhoc2" ----- |Host1|---------------|Router|---------------|Host2| ----- LL1 P1 LL2 ------ LL3 P2 LL4 ----- G1 G4 G1, G4: IPv6 global addresses, for example 2001:db8:1::1/128 and 2001:db8:2::4/128 Manually assigned, or pre-configured with SNMP or formed according to stateless autoconf rfc4862; the prefixes are advertised by Router in RAs. P1, P2: IPv6 global prefixes, for example 2001:db8:1::/64 and 2001:db8:2::/64 Manually assigned, or pre-configured with SNMP. Connecting it to Internet: ----- wifi "adhoc1" ------ wifi "adhoc2" -------- / |Host1|---------------|Router|---------------|Gatewway|---| Internet ----- LL1 LL2 ------ LL3 LL4 -------- \ G1 G4 "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode. Each is an IPv6 subnet. LL1...4: IPv6 link-local addresses. Self-formed according to rfc2464. G1, G4: ? Connecting it to Internet via a Satellite link: ------ wifi "adhoc1" ------ wifi "adhoc2" -------- Satelite / |NEMOMR|---------------|Router|---------------|Gatewway|--------Int'net ------ LL1 LL2 ------ LL3 LL4 -------- TCA1 \ G1 G4 LL1...4: IPv6 link-local addresses. Self-formed according to rfc2464. G1: address formed by NEMOMR either from RA sent by Router, or by DHCPv6 considering Router is a DHCPRelay and Gateway is a DHCPServer. G4: ? TCA: Topologically-Correct Address, for Gateway. It can be manually configured on Gateway, or DHCP, or stateless autoconf. In the multi-hop network below only /64 prefixes are present in Routers' routing tables, no /128 (host-based) routes: ----- wifi "adhoc1" ------ wifi "adhoc2" ------- "adhoc3"----- |Host1|---------------|Router|---------------|Router2|-------|Host2| ----- LL1 P1 LL2 ------ LL3 P2 LL4 -------LL5 P3 LL6--- G1 G4 P1, P2, P3: /64 prefixes, such as: 2001:db8:1::/64 2001:db8:2::/64 and 2001:db8:3::/64 Breaking the connectivity: ------- wifi "adhoc1" ----- ???? ----- "adhoc2" -------- |Router1|---------------|Host1|--/ /--|Host2|---------|Router2| ------- LL2 P1 LL1 --- ----LL6 P2 LL6------ G1 G4 Adding more interfaces of different types: Router1 and Router2 are out of range. So R1 <--> H2 and H1 <--> R2. Host1 MUST communicate to Host2, this is critical (live or dead). +-------+ wifi "adhoc1" +-------+ wifi "adhoc2" +-------+ |Router1|>-------------<|Router2|>-------------<|Router3| +---L---+ LL1 LL21 +---L---+ LL22 LL3 +---L---+ |M1 |M2 |M3 "adhoc1" and "adhoc2": 802.11 SSIDs in "IBSS" mode. Each IBSS is an IPv6 subnet. L: Loopback interface. >, <: MANET interface. LL1, LL21, LL22, LL3: IPv6 link-local addresses. Self-formed according to rfc2464. M1, M2, M3: IPv6 MANET local addresses, for example FD01:db8::1/128, FD01:db8::2/128 and FD01:db8::3/128. Manually assigned, or pre-configured (e.g. with SNMP) or formed according to a to be defined [Autoconf for MANETs] protocol, with a to-be-defined prefix (e.g. ULA, RFC4193). Again connecting to the Internet, this time via an Access Router: Internet | | +-------+-------+ | Access Router | +-------+-------+ | | | Prefix information | V | +-------+ wifi "adhoc1" +---+---+ wifi "adhoc2" +-------+ |Router1|>-------------<|Router2|>-------------<|Router3| +---L---+ LL1 LL21 +---L---+ LL22 LL3 +---L---+ |M1 |M2 |M3 |G1 |G2 |G3 <------- -------> Prefix information Prefix information G1, G2, G3: IPv6 globally unique addresses, for example 2001:db8:G:1/128, 2001:db8:G:2/128 and 2001:db8:G:3/128. Formed according to a to be defined [Autoconf for MANETs] protocol, with the prefix provided by (via) the Access Router. Adding Multi-homing: ---+-------Internet--------+--- | | | | +-------+-------+ +-------+-------+ |Access Router H| |Access Router G| +-------+-------+ +-------+-------+ | | ||Prefix information H | |Prefix information G |V | V | | +---+---+ wifi "adhoc1" +---+---+ wifi "adhoc2" +-------+ |Router1|>-------------<|Router2|>-------------<|Router3| +---L---+ LL1 LL21 +---L---+ LL22 LL3 +---L---+ |M1 |M2 |M3 |G1 |G2 |G3 |H1 |H2 |H3 <------- -------> Prefix information G Prefix information G, H ---------> Prefix information H H1, H2, H3: IPv6 globally unique addresses, for example 2001:db8:H:1/128, 2001:db8:H:2/128 and 2001:db8:H:3/128. Formed according to a to be defined [Autoconf for MANETs] protocol, with the prefix provided by (via) Access Router H. Effect of some links disappearing: ---+-------Internet------ | | +-------+-------+ |Access Router H| +-------+-------+ | ||Prefix information H |V wifi "adhoc1" | <---------------------------v--------> <------|--v----------------------> | |<-|--------------------v-----------------------|---> | | | | +---+--'+ +---'---+ +---'---+ |Router1|>-------------<|Router2|>-------------<|Router4| +---L---+ LL1 LL21 +---L---+ LL22 LL4 +---L---+ |M1 |M2 |M4 |H1 |H2 |H4 ---------> ---------> Prefix information H Prefix information H No computer movement, but obstacle mouvement: (802.11 term: STA is station) +------------------------+ +------------------------+ | | | | | ____STA-B | | ____STA-B | | ___/ | | | ___/ | | STA-A | | | STA-A OBSTACLE | | '--_ | | | '--_ | | '----STA-C | | '----STA-C | | OBSTACLE | | | +------------------------+ +------------------------+ 1-1: No hindrance 1-2: B-C blocked +------------------------+ +------------------------+ | | | O | | ____STA-B | | B STA-B | | ___/ | | | S | | | STA-A OB | | | STA-A T | | | ST | | | A | | | AC STA-C | | C STA-C | | LE | | LE | +------------------------+ +------------------------+ 1-3: A-C blocked 1-4: A-B & A-C blocked MANET Scenarios with blocking obstacle Compare with this one: (802.11 term: AP is access point) +------------------------+ +------------------------+ | | | | | ____STA-B | | ____STA-B | | ___/ | | ___/ | | AP-A | | AP-A OBSTACLE | | '--_ | | '--_ | | '----STA-C | | '----STA-C | | OBSTACLE | | | +------------------------+ +------------------------+ 4-1: No hindrance 4-2: No hindrance +------------------------+ +------------------------+ | | | O | | ____STA-B | | B STA-B | | ___/ | | S | | AP-A OB | | AP-A T | | ST | | A | | AC STA-C | | C STA-C | | LE | | LE | +------------------------+ +------------------------+ 4-3: A-C & B-C blocked 4-4: All blocked 802.11 BSS L2 topology with blocking obstacle |HAving them pictured, may I ask you: do you think anything will ever be |able to communicate through Obstacles? Yes, of course. +------------------------+ +------------------------+ | | | | | ____STA-B | | ____STA-B | | ___/ 1 | | | ___/ 1 . | | STA-A | 1 | | STA-A obstacle 5 | | '--_ 1 | | | '--_ 1 . | | '----STA-C | | '----STA-C | | obstacle | | | +------------------------+ +------------------------+ 2-1: No hindrance 2-2: B-C degraded +------------------------+ +------------------------+ | | | o | | ____STA-B | | 5 b ...STA-B | | ___/ 1 | | | ...s. | | | STA-A ob | 1 | | STA-A t | 1 | | ... st | | | ...a. | | | 5 .ac..STA-C | | 5 c ...STA-C | | le | | le | +------------------------+ +------------------------+ 2-3: A-C degraded 2-4: A-B & A-C degraded Scenarios with degrading obstacle I depicted the metrics: 1 is good, 5 is degraded. Here the routing tables, with metrics: ROUTER DEST NEXTHOP METRIC ROUTER DEST NEXTHOP METRIC +-------+-------+-------+------+ +-------+-------+-------+------+ | A | B | B | 1 | | A | B | B | 1 | | | C | C | 1 | | | C | C | 1 | +-------+-------+-------+------+ +-------+-------+-------+------+ | B | A | A | 1 | | B | A | A | 1 | | | C | C | 1 | | | C | C | 5 | +-------+-------+-------+------+ +-------+-------+-------+------+ | C | A | A | 1 | | C | A | A | 1 | | | B | B | 1 | | | B | B | 5 | +-------+-------+-------+------+ +-------+-------+-------+------+ 11-1: No hindrance 11-2: B-C is degraded +-------+-------+-------+------+ +-------+-------+-------+------+ | A | B | B | 1 | | A | B | B | 5 | | | C | C | 5 | | | C | C | 5 | +-------+-------+-------+------+ +-------+-------+-------+------+ | B | A | A | 1 | | B | A | A | 5 | | | C | C | 1 | | | C | C | 1 | +-------+-------+-------+------+ +-------+-------+-------+------+ | C | A | A | 5 | | C | A | A | 5 | | | B | B | 1 | | | B | B | 1 | +-------+-------+-------+------+ +-------+-------+-------+------+ 11-3: A-C degraded 11-4: A-B & A-C degraded Alex thanking the participants. From dream.hjlim@gmail.com Tue Mar 3 08:20:38 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 684FD28C1AC for ; Tue, 3 Mar 2009 08:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.373 X-Spam-Level: X-Spam-Status: No, score=-1.373 tagged_above=-999 required=5 tests=[AWL=-1.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_LIST=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfaJX86IQ-fC for ; Tue, 3 Mar 2009 08:20:36 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.191]) by core3.amsl.com (Postfix) with ESMTP id CBFFE3A6835 for ; Tue, 3 Mar 2009 08:20:35 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id 11so3097602tim.25 for ; Tue, 03 Mar 2009 08:21:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=7ZYP2hmOtOhYSVDQjac22T7F7ZRp0e3kKLXd8s+Zpk0=; b=Cj4qdzjPm7fa1ih0vuDBfFsV8/Qh15XgPnaAnljyXUxg/0EygleS91UVQL22c9dvNr qlUp0HF1zCFPg0X+DWI1bimHME6TiYiaOLkrj3hoCkUuXJESc1QlKkQJlqcWKLV5i28w FpkfzXj275/gQAiqoPvzUIxVQZItF7CLMr1Hg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RH2/zg3Z5ti/VKIuvpcs+i3Mg/NUSy4zIZhvIpAJZ0vW1wRTZSHbTkVEHP8EXpU9J4 f7SwDtCFEMZtFTsfB85zBwYzC7Ig3+9Tpq9HT0AIt45g/CSvOGMVuBE7gQj6AVRBIjj7 x0taxUQMP3vXrufNzaXtFxkydcwJnL0rwC4Yc= MIME-Version: 1.0 Received: by 10.110.95.11 with SMTP id s11mr10620902tib.24.1236097258216; Tue, 03 Mar 2009 08:20:58 -0800 (PST) In-Reply-To: <49AD55AB.5040304@gmail.com> References: <49AD55AB.5040304@gmail.com> Date: Wed, 4 Mar 2009 01:20:58 +0900 Message-ID: <7e8d02d40903030820o728288c4l11dc7db8f5d1c02b@mail.gmail.com> From: HyungJin Lim To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=0016e64e9300fbdc6c0464395163 Cc: Autoconf@ietf.org Subject: Re: [Autoconf] Summary of topologies and addressing discussed recently X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 16:20:38 -0000 --0016e64e9300fbdc6c0464395163 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Alex I think we should identify the impacts from address model we can choice. for example, whether packet forwarding or packet routing. The packet routing needs a satisfied route distributed time. While the packet forwarding needs additional processing time for tunneling. What do we should choice for proper address model? I don't think only simplest scenario is important. Thanks Hyung-Jin, Lim 2009/3/4 Alexandru Petrescu > Dear AUTOCONFers, > > Recently there was discussion on the mailing list about topologies and > addressing for AUTOCONF. Some topologies for AUTOCONF were named and > classified as: > -only-MANET > -MANET-to-Internet and > -MANET-to-MANET-to-Internet (three or more levels) > -MANET-to-Internet-to-MANET > > Some topologies were pictured in more detail - they're listed below as > a summary. Some participants seemed to agree on these topologies or > on some of their variations. > > A simple topology: > > ----- wifi "adhoc1" ------ wifi "adhoc2" ----- > |Host1|---------------|Router|---------------|Host2| > ----- LL1 LL2 ------ LL3 LL4 ----- > G1 G4 > > > "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode. > Each is an IPv6 subnet. > LL1...4: IPv6 link-local addresses. > Self-formed according to rfc2464. > G1, G4: IPv6 global addresses, for example > 2001:db8:1::1/64 and > 2001:db8:2::4/64 > Manually assigned, or pre-configured with SNMP > or formed according to stateless autoconf rfc4862; > the prefixes are advertised by Router in RAs. > > > A simple topology with Routers: > > ------- wifi "adhoc1" ------- wifi "adhoc2" ------- > |Router1|---------------|Router2|---------------|Router3| > ------ LL1 LL2 -------LL3 LL4 ------- > G1 G4 > > G1, G4: ? > > > More details on the simple topology with Routers, /64 prefixes and > /128 addresses: > > ----- wifi "adhoc1" ------ wifi "adhoc2" ----- > |Host1|---------------|Router|---------------|Host2| > ----- LL1 P1 LL2 ------ LL3 P2 LL4 ----- > G1 G4 > > G1, G4: IPv6 global addresses, for example > 2001:db8:1::1/128 and > 2001:db8:2::4/128 > Manually assigned, or pre-configured with SNMP > or formed according to stateless autoconf rfc4862; > the prefixes are advertised by Router in RAs. > P1, P2: IPv6 global prefixes, for example > 2001:db8:1::/64 and > 2001:db8:2::/64 > Manually assigned, or pre-configured with SNMP. > > Connecting it to Internet: > > ----- wifi "adhoc1" ------ wifi "adhoc2" -------- / > |Host1|---------------|Router|---------------|Gatewway|---| Internet > ----- LL1 LL2 ------ LL3 LL4 -------- \ > G1 G4 > > > "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode. > Each is an IPv6 subnet. > LL1...4: IPv6 link-local addresses. > Self-formed according to rfc2464. > G1, G4: ? > > > Connecting it to Internet via a Satellite link: > > ------ wifi "adhoc1" ------ wifi "adhoc2" -------- Satelite / > |NEMOMR|---------------|Router|---------------|Gatewway|--------Int'net > ------ LL1 LL2 ------ LL3 LL4 -------- TCA1 \ > G1 G4 > > LL1...4: IPv6 link-local addresses. > Self-formed according to rfc2464. > G1: address formed by NEMOMR either from RA sent by Router, or > by DHCPv6 considering Router is a DHCPRelay and Gateway is > a DHCPServer. > G4: ? > TCA: Topologically-Correct Address, for Gateway. It can be > manually configured on Gateway, or DHCP, or stateless > autoconf. > > > > In the multi-hop network below only /64 prefixes are present in > Routers' routing tables, no /128 (host-based) routes: > > > ----- wifi "adhoc1" ------ wifi "adhoc2" ------- "adhoc3"----- > |Host1|---------------|Router|---------------|Router2|-------|Host2| > ----- LL1 P1 LL2 ------ LL3 P2 LL4 -------LL5 P3 LL6--- > G1 G4 > > P1, P2, P3: /64 prefixes, such as: > 2001:db8:1::/64 > 2001:db8:2::/64 and > 2001:db8:3::/64 > > > Breaking the connectivity: > > ------- wifi "adhoc1" ----- ???? ----- "adhoc2" -------- > |Router1|---------------|Host1|--/ /--|Host2|---------|Router2| > ------- LL2 P1 LL1 --- ----LL6 P2 LL6------ > G1 G4 > > Adding more interfaces of different types: > > Router1 and Router2 are out of range. So R1 <--> H2 and H1 <--> R2. > Host1 MUST communicate to Host2, this is critical (live or dead). > > +-------+ wifi "adhoc1" +-------+ wifi "adhoc2" +-------+ > |Router1|>-------------<|Router2|>-------------<|Router3| > +---L---+ LL1 LL21 +---L---+ LL22 LL3 +---L---+ > |M1 |M2 |M3 > > "adhoc1" and "adhoc2": 802.11 SSIDs in "IBSS" mode. > Each IBSS is an IPv6 subnet. > > L: Loopback interface. > > >, <: MANET interface. > > LL1, LL21, LL22, LL3: IPv6 link-local addresses. > Self-formed according to rfc2464. > > M1, M2, M3: IPv6 MANET local addresses, for example > FD01:db8::1/128, FD01:db8::2/128 and FD01:db8::3/128. > Manually assigned, or pre-configured (e.g. with SNMP) > or formed according to a to be defined [Autoconf for MANETs] > protocol, with a to-be-defined prefix (e.g. ULA, RFC4193). > > > Again connecting to the Internet, this time via an Access Router: > > Internet > | > | > +-------+-------+ > | Access Router | > +-------+-------+ > | > | | Prefix information > | V > | > +-------+ wifi "adhoc1" +---+---+ wifi "adhoc2" +-------+ > |Router1|>-------------<|Router2|>-------------<|Router3| > +---L---+ LL1 LL21 +---L---+ LL22 LL3 +---L---+ > |M1 |M2 |M3 > |G1 |G2 |G3 > <------- -------> > Prefix information Prefix information > > > G1, G2, G3: IPv6 globally unique addresses, for example > 2001:db8:G:1/128, 2001:db8:G:2/128 and 2001:db8:G:3/128. > Formed according to a to be defined [Autoconf for MANETs] > protocol, with the prefix provided by (via) the Access Router. > > > Adding Multi-homing: > > ---+-------Internet--------+--- > | | > | | > +-------+-------+ +-------+-------+ > |Access Router H| |Access Router G| > +-------+-------+ +-------+-------+ > | | > ||Prefix information H | |Prefix information G > |V | V > | | > +---+---+ wifi "adhoc1" +---+---+ wifi "adhoc2" +-------+ > |Router1|>-------------<|Router2|>-------------<|Router3| > +---L---+ LL1 LL21 +---L---+ LL22 LL3 +---L---+ > |M1 |M2 |M3 > |G1 |G2 |G3 > |H1 |H2 |H3 > <------- -------> > Prefix information G Prefix information G, H > ---------> > Prefix information H > > H1, H2, H3: IPv6 globally unique addresses, for example > 2001:db8:H:1/128, 2001:db8:H:2/128 and 2001:db8:H:3/128. > Formed according to a to be defined [Autoconf for MANETs] > protocol, with the prefix provided by (via) Access Router H. > > > Effect of some links disappearing: > > > ---+-------Internet------ > | > | > +-------+-------+ > |Access Router H| > +-------+-------+ > | > ||Prefix information H > |V wifi "adhoc1" > | <---------------------------v--------> > <------|--v----------------------> | > |<-|--------------------v-----------------------|---> > | | | | > +---+--'+ +---'---+ +---'---+ > |Router1|>-------------<|Router2|>-------------<|Router4| > +---L---+ LL1 LL21 +---L---+ LL22 LL4 +---L---+ > |M1 |M2 |M4 > |H1 |H2 |H4 > > ---------> ---------> > Prefix information H Prefix information H > > > No computer movement, but obstacle mouvement: > > (802.11 term: STA is station) > > +------------------------+ +------------------------+ > | | | | > | ____STA-B | | ____STA-B | > | ___/ | | | ___/ | > | STA-A | | | STA-A OBSTACLE | > | '--_ | | | '--_ | > | '----STA-C | | '----STA-C | > | OBSTACLE | | | > +------------------------+ +------------------------+ > 1-1: No hindrance 1-2: B-C blocked > > +------------------------+ +------------------------+ > | | | O | > | ____STA-B | | B STA-B | > | ___/ | | | S | | > | STA-A OB | | | STA-A T | | > | ST | | | A | | > | AC STA-C | | C STA-C | > | LE | | LE | > +------------------------+ +------------------------+ > 1-3: A-C blocked 1-4: A-B & A-C blocked > > MANET Scenarios with blocking obstacle > > > Compare with this one: > > (802.11 term: AP is access point) > > +------------------------+ +------------------------+ > | | | | > | ____STA-B | | ____STA-B | > | ___/ | | ___/ | > | AP-A | | AP-A OBSTACLE | > | '--_ | | '--_ | > | '----STA-C | | '----STA-C | > | OBSTACLE | | | > +------------------------+ +------------------------+ > 4-1: No hindrance 4-2: No hindrance > > +------------------------+ +------------------------+ > | | | O | > | ____STA-B | | B STA-B | > | ___/ | | S | > | AP-A OB | | AP-A T | > | ST | | A | > | AC STA-C | | C STA-C | > | LE | | LE | > +------------------------+ +------------------------+ > 4-3: A-C & B-C blocked 4-4: All blocked > > 802.11 BSS L2 topology with blocking obstacle > > > |HAving them pictured, may I ask you: do you think anything will ever be > |able to communicate through Obstacles? > > > Yes, of course. > > > +------------------------+ +------------------------+ > | | | | > | ____STA-B | | ____STA-B | > | ___/ 1 | | | ___/ 1 . | > | STA-A | 1 | | STA-A obstacle 5 | > | '--_ 1 | | | '--_ 1 . | > | '----STA-C | | '----STA-C | > | obstacle | | | > +------------------------+ +------------------------+ > 2-1: No hindrance 2-2: B-C degraded > > +------------------------+ +------------------------+ > | | | o | > | ____STA-B | | 5 b ...STA-B | > | ___/ 1 | | | ...s. | | > | STA-A ob | 1 | | STA-A t | 1 | > | ... st | | | ...a. | | > | 5 .ac..STA-C | | 5 c ...STA-C | > | le | | le | > +------------------------+ +------------------------+ > 2-3: A-C degraded 2-4: A-B & A-C degraded > > Scenarios with degrading obstacle > > > I depicted the metrics: 1 is good, 5 is degraded. > > Here the routing tables, with metrics: > > ROUTER DEST NEXTHOP METRIC ROUTER DEST NEXTHOP METRIC > +-------+-------+-------+------+ +-------+-------+-------+------+ > | A | B | B | 1 | | A | B | B | 1 | > | | C | C | 1 | | | C | C | 1 | > +-------+-------+-------+------+ +-------+-------+-------+------+ > | B | A | A | 1 | | B | A | A | 1 | > | | C | C | 1 | | | C | C | 5 | > +-------+-------+-------+------+ +-------+-------+-------+------+ > | C | A | A | 1 | | C | A | A | 1 | > | | B | B | 1 | | | B | B | 5 | > +-------+-------+-------+------+ +-------+-------+-------+------+ > 11-1: No hindrance 11-2: B-C is degraded > > +-------+-------+-------+------+ +-------+-------+-------+------+ > | A | B | B | 1 | | A | B | B | 5 | > | | C | C | 5 | | | C | C | 5 | > +-------+-------+-------+------+ +-------+-------+-------+------+ > | B | A | A | 1 | | B | A | A | 5 | > | | C | C | 1 | | | C | C | 1 | > +-------+-------+-------+------+ +-------+-------+-------+------+ > | C | A | A | 5 | | C | A | A | 5 | > | | B | B | 1 | | | B | B | 1 | > +-------+-------+-------+------+ +-------+-------+-------+------+ > 11-3: A-C degraded 11-4: A-B & A-C degraded > > Alex thanking the participants. > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > --0016e64e9300fbdc6c0464395163 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Alex
=A0
I think we should identify the impacts from address model we can choic= e.
for example, whether packet forwarding or packet routing.
=A0
The packet routing needs a satisfied route distributed time.
While the packet forwarding needs additional processing time for tunne= ling.
=A0
What do we should choice for proper address model?
I don't think only simplest scenario is important.
=A0
Thanks
=A0
Hyung-Jin, Lim

2009/3/4 Alexandru Petrescu &l= t;alexandru.petrescu@gmail.= com>
Dear AUTOCONFers,

Recentl= y there was discussion on the mailing list about topologies and addressing = for AUTOCONF. =A0Some topologies for AUTOCONF were named and classified as:=
=A0 =A0 =A0-only-MANET
=A0 =A0 =A0-MANET-to-Internet and
=A0 =A0 =A0-= MANET-to-MANET-to-Internet (three or more levels)
=A0 =A0 =A0-MANET-to-I= nternet-to-MANET

Some topologies were pictured in more detail - they= 're listed below as
a summary. =A0Some participants seemed to agree on these topologies or
o= n some of their variations.

A simple topology:

=A0 =A0 =A0 = =A0----- =A0wifi "adhoc1" =A0------ =A0wifi "adhoc2" = =A0-----
=A0 =A0 =A0 |Host1|---------------|Router|---------------|Host2= |
=A0 =A0 =A0 =A0----- LL1 =A0 =A0 =A0 =A0 LL2 ------ LL3 =A0 =A0 =A0 =A0LL4 = =A0-----
=A0 =A0 =A0 =A0 =A0 =A0 =A0G1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0G4


=A0 =A0 =A0 "adhoc1"= and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode.
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Each is an IPv6 subn= et.
=A0 =A0 =A0 LL1...4: IPv6 link-local addresses.
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0Self-formed according to rfc2464.
=A0 =A0 =A0 G1, G4: =A0IPv6 glo= bal addresses, for example
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02001:db8:1::1/= 64 and
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02001:db8:2::4/64
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Manually assigned, or pre-configured with SN= MP
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0or formed according to stateless autoc= onf rfc4862;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the prefixes are advertised = by Router in RAs.


A simple topology with Routers:

=A0 =A0 =A0 ------- =A0wifi "adhoc1" =A0------- =A0wifi "= ;adhoc2" =A0-------
=A0 =A0 =A0|Router1|---------------|Router2|---= ------------|Router3|
=A0 =A0 =A0 ------ LL1 =A0 =A0 =A0 =A0 =A0LL2 ----= ---LL3 =A0 =A0 =A0 =A0 =A0LL4 -------
=A0 =A0 =A0 =A0 =A0 =A0 =A0G1 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0G4

=A0 =A0 =A0G1, G4: ?


More details on the simple topology wit= h Routers, /64 prefixes and
/128 addresses:

=A0 =A0 =A0 =A0----- = =A0wifi "adhoc1" =A0------ =A0wifi "adhoc2" =A0-----=A0 =A0 =A0 |Host1|---------------|Router|---------------|Host2|
=A0 =A0 =A0 =A0----- LL1 =A0 =A0P1 =A0 LL2 ------ LL3 =A0 P2 =A0 LL4 =A0---= --
=A0 =A0 =A0 =A0 =A0 =A0 =A0G1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0G4

=A0 =A0 =A0 G1, G4: =A0IPv6 global addres= ses, for example
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02001:db8:1::1/128 and=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02001:db8:2::4/128
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Manually assigned, or pre-configured with SN= MP
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0or formed according to stateless autoc= onf rfc4862;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the prefixes are advertised = by Router in RAs.
=A0 =A0 =A0 P1, P2: =A0IPv6 global prefixes, for examp= le
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02001:db8:1::/64 and
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A02001:db8:2::/64
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Manually assig= ned, or pre-configured with SNMP.

Connecting it to Internet:

= =A0 ----- =A0wifi "adhoc1" =A0------ =A0wifi "adhoc2" = =A0-------- =A0 =A0 /
=A0|Host1|---------------|Router|---------------|Gatewway|---| Internet
= =A0 ----- LL1 =A0 =A0 =A0 =A0 LL2 ------ LL3 =A0 =A0 =A0 =A0LL4 =A0--------= =A0 =A0 \
=A0 =A0 =A0 =A0 G1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0G4


=A0 =A0 =A0 "adhoc1" and &qu= ot;adhoc2": 802.11 ESSIDs in "ad-hoc" mode.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Each is an IPv6 = subnet.
=A0 =A0 =A0 LL1...4: IPv6 link-local addresses.
=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0Self-formed according to rfc2464.
=A0 =A0 =A0 G1, G4:= ?


Connecting it to Internet via a Satellite link:

=A0------ =A0wifi "adhoc1" =A0------ =A0wifi "adhoc2&quo= t; =A0-------- Satelite /
|NEMOMR|---------------|Router|---------------= |Gatewway|--------Int'net
=A0------ LL1 =A0 =A0 =A0 =A0 LL2 ------ L= L3 =A0 =A0 =A0 =A0LL4 =A0-------- =A0TCA1 =A0 =A0\
=A0 =A0 =A0 =A0G1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 G4

=A0 =A0 =A0 LL1...4: IPv6 link-local addresses.
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0Self-formed according to rfc2464.
=A0 =A0 =A0= G1: address formed by NEMOMR either from RA sent by Router, or
=A0 =A0 =A0 =A0 =A0 by DHCPv6 considering Router is a DHCPRelay and Gateway= is
=A0 =A0 =A0 =A0 =A0 a DHCPServer.
=A0 =A0 =A0 G4: ?
=A0 =A0 = =A0 TCA: Topologically-Correct Address, for Gateway. =A0It can be
=A0 = =A0 =A0 =A0 =A0 =A0manually configured on Gateway, or DHCP, or stateless =A0 =A0 =A0 =A0 =A0 =A0autoconf.



In the multi-hop network be= low only /64 prefixes are present in
Routers' routing tables, no /12= 8 (host-based) routes:


=A0----- =A0wifi "adhoc1" =A0--= ---- =A0wifi "adhoc2" =A0------- "adhoc3"-----
=A0|Host1|---------------|Router|---------------|Router2|-------|Host2|
= =A0----- LL1 =A0 =A0P1 =A0 LL2 ------ LL3 =A0 P2 =A0 LL4 =A0-------LL5 P3 = =A0LL6---
=A0 =A0 =A0 =A0G1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0G4

=A0 = =A0 =A0 =A0 =A0P1, P2, P3: /64 prefixes, such as:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02001:db8:1::/64
=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02001:db8:2::/64 and
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A02001:db8:3::/64


Breaking the connectivity= :

=A0------- =A0wifi "adhoc1" =A0----- =A0 ???? =A0 ----- = =A0"adhoc2" --------
=A0|Router1|---------------|Host1|--/ =A0/--|Host2|---------|Router2|
= =A0------- LL2 =A0 =A0P1 =A0 =A0 LL1 --- =A0 =A0 =A0 =A0 =A0----LL6 =A0 P2 = =A0LL6------
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0G1 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 G4

Adding more interfaces of different t= ypes:

Router1 and Router2 are out of range. So R1 <--> H2 and H1 <--= > R2.
Host1 MUST communicate to Host2, this is critical (live or dead= ).

=A0 =A0+-------+ wifi "adhoc1" +-------+ wifi "adh= oc2" +-------+
=A0 =A0|Router1|>-------------<|Router2|>-------------<|Router3= |
=A0 =A0+---L---+ LL1 =A0 =A0 =A0LL21 +---L---+ LL22 =A0 =A0 =A0LL3 +--= -L---+
=A0 =A0 =A0 =A0|M1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |M2 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |M3

=A0 =A0"adhoc1"= ; and "adhoc2": 802.11 SSIDs in "IBSS" mode.
=A0 =A0Each IBSS is an IPv6 subnet.

=A0 =A0L: Loopback interface.
=A0 =A0>, <: MANET interface.

=A0 =A0LL1, LL21, LL22, LL3= : IPv6 link-local addresses.
=A0 =A0 =A0 Self-formed according to rfc246= 4.

=A0 =A0M1, M2, M3: IPv6 MANET local addresses, for example
=A0 =A0 =A0 FD01:db8::1/128, FD01:db8::2/128 and FD01:db8::3/128.
=A0 = =A0 =A0 Manually assigned, or pre-configured (e.g. with SNMP)
=A0 =A0 = =A0 or formed according to a to be defined [Autoconf for MANETs]
=A0 =A0= =A0 protocol, with a to-be-defined prefix (e.g. ULA, RFC4193).


Again connecting to the Internet, this time via an Access Router:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Internet
= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+-------+-------+
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Access Router |
=A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+-------+-------+
=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| | Prefix information
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| V
=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0+-------+ wifi "adhoc1" +---+---+ wifi "adhoc2" = +-------+
=A0 =A0|Router1|>-------------<|Router2|>------------= -<|Router3|
=A0 =A0+---L---+ LL1 =A0 =A0 =A0LL21 +---L---+ LL22 =A0 = =A0 =A0LL3 +---L---+
=A0 =A0 =A0 =A0|M1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |M2 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 |M3
=A0 =A0 =A0 =A0|G1 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 |G2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |G3
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <------- =A0 =A0 =A0 =A0 =A0 ------->=
=A0 =A0 =A0 =A0 Prefix information =A0 =A0 =A0 =A0 =A0 Prefix informati= on


=A0 =A0G1, G2, G3: IPv6 globally unique addresses, for example
= =A0 =A0 =A0 2001:db8:G:1/128, 2001:db8:G:2/128 and 2001:db8:G:3/128.
=A0= =A0 =A0 Formed according to a to be defined [Autoconf for MANETs]
=A0 = =A0 =A0 protocol, with the prefix provided by (via) the Access Router.


Adding Multi-homing:

=A0 =A0 ---+-------Internet--------+---=
=A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 = =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
+-------+----= ---+ =A0 =A0 =A0 +-------+-------+
|Access Router H| =A0 =A0 =A0 |Access= Router G|
+-------+-------+ =A0 =A0 =A0 +-------+-------+
=A0 =A0 =A0 =A0| =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0||Prefix informati= on H =A0| |Prefix information G
=A0 =A0 =A0 =A0|V =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0| V
=A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 |
=A0 =A0+---+---+ wifi "adhoc1" +---+---+ wif= i "adhoc2" +-------+
=A0 =A0|Router1|>-------------<|Router2|>-------------<|Router3= |
=A0 =A0+---L---+ LL1 =A0 =A0 =A0LL21 +---L---+ LL22 =A0 =A0 =A0LL3 +--= -L---+
=A0 =A0 =A0 =A0|M1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |M2 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |M3
=A0 =A0 =A0 =A0|G1 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |G2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= |G3
=A0 =A0 =A0 =A0|H1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |H2 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 |H3
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <= ------- =A0 =A0 =A0 =A0 =A0 ------->
=A0 =A0 =A0 Prefix information G= =A0 =A0 =A0 =A0 Prefix information G, H
=A0 =A0 =A0 =A0 =A0 =A0 =A0----= ----->
=A0 =A0 =A0 =A0 =A0 =A0 =A0Prefix information H

=A0 =A0H1, H2, H3: IPv6 globally unique addresses, for example
=A0 = =A0 =A0 2001:db8:H:1/128, 2001:db8:H:2/128 and 2001:db8:H:3/128.
=A0 =A0= =A0 Formed according to a to be defined [Autoconf for MANETs]
=A0 =A0 = =A0 protocol, with the prefix provided by (via) Access Router H.


Effect of some links disappearing:


=A0 =A0 ---+-------In= ternet------
=A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0|
+-------+-------+|Access Router H|
+-------+-------+
=A0 =A0 =A0 =A0|
=A0 =A0 =A0= =A0||Prefix information H
=A0 =A0 =A0 =A0|V =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 wifi "adhoc1"
=A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <------------------= ---------v-------->
=A0<------|--v----------------------> =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0|<-|------------= --------v-----------------------|--->
=A0 =A0 =A0 =A0| =A0| =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 |
=A0 =A0+---+--'+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 +---'---+ =A0 =A0 =A0 = =A0 =A0 =A0 =A0 +---'---+
=A0 =A0|Router1|>-------------<|Rout= er2|>-------------<|Router4|
=A0 =A0+---L---+ LL1 =A0 =A0 =A0LL21 = +---L---+ LL22 =A0 =A0 =A0LL4 +---L---+
=A0 =A0 =A0 =A0|M1 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 |M2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |M4=
=A0 =A0 =A0 =A0|H1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |H2 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 |H4

=A0 =A0 =A0 =A0 =A0 =A0 =A0---------= > =A0 =A0 =A0 =A0 =A0 =A0 =A0 --------->
=A0 =A0 =A0 =A0 =A0 =A0 = =A0Prefix information H =A0 =A0 Prefix information H


No computer= movement, but obstacle mouvement:

(802.11 term: STA is station)

=A0 =A0 =A0 =A0 =A0+--------------= ----------+ =A0 +------------------------+
=A0 =A0 =A0 =A0 =A0| =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 ____STA-B = =A0 =A0| =A0 | =A0 =A0 =A0 =A0 =A0 ____STA-B =A0 =A0|
=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 ___/ =A0 =A0 =A0| =A0 =A0 =A0| =A0 | =A0 = =A0 =A0 ___/ =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0| =A0STA-A =A0= =A0 =A0 =A0 =A0| =A0 =A0 =A0| =A0 | =A0STA-A =A0 =A0 =A0OBSTACLE =A0 |
= =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0'--_ =A0 =A0 =A0 | =A0 =A0 =A0| =A0 | = =A0 =A0 =A0'--_ =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0 =A0 =A0'----STA-C =A0 =A0| =A0 | =A0 =A0 =A0 =A0 =A0'--= --STA-C =A0 =A0|
=A0 =A0 =A0 =A0 =A0| =A0OBSTACLE =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 | =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0+----------= --------------+ =A0 +------------------------+
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 1-1: No hindrance =A0 =A0 =A0 =A0 =A0 =A01-2: B-C blocked

=A0 = =A0 =A0 =A0 =A0+------------------------+ =A0 +------------------------+ =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 |= =A0 =A0 =A0 =A0 =A0O =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0| =A0= =A0 =A0 =A0 =A0 ____STA-B =A0 =A0| =A0 | =A0 =A0 =A0 =A0 =A0B =A0 =A0STA-B= =A0 =A0|
=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 ___/ =A0 =A0 =A0| =A0 =A0 =A0= | =A0 | =A0 =A0 =A0 =A0 =A0S =A0 =A0 =A0| =A0 =A0 =A0|
=A0 =A0 =A0 =A0 = =A0| =A0STA-A =A0 =A0 =A0OB =A0| =A0 =A0 =A0| =A0 | =A0STA-A =A0 T =A0 =A0 = =A0| =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0ST =A0 | =A0 =A0 =A0| =A0 | =A0= =A0 =A0 =A0 =A0A =A0 =A0 =A0| =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0| =A0 =A0= =A0 =A0 =A0 AC =A0STA-C =A0 =A0| =A0 | =A0 =A0 =A0 =A0 =A0C =A0 =A0STA-C = =A0 =A0|
=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 LE =A0 =A0 =A0 =A0 =A0 =A0= | =A0 | =A0 =A0 =A0 =A0 =A0LE =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 = =A0+------------------------+ =A0 +------------------------+
=A0 =A0 =A0 =A0 =A0 =A0 =A0 1-3: A-C blocked =A0 =A0 =A0 =A0 1-4: A-B &= A-C blocked

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0MANET Scenarios with blo= cking obstacle


Compare with this one:

(802.11 term: AP is= access point)

=A0 =A0 =A0 =A0 =A0+------------------------+ =A0 +--= ----------------------+
=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 |= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0 =A0 =A0 ____STA-B =A0 =A0| =A0 | =A0 =A0 =A0 =A0 =A0 ____STA-B = =A0 =A0|
=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 ___/ =A0 =A0 =A0 =A0 =A0 =A0 |= =A0 | =A0 =A0 =A0 ___/ =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0| = =A0 AP-A =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 | =A0 AP-A =A0 =A0 =A0OBSTAC= LE =A0 |
=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0'--_ =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 |= =A0 =A0 =A0'--_ =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0 =A0 =A0'----STA-C =A0 =A0| =A0 | =A0 =A0 =A0 =A0 =A0'--= --STA-C =A0 =A0|
=A0 =A0 =A0 =A0 =A0| =A0OBSTACLE =A0 =A0 =A0 =A0 =A0 = =A0 =A0| =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 = =A0 =A0 =A0+------------------------+ =A0 +------------------------+
=A0 =A0 =A0 =A0 =A0 =A0 =A0 4-1: No hindrance =A0 =A0 =A0 =A0 =A0 =A04-2: N= o hindrance

=A0 =A0 =A0 =A0 =A0+------------------------+ =A0 +-----= -------------------+
=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0| =A0 | =A0 =A0 =A0 =A0 =A0O =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 ____STA-B =A0 =A0| =A0 | =A0 =A0= =A0 =A0 =A0B =A0 =A0STA-B =A0 =A0|
=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 ___/ =A0 =A0 =A0 =A0 =A0 =A0 | =A0 | =A0 = =A0 =A0 =A0 =A0S =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0| =A0 AP-A= =A0 =A0 =A0OB =A0 =A0 =A0 =A0 | =A0 | =A0 AP-A =A0 T =A0 =A0 =A0 =A0 =A0 = =A0 |
=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0ST =A0 =A0 =A0 =A0 =A0= | =A0 | =A0 =A0 =A0 =A0 =A0A =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 = =A0| =A0 =A0 =A0 =A0 =A0 AC =A0STA-C =A0 =A0| =A0 | =A0 =A0 =A0 =A0 =A0C = =A0 =A0STA-C =A0 =A0|
=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 LE =A0 =A0 =A0 =A0 =A0 =A0 | =A0 | =A0= =A0 =A0 =A0 =A0LE =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0+--------= ----------------+ =A0 +------------------------+
=A0 =A0 =A0 =A0 =A0 4-3= : A-C & B-C blocked =A0 =A0 =A0 =A0 4-4: All blocked

=A0 =A0 =A0= =A0 =A0 =A0 802.11 BSS L2 topology with blocking obstacle


|HAving them pictured, may I ask you: do you think anything will ev= er be
|able to communicate through Obstacles?


Yes, of course.=


=A0 =A0 =A0 =A0 =A0+------------------------+ =A0 +------------= ------------+
=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 |= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0 =A0 =A0 ____STA-B =A0 =A0| =A0 | =A0 =A0 =A0 =A0 =A0 ____STA-B = =A0 =A0|
=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 ___/ 1 =A0 =A0| =A0 =A0 =A0| = =A0 | =A0 =A0 =A0 ___/ 1 =A0 =A0. =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0| =A0S= TA-A =A0 =A0 =A0 =A0 =A0| 1 =A0 =A0| =A0 | =A0STA-A =A0 =A0obstacle 5 =A0 |=
=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0'--_ 1 =A0 =A0 | =A0 =A0 =A0| =A0 | =A0= =A0 =A0'--_ 1 =A0 =A0 . =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0| =A0 =A0 = =A0 =A0 =A0'----STA-C =A0 =A0| =A0 | =A0 =A0 =A0 =A0 =A0'----STA-C = =A0 =A0|
=A0 =A0 =A0 =A0 =A0| =A0obstacle =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 = =A0+------------------------+ =A0 +------------------------+
=A0 =A0 =A0 =A0 =A0 =A0 =A0 2-1: No hindrance =A0 =A0 =A0 =A0 =A0 =A02-2: B= -C degraded

=A0 =A0 =A0 =A0 =A0+------------------------+ =A0 +-----= -------------------+
=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0| =A0 | =A0 =A0 =A0 =A0 =A0o =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 ____STA-B =A0 =A0| =A0 | =A0 =A0= =A0 5 =A0b ...STA-B =A0 =A0|
=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 ___/ 1 =A0 =A0| =A0 =A0 =A0| =A0 | =A0 =A0= =A0 ...s. =A0 =A0 | =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0| =A0STA-A =A0 =A0 = =A0ob =A0| 1 =A0 =A0| =A0 | =A0STA-A =A0t =A0 =A0 =A0 | 1 =A0 =A0|
=A0 = =A0 =A0 =A0 =A0| =A0 =A0 =A0 ... =A0st =A0 | =A0 =A0 =A0| =A0 | =A0 =A0 =A0= ...a. =A0 =A0 | =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 5 =A0.ac.= .STA-C =A0 =A0| =A0 | =A0 =A0 =A0 5 =A0c ...STA-C =A0 =A0|
=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 le =A0 =A0 =A0 =A0 =A0 =A0 | =A0 | =A0= =A0 =A0 =A0 =A0le =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0+--------= ----------------+ =A0 +------------------------+
=A0 =A0 =A0 =A0 =A0 =A0= =A0 2-3: A-C degraded =A0 =A0 =A0 =A02-4: A-B & A-C degraded

= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Scenarios with degrading obstacle


I depicted the metrics: 1 is good, 5 is degraded.

Here the r= outing tables, with metrics:

=A0 =A0 =A0ROUTER =A0 DEST =A0 NEXTHOP = METRIC =A0 =A0ROUTER =A0 DEST =A0 NEXTHOP METRIC
=A0 =A0 +-------+------= -+-------+------+ =A0+-------+-------+-------+------+
=A0 =A0 | =A0 A =A0 | =A0 B =A0 | =A0 B =A0 | =A0 =A01 | =A0| =A0 A =A0 | = =A0 B =A0 | =A0 B =A0 | =A0 =A01 |
=A0 =A0 | =A0 =A0 =A0 | =A0 C =A0 | = =A0 C =A0 | =A0 =A01 | =A0| =A0 =A0 =A0 | =A0 C =A0 | =A0 C =A0 | =A0 =A01 = |
=A0 =A0 +-------+-------+-------+------+ =A0+-------+-------+-------+-= -----+
=A0 =A0 | =A0 B =A0 | =A0 A =A0 | =A0 A =A0 | =A0 =A01 | =A0| =A0 B =A0 | = =A0 A =A0 | =A0 A =A0 | =A0 =A01 |
=A0 =A0 | =A0 =A0 =A0 | =A0 C =A0 | = =A0 C =A0 | =A0 =A01 | =A0| =A0 =A0 =A0 | =A0 C =A0 | =A0 C =A0 | =A0 =A05 = |
=A0 =A0 +-------+-------+-------+------+ =A0+-------+-------+-------+-= -----+
=A0 =A0 | =A0 C =A0 | =A0 A =A0 | =A0 A =A0 | =A0 =A01 | =A0| =A0 C =A0 | = =A0 A =A0 | =A0 A =A0 | =A0 =A01 |
=A0 =A0 | =A0 =A0 =A0 | =A0 B =A0 | = =A0 B =A0 | =A0 =A01 | =A0| =A0 =A0 =A0 | =A0 B =A0 | =A0 B =A0 | =A0 =A05 = |
=A0 =A0 +-------+-------+-------+------+ =A0+-------+-------+-------+-= -----+
=A0 =A0 =A0 =A0 =A011-1: No hindrance =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A011-2: = B-C is degraded

=A0 =A0 +-------+-------+-------+------+ =A0+-------= +-------+-------+------+
=A0 =A0 | =A0 A =A0 | =A0 B =A0 | =A0 B =A0 | = =A0 =A01 | =A0| =A0 A =A0 | =A0 B =A0 | =A0 B =A0 | =A0 =A05 |
=A0 =A0 |= =A0 =A0 =A0 | =A0 C =A0 | =A0 C =A0 | =A0 =A05 | =A0| =A0 =A0 =A0 | =A0 C = =A0 | =A0 C =A0 | =A0 =A05 |
=A0 =A0 +-------+-------+-------+------+ =A0+-------+-------+-------+------= +
=A0 =A0 | =A0 B =A0 | =A0 A =A0 | =A0 A =A0 | =A0 =A01 | =A0| =A0 B = =A0 | =A0 A =A0 | =A0 A =A0 | =A0 =A05 |
=A0 =A0 | =A0 =A0 =A0 | =A0 C = =A0 | =A0 C =A0 | =A0 =A01 | =A0| =A0 =A0 =A0 | =A0 C =A0 | =A0 C =A0 | =A0= =A01 |
=A0 =A0 +-------+-------+-------+------+ =A0+-------+-------+-------+------= +
=A0 =A0 | =A0 C =A0 | =A0 A =A0 | =A0 A =A0 | =A0 =A05 | =A0| =A0 C = =A0 | =A0 A =A0 | =A0 A =A0 | =A0 =A05 |
=A0 =A0 | =A0 =A0 =A0 | =A0 B = =A0 | =A0 B =A0 | =A0 =A01 | =A0| =A0 =A0 =A0 | =A0 B =A0 | =A0 B =A0 | =A0= =A01 |
=A0 =A0 +-------+-------+-------+------+ =A0+-------+-------+-------+------= +
=A0 =A0 =A0 =A0 =A0 11-3: A-C degraded =A0 =A0 =A0 =A0 =A0 =A0 =A0 11-= 4: A-B & A-C degraded

Alex thanking the participants.

___= ____________________________________________
Autoconf mailing list
Autoconf@ietf.org
https://www.ietf.org/mailman/listinfo/autoc= onf

--0016e64e9300fbdc6c0464395163-- From alexandru.petrescu@gmail.com Tue Mar 3 08:59:15 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB1E83A6917 for ; Tue, 3 Mar 2009 08:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.03 X-Spam-Level: X-Spam-Status: No, score=-1.03 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_LIST=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9hIs8ViSxJV for ; Tue, 3 Mar 2009 08:59:14 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 0AB623A684F for ; Tue, 3 Mar 2009 08:59:12 -0800 (PST) Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id 28E4794019C; Tue, 3 Mar 2009 17:59:35 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 725A39401DD; Tue, 3 Mar 2009 17:59:32 +0100 (CET) Message-ID: <49AD61F1.7010109@gmail.com> Date: Tue, 03 Mar 2009 17:59:29 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: HyungJin Lim References: <49AD55AB.5040304@gmail.com> <7e8d02d40903030820o728288c4l11dc7db8f5d1c02b@mail.gmail.com> In-Reply-To: <7e8d02d40903030820o728288c4l11dc7db8f5d1c02b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090303-0, 03/03/2009), Outbound message X-Antivirus-Status: Clean Cc: Autoconf@ietf.org Subject: Re: [Autoconf] Summary of topologies and addressing discussed recently X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 16:59:16 -0000 Hi Hyung-Jin, HyungJin Lim a écrit : > Hi, Alex > > I think we should identify the impacts from address model we can choice. > for example, whether packet forwarding or packet routing. > > The packet routing needs a satisfied route distributed time. > While the packet forwarding needs additional processing time for tunneling. I think packet forwarding and packet routing is the same (I've heard of 'map&encap' to mean something where a router presented with a packet to forward it searches its routing table (map) and then finds the next hop to be a tunnel interface, so it encapsulates the original packet). > What do we should choice for proper address model? I think the best address architecture one could come up with is the one that could be drawn on paper and circulated on the mailing list and agreed on by several people. > I don't think only simplest scenario is important. Let's first agree on the simplest scenario. What's the simplest scenario for you? Alex > > Thanks > > Hyung-Jin, Lim > > 2009/3/4 Alexandru Petrescu > > > Dear AUTOCONFers, > > Recently there was discussion on the mailing list about topologies > and addressing for AUTOCONF. Some topologies for AUTOCONF were > named and classified as: > -only-MANET > -MANET-to-Internet and > -MANET-to-MANET-to-Internet (three or more levels) > -MANET-to-Internet-to-MANET > > Some topologies were pictured in more detail - they're listed below as > a summary. Some participants seemed to agree on these topologies or > on some of their variations. > > A simple topology: > > ----- wifi "adhoc1" ------ wifi "adhoc2" ----- > |Host1|---------------|Router|---------------|Host2| > ----- LL1 LL2 ------ LL3 LL4 ----- > G1 G4 > > > "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode. > Each is an IPv6 subnet. > LL1...4: IPv6 link-local addresses. > Self-formed according to rfc2464. > G1, G4: IPv6 global addresses, for example > 2001:db8:1::1/64 and > 2001:db8:2::4/64 > Manually assigned, or pre-configured with SNMP > or formed according to stateless autoconf rfc4862; > the prefixes are advertised by Router in RAs. > > > A simple topology with Routers: > > ------- wifi "adhoc1" ------- wifi "adhoc2" ------- > |Router1|---------------|Router2|---------------|Router3| > ------ LL1 LL2 -------LL3 LL4 ------- > G1 G4 > > G1, G4: ? > > > More details on the simple topology with Routers, /64 prefixes and > /128 addresses: > > ----- wifi "adhoc1" ------ wifi "adhoc2" ----- > |Host1|---------------|Router|---------------|Host2| > ----- LL1 P1 LL2 ------ LL3 P2 LL4 ----- > G1 G4 > > G1, G4: IPv6 global addresses, for example > 2001:db8:1::1/128 and > 2001:db8:2::4/128 > Manually assigned, or pre-configured with SNMP > or formed according to stateless autoconf rfc4862; > the prefixes are advertised by Router in RAs. > P1, P2: IPv6 global prefixes, for example > 2001:db8:1::/64 and > 2001:db8:2::/64 > Manually assigned, or pre-configured with SNMP. > > Connecting it to Internet: > > ----- wifi "adhoc1" ------ wifi "adhoc2" -------- / > |Host1|---------------|Router|---------------|Gatewway|---| Internet > ----- LL1 LL2 ------ LL3 LL4 -------- \ > G1 G4 > > > "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode. > Each is an IPv6 subnet. > LL1...4: IPv6 link-local addresses. > Self-formed according to rfc2464. > G1, G4: ? > > > Connecting it to Internet via a Satellite link: > > ------ wifi "adhoc1" ------ wifi "adhoc2" -------- Satelite / > |NEMOMR|---------------|Router|---------------|Gatewway|--------Int'net > ------ LL1 LL2 ------ LL3 LL4 -------- TCA1 \ > G1 G4 > > LL1...4: IPv6 link-local addresses. > Self-formed according to rfc2464. > G1: address formed by NEMOMR either from RA sent by Router, or > by DHCPv6 considering Router is a DHCPRelay and Gateway is > a DHCPServer. > G4: ? > TCA: Topologically-Correct Address, for Gateway. It can be > manually configured on Gateway, or DHCP, or stateless > autoconf. > > > > In the multi-hop network below only /64 prefixes are present in > Routers' routing tables, no /128 (host-based) routes: > > > ----- wifi "adhoc1" ------ wifi "adhoc2" ------- "adhoc3"----- > |Host1|---------------|Router|---------------|Router2|-------|Host2| > ----- LL1 P1 LL2 ------ LL3 P2 LL4 -------LL5 P3 LL6--- > G1 G4 > > P1, P2, P3: /64 prefixes, such as: > 2001:db8:1::/64 > 2001:db8:2::/64 and > 2001:db8:3::/64 > > > Breaking the connectivity: > > ------- wifi "adhoc1" ----- ???? ----- "adhoc2" -------- > |Router1|---------------|Host1|--/ /--|Host2|---------|Router2| > ------- LL2 P1 LL1 --- ----LL6 P2 LL6------ > G1 G4 > > Adding more interfaces of different types: > > Router1 and Router2 are out of range. So R1 <--> H2 and H1 <--> R2. > Host1 MUST communicate to Host2, this is critical (live or dead). > > +-------+ wifi "adhoc1" +-------+ wifi "adhoc2" +-------+ > |Router1|>-------------<|Router2|>-------------<|Router3| > +---L---+ LL1 LL21 +---L---+ LL22 LL3 +---L---+ > |M1 |M2 |M3 > > "adhoc1" and "adhoc2": 802.11 SSIDs in "IBSS" mode. > Each IBSS is an IPv6 subnet. > > L: Loopback interface. > > >, <: MANET interface. > > LL1, LL21, LL22, LL3: IPv6 link-local addresses. > Self-formed according to rfc2464. > > M1, M2, M3: IPv6 MANET local addresses, for example > FD01:db8::1/128, FD01:db8::2/128 and FD01:db8::3/128. > Manually assigned, or pre-configured (e.g. with SNMP) > or formed according to a to be defined [Autoconf for MANETs] > protocol, with a to-be-defined prefix (e.g. ULA, RFC4193). > > > Again connecting to the Internet, this time via an Access Router: > > Internet > | > | > +-------+-------+ > | Access Router | > +-------+-------+ > | > | | Prefix information > | V > | > +-------+ wifi "adhoc1" +---+---+ wifi "adhoc2" +-------+ > |Router1|>-------------<|Router2|>-------------<|Router3| > +---L---+ LL1 LL21 +---L---+ LL22 LL3 +---L---+ > |M1 |M2 |M3 > |G1 |G2 |G3 > <------- -------> > Prefix information Prefix information > > > G1, G2, G3: IPv6 globally unique addresses, for example > 2001:db8:G:1/128, 2001:db8:G:2/128 and 2001:db8:G:3/128. > Formed according to a to be defined [Autoconf for MANETs] > protocol, with the prefix provided by (via) the Access Router. > > > Adding Multi-homing: > > ---+-------Internet--------+--- > | | > | | > +-------+-------+ +-------+-------+ > |Access Router H| |Access Router G| > +-------+-------+ +-------+-------+ > | | > ||Prefix information H | |Prefix information G > |V | V > | | > +---+---+ wifi "adhoc1" +---+---+ wifi "adhoc2" +-------+ > |Router1|>-------------<|Router2|>-------------<|Router3| > +---L---+ LL1 LL21 +---L---+ LL22 LL3 +---L---+ > |M1 |M2 |M3 > |G1 |G2 |G3 > |H1 |H2 |H3 > <------- -------> > Prefix information G Prefix information G, H > ---------> > Prefix information H > > H1, H2, H3: IPv6 globally unique addresses, for example > 2001:db8:H:1/128, 2001:db8:H:2/128 and 2001:db8:H:3/128. > Formed according to a to be defined [Autoconf for MANETs] > protocol, with the prefix provided by (via) Access Router H. > > > Effect of some links disappearing: > > > ---+-------Internet------ > | > | > +-------+-------+ > |Access Router H| > +-------+-------+ > | > ||Prefix information H > |V wifi "adhoc1" > | <---------------------------v--------> > <------|--v----------------------> | > |<-|--------------------v-----------------------|---> > | | | | > +---+--'+ +---'---+ +---'---+ > |Router1|>-------------<|Router2|>-------------<|Router4| > +---L---+ LL1 LL21 +---L---+ LL22 LL4 +---L---+ > |M1 |M2 |M4 > |H1 |H2 |H4 > > ---------> ---------> > Prefix information H Prefix information H > > > No computer movement, but obstacle mouvement: > > (802.11 term: STA is station) > > +------------------------+ +------------------------+ > | | | | > | ____STA-B | | ____STA-B | > | ___/ | | | ___/ | > | STA-A | | | STA-A OBSTACLE | > | '--_ | | | '--_ | > | '----STA-C | | '----STA-C | > | OBSTACLE | | | > +------------------------+ +------------------------+ > 1-1: No hindrance 1-2: B-C blocked > > +------------------------+ +------------------------+ > | | | O | > | ____STA-B | | B STA-B | > | ___/ | | | S | | > | STA-A OB | | | STA-A T | | > | ST | | | A | | > | AC STA-C | | C STA-C | > | LE | | LE | > +------------------------+ +------------------------+ > 1-3: A-C blocked 1-4: A-B & A-C blocked > > MANET Scenarios with blocking obstacle > > > Compare with this one: > > (802.11 term: AP is access point) > > +------------------------+ +------------------------+ > | | | | > | ____STA-B | | ____STA-B | > | ___/ | | ___/ | > | AP-A | | AP-A OBSTACLE | > | '--_ | | '--_ | > | '----STA-C | | '----STA-C | > | OBSTACLE | | | > +------------------------+ +------------------------+ > 4-1: No hindrance 4-2: No hindrance > > +------------------------+ +------------------------+ > | | | O | > | ____STA-B | | B STA-B | > | ___/ | | S | > | AP-A OB | | AP-A T | > | ST | | A | > | AC STA-C | | C STA-C | > | LE | | LE | > +------------------------+ +------------------------+ > 4-3: A-C & B-C blocked 4-4: All blocked > > 802.11 BSS L2 topology with blocking obstacle > > > |HAving them pictured, may I ask you: do you think anything will ever be > |able to communicate through Obstacles? > > > Yes, of course. > > > +------------------------+ +------------------------+ > | | | | > | ____STA-B | | ____STA-B | > | ___/ 1 | | | ___/ 1 . | > | STA-A | 1 | | STA-A obstacle 5 | > | '--_ 1 | | | '--_ 1 . | > | '----STA-C | | '----STA-C | > | obstacle | | | > +------------------------+ +------------------------+ > 2-1: No hindrance 2-2: B-C degraded > > +------------------------+ +------------------------+ > | | | o | > | ____STA-B | | 5 b ...STA-B | > | ___/ 1 | | | ...s. | | > | STA-A ob | 1 | | STA-A t | 1 | > | ... st | | | ...a. | | > | 5 .ac..STA-C | | 5 c ...STA-C | > | le | | le | > +------------------------+ +------------------------+ > 2-3: A-C degraded 2-4: A-B & A-C degraded > > Scenarios with degrading obstacle > > > I depicted the metrics: 1 is good, 5 is degraded. > > Here the routing tables, with metrics: > > ROUTER DEST NEXTHOP METRIC ROUTER DEST NEXTHOP METRIC > +-------+-------+-------+------+ +-------+-------+-------+------+ > | A | B | B | 1 | | A | B | B | 1 | > | | C | C | 1 | | | C | C | 1 | > +-------+-------+-------+------+ +-------+-------+-------+------+ > | B | A | A | 1 | | B | A | A | 1 | > | | C | C | 1 | | | C | C | 5 | > +-------+-------+-------+------+ +-------+-------+-------+------+ > | C | A | A | 1 | | C | A | A | 1 | > | | B | B | 1 | | | B | B | 5 | > +-------+-------+-------+------+ +-------+-------+-------+------+ > 11-1: No hindrance 11-2: B-C is degraded > > +-------+-------+-------+------+ +-------+-------+-------+------+ > | A | B | B | 1 | | A | B | B | 5 | > | | C | C | 5 | | | C | C | 5 | > +-------+-------+-------+------+ +-------+-------+-------+------+ > | B | A | A | 1 | | B | A | A | 5 | > | | C | C | 1 | | | C | C | 1 | > +-------+-------+-------+------+ +-------+-------+-------+------+ > | C | A | A | 5 | | C | A | A | 5 | > | | B | B | 1 | | | B | B | 1 | > +-------+-------+-------+------+ +-------+-------+-------+------+ > 11-3: A-C degraded 11-4: A-B & A-C degraded > > Alex thanking the participants. > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > > From teco@inf-net.nl Tue Mar 3 12:10:45 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C00D028C1ED for ; Tue, 3 Mar 2009 12:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.436 X-Spam-Level: X-Spam-Status: No, score=-1.436 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=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 fiWBMgxLXm7i for ; Tue, 3 Mar 2009 12:10:45 -0800 (PST) Received: from hpsmtp-eml15.kpnxchange.com (hpsmtp-eml15.KPNXCHANGE.COM [213.75.38.115]) by core3.amsl.com (Postfix) with ESMTP id C5BB73A67F9 for ; Tue, 3 Mar 2009 12:10:44 -0800 (PST) Received: from cpsmtp-eml109.kpnxchange.com ([10.94.168.109]) by hpsmtp-eml15.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 21:11:11 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml109.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 21:11:09 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl> <49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl> <49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl> <49AD5184.6080300@gmail.com> In-Reply-To: <49AD5184.6080300@gmail.com> Date: Tue, 3 Mar 2009 21:11:09 +0100 Message-ID: <000101c99c3c$3121a870$9364f950$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmcF6OekugF+0urQ6S/vp/5EAtfMAAH4cgw Content-Language: nl X-OriginalArrivalTime: 03 Mar 2009 20:11:09.0092 (UTC) FILETIME=[31017640:01C99C3C] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Tue, 03 Mar 2009 20:10:45 -0000 Hi Alex, As far as I know, you are the first person that came up with problems using a loopback interface for globally unique addresses / host prefixes (/128, /32) for routers. Please provide good argumentation, otherwise we follow the already accepted practice in the routing community, also documented in RFC5375 (and others, e.g. RFC3484). Maybe you should post this in v6ops, not in Autoconf. Teco. From charles.perkins@earthlink.net Tue Mar 3 12:19:11 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C6713A6869 for ; Tue, 3 Mar 2009 12:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=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 CXU1JywSvvkH for ; Tue, 3 Mar 2009 12:19:10 -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 89AC13A67F6 for ; Tue, 3 Mar 2009 12:19:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=STz8m96yjUEbuW+kzc0B/VVKLaeTqjBZnbG+f63CWZ5b8ET3N+xXJ0I6VbzUOUis; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.129.145] (helo=[10.166.254.146]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Leb5V-0003mJ-D9; Tue, 03 Mar 2009 15:19:37 -0500 Message-ID: <49AD90D9.5040100@earthlink.net> Date: Tue, 03 Mar 2009 12:19:37 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Teco Boot References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl> <49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl> <49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl> <49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl> In-Reply-To: <000101c99c3c$3121a870$9364f950$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f526b8bbecdbb6263feaeb0d17d81573c06350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.129.145 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Tue, 03 Mar 2009 20:19:11 -0000 Hello Teco, How was it already decided to use loopback addresses? I hope not, really... In various implementations of AODV with gateways and in other situations, even running Mobile IP to infrastructure home agents, we never used loopback. What would happen if the "autoconf addressing model" was the same as the "Internet addressing model"? Would that really be so bad? We could have nice things like "multicast", "anycast", unicast, subnets and the typical addressing fundamentals that people already understand. Don't we just have to make sure that routing updates inside the MANET network don't pester routers in the external networks (e.g., Internet)? I don';t see why making that assurance should imply that we have to re-architect the whole Internet addressing model. Regards, Charlie P. Teco Boot wrote: > Hi Alex, > > As far as I know, you are the first person that came up with problems using > a loopback interface for globally unique addresses / host prefixes (/128, > /32) for routers. Please provide good argumentation, otherwise we follow the > already accepted practice in the routing community, also documented in > RFC5375 (and others, e.g. RFC3484). > > Maybe you should post this in v6ops, not in Autoconf. > > Teco. > > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > > > From alexandru.petrescu@gmail.com Tue Mar 3 12:47:14 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 161413A6953 for ; Tue, 3 Mar 2009 12:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.835 X-Spam-Level: X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=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 Wf8Kyyod0rJ7 for ; Tue, 3 Mar 2009 12:47:13 -0800 (PST) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by core3.amsl.com (Postfix) with ESMTP id 030013A689E for ; Tue, 3 Mar 2009 12:47:11 -0800 (PST) Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by smtp3-g21.free.fr (Postfix) with ESMTP id 665588181D3; Tue, 3 Mar 2009 21:47:34 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp3-g21.free.fr (Postfix) with ESMTP id 208E08181F8; Tue, 3 Mar 2009 21:47:31 +0100 (CET) Message-ID: <49AD9760.3080909@gmail.com> Date: Tue, 03 Mar 2009 21:47:28 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Teco Boot References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl> <49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl> <49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl> <49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl> In-Reply-To: <000101c99c3c$3121a870$9364f950$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090303-1, 03/03/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Tue, 03 Mar 2009 20:47:14 -0000 Teco, the problem is simple: host-based routes are not preferrable. Host-based routes in routers surrounding router X (this is what a /128 address on a virtual interface on router X implies, be that loopback interface or not loopback interface) for a dynamically changing topology may lead to too many routes coming up and down, too many specific entries in the routing tables, too much dedicated routing messaging, and more. That only for the network itself. Connecting it to the Internet, with host-based routes propagated up and down throughout, may risk influencing the routes in the Internet proper. A new host-based route inserted in the routing table of the gateway connecting this network to the Internet may propagate throughout the entire fixed access system. If you told me which part of the above were unclear I could explain further. But I think there's large agreement on it. About the feasibility of _one_ /128 address on 'lo' while using _one_ host-based route: as you pointed out with the ios-linux example, I fully agree a /128 address assigned on the 'lo' interface of one computer, and a host-based route in the other computer towards that /128 address - will work. But just one. About posting to v6ops: which part do you think I should post there? About singling me out being the first and only mentioning some problem: I can only be happy about it and stop posting :-) But this host-based route stuff is not new, I'm myself surprised I'm singled out about it. Alex Teco Boot a écrit : > Hi Alex, > > As far as I know, you are the first person that came up with problems > using a loopback interface for globally unique addresses / host > prefixes (/128, /32) for routers. Please provide good argumentation, > otherwise we follow the already accepted practice in the routing > community, also documented in RFC5375 (and others, e.g. RFC3484). > > Maybe you should post this in v6ops, not in Autoconf. > > Teco. > > > > From charles.perkins@earthlink.net Tue Mar 3 12:53:33 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 652973A67BD for ; Tue, 3 Mar 2009 12:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 fG5C2RK4J+EJ for ; Tue, 3 Mar 2009 12:53:32 -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 5056D3A68E8 for ; Tue, 3 Mar 2009 12:53:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=T7JU4G9dzgMDcHsvBQZ+BVIvXabpa5glw63jj9nW9/h8sNiwkLyvhlWc0GeMF07J; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.129.145] (helo=[10.166.254.146]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LebcS-0005bL-RN; Tue, 03 Mar 2009 15:53:40 -0500 Message-ID: <49AD98D4.3@earthlink.net> Date: Tue, 03 Mar 2009 12:53:40 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Alexandru Petrescu References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl> <49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl> <49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl> <49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl> <49AD9760.3080909@gmail.com> In-Reply-To: <49AD9760.3080909@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52944a24a0e5f2efcb08bc5d7d1c1f9d67350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.129.145 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Tue, 03 Mar 2009 20:53:33 -0000 Hello Alex, Alexandru Petrescu wrote: > Teco, the problem is simple: host-based routes are not preferrable. > Why is that? > > Host-based routes in routers surrounding router X (this is what a /128 > address on a virtual interface on router X implies, be that loopback > interface or not loopback interface) for a dynamically changing topology > may lead to too many routes coming up and down, too many specific > entries in the routing tables, too much dedicated routing messaging, and > more. This magically "forgets" the last 10 years of development for ad hoc networking protocols. Do you think this work was somehow invalid? Solving the problems you mentioned was, after all, the entire point of the work. > Connecting it to the Internet, with host-based routes propagated up and > down throughout, may risk influencing the routes in the Internet proper. > A new host-based route inserted in the routing table of the gateway > connecting this network to the Internet may propagate throughout the > entire fixed access system. That would be the result of somebody making very poor design and configuration choices on the gateway. Presumably we can make a specification that would avoid such bad design choices. I say this, because I have myself been involved with design efforts where we already did it at least two or three times. Regards, Charlie P. From alexandru.petrescu@gmail.com Tue Mar 3 13:18:18 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2055A3A67D6 for ; Tue, 3 Mar 2009 13:18:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=0.122, 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 09DHt8pCrQVX for ; Tue, 3 Mar 2009 13:18:17 -0800 (PST) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by core3.amsl.com (Postfix) with ESMTP id 1B00B3A69A0 for ; Tue, 3 Mar 2009 13:18:15 -0800 (PST) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id E0C544C815C; Tue, 3 Mar 2009 22:18:38 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp4-g21.free.fr (Postfix) with ESMTP id 464014C819D; Tue, 3 Mar 2009 22:18:35 +0100 (CET) Message-ID: <49AD9EA8.6040803@gmail.com> Date: Tue, 03 Mar 2009 22:18:32 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Charles E. Perkins" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl> <49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl> <49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl> <49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl> <49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net> In-Reply-To: <49AD98D4.3@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090303-1, 03/03/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Tue, 03 Mar 2009 21:18:18 -0000 Charles - overall: -I don't find it advantageous to specify an addressing architecture talking about virtual interfaces, be they loopback interfaces; rather I'd describe real interfaces. -I find it more advantageous to describe stable subnets, with prefixes (between /48 and /64) exchanged around, rather than /128s. -I would avoid the assumption that an ad-hoc router maintains a stable IP address while moving around. For details, see below. Alex The churning aspect of host-based routes was just one argument against /128s and finally against loopback/virtual interfaces. Of course, host-based routes could work in some networks, mainly depending on their size and way of moving. Charles E. Perkins a écrit : > Hello Alex, > > Alexandru Petrescu wrote: >> Teco, the problem is simple: host-based routes are not preferrable. >> >> >> > > Why is that? BEcause we simply don't know the size of the network in which they could work. And that apparently it is avoided to put any limit on size of any kind. Even approximative evaluations of the size of the network in which these host-based routes would work aren't preferred by many. >> Host-based routes in routers surrounding router X (this is what a >> /128 address on a virtual interface on router X implies, be that >> loopback interface or not loopback interface) for a dynamically >> changing topology may lead to too many routes coming up and down, >> too many specific entries in the routing tables, too much dedicated >> routing messaging, and more. > > This magically "forgets" the last 10 years of development for ad hoc > networking protocols. Do you think this work was somehow invalid? > Solving the problems you mentioned was, after all, the entire point > of the work. Sorry for having sounded neglecting the results of ad-hoc networking protocols. It was not the intention. I believe some protocols could be used to propagate prefixes - instead of /128s - and may be more efficient, grow the network larger. >> Connecting it to the Internet, with host-based routes propagated up >> and down throughout, may risk influencing the routes in the >> Internet proper. A new host-based route inserted in the routing >> table of the gateway connecting this network to the Internet may >> propagate throughout the entire fixed access system. > > That would be the result of somebody making very poor design and > configuration choices on the gateway. > > Presumably we can make a specification that would avoid such bad > design choices. I say this, because I have myself been involved with > design efforts where we already did it at least two or three times. Well yes, that's a good point, worth mentioning raw like that. There is an additional way achieving it: using ULAs, they wouldn't propagate, because their own nature. They wouldn't be reachable either. These aspects could be mentioned. Alex From charles.perkins@earthlink.net Tue Mar 3 13:30:09 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DF0C28C10B for ; Tue, 3 Mar 2009 13:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 x7WgyU05-o22 for ; Tue, 3 Mar 2009 13:30:08 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 5AF8328C0FE for ; Tue, 3 Mar 2009 13:30:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=K2dmMz7Zkf5zD55EOu2nUlDR9WqpJsgaPfG/U7YPEbP5Bna2MNR1kCnb81ybIepp; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.129.145] (helo=[10.166.254.146]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LecCB-0002aT-MT; Tue, 03 Mar 2009 16:30:35 -0500 Message-ID: <49ADA17B.9040600@earthlink.net> Date: Tue, 03 Mar 2009 13:30:35 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Alexandru Petrescu References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl> <49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl> <49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl> <49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl> <49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net> <49AD9EA8.6040803@gmail.com> In-Reply-To: <49AD9EA8.6040803@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5261b73a89d4d4c70ac340024b1abf6be5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.129.145 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Tue, 03 Mar 2009 21:30:09 -0000 Hello Alex, Alexandru Petrescu wrote: > > -I find it more advantageous to describe stable subnets, with prefixes > (between /48 and /64) exchanged around, rather than /128s. That's fine, as long as the destination is addressable within a subnet. If the destination does not live on a subnet, why not use a host route (i.e., /128 address)? > -I would avoid the assumption that an ad-hoc router maintains a > stable IP address while moving around. Then you will have trouble. There is no free lunch. Either: (a) the IP address stays the same, and the routes change, or (b) the IP address changes, and there is a resolver to associate the IP address with some other identifier. Since the design of the resolver in (b) is an unknown and arguably much more difficult, I'll take (a) with a great sigh of relief. > > > The churning aspect of host-based routes was just one argument against > /128s and finally against loopback/virtual interfaces. Are the other arguments easily summarized in a few words? > > Of course, host-based routes could work in some networks, mainly > depending on their size and way of moving. This is true. I don't see what's wrong with it. > > BEcause we simply don't know the size of the network in which they could > work. And that apparently it is avoided to put any limit on size of any > kind. Who said we had to avoid size limits? > > Even approximative evaluations of the size of the network in which these > host-based routes would work aren't preferred by many. I must have missed that, sorry. Those "many" didn't often assert their preferences in the [manet] working group. > >> >> This magically "forgets" the last 10 years of development for ad hoc >> networking protocols. Do you think this work was somehow invalid? >> Solving the problems you mentioned was, after all, the entire point >> of the work. > > Sorry for having sounded neglecting the results of ad-hoc networking > protocols. It was not the intention. I believe some protocols could be > used to propagate prefixes - instead of /128s - and may be more > efficient, grow the network larger. Well, to me it did sound very negative. Moreover, I think it is just fine to pass around subnet prefixes, if you have subnets. Regards, Charlie P. From teco@inf-net.nl Tue Mar 3 13:36:52 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4D6A3A6911 for ; Tue, 3 Mar 2009 13:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.191 X-Spam-Level: X-Spam-Status: No, score=0.191 tagged_above=-999 required=5 tests=[AWL=-1.618, BAYES_00=-2.599, FRT_LITTLE=1.555, HELO_MISMATCH_COM=0.553, MANGLED_LIST=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJaC5sL0d9OM for ; Tue, 3 Mar 2009 13:36:51 -0800 (PST) Received: from hpsmtp-eml19.kpnxchange.com (hpsmtp-eml19.KPNXCHANGE.COM [213.75.38.84]) by core3.amsl.com (Postfix) with ESMTP id 62DEE3A687A for ; Tue, 3 Mar 2009 13:36:51 -0800 (PST) Received: from cpsmtp-eml109.kpnxchange.com ([10.94.168.109]) by hpsmtp-eml19.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 22:37:18 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml109.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 22:37:18 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl> <49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl> <49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl> <49AD5184.6080300@gmail.com> In-Reply-To: <49AD5184.6080300@gmail.com> Date: Tue, 3 Mar 2009 22:37:18 +0100 Message-ID: <000b01c99c48$3a34ffa0$ae9efee0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmcF6OekugF+0urQ6S/vp/5EAtfMAAJPiUg Content-Language: nl X-OriginalArrivalTime: 03 Mar 2009 21:37:18.0256 (UTC) FILETIME=[3A114B00:01C99C48] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Tue, 03 Mar 2009 21:36:52 -0000 Hi Alex, I included wrong routing table info in the "obstacles" scenarios. Here a full set of diagrams with routing table info. I removed "STA-", now the model applies to non-802.11 topologies as well. Teco. 1. MANET topology with moving and blocking obstacle +------------------------+ +------------------------+ | | | | | ______B | | ______B | | ___/ | | | ___/ | | A | | | A OBSTACLE | | '--_ | | | '--_ | | '------C | | '------C | | OBSTACLE | | | +------------------------+ +------------------------+ 1-1: Full connected 1-2: B-C via A +------------------------+ +------------------------+ | | | O | | ______B | | B B | | ___/ | | | S | | | A OB | | | A T | | | ST | | | A | | | AC C | | C C | | LE | | L | | | | E | +------------------------+ +------------------------+ 1-3: A-C via B 1-4: A-B and A-C blocked The routing tables for the MANET Routers look as follows: ROUTER DEST NEXTHOP COST ROUTER DEST NEXTHOP COST +-------+-------+-------+----+ +-------+-------+-------+----+ | A | B | B | 1 | | A | B | B | 1 | | | C | C | 1 | | | C | C | 1 | +-------+-------+-------+----+ +-------+-------+-------+----+ | B | A | A | 1 | | B | A | A | 1 | | | C | C | 1 | | | C | A | 2 | +-------+-------+-------+----+ +-------+-------+-------+----+ | C | A | A | 1 | | C | A | A | 1 | | | B | B | 1 | | | B | B | 2 | +-------+-------+-------+----+ +-------+-------+-------+----+ 1-1: All single hop 1-2: B-C degraded +-------+-------+-------+----+ +-------+-------+-------+----+ | A | B | B | 1 | | A | | | | | | C | B | 2 | | | | | | +-------+-------+-------+----+ +-------+-------+-------+----+ | B | A | A | 1 | | B | | | | | | C | C | 1 | | | C | C | 1 | +-------+-------+-------+----+ +-------+-------+-------+----+ | C | A | B | 2 | | C | | | | | | B | B | 1 | | | B | B | 1 | +-------+-------+-------+----+ +-------+-------+-------+----+ 1-3: A-C degraded 1-4: A-B and A-C blocked 2. MANET topology with moving and degrading obstacle In these scenarios, link metrics are introduced. +------------------------+ +------------------------+ | | | | | _______B | | ______B | | __/ 1 | | | __/ 1 . | | A | 1 | | A obstacle | | '--_ 1 | | | '--_ 1 . 5 | | '------C | | '------C | | obstacle | | | +------------------------+ +------------------------+ 2-1: No hindrance 2-2: B-C degraded +------------------------+ +------------------------+ | | | o | | ______B | | 5 b .....B | | ___/ 1 | | | ...s. | | | A ob | 1 | | A t | 1 | | ... st | | | ...a. | | | 5 .ac.... C | | 5 c .....C | | le | | l | | | | e | +------------------------+ +------------------------+ 2-3: A-C degraded 2-4: A-B and A-C degraded The routing tables: ROUTER DEST NEXTHOP COST ROUTER DEST NEXTHOP COST +-------+-------+-------+----+ +-------+-------+-------+----+ | A | B | B | 1 | | A | B | B | 1 | | | C | C | 1 | | | C | C | 1 | +-------+-------+-------+----+ +-------+-------+-------+----+ | B | A | A | 1 | | B | A | A | 1 | | | C | C | 1 | | | C | A | 2 | +-------+-------+-------+----+ +-------+-------+-------+----+ | C | A | A | 1 | | C | A | A | 1 | | | B | B | 1 | | | B | A | 2 | +-------+-------+-------+----+ +-------+-------+-------+----+ 2-1: No hindrance 2-2: B-C degraded +-------+-------+-------+----+ +-------+-------+-------+----+ | A | B | B | 1 | | A | B | B | 5 | | | C | B | 2 | | | C | C | 5 | +-------+-------+-------+----+ +-------+-------+-------+----+ | B | A | A | 1 | | B | A | A | 5 | | | C | C | 1 | | | C | C | 1 | +-------+-------+-------+----+ +-------+-------+-------+----+ | C | A | B | 2 | | C | A | A | 5 | | | B | B | 1 | | | B | B | 1 | +-------+-------+-------+----+ +-------+-------+-------+----+ 2-3: A-C degraded 2-4: A-B and A-C degraded In this scenario, the most optimal paths are used, a 2-hop path with metric 2 is used instead of a single hop path with metric 5. 3. MANET topology with degrading obstacle and noise In this scenario, C can hear A through an obstacle as scenario 2-3, but A reception of B and C is affected by high level "NOISE" (3.1) or low level "noise" (3-2). With high level noise, A cannot hear C and the link is "uni-directional". Term "asymmetric" is used to indicate unbalanced metrics for the direction of traffic between two nodes. In other documents, "asymmetric" is used for what is called "uni-directional" here. +------------------------+ +------------------------+ | | | | | ____1_B | | ____1_B | | 3__/ | | | 2__/ | | | A ob | 1 | | A ob | 1 | | NOISE st | | | noise ... st | | | x.ac.>..C | | 10 .ac....C | | le | | le 5 | +------------------------+ +------------------------+ 3-1: A-C uni-directional 3-2: A-C & B-C asymmetric A-B asymmetric ROUTER DEST NEXTHOP METRIC ROUTER DEST NEXTHOP METRIC +-------+-------+-------+------+ +-------+-------+-------+------+ | A | B | B | 3 | | A | B | B | 2 | | | C | B | 4 | | | C | B | 3 | +-------+-------+-------+------+ +-------+-------+-------+------+ | B | A | A | 1 | | B | A | A | 1 | | | C | C | 1 | | | C | C | 1 | +-------+-------+-------+------+ +-------+-------+-------+------+ | C | A | B | 2 | | C | A | B | 2 | | | B | B | 1 | | | B | B | 1 | +-------+-------+-------+------+ +-------+-------+-------+------+ 3-1: A-C uni-directional 3-2: A-C & B-C asymmetric A-B asymmetric When the noise level near station A is intermitting between high and low levels, this does not influence the routing topology, as the MANET protocol has selected path A-B-C between the routers A and C, because better metrics and bidirectional validation. The MANET Routing Protocol checks directionality of links before using these. From alexandru.petrescu@gmail.com Tue Mar 3 14:30:04 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAA553A6973 for ; Tue, 3 Mar 2009 14:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.132 X-Spam-Level: X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=0.117, 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 8yyfQ0YtPNLx for ; Tue, 3 Mar 2009 14:30:04 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id B980C3A6A97 for ; Tue, 3 Mar 2009 14:30:02 -0800 (PST) Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id 869E8940019; Tue, 3 Mar 2009 23:30:25 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 328D39400C4; Tue, 3 Mar 2009 23:30:23 +0100 (CET) Message-ID: <49ADAF7C.1050509@gmail.com> Date: Tue, 03 Mar 2009 23:30:20 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Charles E. Perkins" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl> <49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl> <49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl> <49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl> <49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net> <49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net> In-Reply-To: <49ADA17B.9040600@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090303-1, 03/03/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Tue, 03 Mar 2009 22:30:05 -0000 Charles E. Perkins a écrit : > > Hello Alex, > > Alexandru Petrescu wrote: >> >> -I find it more advantageous to describe stable subnets, with >> prefixes (between /48 and /64) exchanged around, rather than /128s. >> > > That's fine, as long as the destination is addressable within a > subnet. If the destination does not live on a subnet, why not use a > host route (i.e., /128 address)? Because it wouldn't allow the AUTOCONF network to grow larger and more dynamic. >> -I would avoid the assumption that an ad-hoc router maintains a >> stable IP address while moving around. > > Then you will have trouble. There is no free lunch. Either: (a) the > IP address stays the same, and the routes change, or (b) the IP > address changes, and there is a resolver to associate the IP address > with some other identifier. > > Since the design of the resolver in (b) is an unknown and arguably > much more difficult, I'll take (a) with a great sigh of relief. Resolvers such as (m)DNS or some DHCP features could work I believe. I don't understand why it's claimed much more difficult. >> The churning aspect of host-based routes was just one argument >> against /128s and finally against loopback/virtual interfaces. > > Are the other arguments easily summarized in a few words? No :-) sorry >> Of course, host-based routes could work in some networks, mainly >> depending on their size and way of moving. > > This is true. I don't see what's wrong with it. > >> >> BEcause we simply don't know the size of the network in which they >> could work. And that apparently it is avoided to put any limit on >> size of any kind. > > Who said we had to avoid size limits? Well we don't have size limits in the charter proposal, we don't have agreement on '25m IPv6 subnets', we don't have limits on the types of the link layers involved. However, your question seems to imply you think there may be a limit: AUTOCONF network is small enough to accommodate host-based routes. Is it this? >> Even approximative evaluations of the size of the network in which >> these host-based routes would work aren't preferred by many. > > I must have missed that, sorry. Those "many" didn't often assert > their preferences in the [manet] working group. Ok, it was my own interpretation. >>> This magically "forgets" the last 10 years of development for ad >>> hoc networking protocols. Do you think this work was somehow >>> invalid? Solving the problems you mentioned was, after all, the >>> entire point of the work. >> >> Sorry for having sounded neglecting the results of ad-hoc >> networking protocols. It was not the intention. I believe some >> protocols could be used to propagate prefixes - instead of /128s - >> and may be more efficient, grow the network larger. > > Well, to me it did sound very negative. Moreover, I think it is just > fine to pass around subnet prefixes, if you have subnets. Charles, yes - the subnets are there first, before IP. Once the link is up the subnet is the set of nodes on it. In this sense I agree it is just fine to pass subnet prefixes around. Thanks for the message, Alex From teco@inf-net.nl Tue Mar 3 14:31:20 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CFE33A6B58 for ; Tue, 3 Mar 2009 14:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.213 X-Spam-Level: X-Spam-Status: No, score=-0.213 tagged_above=-999 required=5 tests=[AWL=-1.067, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, MANGLED_PILL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCLisIzEJcK6 for ; Tue, 3 Mar 2009 14:31:13 -0800 (PST) Received: from hpsmtp-eml19.kpnxchange.com (hpsmtp-eml19.KPNXCHANGE.COM [213.75.38.84]) by core3.amsl.com (Postfix) with ESMTP id 0D8083A6973 for ; Tue, 3 Mar 2009 14:31:11 -0800 (PST) Received: from cpsmtp-eml103.kpnxchange.com ([213.75.84.103]) by hpsmtp-eml19.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 23:31:38 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml103.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 23:31:38 +0100 From: "Teco Boot" To: "'Charles E. Perkins'" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl> <49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl> <49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl> <49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl> <49AD90D9.5040100@earthlink.net> In-Reply-To: <49AD90D9.5040100@earthlink.net> Date: Tue, 3 Mar 2009 23:31:38 +0100 Message-ID: <000c01c99c4f$d1ab1750$750145f0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmcPWIgkYbjQVANQ42eNsizbcZxvgACvuXw Content-Language: nl X-OriginalArrivalTime: 03 Mar 2009 22:31:38.0257 (UTC) FILETIME=[D12DF810:01C99C4F] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Tue, 03 Mar 2009 22:31:20 -0000 Hi Charlie, I never suggested using loopback interfaces are mandatory. I suggest MAY or SHOULD, or BCP. For some systems, the overhead or complexity or whatever could be unacceptable and we should not enforce this (no MUST). As long as I designed and maintained network infrastructures, I worked with "/32 management addresses" on loopback interfaces. Still, I have annoying experiences with routers that select the outgoing interface address as default source address. Shutting down an interface could have unintended bad impact on your terminal session. Same for link flapping due to other causes. For this reason, many routers on the Internet use the loopback interface for "management". "Management" is the host application on routers. There are lots of design guidelines for this. My proposal is using the "Internet lessons learned" in the MANET. Nothing wrong with this, agreed? As said before, I have also bad experience with applications that bind to the MANET interface address directly. I am sure I am not the only one. With MobileIP, we are discussing a host (could be NEMO Router, but then it acts as host on the visiting link). The MobileIP stack is interested in the status of the visiting link, but does it propagate this to the applications? Or use the applications some kind of virtual interface (e.g. a loopback interface)? Or spoof ifup for interface to home link? On MANET topology changes reflected in the Internet, I would say: it depends. With NEMO technology, MR would present its status to the HA. We could run MANET Routing over an MRHA tunnel, so HA learns prefixes of other MANET Routers connected to the MR. With redundant HA, things are getting more and more complex. I would say: reachability shall be reflected in The Internet, intra-MANET link updates should not. Running BGP in the MRHA tunnel? Or use the nested NEMO model? See what MEXT will do here, and check if we can help (e.g. a MANET for NEMO). Or come up with some kind of prefix delegation for MANETs, where summaries belong to the Border Router and MANET topology is hidden form the Internet. This is what BRDP provides. Regards, Teco |-----Oorspronkelijk bericht----- |Van: Charles E. Perkins [mailto:charles.perkins@earthlink.net] |Verzonden: dinsdag 3 maart 2009 21:20 |Aan: Teco Boot |CC: autoconf@ietf.org |Onderwerp: Re: [Autoconf] Autoconf addressing model | | |Hello Teco, | |How was it already decided to use loopback addresses? | |I hope not, really... | |In various implementations of AODV with gateways and |in other situations, even running Mobile IP to infrastructure |home agents, we never used loopback. | |What would happen if the "autoconf addressing model" |was the same as the "Internet addressing model"? |Would that really be so bad? We could have nice |things like "multicast", "anycast", unicast, subnets |and the typical addressing fundamentals that people |already understand. | |Don't we just have to make sure that routing updates |inside the MANET network don't pester routers in |the external networks (e.g., Internet)? I don';t see |why making that assurance should imply that we have |to re-architect the whole Internet addressing model. | |Regards, |Charlie P. | | | | |Teco Boot wrote: |> Hi Alex, |> |> As far as I know, you are the first person that came up with problems |using |> a loopback interface for globally unique addresses / host prefixes |(/128, |> /32) for routers. Please provide good argumentation, otherwise we |follow the |> already accepted practice in the routing community, also documented in |> RFC5375 (and others, e.g. RFC3484). |> |> Maybe you should post this in v6ops, not in Autoconf. |> |> Teco. |> |> |> |> _______________________________________________ |> Autoconf mailing list |> Autoconf@ietf.org |> https://www.ietf.org/mailman/listinfo/autoconf |> |> |> From alexandru.petrescu@gmail.com Tue Mar 3 14:39:57 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86DF13A6849 for ; Tue, 3 Mar 2009 14:39:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.986 X-Spam-Level: X-Spam-Status: No, score=-0.986 tagged_above=-999 required=5 tests=[AWL=-1.037, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_LIST=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K02SM5ghYCMs for ; Tue, 3 Mar 2009 14:39:56 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 24F2F3A67FA for ; Tue, 3 Mar 2009 14:39:54 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 92DB1E08125; Tue, 3 Mar 2009 23:40:17 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp6-g21.free.fr (Postfix) with ESMTP id 60543E08067; Tue, 3 Mar 2009 23:40:15 +0100 (CET) Message-ID: <49ADB1CC.4000704@gmail.com> Date: Tue, 03 Mar 2009 23:40:12 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Teco Boot References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl> <49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl> <49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl> <49AD5184.6080300@gmail.com> <000b01c99c48$3a34ffa0$ae9efee0$@nl> In-Reply-To: <000b01c99c48$3a34ffa0$ae9efee0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090303-1, 03/03/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Tue, 03 Mar 2009 22:39:57 -0000 Teco, I'm happy you updated the obstacles scenario. That's important insight on what movement may actually be. I'd go further include default routes in the tables, and specific addresses like 10.1.1.1/32 instead of A, and subnet prefixes 10.1.1.0/24 for example. Sorry just asking about this: the Cost in the routing tables. The kernel routing tables don't have variable Cost, they're all metric 1 I believe (all next-hops are 1-hop away). The routing protocols' tables may have Cost and other variables. Did you assume a routing protocol? My preference is to not assume any routing protocol. Alex Teco Boot a écrit : > Hi Alex, > > I included wrong routing table info in the "obstacles" scenarios. > Here a full set of diagrams with routing table info. > > I removed "STA-", now the model applies to non-802.11 topologies as well. > > Teco. > > > > > 1. MANET topology with moving and blocking obstacle > > +------------------------+ +------------------------+ > | | | | > | ______B | | ______B | > | ___/ | | | ___/ | > | A | | | A OBSTACLE | > | '--_ | | | '--_ | > | '------C | | '------C | > | OBSTACLE | | | > +------------------------+ +------------------------+ > 1-1: Full connected 1-2: B-C via A > > +------------------------+ +------------------------+ > | | | O | > | ______B | | B B | > | ___/ | | | S | | > | A OB | | | A T | | > | ST | | | A | | > | AC C | | C C | > | LE | | L | > | | | E | > +------------------------+ +------------------------+ > 1-3: A-C via B 1-4: A-B and A-C blocked > > > The routing tables for the MANET Routers look as follows: > > ROUTER DEST NEXTHOP COST ROUTER DEST NEXTHOP COST > +-------+-------+-------+----+ +-------+-------+-------+----+ > | A | B | B | 1 | | A | B | B | 1 | > | | C | C | 1 | | | C | C | 1 | > +-------+-------+-------+----+ +-------+-------+-------+----+ > | B | A | A | 1 | | B | A | A | 1 | > | | C | C | 1 | | | C | A | 2 | > +-------+-------+-------+----+ +-------+-------+-------+----+ > | C | A | A | 1 | | C | A | A | 1 | > | | B | B | 1 | | | B | B | 2 | > +-------+-------+-------+----+ +-------+-------+-------+----+ > 1-1: All single hop 1-2: B-C degraded > > +-------+-------+-------+----+ +-------+-------+-------+----+ > | A | B | B | 1 | | A | | | | > | | C | B | 2 | | | | | | > +-------+-------+-------+----+ +-------+-------+-------+----+ > | B | A | A | 1 | | B | | | | > | | C | C | 1 | | | C | C | 1 | > +-------+-------+-------+----+ +-------+-------+-------+----+ > | C | A | B | 2 | | C | | | | > | | B | B | 1 | | | B | B | 1 | > +-------+-------+-------+----+ +-------+-------+-------+----+ > 1-3: A-C degraded 1-4: A-B and A-C blocked > > > > 2. MANET topology with moving and degrading obstacle > > In these scenarios, link metrics are introduced. > > +------------------------+ +------------------------+ > | | | | > | _______B | | ______B | > | __/ 1 | | | __/ 1 . | > | A | 1 | | A obstacle | > | '--_ 1 | | | '--_ 1 . 5 | > | '------C | | '------C | > | obstacle | | | > +------------------------+ +------------------------+ > 2-1: No hindrance 2-2: B-C degraded > > +------------------------+ +------------------------+ > | | | o | > | ______B | | 5 b .....B | > | ___/ 1 | | | ...s. | | > | A ob | 1 | | A t | 1 | > | ... st | | | ...a. | | > | 5 .ac.... C | | 5 c .....C | > | le | | l | > | | | e | > +------------------------+ +------------------------+ > 2-3: A-C degraded 2-4: A-B and A-C degraded > > > The routing tables: > > ROUTER DEST NEXTHOP COST ROUTER DEST NEXTHOP COST > +-------+-------+-------+----+ +-------+-------+-------+----+ > | A | B | B | 1 | | A | B | B | 1 | > | | C | C | 1 | | | C | C | 1 | > +-------+-------+-------+----+ +-------+-------+-------+----+ > | B | A | A | 1 | | B | A | A | 1 | > | | C | C | 1 | | | C | A | 2 | > +-------+-------+-------+----+ +-------+-------+-------+----+ > | C | A | A | 1 | | C | A | A | 1 | > | | B | B | 1 | | | B | A | 2 | > +-------+-------+-------+----+ +-------+-------+-------+----+ > 2-1: No hindrance 2-2: B-C degraded > > +-------+-------+-------+----+ +-------+-------+-------+----+ > | A | B | B | 1 | | A | B | B | 5 | > | | C | B | 2 | | | C | C | 5 | > +-------+-------+-------+----+ +-------+-------+-------+----+ > | B | A | A | 1 | | B | A | A | 5 | > | | C | C | 1 | | | C | C | 1 | > +-------+-------+-------+----+ +-------+-------+-------+----+ > | C | A | B | 2 | | C | A | A | 5 | > | | B | B | 1 | | | B | B | 1 | > +-------+-------+-------+----+ +-------+-------+-------+----+ > 2-3: A-C degraded 2-4: A-B and A-C degraded > > In this scenario, the most optimal paths are used, a 2-hop path with > metric 2 is used instead of a single hop path with metric 5. > > > > 3. MANET topology with degrading obstacle and noise > > In this scenario, C can hear A through an obstacle as scenario 2-3, > but A reception of B and C is affected by high level "NOISE" (3.1) > or low level "noise" (3-2). With high level noise, A cannot hear C and > the link is "uni-directional". > > Term "asymmetric" is used to indicate unbalanced metrics for the > direction > of traffic between two nodes. In other documents, "asymmetric" is used > for > what is called "uni-directional" here. > > > +------------------------+ +------------------------+ > | | | | > | ____1_B | | ____1_B | > | 3__/ | | | 2__/ | | > | A ob | 1 | | A ob | 1 | > | NOISE st | | | noise ... st | | > | x.ac.>..C | | 10 .ac....C | > | le | | le 5 | > +------------------------+ +------------------------+ > 3-1: A-C uni-directional 3-2: A-C & B-C asymmetric > A-B asymmetric > > > ROUTER DEST NEXTHOP METRIC ROUTER DEST NEXTHOP METRIC > +-------+-------+-------+------+ +-------+-------+-------+------+ > | A | B | B | 3 | | A | B | B | 2 | > | | C | B | 4 | | | C | B | 3 | > +-------+-------+-------+------+ +-------+-------+-------+------+ > | B | A | A | 1 | | B | A | A | 1 | > | | C | C | 1 | | | C | C | 1 | > +-------+-------+-------+------+ +-------+-------+-------+------+ > | C | A | B | 2 | | C | A | B | 2 | > | | B | B | 1 | | | B | B | 1 | > +-------+-------+-------+------+ +-------+-------+-------+------+ > 3-1: A-C uni-directional 3-2: A-C & B-C asymmetric > A-B asymmetric > > When the noise level near station A is intermitting between high and low > levels, this does not influence the routing topology, as the MANET > protocol > has selected path A-B-C between the routers A and C, because better > metrics > and bidirectional validation. > The MANET Routing Protocol checks directionality of links before using > these. > > > > > From charles.perkins@earthlink.net Tue Mar 3 15:14:41 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61F3C3A67CC for ; Tue, 3 Mar 2009 15:14: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 DnAbtRQvSOCN for ; Tue, 3 Mar 2009 15:14:40 -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 58A1B3A6814 for ; Tue, 3 Mar 2009 15:14:40 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=l7R46lVJloo2+i30U8tXcbkvawyy91cg3QyZ9t1rqZ26Kk03RWB5uB6Ik9X+rIMR; 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.104]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LedpL-0003UV-CZ; Tue, 03 Mar 2009 18:15:07 -0500 Message-ID: <49ADB9FB.6050600@earthlink.net> Date: Tue, 03 Mar 2009 15:15:07 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Alexandru Petrescu References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl> <49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl> <49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl> <49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl> <49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net> <49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net> <49ADAF7C.1050509@gmail.com> In-Reply-To: <49ADAF7C.1050509@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f528ddb54621b1b0b9d32729b63824c8546350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.138.86.46 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Tue, 03 Mar 2009 23:14:41 -0000 Hello Alex, Alexandru Petrescu wrote: > >> >> That's fine, as long as the destination is addressable within a >> subnet. If the destination does not live on a subnet, why not use a >> host route (i.e., /128 address)? > > Because it wouldn't allow the AUTOCONF network to grow larger and more > dynamic. Just saying "subnet" doesn't do that either, though. In fact, the signaling to support subnets could (conceivably) be even more complicated than the signaling to support host routes. > >>> -I would avoid the assumption that an ad-hoc router maintains a >>> stable IP address while moving around. >> >> Then you will have trouble. There is no free lunch. Either: (a) the >> IP address stays the same, and the routes change, or (b) the IP >> address changes, and there is a resolver to associate the IP address >> with some other identifier. >> >> Since the design of the resolver in (b) is an unknown and arguably >> much more difficult, I'll take (a) with a great sigh of relief. > > Resolvers such as (m)DNS or some DHCP features could work I believe. I > don't understand why it's claimed much more difficult. I assure you it is not trivial to implement DNS or DHCP inside an ad hoc network. Most of the proposals I have seen for this have located the function _outside_ the ad hoc network, for convenient and straightforward access when connectivity is actually available. Watching your DNS server [(m) or not!] move from place to place in an ad hoc network, sometimes finding itself partitioned from your favorite node, could be an exciting and enlightening adventure. > >>> The churning aspect of host-based routes was just one argument >>> against /128s and finally against loopback/virtual interfaces. >> >> Are the other arguments easily summarized in a few words? > > No :-) sorry Well, then I reserve the right to be very skeptical about their validity. > >> >> Who said we had to avoid size limits? > > Well we don't have size limits in the charter proposal, we don't have > agreement on '25m IPv6 subnets', we don't have limits on the types of > the link layers involved. If you are talking about an ad hoc network with 25,000,000 subnets, then I am basically not on the same page. And not in the same decade. > > However, your question seems to imply you think there may be a limit: > AUTOCONF network is small enough to accommodate host-based routes. Is > it this? I think the network has to accomodate the routes needed for connectivity to destinations within the network. Again, just saying "subnet" doesn't buy even one gram of additional scalability. You need more. You need a procedure for enabling aggregation. Such a procedure is not always available. > >> >> Well, to me it did sound very negative. Moreover, I think it is just >> fine to pass around subnet prefixes, if you have subnets. > > Charles, yes - the subnets are there first, before IP. Once the link is > up the subnet is the set of nodes on it. In this sense I agree it is > just fine to pass subnet prefixes around. This is wrong*2. First, there is IP, which fixes the address format and address modes. Then there are subnets. Some people here probably remember when the word "subnet" starting coming into more active use. Second, just because nodes are reachable over the air as neighbors, does not imply they are on the same IP subnet. Trying to maintain otherwise leads to madness. Surely you will agree. A subnet is an abstraction to support more efficient routing. It is not a wire or a piece of plastic or a contiguous region of space. Regards, Charlie P. From teco@inf-net.nl Tue Mar 3 15:24:45 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44A093A6908 for ; Tue, 3 Mar 2009 15:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.317 X-Spam-Level: X-Spam-Status: No, score=-1.317 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=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 JmC4ZUYy5-98 for ; Tue, 3 Mar 2009 15:24:44 -0800 (PST) Received: from cpsmtpo-eml04.kpnxchange.com (cpsmtpo-eml04.KPNXCHANGE.COM [213.75.38.153]) by core3.amsl.com (Postfix) with ESMTP id EA8F43A67E9 for ; Tue, 3 Mar 2009 15:24:43 -0800 (PST) Received: from cpsmtp-eml109.kpnxchange.com ([10.94.168.109]) by cpsmtpo-eml04.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 00:25:10 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml109.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 00:25:10 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl> <49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl> <49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl> <49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl> <49AD9760.3080909@gmail.com> In-Reply-To: <49AD9760.3080909@gmail.com> Date: Wed, 4 Mar 2009 00:25:10 +0100 Message-ID: <000d01c99c57$4c276db0$e4764910$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmcQUpKj5z7VM3RRZqIo24z+bHJJQAEHBYg Content-Language: nl X-OriginalArrivalTime: 03 Mar 2009 23:25:10.0372 (UTC) FILETIME=[4BBFD240:01C99C57] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Tue, 03 Mar 2009 23:24:45 -0000 Hi Alex, We shall distinguish two subjects here: - Prefix assigned to MANET Interface or Loopback Interface - Usage of host prefix (/128 or /32 for IPv4). I'll respond on host prefixes only. I fully agree on minimizing overhead. All proposals I have done try to realize this target.=20 One of the mechanisms would be assigning a summary to a "mobile object", e.g. a /60 summary for 16 /64 subnets. The router(s) in this "mobile = object" would only need to advertize the /60 prefix, nothing more. Some routers support such a feature for a subset of the routing protocols, but most = will advertize all prefixes assigned to all (up) interfaces.=20 I think for a MANET Routing Protocol, this summarization attribute is = almost mandatory (a SHOULD). I'll post this again on MANET when we discuss NHDP = / OLSR. A loopback interface could have a /128 out of this address block. Using a /64 is OK also, but against guidelines for this. Before a MANET Router has assigned such a summary prefix, it could act = as a router with LL addresses only and start exchanging routing messages. = Now, the router learns topology. It could be a requirement for the routing protocol to use a unique identifier, e.g. an IPv4 address like what is = being used in OSPF (including OSPF-MANET). Maybe we need in MANET a 64-bit or 128-bit router-ID for randomly generated and unique IDs. So one of our topics: what is (are) the unique IDs for the router, used by the MANET Routing Protocol? Also, if the router is MR (NEMO), it requires a globally unique address = to reach HA. This address is the only address that is required to = distribute in the MANET. Other prefix lengths are allowed, but of no help. So it = doesn't help scalability. I still do not understand your concerns on using /128. Teco. PS. I think the /128 is mainly to be used for bootstrapping, for reaching a = DHCP server. Then, the router allocates a summary prefix. The summaries = should be optimized for MANET efficiency, e.g. address compression by RFC5444. = Using a self generated /64 (or shorter) ULA prefix is another option, but here = we might need more advanced duplicate detection mechanisms. |-----Oorspronkelijk bericht----- |Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] |Verzonden: dinsdag 3 maart 2009 21:47 |Aan: Teco Boot |CC: autoconf@ietf.org |Onderwerp: Re: Autoconf addressing model | |Teco, the problem is simple: host-based routes are not preferrable. | |Host-based routes in routers surrounding router X (this is what a /128 |address on a virtual interface on router X implies, be that loopback |interface or not loopback interface) for a dynamically changing = topology |may lead to too many routes coming up and down, too many specific |entries in the routing tables, too much dedicated routing messaging, = and |more. | |That only for the network itself. | |Connecting it to the Internet, with host-based routes propagated up and |down throughout, may risk influencing the routes in the Internet = proper. | A new host-based route inserted in the routing table of the gateway |connecting this network to the Internet may propagate throughout the |entire fixed access system. | |If you told me which part of the above were unclear I could explain |further. But I think there's large agreement on it. | |About the feasibility of _one_ /128 address on 'lo' while using _one_ |host-based route: as you pointed out with the ios-linux example, I = fully |agree a /128 address assigned on the 'lo' interface of one computer, = and |a host-based route in the other computer towards that /128 address - |will work. But just one. | |About posting to v6ops: which part do you think I should post there? | |About singling me out being the first and only mentioning some problem: |I can only be happy about it and stop posting :-) But this host-based |route stuff is not new, I'm myself surprised I'm singled out about it. | |Alex | |Teco Boot a =E9crit : |> Hi Alex, |> |> As far as I know, you are the first person that came up with problems |> using a loopback interface for globally unique addresses / host |> prefixes (/128, /32) for routers. Please provide good argumentation, |> otherwise we follow the already accepted practice in the routing |> community, also documented in RFC5375 (and others, e.g. RFC3484). |> |> Maybe you should post this in v6ops, not in Autoconf. |> |> Teco. |> |> |> |> From charles.perkins@earthlink.net Tue Mar 3 15:26:55 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B5823A6968 for ; Tue, 3 Mar 2009 15:26:55 -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 XX8b1p4o8Oae for ; Tue, 3 Mar 2009 15:26:54 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 2F5283A67E9 for ; Tue, 3 Mar 2009 15:26:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Qh1NrCqEdQ3s47DkaKlggsUZQG9z3FqbsMt7Qsvb9eN+/M4ulr7XDAaGkUk/zOvn; 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.104]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Lee1A-0007rV-V6; Tue, 03 Mar 2009 18:27:21 -0500 Message-ID: <49ADBCD8.9040301@earthlink.net> Date: Tue, 03 Mar 2009 15:27:20 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Teco Boot References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl> <49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl> <49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl> <49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl> <49AD90D9.5040100@earthlink.net> <000c01c99c4f$d1ab1750$750145f0$@nl> In-Reply-To: <000c01c99c4f$d1ab1750$750145f0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f523073ddb5abed83b1af65e0939b10933d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.138.86.46 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Tue, 03 Mar 2009 23:26:55 -0000 Hello Teco, You raise interesting questions, but I think mostly not definitive for the questions at hand. I don't know if I have any good answers, but here are some comments. Teco Boot wrote: > As long as I designed and maintained network infrastructures, I worked with > "/32 management addresses" on loopback interfaces. Still, I have annoying > experiences with routers that select the outgoing interface address as > default source address. Shutting down an interface could have unintended bad > impact on your terminal session. Same for link flapping due to other causes. > I guess this is relevant for packet forwarders with more than one network interface. For our little wireless nodes that have a single interface, I don't imagine we'd see that kind of interface aggravation. > For this reason, many routers on the Internet use the loopback interface for > "management". "Management" is the host application on routers. There are > lots of design guidelines for this. My proposal is using the "Internet > lessons learned" in the MANET. Nothing wrong with this, agreed? > I know only a small bit about this. Do you have a favorite document that I could read to learn more? > > With MobileIP, we are discussing a host (could be NEMO Router, but then it > acts as host on the visiting link). The MobileIP stack is interested in the > status of the visiting link, but does it propagate this to the applications? > Or use the applications some kind of virtual interface (e.g. a loopback > interface)? Or spoof ifup for interface to home link? > Whether or not applications have access to link information is something not closely related to Mobile IP. Whether or not the care-of address is available to applications is a surprisingly complicated question, which in my opinion opens the door to many interesting questions and indicates the insufficiency of today's typical application socket interface. I've had a lot of ideas about how to fix this, but never been able to initiate a project to supply a finished proposal. Regards, Charlie P. From teco@inf-net.nl Tue Mar 3 15:56:45 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 748213A6959 for ; Tue, 3 Mar 2009 15:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[AWL=0.424, 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 Kcvixu4h7n8m for ; Tue, 3 Mar 2009 15:56:39 -0800 (PST) Received: from hpsmtp-eml16.kpnxchange.com (hpsmtp-eml16.KPNXCHANGE.COM [213.75.38.116]) by core3.amsl.com (Postfix) with ESMTP id 53F083A6AB6 for ; Tue, 3 Mar 2009 15:56:38 -0800 (PST) Received: from cpsmtp-eml103.kpnxchange.com ([213.75.84.103]) by hpsmtp-eml16.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 00:57:05 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml103.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 00:57:04 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl> <49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl> <49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl> <49AD5184.6080300@gmail.com> <000b01c99c48$3a34ffa0$ae9efee0$@nl> <49ADB1CC.4000704@gmail.com> In-Reply-To: <49ADB1CC.4000704@gmail.com> Date: Wed, 4 Mar 2009 00:57:05 +0100 Message-ID: <000e01c99c5b$c16e2d30$444a8790$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmcUQqL/q/Tw3AFSP+QVKsjATyB5gABuWTQ Content-Language: nl X-OriginalArrivalTime: 03 Mar 2009 23:57:04.0914 (UTC) FILETIME=[C0E7BF20:01C99C5B] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Tue, 03 Mar 2009 23:56:45 -0000 I'll think more on Internet access. The diagrams were meant for MANET = intra topology. I would not use private addresses for this. For IPv4, all link addresses could be LL also (169.254.0.0/16).=20 On names in the tables: assume (m)DNS, with A, B and C resolved by it. = OK? On metrics / costs, pick the term you like. I am assuming nothing, I use = the term metric where others use cost (or mixed usage, as below in the = diagrams / text). Sample below uses metric where I would use hopcount.=20 I just play a bit with some protocols on some platforms. Here a (part = off a) routing table snapshot from one of the toys (OLSRv1 adjusted with ETX = and Link Costs): OLSR Routes in Kernel Destination Gateway Metric Cost Interface 10.128.12.0/24 169.254.1.12 1 725.000 ath0 10.128.13.0/24 169.254.1.13 1 630.303 ath0 10.128.14.0/24 169.254.1.14 1 622.727 ath0 10.128.15.0/24 169.254.1.15 1 671.429 ath0 10.128.16.0/24 169.254.1.16 1 973.594 ath0 10.128.17.0/24 169.254.1.17 1 749.285 ath0 10.128.18.0/24 169.254.1.18 1 766.667 ath0 10.128.19.0/24 169.254.1.19 1 663.244 ath0 10.128.20.0/24 169.254.1.20 1 958.831 ath0 10.128.21.0/24 169.254.1.16 2 1853.594 ath0 10.128.22.0/24 169.254.1.16 2 1754.594 ath0 10.128.23.0/24 169.254.1.16 2 1836.594 ath0 10.128.24.0/24 169.254.1.16 2 1662.594 ath0 10.128.25.0/24 169.254.1.16 2 1939.594 ath0 10.128.26.0/24 169.254.1.26 1 637.633 ath0 10.128.27.0/24 169.254.1.27 1 629.622 ath0 10.128.28.0/24 169.254.1.28 1 710.918 ath0 10.128.29.0/24 169.254.1.29 1 737.511 ath0 10.128.30.0/24 169.254.1.30 1 817.725 ath0 Metrics and cost do not have a need to be "published" in the kernel RT. On this toy, LL are multihop reachable (bad behavior !!): 169.254.1.21 169.254.1.16 2 1853.594 ath0 169.254.1.22 169.254.1.16 2 1754.594 ath0 Teco. |-----Oorspronkelijk bericht----- |Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] |Verzonden: dinsdag 3 maart 2009 23:40 |Aan: Teco Boot |CC: autoconf@ietf.org |Onderwerp: Re: Autoconf addressing model | |Teco, I'm happy you updated the obstacles scenario. That's important |insight on what movement may actually be. | |I'd go further include default routes in the tables, and specific |addresses like 10.1.1.1/32 instead of A, and subnet prefixes = 10.1.1.0/24 |for example. | |Sorry just asking about this: the Cost in the routing tables. The |kernel routing tables don't have variable Cost, they're all metric 1 I |believe (all next-hops are 1-hop away). The routing protocols' tables |may have Cost and other variables. | |Did you assume a routing protocol? | |My preference is to not assume any routing protocol. | |Alex | |Teco Boot a =E9crit : |> Hi Alex, |> |> I included wrong routing table info in the "obstacles" scenarios. |> Here a full set of diagrams with routing table info. |> |> I removed "STA-", now the model applies to non-802.11 topologies as |well. |> |> Teco. |> |> |> |> |> 1. MANET topology with moving and blocking obstacle |> |> +------------------------+ +------------------------+ |> | | | | |> | ______B | | ______B | |> | ___/ | | | ___/ | |> | A | | | A OBSTACLE | |> | '--_ | | | '--_ | |> | '------C | | '------C | |> | OBSTACLE | | | |> +------------------------+ +------------------------+ |> 1-1: Full connected 1-2: B-C via A |> |> +------------------------+ +------------------------+ |> | | | O | |> | ______B | | B B | |> | ___/ | | | S | | |> | A OB | | | A T | | |> | ST | | | A | | |> | AC C | | C C | |> | LE | | L | |> | | | E | |> +------------------------+ +------------------------+ |> 1-3: A-C via B 1-4: A-B and A-C blocked |> |> |> The routing tables for the MANET Routers look as follows: |> |> ROUTER DEST NEXTHOP COST ROUTER DEST NEXTHOP COST |> +-------+-------+-------+----+ +-------+-------+-------+----+ |> | A | B | B | 1 | | A | B | B | 1 | |> | | C | C | 1 | | | C | C | 1 | |> +-------+-------+-------+----+ +-------+-------+-------+----+ |> | B | A | A | 1 | | B | A | A | 1 | |> | | C | C | 1 | | | C | A | 2 | |> +-------+-------+-------+----+ +-------+-------+-------+----+ |> | C | A | A | 1 | | C | A | A | 1 | |> | | B | B | 1 | | | B | B | 2 | |> +-------+-------+-------+----+ +-------+-------+-------+----+ |> 1-1: All single hop 1-2: B-C degraded |> |> +-------+-------+-------+----+ +-------+-------+-------+----+ |> | A | B | B | 1 | | A | | | | |> | | C | B | 2 | | | | | | |> +-------+-------+-------+----+ +-------+-------+-------+----+ |> | B | A | A | 1 | | B | | | | |> | | C | C | 1 | | | C | C | 1 | |> +-------+-------+-------+----+ +-------+-------+-------+----+ |> | C | A | B | 2 | | C | | | | |> | | B | B | 1 | | | B | B | 1 | |> +-------+-------+-------+----+ +-------+-------+-------+----+ |> 1-3: A-C degraded 1-4: A-B and A-C blocked |> |> |> |> 2. MANET topology with moving and degrading obstacle |> |> In these scenarios, link metrics are introduced. |> |> +------------------------+ +------------------------+ |> | | | | |> | _______B | | ______B | |> | __/ 1 | | | __/ 1 . | |> | A | 1 | | A obstacle | |> | '--_ 1 | | | '--_ 1 . 5 | |> | '------C | | '------C | |> | obstacle | | | |> +------------------------+ +------------------------+ |> 2-1: No hindrance 2-2: B-C degraded |> |> +------------------------+ +------------------------+ |> | | | o | |> | ______B | | 5 b .....B | |> | ___/ 1 | | | ...s. | | |> | A ob | 1 | | A t | 1 | |> | ... st | | | ...a. | | |> | 5 .ac.... C | | 5 c .....C | |> | le | | l | |> | | | e | |> +------------------------+ +------------------------+ |> 2-3: A-C degraded 2-4: A-B and A-C degraded |> |> |> The routing tables: |> |> ROUTER DEST NEXTHOP COST ROUTER DEST NEXTHOP COST |> +-------+-------+-------+----+ +-------+-------+-------+----+ |> | A | B | B | 1 | | A | B | B | 1 | |> | | C | C | 1 | | | C | C | 1 | |> +-------+-------+-------+----+ +-------+-------+-------+----+ |> | B | A | A | 1 | | B | A | A | 1 | |> | | C | C | 1 | | | C | A | 2 | |> +-------+-------+-------+----+ +-------+-------+-------+----+ |> | C | A | A | 1 | | C | A | A | 1 | |> | | B | B | 1 | | | B | A | 2 | |> +-------+-------+-------+----+ +-------+-------+-------+----+ |> 2-1: No hindrance 2-2: B-C degraded |> |> +-------+-------+-------+----+ +-------+-------+-------+----+ |> | A | B | B | 1 | | A | B | B | 5 | |> | | C | B | 2 | | | C | C | 5 | |> +-------+-------+-------+----+ +-------+-------+-------+----+ |> | B | A | A | 1 | | B | A | A | 5 | |> | | C | C | 1 | | | C | C | 1 | |> +-------+-------+-------+----+ +-------+-------+-------+----+ |> | C | A | B | 2 | | C | A | A | 5 | |> | | B | B | 1 | | | B | B | 1 | |> +-------+-------+-------+----+ +-------+-------+-------+----+ |> 2-3: A-C degraded 2-4: A-B and A-C degraded |> |> In this scenario, the most optimal paths are used, a 2-hop path |with |> metric 2 is used instead of a single hop path with metric 5. |> |> |> |> 3. MANET topology with degrading obstacle and noise |> |> In this scenario, C can hear A through an obstacle as scenario 2- |3, |> but A reception of B and C is affected by high level "NOISE" = (3.1) |> or low level "noise" (3-2). With high level noise, A cannot hear = C |and |> the link is "uni-directional". |> |> Term "asymmetric" is used to indicate unbalanced metrics for the |> direction |> of traffic between two nodes. In other documents, "asymmetric" is |used |> for |> what is called "uni-directional" here. |> |> |> +------------------------+ +------------------------+ |> | | | | |> | ____1_B | | ____1_B | |> | 3__/ | | | 2__/ | | |> | A ob | 1 | | A ob | 1 | |> | NOISE st | | | noise ... st | | |> | x.ac.>..C | | 10 .ac....C | |> | le | | le 5 | |> +------------------------+ +------------------------+ |> 3-1: A-C uni-directional 3-2: A-C & B-C asymmetric |> A-B asymmetric |> |> |> ROUTER DEST NEXTHOP METRIC ROUTER DEST NEXTHOP = METRIC |> +-------+-------+-------+------+ = +-------+-------+-------+------ |+ |> | A | B | B | 3 | | A | B | B | 2 || |> | | C | B | 4 | | | C | B | 3 || |> +-------+-------+-------+------+ = +-------+-------+-------+------ |+ |> | B | A | A | 1 | | B | A | A | 1 || |> | | C | C | 1 | | | C | C | 1 || |> +-------+-------+-------+------+ = +-------+-------+-------+------ |+ |> | C | A | B | 2 | | C | A | B | 2 || |> | | B | B | 1 | | | B | B | 1 || |> +-------+-------+-------+------+ = +-------+-------+-------+------ |+ |> 3-1: A-C uni-directional 3-2: A-C & B-C asymmetric |> A-B asymmetric |> |> When the noise level near station A is intermitting between high |and low |> levels, this does not influence the routing topology, as the MANET |> protocol |> has selected path A-B-C between the routers A and C, because = better |> metrics |> and bidirectional validation. |> The MANET Routing Protocol checks directionality of links before |using |> these. |> |> |> |> |> From alexandru.petrescu@gmail.com Wed Mar 4 00:22:04 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EC7628C2BC for ; Wed, 4 Mar 2009 00:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.150, 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 vF9Xy-fCSW4Q for ; Wed, 4 Mar 2009 00:22:03 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id D301828C184 for ; Wed, 4 Mar 2009 00:22:01 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id A8C6FD480DE; Wed, 4 Mar 2009 09:22:25 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 77798D48135; Wed, 4 Mar 2009 09:22:22 +0100 (CET) Message-ID: <49AE3A3A.5000305@gmail.com> Date: Wed, 04 Mar 2009 09:22:18 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Charles E. Perkins" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl> <49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl> <49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl> <49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl> <49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net> <49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net> <49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net> In-Reply-To: <49ADB9FB.6050600@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090303-2, 04/03/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Wed, 04 Mar 2009 08:22:04 -0000 Charles E. Perkins a écrit : >>> That's fine, as long as the destination is addressable within a >>> subnet. If the destination does not live on a subnet, why not >>> use a host route (i.e., /128 address)? >> >> Because it wouldn't allow the AUTOCONF network to grow larger and >> more dynamic. > > Just saying "subnet" doesn't do that either, though. In fact, the > signaling to support subnets could (conceivably) be even more > complicated than the signaling to support host routes. I agree link-layer signalling within each subnet, for the purpose of maintaining that subnet coherent, may contain numerous messages. >>>> -I would avoid the assumption that an ad-hoc router maintains a >>>> stable IP address while moving around. >>> >>> Then you will have trouble. There is no free lunch. Either: (a) >>> the IP address stays the same, and the routes change, or (b) the >>> IP address changes, and there is a resolver to associate the IP >>> address with some other identifier. >>> >>> Since the design of the resolver in (b) is an unknown and >>> arguably much more difficult, I'll take (a) with a great sigh of >>> relief. >> >> Resolvers such as (m)DNS or some DHCP features could work I >> believe. I don't understand why it's claimed much more difficult. > > I assure you it is not trivial to implement DNS or DHCP inside an ad > hoc network. Most of the proposals I have seen for this have located > the function _outside_ the ad hoc network, for convenient and > straightforward access when connectivity is actually available. Well if the subnet structure is coherent and things don't move around too much then putting a DNS Server or a DHCP Server in the ad-hoc network should be easy. By not moving too much I mean each node not moving out of its 25meter radius. > Watching your DNS server [(m) or not!] move from place to place in an > ad hoc network, sometimes finding itself partitioned from your > favorite node, could be an exciting and enlightening adventure. I agree we could find very dynamic ways of Routers and Hosts of an ad-hoc network moving in and out such that subnet structure is not maintained, and thus servers not being reachable. But unless we describe these movements we can't deal with them. >>> Who said we had to avoid size limits? >> >> Well we don't have size limits in the charter proposal, we don't >> have agreement on '25m IPv6 subnets', we don't have limits on the >> types of the link layers involved. > > If you are talking about an ad hoc network with 25,000,000 subnets, > then I am basically not on the same page. And not in the same > decade. Sorry I meant 25meters not millions. A '25m IPv6 subnet' would be a wireless coverage area of radius 25meter, without obstacles, and within which there are only exposed terminals, fully transitive and symmetric communications. Would you agree such a subnet makes sense? Does not make sense? >> However, your question seems to imply you think there may be a >> limit: AUTOCONF network is small enough to accommodate host-based >> routes. Is it this? > > I think the network has to accomodate the routes needed for > connectivity to destinations within the network. > > Again, just saying "subnet" doesn't buy even one gram of additional > scalability. You need more. > > You need a procedure for enabling aggregation. Such a procedure is > not always available. If by aggregation is meant addressing aggregation (as Teco also proposes a /60 prefix assigned to several Routers themselves assigning /64 prefixes to their links) then I think we should not strive to respect aggregation. Address aggregation wouldn't make sense if we talk host-based routes either. >>> Well, to me it did sound very negative. Moreover, I think it is >>> just fine to pass around subnet prefixes, if you have subnets. >> >> Charles, yes - the subnets are there first, before IP. Once the >> link is up the subnet is the set of nodes on it. In this sense I >> agree it is just fine to pass subnet prefixes around. > > This is wrong*2. First, there is IP, which fixes the address format > and address modes. Then there are subnets. Some people here > probably remember when the word "subnet" starting coming into more > active use. > > > Second, just because nodes are reachable over the air as neighbors, > does not imply they are on the same IP subnet. Trying to maintain > otherwise leads to madness. > > Surely you will agree. A subnet is an abstraction to support more > efficient routing. It is not a wire or a piece of plastic or a > contiguous region of space. I can live with that. However, I think the simplest cases we have to deal with have very simple subnet structure that we should take advantage of. Alex From alexandru.petrescu@gmail.com Wed Mar 4 02:13:55 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64BBD3A6AA4 for ; Wed, 4 Mar 2009 02:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=0.078, 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 M4xO3WRRjSxC for ; Wed, 4 Mar 2009 02:13:54 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 879533A689E for ; Wed, 4 Mar 2009 02:12:48 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n24ADGwb004766; Wed, 4 Mar 2009 11:13:16 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n24ADFZQ001055; Wed, 4 Mar 2009 11:13:15 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n24ADEcQ027188; Wed, 4 Mar 2009 11:13:15 +0100 Message-ID: <49AE543A.8020602@gmail.com> Date: Wed, 04 Mar 2009 11:13:14 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Teco Boot References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl> <49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl> <49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl> <49AD5184.6080300@gmail.com> <000b01c99c48$3a34ffa0$ae9efee0$@nl> <49ADB1CC.4000704@gmail.com> <000e01c99c5b$c16e2d30$444a8790$@nl> In-Reply-To: <000e01c99c5b$c16e2d30$444a8790$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Wed, 04 Mar 2009 10:13:55 -0000 Teco Boot a écrit : > I'll think more on Internet access. Teco, when I mentioned default routes I didn't think Internet access. I think default routes are good for networks disconnected from the Internet too. > The diagrams were meant for MANET intra topology. I would not use > private addresses for this. For IPv4, all link addresses could be LL > also (169.254.0.0/16). YEs, I think for IPv4 the LL addresses could be 169.254. > On names in the tables: assume (m)DNS, with A, B and C resolved by it. OK? Ok if you wish so, with the caveat that DNS does not hold their prefix lengths whereas the routing tables do and the prefix lengths are important in the hits. > On metrics / costs, pick the term you like. I am assuming nothing, I use the > term metric where others use cost (or mixed usage, as below in the diagrams > / text). Sample below uses metric where I would use hopcount. > > I just play a bit with some protocols on some platforms. Here a (part off a) > routing table snapshot from one of the toys (OLSRv1 adjusted with ETX and > Link Costs): > > OLSR Routes in Kernel Is this the kernel routing table? Or OLSR's routing table? I believe it's OLSR, not vanilla kernel, because there are two fields 'Metric' and 'Cost' whereas the vanilla kernel only has 'Metric'. > Destination Gateway Metric Cost Interface > 10.128.12.0/24 169.254.1.12 1 725.000 ath0 > 10.128.13.0/24 169.254.1.13 1 630.303 ath0 > 10.128.14.0/24 169.254.1.14 1 622.727 ath0 > 10.128.15.0/24 169.254.1.15 1 671.429 ath0 > 10.128.16.0/24 169.254.1.16 1 973.594 ath0 > 10.128.17.0/24 169.254.1.17 1 749.285 ath0 > 10.128.18.0/24 169.254.1.18 1 766.667 ath0 > 10.128.19.0/24 169.254.1.19 1 663.244 ath0 > 10.128.20.0/24 169.254.1.20 1 958.831 ath0 > 10.128.21.0/24 169.254.1.16 2 1853.594 ath0 > 10.128.22.0/24 169.254.1.16 2 1754.594 ath0 > 10.128.23.0/24 169.254.1.16 2 1836.594 ath0 > 10.128.24.0/24 169.254.1.16 2 1662.594 ath0 > 10.128.25.0/24 169.254.1.16 2 1939.594 ath0 > 10.128.26.0/24 169.254.1.26 1 637.633 ath0 > 10.128.27.0/24 169.254.1.27 1 629.622 ath0 > 10.128.28.0/24 169.254.1.28 1 710.918 ath0 > 10.128.29.0/24 169.254.1.29 1 737.511 ath0 > 10.128.30.0/24 169.254.1.30 1 817.725 ath0 For my clarification: this table doesn't contain host-based routes, we agree. Also: are all the addresses 169.254.1.12-30 neighbors of the ath0 interface? What is/are the addresses assigned on ath0 of this node? What is the subnet address of the subnet on which ath0 is connected? If we have that then I could picture the topoology you're using, and draw subnet addresses and routing tables. > Metrics and cost do not have a need to be "published" in the kernel RT. > > On this toy, LL are multihop reachable (bad behavior !!): > > 169.254.1.21 169.254.1.16 2 1853.594 ath0 > 169.254.1.22 169.254.1.16 2 1754.594 ath0 Right! (LL addresses should be neighbors, not Metric 2.) Thanks for the routing table dump. Alex > > Teco. > > > > |-----Oorspronkelijk bericht----- > |Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > |Verzonden: dinsdag 3 maart 2009 23:40 > |Aan: Teco Boot > |CC: autoconf@ietf.org > |Onderwerp: Re: Autoconf addressing model > | > |Teco, I'm happy you updated the obstacles scenario. That's important > |insight on what movement may actually be. > | > |I'd go further include default routes in the tables, and specific > |addresses like 10.1.1.1/32 instead of A, and subnet prefixes 10.1.1.0/24 > |for example. > | > |Sorry just asking about this: the Cost in the routing tables. The > |kernel routing tables don't have variable Cost, they're all metric 1 I > |believe (all next-hops are 1-hop away). The routing protocols' tables > |may have Cost and other variables. > | > |Did you assume a routing protocol? > | > |My preference is to not assume any routing protocol. > | > |Alex > | > |Teco Boot a écrit : > |> Hi Alex, > |> > |> I included wrong routing table info in the "obstacles" scenarios. > |> Here a full set of diagrams with routing table info. > |> > |> I removed "STA-", now the model applies to non-802.11 topologies as > |well. > |> > |> Teco. > |> > |> > |> > |> > |> 1. MANET topology with moving and blocking obstacle > |> > |> +------------------------+ +------------------------+ > |> | | | | > |> | ______B | | ______B | > |> | ___/ | | | ___/ | > |> | A | | | A OBSTACLE | > |> | '--_ | | | '--_ | > |> | '------C | | '------C | > |> | OBSTACLE | | | > |> +------------------------+ +------------------------+ > |> 1-1: Full connected 1-2: B-C via A > |> > |> +------------------------+ +------------------------+ > |> | | | O | > |> | ______B | | B B | > |> | ___/ | | | S | | > |> | A OB | | | A T | | > |> | ST | | | A | | > |> | AC C | | C C | > |> | LE | | L | > |> | | | E | > |> +------------------------+ +------------------------+ > |> 1-3: A-C via B 1-4: A-B and A-C blocked > |> > |> > |> The routing tables for the MANET Routers look as follows: > |> > |> ROUTER DEST NEXTHOP COST ROUTER DEST NEXTHOP COST > |> +-------+-------+-------+----+ +-------+-------+-------+----+ > |> | A | B | B | 1 | | A | B | B | 1 | > |> | | C | C | 1 | | | C | C | 1 | > |> +-------+-------+-------+----+ +-------+-------+-------+----+ > |> | B | A | A | 1 | | B | A | A | 1 | > |> | | C | C | 1 | | | C | A | 2 | > |> +-------+-------+-------+----+ +-------+-------+-------+----+ > |> | C | A | A | 1 | | C | A | A | 1 | > |> | | B | B | 1 | | | B | B | 2 | > |> +-------+-------+-------+----+ +-------+-------+-------+----+ > |> 1-1: All single hop 1-2: B-C degraded > |> > |> +-------+-------+-------+----+ +-------+-------+-------+----+ > |> | A | B | B | 1 | | A | | | | > |> | | C | B | 2 | | | | | | > |> +-------+-------+-------+----+ +-------+-------+-------+----+ > |> | B | A | A | 1 | | B | | | | > |> | | C | C | 1 | | | C | C | 1 | > |> +-------+-------+-------+----+ +-------+-------+-------+----+ > |> | C | A | B | 2 | | C | | | | > |> | | B | B | 1 | | | B | B | 1 | > |> +-------+-------+-------+----+ +-------+-------+-------+----+ > |> 1-3: A-C degraded 1-4: A-B and A-C blocked > |> > |> > |> > |> 2. MANET topology with moving and degrading obstacle > |> > |> In these scenarios, link metrics are introduced. > |> > |> +------------------------+ +------------------------+ > |> | | | | > |> | _______B | | ______B | > |> | __/ 1 | | | __/ 1 . | > |> | A | 1 | | A obstacle | > |> | '--_ 1 | | | '--_ 1 . 5 | > |> | '------C | | '------C | > |> | obstacle | | | > |> +------------------------+ +------------------------+ > |> 2-1: No hindrance 2-2: B-C degraded > |> > |> +------------------------+ +------------------------+ > |> | | | o | > |> | ______B | | 5 b .....B | > |> | ___/ 1 | | | ...s. | | > |> | A ob | 1 | | A t | 1 | > |> | ... st | | | ...a. | | > |> | 5 .ac.... C | | 5 c .....C | > |> | le | | l | > |> | | | e | > |> +------------------------+ +------------------------+ > |> 2-3: A-C degraded 2-4: A-B and A-C degraded > |> > |> > |> The routing tables: > |> > |> ROUTER DEST NEXTHOP COST ROUTER DEST NEXTHOP COST > |> +-------+-------+-------+----+ +-------+-------+-------+----+ > |> | A | B | B | 1 | | A | B | B | 1 | > |> | | C | C | 1 | | | C | C | 1 | > |> +-------+-------+-------+----+ +-------+-------+-------+----+ > |> | B | A | A | 1 | | B | A | A | 1 | > |> | | C | C | 1 | | | C | A | 2 | > |> +-------+-------+-------+----+ +-------+-------+-------+----+ > |> | C | A | A | 1 | | C | A | A | 1 | > |> | | B | B | 1 | | | B | A | 2 | > |> +-------+-------+-------+----+ +-------+-------+-------+----+ > |> 2-1: No hindrance 2-2: B-C degraded > |> > |> +-------+-------+-------+----+ +-------+-------+-------+----+ > |> | A | B | B | 1 | | A | B | B | 5 | > |> | | C | B | 2 | | | C | C | 5 | > |> +-------+-------+-------+----+ +-------+-------+-------+----+ > |> | B | A | A | 1 | | B | A | A | 5 | > |> | | C | C | 1 | | | C | C | 1 | > |> +-------+-------+-------+----+ +-------+-------+-------+----+ > |> | C | A | B | 2 | | C | A | A | 5 | > |> | | B | B | 1 | | | B | B | 1 | > |> +-------+-------+-------+----+ +-------+-------+-------+----+ > |> 2-3: A-C degraded 2-4: A-B and A-C degraded > |> > |> In this scenario, the most optimal paths are used, a 2-hop path > |with > |> metric 2 is used instead of a single hop path with metric 5. > |> > |> > |> > |> 3. MANET topology with degrading obstacle and noise > |> > |> In this scenario, C can hear A through an obstacle as scenario 2- > |3, > |> but A reception of B and C is affected by high level "NOISE" (3.1) > |> or low level "noise" (3-2). With high level noise, A cannot hear C > |and > |> the link is "uni-directional". > |> > |> Term "asymmetric" is used to indicate unbalanced metrics for the > |> direction > |> of traffic between two nodes. In other documents, "asymmetric" is > |used > |> for > |> what is called "uni-directional" here. > |> > |> > |> +------------------------+ +------------------------+ > |> | | | | > |> | ____1_B | | ____1_B | > |> | 3__/ | | | 2__/ | | > |> | A ob | 1 | | A ob | 1 | > |> | NOISE st | | | noise ... st | | > |> | x.ac.>..C | | 10 .ac....C | > |> | le | | le 5 | > |> +------------------------+ +------------------------+ > |> 3-1: A-C uni-directional 3-2: A-C & B-C asymmetric > |> A-B asymmetric > |> > |> > |> ROUTER DEST NEXTHOP METRIC ROUTER DEST NEXTHOP METRIC > |> +-------+-------+-------+------+ +-------+-------+-------+------ > |+ > |> | A | B | B | 3 | | A | B | B | 2 > || > |> | | C | B | 4 | | | C | B | 3 > || > |> +-------+-------+-------+------+ +-------+-------+-------+------ > |+ > |> | B | A | A | 1 | | B | A | A | 1 > || > |> | | C | C | 1 | | | C | C | 1 > || > |> +-------+-------+-------+------+ +-------+-------+-------+------ > |+ > |> | C | A | B | 2 | | C | A | B | 2 > || > |> | | B | B | 1 | | | B | B | 1 > || > |> +-------+-------+-------+------+ +-------+-------+-------+------ > |+ > |> 3-1: A-C uni-directional 3-2: A-C & B-C asymmetric > |> A-B asymmetric > |> > |> When the noise level near station A is intermitting between high > |and low > |> levels, this does not influence the routing topology, as the MANET > |> protocol > |> has selected path A-B-C between the routers A and C, because better > |> metrics > |> and bidirectional validation. > |> The MANET Routing Protocol checks directionality of links before > |using > |> these. > |> > |> > |> > |> > |> > > From sratliff@cisco.com Wed Mar 4 06:40:15 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79A123A68F6 for ; Wed, 4 Mar 2009 06:40:15 -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 HVDSJT+5CL1C for ; Wed, 4 Mar 2009 06:40:14 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E351B3A68AD for ; Wed, 4 Mar 2009 06:40:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,301,1233532800"; d="scan'208";a="38984837" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 04 Mar 2009 14:40:41 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n24EefEs014431; Wed, 4 Mar 2009 09:40:41 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n24EefDh023077; Wed, 4 Mar 2009 14:40:41 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); Wed, 4 Mar 2009 09:40:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Mar 2009 09:40:40 -0500 Message-ID: <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> In-Reply-To: <49AE3A3A.5000305@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Autoconf addressing model Thread-Index: Acmcol9Dy08x3ZdJSlOzpqBHCEjg3gAMpTAg References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com><000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com><1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl><49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl><49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl><49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl><49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl><49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net> <49AE3A3A.5000305@gmail.com> From: "Stan Ratliff (sratliff)" To: "Alexandru Petrescu" , "Charles E. Perkins" X-OriginalArrivalTime: 04 Mar 2009 14:40:41.0544 (UTC) FILETIME=[31477C80:01C99CD7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6787; t=1236177641; x=1237041641; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20=22Stan=20Ratliff=20(sratliff)=22=20 |Subject:=20RE=3A=20[Autoconf]=20Autoconf=20addressing=20mo del |Sender:=20 |To:=20=22Alexandru=20Petrescu=22=20,=0A=20=20=20=20=20=20=20=20=22Charles=20E.=20Perkins =22=20; bh=gHwWXwxieuAtwHGPW72ouFRl20kbW4ByIxr2Z+MJsE8=; b=PSiier/8j3P9xZ4nK2K73gwK1hBWX1hGBtfjGYC23NavD46XqX4c1cAAKz 3Nuc6+u97zTxl//UeoLcPmAhGZfL/1HfTMIAdd02KAJ+xeHk88OSj3Uh0Sbz /DgT5TUgCF; Authentication-Results: rtp-dkim-1; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Wed, 04 Mar 2009 14:40:15 -0000 Inline. =20 > -----Original Message----- > From: autoconf-bounces@ietf.org=20 > [mailto:autoconf-bounces@ietf.org] On Behalf Of Alexandru Petrescu > Sent: Wednesday, March 04, 2009 3:22 AM > To: Charles E. Perkins > Cc: autoconf@ietf.org > Subject: Re: [Autoconf] Autoconf addressing model >=20 > Charles E. Perkins a =E9crit : > >>> That's fine, as long as the destination is addressable within a=20 > >>> subnet. If the destination does not live on a subnet,=20 > why not use a=20 > >>> host route (i.e., /128 address)? > >>=20 > >> Because it wouldn't allow the AUTOCONF network to grow larger and=20 > >> more dynamic. > >=20 > > Just saying "subnet" doesn't do that either, though. In fact, the=20 > > signaling to support subnets could (conceivably) be even more=20 > > complicated than the signaling to support host routes. >=20 > I agree link-layer signalling within each subnet, for the=20 > purpose of maintaining that subnet coherent, may contain=20 > numerous messages. >=20 > >>>> -I would avoid the assumption that an ad-hoc router maintains a =20 > >>>> stable IP address while moving around. > >>>=20 > >>> Then you will have trouble. There is no free lunch.=20 > Either: (a) the=20 > >>> IP address stays the same, and the routes change, or (b) the IP=20 > >>> address changes, and there is a resolver to associate the=20 > IP address=20 > >>> with some other identifier. > >>>=20 > >>> Since the design of the resolver in (b) is an unknown and=20 > arguably=20 > >>> much more difficult, I'll take (a) with a great sigh of relief. > >>=20 > >> Resolvers such as (m)DNS or some DHCP features could work=20 > I believe. =20 > >> I don't understand why it's claimed much more difficult. > >=20 > > I assure you it is not trivial to implement DNS or DHCP=20 > inside an ad=20 > > hoc network. Most of the proposals I have seen for this=20 > have located =20 > > the function _outside_ the ad hoc network, for convenient and=20 > > straightforward access when connectivity is actually available. >=20 > Well if the subnet structure is coherent and things don't=20 > move around too much then putting a DNS Server or a DHCP=20 > Server in the ad-hoc network should be easy. >=20 > By not moving too much I mean each node not moving out of its=20 > 25meter radius. >=20 We've already been over the 25m subnet thing. It's a non-starter. = Limiting movement, or mandating that a DHCP or DNS server is always on = and available is also a non-starter. 25m subnets with "always on" = DNS/DHCP servers sounds to me like a few guys gathering together to play = "Doom" at their local coffee shop. I deploy MANET networks for = governmental applications. Think disaster recovery, like after Hurricane = Katrina, or the last round of wildfires in California. Do you think it = appropriate to tell the firefighters "you can't let the trucks get more = than 25m apart, or your network breaks"? Or, "if your DNS server should = fail, just forget what you're doing and go home"? So, once again, no -- 25m subnets don't make sense and won't work in the = environments where I'm deploying networks. Placing this type of = limitation on AUTOCONF will, IMO, make the work output useless. Stan =20 > > Watching your DNS server [(m) or not!] move from place to=20 > place in an =20 > > ad hoc network, sometimes finding itself partitioned from your=20 > > favorite node, could be an exciting and enlightening adventure. >=20 > I agree we could find very dynamic ways of Routers and Hosts=20 > of an ad-hoc network moving in and out such that subnet=20 > structure is not maintained, and thus servers not being=20 > reachable. But unless we describe these movements we can't=20 > deal with them. >=20 > >>> Who said we had to avoid size limits? > >>=20 > >> Well we don't have size limits in the charter proposal, we=20 > don't have=20 > >> agreement on '25m IPv6 subnets', we don't have limits on=20 > the types of=20 > >> the link layers involved. > >=20 > > If you are talking about an ad hoc network with 25,000,000 subnets,=20 > > then I am basically not on the same page. And not in the=20 > same decade. >=20 > Sorry I meant 25meters not millions. A '25m IPv6 subnet'=20 > would be a wireless coverage area of radius 25meter, without=20 > obstacles, and within which there are only exposed terminals,=20 > fully transitive and symmetric communications. >=20 > Would you agree such a subnet makes sense? Does not make sense? >=20 > >> However, your question seems to imply you think there may be a > >> limit: AUTOCONF network is small enough to accommodate host-based=20 > >> routes. Is it this? > >=20 > > I think the network has to accomodate the routes needed for=20 > > connectivity to destinations within the network. > >=20 > > Again, just saying "subnet" doesn't buy even one gram of additional=20 > > scalability. You need more. > >=20 > > You need a procedure for enabling aggregation. Such a=20 > procedure is not=20 > > always available. >=20 > If by aggregation is meant addressing aggregation (as Teco=20 > also proposes a /60 prefix assigned to several Routers=20 > themselves assigning > /64 prefixes to their links) then I think we should not=20 > strive to respect aggregation. Address aggregation wouldn't=20 > make sense if we talk host-based routes either. >=20 > >>> Well, to me it did sound very negative. Moreover, I think it is=20 > >>> just fine to pass around subnet prefixes, if you have subnets. > >>=20 > >> Charles, yes - the subnets are there first, before IP. =20 > Once the link=20 > >> is up the subnet is the set of nodes on it. In this sense=20 > I agree it=20 > >> is just fine to pass subnet prefixes around. > >=20 > > This is wrong*2. First, there is IP, which fixes the=20 > address format > > and address modes. Then there are subnets. Some people=20 > here probably=20 > > remember when the word "subnet" starting coming into more=20 > active use. > >=20 > >=20 > > Second, just because nodes are reachable over the air as neighbors,=20 > > does not imply they are on the same IP subnet. Trying to maintain=20 > > otherwise leads to madness. > >=20 > > Surely you will agree. A subnet is an abstraction to support more=20 > > efficient routing. It is not a wire or a piece of plastic or a=20 > > contiguous region of space. >=20 > I can live with that. >=20 > However, I think the simplest cases we have to deal with have=20 > very simple subnet structure that we should take advantage of. >=20 > Alex >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf >=20 From alexandru.petrescu@gmail.com Wed Mar 4 07:02:44 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 432E128C377 for ; Wed, 4 Mar 2009 07:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.077, 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 3IHNsit+5n2J for ; Wed, 4 Mar 2009 07:02:43 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 09A783A67C0 for ; Wed, 4 Mar 2009 07:02:39 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n24F1HCj001648; Wed, 4 Mar 2009 16:01:17 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n24F33Jk013115; Wed, 4 Mar 2009 16:03:03 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n24F33kq026938; Wed, 4 Mar 2009 16:03:03 +0100 Message-ID: <49AE9827.5090309@gmail.com> Date: Wed, 04 Mar 2009 16:03:03 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Stan Ratliff (sratliff)" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com><000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com><1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl><49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl><49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl><49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl><49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl><49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net> <49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> In-Reply-To: <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Wed, 04 Mar 2009 15:02:44 -0000 Stan Ratliff (sratliff) a écrit : [...] > We've already been over the 25m subnet thing. It's a non-starter. > Limiting movement, or mandating that a DHCP or DNS server is always > on and available is also a non-starter. 25m subnets with "always on" > DNS/DHCP servers sounds to me like a few guys gathering together to > play "Doom" at their local coffee shop. I deploy MANET networks for > governmental applications. Think disaster recovery, like after > Hurricane Katrina, or the last round of wildfires in California. Do > you think it appropriate to tell the firefighters "you can't let the > trucks get more than 25m apart, or your network breaks"? Or, "if your > DNS server should fail, just forget what you're doing and go home"? No, I don't think it appropriate. But I didn't mean to imply AUTOCONF networks span only 25meter range - they could be made of several such single subnets. > So, once again, no -- 25m subnets don't make sense and won't work in > the environments where I'm deploying networks. Placing this type of > limitation on AUTOCONF will, IMO, make the work output useless. How about a unit being a 25m subnet containing exposed terminals; and a network growing as a chain of such units, linked by routers. Would this make more sense? The disaster relief scenarios you describe also have certain limits of movements. For example: -firefighter never gets very far away from truck. -among all intervening trucks only some are designated as special, for example command and control. -etc. Expressing this inherent structure in terms of subnet structure can be very useful. Alex > > Stan > > >>> Watching your DNS server [(m) or not!] move from place to >> place in an >>> ad hoc network, sometimes finding itself partitioned from your >>> favorite node, could be an exciting and enlightening adventure. >> I agree we could find very dynamic ways of Routers and Hosts of an >> ad-hoc network moving in and out such that subnet structure is not >> maintained, and thus servers not being reachable. But unless we >> describe these movements we can't deal with them. >> >>>>> Who said we had to avoid size limits? >>>> Well we don't have size limits in the charter proposal, we >> don't have >>>> agreement on '25m IPv6 subnets', we don't have limits on >> the types of >>>> the link layers involved. >>> If you are talking about an ad hoc network with 25,000,000 >>> subnets, then I am basically not on the same page. And not in >>> the >> same decade. >> >> Sorry I meant 25meters not millions. A '25m IPv6 subnet' would be >> a wireless coverage area of radius 25meter, without obstacles, and >> within which there are only exposed terminals, fully transitive and >> symmetric communications. >> >> Would you agree such a subnet makes sense? Does not make sense? >> >>>> However, your question seems to imply you think there may be a >>>> limit: AUTOCONF network is small enough to accommodate >>>> host-based routes. Is it this? >>> I think the network has to accomodate the routes needed for >>> connectivity to destinations within the network. >>> >>> Again, just saying "subnet" doesn't buy even one gram of >>> additional scalability. You need more. >>> >>> You need a procedure for enabling aggregation. Such a >> procedure is not >>> always available. >> If by aggregation is meant addressing aggregation (as Teco also >> proposes a /60 prefix assigned to several Routers themselves >> assigning /64 prefixes to their links) then I think we should not >> strive to respect aggregation. Address aggregation wouldn't make >> sense if we talk host-based routes either. >> >>>>> Well, to me it did sound very negative. Moreover, I think it >>>>> is just fine to pass around subnet prefixes, if you have >>>>> subnets. >>>> Charles, yes - the subnets are there first, before IP. >> Once the link >>>> is up the subnet is the set of nodes on it. In this sense >> I agree it >>>> is just fine to pass subnet prefixes around. >>> This is wrong*2. First, there is IP, which fixes the >> address format >>> and address modes. Then there are subnets. Some people >> here probably >>> remember when the word "subnet" starting coming into more >> active use. >>> >>> Second, just because nodes are reachable over the air as >>> neighbors, does not imply they are on the same IP subnet. Trying >>> to maintain otherwise leads to madness. >>> >>> Surely you will agree. A subnet is an abstraction to support >>> more efficient routing. It is not a wire or a piece of plastic >>> or a contiguous region of space. >> I can live with that. >> >> However, I think the simplest cases we have to deal with have very >> simple subnet structure that we should take advantage of. >> >> Alex >> >> _______________________________________________ Autoconf mailing >> list Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >> > From sratliff@cisco.com Wed Mar 4 07:30:26 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADAF43A679F for ; Wed, 4 Mar 2009 07:30:26 -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 nZlbFD2xD1ZS for ; Wed, 4 Mar 2009 07:30:25 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id EC8B63A6CAA for ; Wed, 4 Mar 2009 07:30:22 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,301,1233532800"; d="scan'208";a="150716455" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 04 Mar 2009 15:30:51 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n24FUpIS025705; Wed, 4 Mar 2009 07:30:51 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n24FUndT027203; Wed, 4 Mar 2009 15:30:51 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Mar 2009 10:30:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Mar 2009 10:30:49 -0500 Message-ID: <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D803@xmb-rtp-208.amer.cisco.com> In-Reply-To: <49AE9827.5090309@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Autoconf addressing model Thread-Index: Acmc2lRFwPYuEwx1R1mROqaucljYQQAAQPKA References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com><000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com><1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl><49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl><49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl><49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl><49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl><49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net> <49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com> From: "Stan Ratliff (sratliff)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 04 Mar 2009 15:30:50.0488 (UTC) FILETIME=[32BFE780:01C99CDE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7098; t=1236180651; x=1237044651; c=relaxed/simple; s=sjdkim3002; 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]=20Autoconf=20addressing=20mo del |Sender:=20; bh=c8SlZ27aJkisB1ND2FyV1oczIjnuXildiGbVWjwyhjw=; b=UZme4MFq6urN6cEJwzkL2gpCGXx/uPIhgaHVEXN0wpd/Ppvw2XlDzZT9Z/ 2RZL1fDV4uEImi/R2OFwLD9D4rcnNpUVdUUpNds1QqMVhe/IJK+L0lx3+VXV O3UfS+xhbF; Authentication-Results: sj-dkim-3; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Wed, 04 Mar 2009 15:30:26 -0000 Inline.=20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Wednesday, March 04, 2009 10:03 AM > To: Stan Ratliff (sratliff) > Cc: Charles E. Perkins; autoconf@ietf.org > Subject: Re: [Autoconf] Autoconf addressing model >=20 > Stan Ratliff (sratliff) a =E9crit : > [...] > > We've already been over the 25m subnet thing. It's a non-starter.=20 > > Limiting movement, or mandating that a DHCP or DNS server=20 > is always on=20 > > and available is also a non-starter. 25m subnets with "always on" > > DNS/DHCP servers sounds to me like a few guys gathering together to=20 > > play "Doom" at their local coffee shop. I deploy MANET networks for=20 > > governmental applications. Think disaster recovery, like after=20 > > Hurricane Katrina, or the last round of wildfires in California. Do=20 > > you think it appropriate to tell the firefighters "you=20 > can't let the=20 > > trucks get more than 25m apart, or your network breaks"?=20 > Or, "if your =20 > > DNS server should fail, just forget what you're doing and go home"? >=20 > No, I don't think it appropriate. >=20 > But I didn't mean to imply AUTOCONF networks span only=20 > 25meter range - they could be made of several such single subnets. >=20 > > So, once again, no -- 25m subnets don't make sense and=20 > won't work in=20 > > the environments where I'm deploying networks. Placing this type of=20 > > limitation on AUTOCONF will, IMO, make the work output useless. >=20 > How about a unit being a 25m subnet containing exposed=20 > terminals; and a network growing as a chain of such units,=20 > linked by routers. Would this make more sense? >=20 First off, you *can't* arbitrarily limit subnets to 25m. 25m from what? = The center? And, how do you designate the center? Do you constantly = re-calculate the center based on movement? Also, from a radio = perspective, how do you tell how far apart you are in the first place? = Do you suppose that all radios have GPS? That's a non-starter, because = GPS signals aren't always available. And what about the wired MANET case = brought up by Christopher Dearlove? Should we limit the cable runs? I = could understand (but wouldn't really like) the notion of limiting the = discussion to links that are transitive; but placing some arbitrary = distance limit that's based on 802.11 just doesn't cut it for me.=20 Regards, Stan > The disaster relief scenarios you describe also have certain=20 > limits of movements. For example: > -firefighter never gets very far away from truck. - Not really. Firefighters regularly deploy at "some distance" from the = truck. They go where they're needed, regardless of distance from the = truck. Especially true in the case of people fighting wildfires in a = forest. =20 > -among all intervening trucks only some are designated as special, for > example command and control. - If you designate some trucks as "special", then you limit the possible = network deployments, and/or create single points of failure. The overall = network isn't as resilient as it needs to be -- for instance, if you = designate a truck as "special", and a burning tree falls on it, what = now? Stan > -etc. >=20 > Expressing this inherent structure in terms of subnet=20 > structure can be very useful. >=20 > Alex >=20 > >=20 > > Stan > >=20 > >=20 > >>> Watching your DNS server [(m) or not!] move from place to > >> place in an > >>> ad hoc network, sometimes finding itself partitioned from your=20 > >>> favorite node, could be an exciting and enlightening adventure. > >> I agree we could find very dynamic ways of Routers and Hosts of an=20 > >> ad-hoc network moving in and out such that subnet structure is not=20 > >> maintained, and thus servers not being reachable. But unless we=20 > >> describe these movements we can't deal with them. > >>=20 > >>>>> Who said we had to avoid size limits? > >>>> Well we don't have size limits in the charter proposal, we > >> don't have > >>>> agreement on '25m IPv6 subnets', we don't have limits on > >> the types of > >>>> the link layers involved. > >>> If you are talking about an ad hoc network with=20 > 25,000,000 subnets,=20 > >>> then I am basically not on the same page. And not in the > >> same decade. > >>=20 > >> Sorry I meant 25meters not millions. A '25m IPv6 subnet'=20 > would be a=20 > >> wireless coverage area of radius 25meter, without obstacles, and=20 > >> within which there are only exposed terminals, fully=20 > transitive and =20 > >> symmetric communications. > >>=20 > >> Would you agree such a subnet makes sense? Does not make sense? > >>=20 > >>>> However, your question seems to imply you think there may be a > >>>> limit: AUTOCONF network is small enough to accommodate=20 > host-based=20 > >>>> routes. Is it this? > >>> I think the network has to accomodate the routes needed for=20 > >>> connectivity to destinations within the network. > >>>=20 > >>> Again, just saying "subnet" doesn't buy even one gram of=20 > additional=20 > >>> scalability. You need more. > >>>=20 > >>> You need a procedure for enabling aggregation. Such a > >> procedure is not > >>> always available. > >> If by aggregation is meant addressing aggregation (as Teco also=20 > >> proposes a /60 prefix assigned to several Routers themselves=20 > >> assigning /64 prefixes to their links) then I think we should not=20 > >> strive to respect aggregation. Address aggregation wouldn't make=20 > >> sense if we talk host-based routes either. > >>=20 > >>>>> Well, to me it did sound very negative. Moreover, I=20 > think it is=20 > >>>>> just fine to pass around subnet prefixes, if you have subnets. > >>>> Charles, yes - the subnets are there first, before IP. > >> Once the link > >>>> is up the subnet is the set of nodes on it. In this sense > >> I agree it > >>>> is just fine to pass subnet prefixes around. > >>> This is wrong*2. First, there is IP, which fixes the > >> address format > >>> and address modes. Then there are subnets. Some people > >> here probably > >>> remember when the word "subnet" starting coming into more > >> active use. > >>>=20 > >>> Second, just because nodes are reachable over the air as=20 > neighbors,=20 > >>> does not imply they are on the same IP subnet. Trying =20 > to maintain=20 > >>> otherwise leads to madness. > >>>=20 > >>> Surely you will agree. A subnet is an abstraction to=20 > support more=20 > >>> efficient routing. It is not a wire or a piece of plastic or a=20 > >>> contiguous region of space. > >> I can live with that. > >>=20 > >> However, I think the simplest cases we have to deal with have very=20 > >> simple subnet structure that we should take advantage of. > >>=20 > >> Alex > >>=20 > >> _______________________________________________ Autoconf=20 > mailing list=20 > >> Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf > >>=20 > >=20 >=20 >=20 >=20 From wwwrun@core3.amsl.com Wed Mar 4 08:32:57 2009 Return-Path: X-Original-To: autoconf@ietf.org Delivered-To: autoconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 82E843A6B2E; Wed, 4 Mar 2009 08:32:57 -0800 (PST) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090304163257.82E843A6B2E@core3.amsl.com> Date: Wed, 4 Mar 2009 08:32:57 -0800 (PST) Cc: autoconf@ietf.org, T.Clausen@computer.org Subject: [Autoconf] WG Review: Recharter of Ad-Hoc Network Autoconfiguration (autoconf) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: iesg@ietf.org List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 16:32:57 -0000 A modified charter has been submitted for the Ad-Hoc Network Autoconfiguration working group in the Internet Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Wednesday, March 11, 2009. Ad-Hoc Network Autoconfiguration (autoconf) ------------------------------------------------------------- Last Modified: 2009-02-18 Current Status: Active Working Group Additional information is available at tools.ietf.org/wg/autoconf Chair(s): Ryuji Wakikawa [ryuji.wakikawa@gmail.com] Thomas Clausen [T.Clausen@computer.org] Internet Area Director(s): Jari Arkko [jari.arkko@piuha.net] Mark Townsley [townsley@cisco.com] Internet Area Advisor: Jari Arkko [jari.arkko@piuha.net] Mailing Lists: General Discussion: autoconf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf Archive: http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html Description of Working Group: In order to communicate among themselves, ad hoc nodes (refer to RFC 2501) need to configure their network interface(s) with local addresses that are valid within an ad hoc network. Ad hoc nodes may also need to configure globally routable addresses, in order to communicate with devices on the Internet. From the IP layer perspective, an ad hoc network presents itself as a L3 multi-hop network formed over a collection of links. The main purpose of the AUTOCONF WG is to describe the addressing model for ad hoc networks and how nodes in these networks configure their addresses. It is required that such models do not cause problems for ad hoc-unaware parts of the system, such as standard applications running on an ad hoc node or regular Internet nodes attached to the ad hoc nodes. This group's effort may include the development of new protocol mechanisms, should the existing IP autoconfiguration mechanisms be found inadequate. However, the first task of the working group is to describe one practical addressing model for ad hoc networks. Once this sole work item is completed, the group can be rechartered to work on additional issues. Goals and Milestones: Apr 2009 Submit initial draft on address configuration in ad hoc networks Sep 2009 Submit address configuration draft to IESG as Informational or close WG From teco@inf-net.nl Wed Mar 4 08:54:06 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CCFE3A6B72 for ; Wed, 4 Mar 2009 08:54:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.337 X-Spam-Level: X-Spam-Status: No, score=-0.337 tagged_above=-999 required=5 tests=[AWL=1.167, 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 WGNA+34iVXlT for ; Wed, 4 Mar 2009 08:54:05 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 4B4463A6B56 for ; Wed, 4 Mar 2009 08:54:02 -0800 (PST) Received: (qmail 24104 invoked from network); 4 Mar 2009 17:54:26 +0100 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 4 Mar 2009 17:54:26 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" , "'Stan Ratliff \(sratliff\)'" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com><000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com><1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl><49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl><49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl><49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl><49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl><49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net> <49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com> In-Reply-To: <49AE9827.5090309@gmail.com> Date: Wed, 4 Mar 2009 17:53:56 +0100 Message-ID: <000c01c99ce9$e09bf500$a1d3df00$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acmc2md/jBTyFhX0SNGtQobr5iIW4QADj8Ew Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Wed, 04 Mar 2009 16:54:06 -0000 Alex, It happen to be I am working on the customer side, not the equipment = vendor / supplier side. I can say your limitations for 25meter and a requirement for relay nodes with multiple interfaces are far, far from acceptable. I go for what = Stan says. Sorry, I cannot go into details on what the specs are. I am not in the position to say you, this is not the medium to publish and moreover, = there is no need for these details. We in IETF never went in this before (e.g. there is no range limitation for ICMP messages). Thanks, Teco |-----Oorspronkelijk bericht----- |Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] = Namens |Alexandru Petrescu |Verzonden: woensdag 4 maart 2009 16:03 |Aan: Stan Ratliff (sratliff) |CC: autoconf@ietf.org |Onderwerp: Re: [Autoconf] Autoconf addressing model | |Stan Ratliff (sratliff) a =E9crit : |[...] |> We've already been over the 25m subnet thing. It's a non-starter. |> Limiting movement, or mandating that a DHCP or DNS server is always |> on and available is also a non-starter. 25m subnets with "always on" |> DNS/DHCP servers sounds to me like a few guys gathering together to |> play "Doom" at their local coffee shop. I deploy MANET networks for |> governmental applications. Think disaster recovery, like after |> Hurricane Katrina, or the last round of wildfires in California. Do |> you think it appropriate to tell the firefighters "you can't let the |> trucks get more than 25m apart, or your network breaks"? Or, "if your |> DNS server should fail, just forget what you're doing and go home"? | |No, I don't think it appropriate. | |But I didn't mean to imply AUTOCONF networks span only 25meter range - |they could be made of several such single subnets. | |> So, once again, no -- 25m subnets don't make sense and won't work in |> the environments where I'm deploying networks. Placing this type of |> limitation on AUTOCONF will, IMO, make the work output useless. | |How about a unit being a 25m subnet containing exposed terminals; and a |network growing as a chain of such units, linked by routers. Would = this |make more sense? | |The disaster relief scenarios you describe also have certain limits of |movements. For example: |-firefighter never gets very far away from truck. |-among all intervening trucks only some are designated as special, for | example command and control. |-etc. | |Expressing this inherent structure in terms of subnet structure can be |very useful. | |Alex | |> |> Stan |> |> |>>> Watching your DNS server [(m) or not!] move from place to |>> place in an |>>> ad hoc network, sometimes finding itself partitioned from your |>>> favorite node, could be an exciting and enlightening adventure. |>> I agree we could find very dynamic ways of Routers and Hosts of an |>> ad-hoc network moving in and out such that subnet structure is not |>> maintained, and thus servers not being reachable. But unless we |>> describe these movements we can't deal with them. |>> |>>>>> Who said we had to avoid size limits? |>>>> Well we don't have size limits in the charter proposal, we |>> don't have |>>>> agreement on '25m IPv6 subnets', we don't have limits on |>> the types of |>>>> the link layers involved. |>>> If you are talking about an ad hoc network with 25,000,000 |>>> subnets, then I am basically not on the same page. And not in |>>> the |>> same decade. |>> |>> Sorry I meant 25meters not millions. A '25m IPv6 subnet' would be |>> a wireless coverage area of radius 25meter, without obstacles, and |>> within which there are only exposed terminals, fully transitive and |>> symmetric communications. |>> |>> Would you agree such a subnet makes sense? Does not make sense? |>> |>>>> However, your question seems to imply you think there may be a |>>>> limit: AUTOCONF network is small enough to accommodate |>>>> host-based routes. Is it this? |>>> I think the network has to accomodate the routes needed for |>>> connectivity to destinations within the network. |>>> |>>> Again, just saying "subnet" doesn't buy even one gram of |>>> additional scalability. You need more. |>>> |>>> You need a procedure for enabling aggregation. Such a |>> procedure is not |>>> always available. |>> If by aggregation is meant addressing aggregation (as Teco also |>> proposes a /60 prefix assigned to several Routers themselves |>> assigning /64 prefixes to their links) then I think we should not |>> strive to respect aggregation. Address aggregation wouldn't make |>> sense if we talk host-based routes either. |>> |>>>>> Well, to me it did sound very negative. Moreover, I think it |>>>>> is just fine to pass around subnet prefixes, if you have |>>>>> subnets. |>>>> Charles, yes - the subnets are there first, before IP. |>> Once the link |>>>> is up the subnet is the set of nodes on it. In this sense |>> I agree it |>>>> is just fine to pass subnet prefixes around. |>>> This is wrong*2. First, there is IP, which fixes the |>> address format |>>> and address modes. Then there are subnets. Some people |>> here probably |>>> remember when the word "subnet" starting coming into more |>> active use. |>>> |>>> Second, just because nodes are reachable over the air as |>>> neighbors, does not imply they are on the same IP subnet. Trying |>>> to maintain otherwise leads to madness. |>>> |>>> Surely you will agree. A subnet is an abstraction to support |>>> more efficient routing. It is not a wire or a piece of plastic |>>> or a contiguous region of space. |>> I can live with that. |>> |>> However, I think the simplest cases we have to deal with have very |>> simple subnet structure that we should take advantage of. |>> |>> Alex |>> |>> _______________________________________________ Autoconf mailing |>> list Autoconf@ietf.org |>> https://www.ietf.org/mailman/listinfo/autoconf |>> |> | | |_______________________________________________ |Autoconf mailing list |Autoconf@ietf.org |https://www.ietf.org/mailman/listinfo/autoconf From alexandru.petrescu@gmail.com Wed Mar 4 09:19:52 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C90623A6B1A for ; Wed, 4 Mar 2009 09:19:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[AWL=0.145, 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 fg+Fifev2J2X for ; Wed, 4 Mar 2009 09:19:51 -0800 (PST) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by core3.amsl.com (Postfix) with ESMTP id 4DEE23A6AA2 for ; Wed, 4 Mar 2009 09:19:49 -0800 (PST) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id 96D354C81A9; Wed, 4 Mar 2009 18:20:13 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp4-g21.free.fr (Postfix) with ESMTP id 3C5AC4C81B4; Wed, 4 Mar 2009 18:20:10 +0100 (CET) Message-ID: <49AEB846.5020103@gmail.com> Date: Wed, 04 Mar 2009 18:20:06 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Teco Boot References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com><000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com><1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl><49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl><49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl><49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl><49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl><49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net> <49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com> <000c01c99ce9$e09bf500$a1d3df00$@nl> In-Reply-To: <000c01c99ce9$e09bf500$a1d3df00$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090303-2, 04/03/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Wed, 04 Mar 2009 17:19:52 -0000 Teco Boot a écrit : > Alex, > > It happen to be I am working on the customer side, not the equipment > vendor / supplier side. I can say your limitations for 25meter and a > requirement for relay nodes with multiple interfaces are far, far > from acceptable. I go for what Stan says. Sorry, I cannot go into > details on what the specs are. I am not in the position to say you, > this is not the medium to publish and moreover, there is no need for > these details. We in IETF never went in this before (e.g. there is no > range limitation for ICMP messages). I meant to say to explicitely consider the characteristics of the link-layers you consider for AUTOCONF ad-hoc networks. These all have specifications about their physical lengths (for wired), for dbm powerlevels and range in meters (wireless). I can't build a network without knowing these specifications in detail; its IP addressing architecture is impossible to agree on. Alex > > Thanks, Teco > > |-----Oorspronkelijk bericht----- |Van: autoconf-bounces@ietf.org > [mailto:autoconf-bounces@ietf.org] Namens |Alexandru Petrescu > |Verzonden: woensdag 4 maart 2009 16:03 |Aan: Stan Ratliff (sratliff) > |CC: autoconf@ietf.org |Onderwerp: Re: [Autoconf] Autoconf > addressing model | |Stan Ratliff (sratliff) a écrit : |[...] |> We've > already been over the 25m subnet thing. It's a non-starter. |> > Limiting movement, or mandating that a DHCP or DNS server is always > |> on and available is also a non-starter. 25m subnets with "always > on" |> DNS/DHCP servers sounds to me like a few guys gathering > together to |> play "Doom" at their local coffee shop. I deploy MANET > networks for |> governmental applications. Think disaster recovery, > like after |> Hurricane Katrina, or the last round of wildfires in > California. Do |> you think it appropriate to tell the firefighters > "you can't let the |> trucks get more than 25m apart, or your network > breaks"? Or, "if your |> DNS server should fail, just forget what > you're doing and go home"? | |No, I don't think it appropriate. | > |But I didn't mean to imply AUTOCONF networks span only 25meter range > - |they could be made of several such single subnets. | |> So, once > again, no -- 25m subnets don't make sense and won't work in |> the > environments where I'm deploying networks. Placing this type of |> > limitation on AUTOCONF will, IMO, make the work output useless. | > |How about a unit being a 25m subnet containing exposed terminals; > and a |network growing as a chain of such units, linked by routers. > Would this |make more sense? | |The disaster relief scenarios you > describe also have certain limits of |movements. For example: > |-firefighter never gets very far away from truck. |-among all > intervening trucks only some are designated as special, for | > example command and control. |-etc. | |Expressing this inherent > structure in terms of subnet structure can be |very useful. | |Alex | > |> |> Stan |> |> |>>> Watching your DNS server [(m) or not!] move > from place to |>> place in an |>>> ad hoc network, sometimes finding > itself partitioned from your |>>> favorite node, could be an exciting > and enlightening adventure. |>> I agree we could find very dynamic > ways of Routers and Hosts of an |>> ad-hoc network moving in and out > such that subnet structure is not |>> maintained, and thus servers > not being reachable. But unless we |>> describe these movements we > can't deal with them. |>> |>>>>> Who said we had to avoid size > limits? |>>>> Well we don't have size limits in the charter proposal, > we |>> don't have |>>>> agreement on '25m IPv6 subnets', we don't > have limits on |>> the types of |>>>> the link layers involved. |>>> > If you are talking about an ad hoc network with 25,000,000 |>>> > subnets, then I am basically not on the same page. And not in |>>> > the |>> same decade. |>> |>> Sorry I meant 25meters not millions. A > '25m IPv6 subnet' would be |>> a wireless coverage area of radius > 25meter, without obstacles, and |>> within which there are only > exposed terminals, fully transitive and |>> symmetric > communications. |>> |>> Would you agree such a subnet makes sense? > Does not make sense? |>> |>>>> However, your question seems to imply > you think there may be a |>>>> limit: AUTOCONF network is small > enough to accommodate |>>>> host-based routes. Is it this? |>>> I > think the network has to accomodate the routes needed for |>>> > connectivity to destinations within the network. |>>> |>>> Again, > just saying "subnet" doesn't buy even one gram of |>>> additional > scalability. You need more. |>>> |>>> You need a procedure for > enabling aggregation. Such a |>> procedure is not |>>> always > available. |>> If by aggregation is meant addressing aggregation (as > Teco also |>> proposes a /60 prefix assigned to several Routers > themselves |>> assigning /64 prefixes to their links) then I think we > should not |>> strive to respect aggregation. Address aggregation > wouldn't make |>> sense if we talk host-based routes either. |>> > |>>>>> Well, to me it did sound very negative. Moreover, I think it > |>>>>> is just fine to pass around subnet prefixes, if you have > |>>>>> subnets. |>>>> Charles, yes - the subnets are there first, > before IP. |>> Once the link |>>>> is up the subnet is the set of > nodes on it. In this sense |>> I agree it |>>>> is just fine to pass > subnet prefixes around. |>>> This is wrong*2. First, there is IP, > which fixes the |>> address format |>>> and address modes. Then > there are subnets. Some people |>> here probably |>>> remember when > the word "subnet" starting coming into more |>> active use. |>>> |>>> > Second, just because nodes are reachable over the air as |>>> > neighbors, does not imply they are on the same IP subnet. Trying > |>>> to maintain otherwise leads to madness. |>>> |>>> Surely you > will agree. A subnet is an abstraction to support |>>> more > efficient routing. It is not a wire or a piece of plastic |>>> or a > contiguous region of space. |>> I can live with that. |>> |>> > However, I think the simplest cases we have to deal with have very > |>> simple subnet structure that we should take advantage of. |>> |>> > Alex |>> |>> _______________________________________________ Autoconf > mailing |>> list Autoconf@ietf.org |>> > https://www.ietf.org/mailman/listinfo/autoconf |>> |> | | > |_______________________________________________ |Autoconf mailing > list |Autoconf@ietf.org > |https://www.ietf.org/mailman/listinfo/autoconf > > From alexandru.petrescu@gmail.com Wed Mar 4 09:29:23 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05D8A3A6916 for ; Wed, 4 Mar 2009 09:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=0.140, 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 vYmyvjT8oK7j for ; Wed, 4 Mar 2009 09:29:22 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 3B40C28C40A for ; Wed, 4 Mar 2009 09:29:00 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 2C459D48200; Wed, 4 Mar 2009 18:29:24 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 8EDB2D4824A; Wed, 4 Mar 2009 18:29:21 +0100 (CET) Message-ID: <49AEBA6D.7030903@gmail.com> Date: Wed, 04 Mar 2009 18:29:17 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Stan Ratliff (sratliff)" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com><000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com><1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl><49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl><49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl><49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl><49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl><49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net> <49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D803@xmb-rtp-208.amer.cisco.com> In-Reply-To: <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D803@xmb-rtp-208.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090303-2, 04/03/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Wed, 04 Mar 2009 17:29:23 -0000 Stan Ratliff (sratliff) a écrit : > First off, you *can't* arbitrarily limit subnets to 25m. 25m from > what? The center? Yes, an area of 25meters with a wifi access point in the center. > And, how do you designate the center? Do you constantly re-calculate > the center based on movement? No, not constantly re-computed. But have a fixed view at a point in time. Saying everything varies isn't helpful either. > Also, from a radio perspective, how do you tell how far apart you are > in the first place? Do you suppose that all radios have GPS? That's > a non-starter, because GPS signals aren't always available. No I didn't suppose GPS is available on each device, it wouldn't work well under foliage. Just a rough evaluation of a specific link-layer radio range, correspondign to widely used networks. > And what about the wired MANET case brought up by Christopher > Dearlove? Should we limit the cable runs? YEs, certainly. All cabled link-layers have specific limitations on their lengths: 2m USB, 50m Ethernet Category6 (IIRC) and so on. > I could understand (but > wouldn't really like) the notion of limiting the discussion to links > that are transitive; but placing some arbitrary distance limit that's > based on 802.11 just doesn't cut it for me. 802.11 is being used widely, no reason to ignore. I'd happily accept to add another specific limitation, from the link-layer of your choice. And be speecifically addressing these two link layers. And maybe three. No more than three. I find addressing them all to be difficult for me. (about single point of failure being destroyed by a falling tree: problem could be addressed at its layer: don't move the command center under trees risking falling); or maybe have two command centers, but specificllay two, not an arbitrary large unknown number. Alex From charles.perkins@earthlink.net Wed Mar 4 09:35:03 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 682E128C3C1 for ; Wed, 4 Mar 2009 09:35: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 DLKaPxGZwLNJ for ; Wed, 4 Mar 2009 09:35:02 -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 6BFDC28C36B for ; Wed, 4 Mar 2009 09:35:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=cSW8pWG/+gES4grGBUGP2fPMEwnbe1/oEqd7KXqc04yYVeHr7zboZpVCNsazYy8k; 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.104]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Lev0E-0005pj-EH; Wed, 04 Mar 2009 12:35:30 -0500 Message-ID: <49AEBBD1.20308@earthlink.net> Date: Wed, 04 Mar 2009 09:35:13 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Alexandru Petrescu References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl> <49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl> <49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl> <49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl> <49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net> <49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net> <49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net> <49AE3A3A.5000305@gmail.com> In-Reply-To: <49AE3A3A.5000305@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f529782536382f400f48300bad175a249ec350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.138.86.46 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Wed, 04 Mar 2009 17:35:03 -0000 Hello Alex, Alexandru Petrescu wrote: > >> >> I assure you it is not trivial to implement DNS or DHCP inside an ad >> hoc network. Most of the proposals I have seen for this have located >> the function _outside_ the ad hoc network, for convenient and >> straightforward access when connectivity is actually available. > > Well if the subnet structure is coherent and things don't move around > too much then putting a DNS Server or a DHCP Server in the ad-hoc > network should be easy. > > By not moving too much I mean each node not moving out of its 25meter > radius. This 25m radius is not legislated nor approved by the working group. I don't see anyone else supporting your contention here, and I think the sooner we resolve that there is no such limitation, the better. Which then almost immediately invalidates your observation about DNS and DHCP servers. > > I agree we could find very dynamic ways of Routers and Hosts of an > ad-hoc network moving in and out such that subnet structure is not > maintained, and thus servers not being reachable. But unless we > describe these movements we can't deal with them. I maintain that it is not necessary, not always possible, and thus not relevant to the discussion. > > . A '25m IPv6 subnet' would be a > wireless coverage area of radius 25meter, without obstacles, and within > which there are only exposed terminals, fully transitive and symmetric > communications. > > Would you agree such a subnet makes sense? Does not make sense? By now I hope it is clear that I don't agree with equating subnets with physical extents. > > > If by aggregation is meant addressing aggregation (as Teco also > proposes a /60 prefix assigned to several Routers themselves assigning > /64 prefixes to their links) then I think we should not strive to > respect aggregation. Address aggregation wouldn't make sense if we talk > host-based routes either. If you don't have aggregation, you don't have any reason to define subnets. Of course if you don't have aggregation, you can just as easily live with host routes. Which is my point all along. > >> >> >> Surely you will agree. A subnet is an abstraction to support more >> efficient routing. It is not a wire or a piece of plastic or a >> contiguous region of space. > > I can live with that. > > However, I think the simplest cases we have to deal with have very > simple subnet structure that we should take advantage of. Surely, if we have economically realizable subnets, we should take advantage of them. That is not at all the same as insisting that we _must_ have subnets, or even worse distorting physical reality to lend credence to some fictional subnet boundaries. Regards, Charlie P. From alexandru.petrescu@gmail.com Wed Mar 4 09:35:30 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 671FA28C411; Wed, 4 Mar 2009 09:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.468 X-Spam-Level: X-Spam-Status: No, score=-1.468 tagged_above=-999 required=5 tests=[AWL=-0.511, BAYES_00=-2.599, HELO_EQ_FR=0.35, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NKK1S3UhfIQ; Wed, 4 Mar 2009 09:35:29 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 12AEE28C407; Wed, 4 Mar 2009 09:35:26 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 05A82E0810B; Wed, 4 Mar 2009 18:35:50 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp6-g21.free.fr (Postfix) with ESMTP id B0DDCE0809D; Wed, 4 Mar 2009 18:35:42 +0100 (CET) Message-ID: <49AEBBEA.7020400@gmail.com> Date: Wed, 04 Mar 2009 18:35:38 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 References: <20090304163257.82E843A6B2E@core3.amsl.com> In-Reply-To: <20090304163257.82E843A6B2E@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090303-2, 04/03/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org, iesg@ietf.org, T.Clausen@computer.org Subject: Re: [Autoconf] WG Review: Recharter of Ad-Hoc Network Autoconfiguration (autoconf) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 17:35:30 -0000 I would like to suggest: add explicitely that the practical addressing model should work at least with manual and static routes. And that the practical addressing model should not be preconditioned by the use of OLSR nor DYMO in the ad-hoc network. Also suggest: specifically mention which link-layers are being considered for ad-hoc networks. I personally consider 802.11, 802.15.4, wired Ethernet, USB and eventually 802.16. If anybody else considers other link-layers please mention them. Alex IESG Secretary a écrit : > A modified charter has been submitted for the Ad-Hoc Network > Autoconfiguration working group in the Internet Area of the IETF. The > IESG has not made any determination as yet. The modified charter is > provided below for informational purposes only. Please send your comments > to the IESG mailing list (iesg@ietf.org) by Wednesday, March 11, 2009. > > Ad-Hoc Network Autoconfiguration (autoconf) > ------------------------------------------------------------- > Last Modified: 2009-02-18 > > Current Status: Active Working Group > > Additional information is available at tools.ietf.org/wg/autoconf > > Chair(s): > Ryuji Wakikawa [ryuji.wakikawa@gmail.com] > Thomas Clausen [T.Clausen@computer.org] > > Internet Area Director(s): > Jari Arkko [jari.arkko@piuha.net] > Mark Townsley [townsley@cisco.com] > > Internet Area Advisor: > Jari Arkko [jari.arkko@piuha.net] > > Mailing Lists: > General Discussion: autoconf@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf > Archive: > http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html > > Description of Working Group: > > In order to communicate among themselves, ad hoc nodes (refer to RFC > 2501) need to configure their network interface(s) with local addresses > that are valid within an ad hoc network. Ad hoc nodes may also need to > configure globally routable addresses, in order to communicate with > devices on the Internet. From the IP layer perspective, an ad hoc > network presents itself as a L3 multi-hop network formed over a > collection of links. > > The main purpose of the AUTOCONF WG is to describe the addressing model > for ad hoc networks and how nodes in these networks configure their > addresses. It is required that such models do not cause problems for ad > hoc-unaware parts of the system, such as standard applications running > on an ad hoc node or regular Internet nodes attached to the ad hoc > nodes. This group's effort may include the development of new protocol > mechanisms, should the existing IP autoconfiguration mechanisms be found > inadequate. However, the first task of the working group is to describe > one practical addressing model for ad hoc networks. > > Once this sole work item is completed, the group can be rechartered to > work on additional issues. > > Goals and Milestones: > > Apr 2009 Submit initial draft on address configuration in ad hoc networks > Sep 2009 Submit address configuration draft to IESG as Informational or > close WG > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From teco@inf-net.nl Wed Mar 4 11:19:16 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74BFC3A68EF; Wed, 4 Mar 2009 11:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[AWL=0.407, 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 Mwy9IJvkja2L; Wed, 4 Mar 2009 11:19:15 -0800 (PST) Received: from hpsmtp-eml19.kpnxchange.com (hpsmtp-eml19.KPNXCHANGE.COM [213.75.38.84]) by core3.amsl.com (Postfix) with ESMTP id BDC5428C1C0; Wed, 4 Mar 2009 11:18:25 -0800 (PST) Received: from cpsmtp-eml101.kpnxchange.com ([213.75.84.101]) by hpsmtp-eml19.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 20:18:52 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml101.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 20:18:52 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <20090304163257.82E843A6B2E@core3.amsl.com> <49AEBBEA.7020400@gmail.com> In-Reply-To: <49AEBBEA.7020400@gmail.com> Date: Wed, 4 Mar 2009 20:18:51 +0100 Message-ID: <000001c99cfe$0d927ca0$28b775e0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acmc79FWlnGjsPWCS7Spy46jOjk7QgAC8Zyw Content-Language: nl X-OriginalArrivalTime: 04 Mar 2009 19:18:52.0184 (UTC) FILETIME=[0DAD0980:01C99CFE] Cc: autoconf@ietf.org, iesg@ietf.org, T.Clausen@computer.org Subject: Re: [Autoconf] WG Review: Recharter of Ad-Hoc Network Autoconfiguration (autoconf) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 19:19:16 -0000 Inline. |-----Oorspronkelijk bericht----- |Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] = Namens |Alexandru Petrescu |Verzonden: woensdag 4 maart 2009 18:36 |CC: autoconf@ietf.org; iesg@ietf.org; T.Clausen@computer.org |Onderwerp: Re: [Autoconf] WG Review: Recharter of Ad-Hoc Network |Autoconfiguration (autoconf) | |I would like to suggest: add explicitely that the practical addressing |model should work at least with manual and static routes. And that the |practical addressing model should not be preconditioned by the use of |OLSR nor DYMO in the ad-hoc network. I think the addressing model has little to do with the method how to = assign and configure the addresses. This is a next step. I wonder if any model exclude what you are asking for. Worried for some reason??? I would not suggest working with static routes in a mobile ad hoc = network. I agree on the last one, the model should apply to other MANET Routing Protocols as well. OSPF-MANET is an important one, not forgetting = others, including multicast. =20 |Also suggest: specifically mention which link-layers are being |considered for ad-hoc networks. I personally consider 802.11, = 802.15.4, |wired Ethernet, USB and eventually 802.16. If anybody else considers |other link-layers please mention them. I consider other link layers, but I will not mention them. I do not know = all details or even a complete list. And if I would, it doesn't help. I = think it is sufficient and more useful to describe the MANET link = characteristics. Teco. | |Alex | |IESG Secretary a =E9crit : |> A modified charter has been submitted for the Ad-Hoc Network |> Autoconfiguration working group in the Internet Area of the IETF. = The |> IESG has not made any determination as yet. The modified charter is |> provided below for informational purposes only. Please send your |comments |> to the IESG mailing list (iesg@ietf.org) by Wednesday, March 11, = 2009. |> |> Ad-Hoc Network Autoconfiguration (autoconf) |> ------------------------------------------------------------- |> Last Modified: 2009-02-18 |> |> Current Status: Active Working Group |> |> Additional information is available at tools.ietf.org/wg/autoconf |> |> Chair(s): |> Ryuji Wakikawa [ryuji.wakikawa@gmail.com] |> Thomas Clausen [T.Clausen@computer.org] |> |> Internet Area Director(s): |> Jari Arkko [jari.arkko@piuha.net] |> Mark Townsley [townsley@cisco.com] |> |> Internet Area Advisor: |> Jari Arkko [jari.arkko@piuha.net] |> |> Mailing Lists: |> General Discussion: autoconf@ietf.org |> To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf |> Archive: |> http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html |> |> Description of Working Group: |> |> In order to communicate among themselves, ad hoc nodes (refer to RFC |> 2501) need to configure their network interface(s) with local |addresses |> that are valid within an ad hoc network. Ad hoc nodes may also need = to |> configure globally routable addresses, in order to communicate with |> devices on the Internet. From the IP layer perspective, an ad hoc |> network presents itself as a L3 multi-hop network formed over a |> collection of links. |> |> The main purpose of the AUTOCONF WG is to describe the addressing |model |> for ad hoc networks and how nodes in these networks configure their |> addresses. It is required that such models do not cause problems for |ad |> hoc-unaware parts of the system, such as standard applications = running |> on an ad hoc node or regular Internet nodes attached to the ad hoc |> nodes. This group's effort may include the development of new = protocol |> mechanisms, should the existing IP autoconfiguration mechanisms be |found |> inadequate. However, the first task of the working group is to |describe |> one practical addressing model for ad hoc networks. |> |> Once this sole work item is completed, the group can be rechartered = to |> work on additional issues. |> |> Goals and Milestones: |> |> Apr 2009 Submit initial draft on address configuration in ad hoc |networks |> Sep 2009 Submit address configuration draft to IESG as Informational |or |> close WG |> |> _______________________________________________ |> 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 teco@inf-net.nl Wed Mar 4 11:35:15 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9AFF28C477 for ; Wed, 4 Mar 2009 11:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.655 X-Spam-Level: X-Spam-Status: No, score=-1.655 tagged_above=-999 required=5 tests=[AWL=0.391, 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 h8+fZChqPczB for ; Wed, 4 Mar 2009 11:35:14 -0800 (PST) Received: from hpsmtp-eml18.kpnxchange.com (hpsmtp-eml18.KPNXCHANGE.COM [213.75.38.118]) by core3.amsl.com (Postfix) with ESMTP id CF16B28C446 for ; Wed, 4 Mar 2009 11:35:13 -0800 (PST) Received: from cpsmtp-eml103.kpnxchange.com ([213.75.84.103]) by hpsmtp-eml18.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 20:35:41 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml103.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 20:35:40 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com><000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com><1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl><49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl><49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl><49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl><49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl><49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net> <49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com> <000c01c99ce9$e09bf500$a1d3df00$@nl> <49AEB846.5020103@gmail.com> In-Reply-To: <49AEB846.5020103@gmail.com> Date: Wed, 4 Mar 2009 20:35:39 +0100 Message-ID: <000101c99d00$664c7f60$32e57e20$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acmc7X3j+4HosC1JRzGA2GNhP5ShBgAEWOYA Content-Language: nl X-OriginalArrivalTime: 04 Mar 2009 19:35:40.0094 (UTC) FILETIME=[666FE5E0:01C99D00] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Wed, 04 Mar 2009 19:35:15 -0000 Inline. |-----Oorspronkelijk bericht----- |Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] |Verzonden: woensdag 4 maart 2009 18:20 |Aan: Teco Boot |CC: 'Alexandru Petrescu'; 'Stan Ratliff (sratliff)'; autoconf@ietf.org |Onderwerp: Re: [Autoconf] Autoconf addressing model | |Teco Boot a =E9crit : |> Alex, |> |> It happen to be I am working on the customer side, not the equipment |> vendor / supplier side. I can say your limitations for 25meter and a |> requirement for relay nodes with multiple interfaces are far, far |> from acceptable. I go for what Stan says. Sorry, I cannot go into |> details on what the specs are. I am not in the position to say you, |> this is not the medium to publish and moreover, there is no need for |> these details. We in IETF never went in this before (e.g. there is no |> range limitation for ICMP messages). | |I meant to say to explicitely consider the characteristics of the |link-layers you consider for AUTOCONF ad-hoc networks. These all have |specifications about their physical lengths (for wired), for dbm |powerlevels and range in meters (wireless). The problem with this is that it is of almost no use for an ad hoc = network. Ad hoc means "to this", "for this purpose". It refers to dealing with special situations as they occur rather than functions that are repeated = on a regular basis. (http://www.answers.com/topic/ad-hoc). Or "created on = the spur of the moment, impromptu" (http://en.wiktionary.org/wiki/ad_hoc). |I can't build a network without knowing these specifications |in detail; its IP addressing architecture is impossible to agree on. Why do you think you were asked to build a network? All we ask is a little cooperation in our common goal defining an = Autoconf mechanisms for MANETs. Teco. |Alex | |> |> Thanks, Teco |> |> |-----Oorspronkelijk bericht----- |Van: autoconf-bounces@ietf.org |> [mailto:autoconf-bounces@ietf.org] Namens |Alexandru Petrescu |> |Verzonden: woensdag 4 maart 2009 16:03 |Aan: Stan Ratliff (sratliff) |> |CC: autoconf@ietf.org |Onderwerp: Re: [Autoconf] Autoconf |> addressing model | |Stan Ratliff (sratliff) a =E9crit : |[...] |> = We've |> already been over the 25m subnet thing. It's a non-starter. |> |> Limiting movement, or mandating that a DHCP or DNS server is always |> |> on and available is also a non-starter. 25m subnets with "always |> on" |> DNS/DHCP servers sounds to me like a few guys gathering |> together to |> play "Doom" at their local coffee shop. I deploy MANET |> networks for |> governmental applications. Think disaster recovery, |> like after |> Hurricane Katrina, or the last round of wildfires in |> California. Do |> you think it appropriate to tell the firefighters |> "you can't let the |> trucks get more than 25m apart, or your network |> breaks"? Or, "if your |> DNS server should fail, just forget what |> you're doing and go home"? | |No, I don't think it appropriate. | |> |But I didn't mean to imply AUTOCONF networks span only 25meter range |> - |they could be made of several such single subnets. | |> So, once |> again, no -- 25m subnets don't make sense and won't work in |> the |> environments where I'm deploying networks. Placing this type of |> |> limitation on AUTOCONF will, IMO, make the work output useless. | |> |How about a unit being a 25m subnet containing exposed terminals; |> and a |network growing as a chain of such units, linked by routers. |> Would this |make more sense? | |The disaster relief scenarios you |> describe also have certain limits of |movements. For example: |> |-firefighter never gets very far away from truck. |-among all |> intervening trucks only some are designated as special, for | |> example command and control. |-etc. | |Expressing this inherent |> structure in terms of subnet structure can be |very useful. | |Alex | |> |> |> Stan |> |> |>>> Watching your DNS server [(m) or not!] move |> from place to |>> place in an |>>> ad hoc network, sometimes finding |> itself partitioned from your |>>> favorite node, could be an exciting |> and enlightening adventure. |>> I agree we could find very dynamic |> ways of Routers and Hosts of an |>> ad-hoc network moving in and out |> such that subnet structure is not |>> maintained, and thus servers |> not being reachable. But unless we |>> describe these movements we |> can't deal with them. |>> |>>>>> Who said we had to avoid size |> limits? |>>>> Well we don't have size limits in the charter proposal, |> we |>> don't have |>>>> agreement on '25m IPv6 subnets', we don't |> have limits on |>> the types of |>>>> the link layers involved. |>>> |> If you are talking about an ad hoc network with 25,000,000 |>>> |> subnets, then I am basically not on the same page. And not in |>>> |> the |>> same decade. |>> |>> Sorry I meant 25meters not millions. A |> '25m IPv6 subnet' would be |>> a wireless coverage area of radius |> 25meter, without obstacles, and |>> within which there are only |> exposed terminals, fully transitive and |>> symmetric |> communications. |>> |>> Would you agree such a subnet makes sense? |> Does not make sense? |>> |>>>> However, your question seems to imply |> you think there may be a |>>>> limit: AUTOCONF network is small |> enough to accommodate |>>>> host-based routes. Is it this? |>>> I |> think the network has to accomodate the routes needed for |>>> |> connectivity to destinations within the network. |>>> |>>> Again, |> just saying "subnet" doesn't buy even one gram of |>>> additional |> scalability. You need more. |>>> |>>> You need a procedure for |> enabling aggregation. Such a |>> procedure is not |>>> always |> available. |>> If by aggregation is meant addressing aggregation (as |> Teco also |>> proposes a /60 prefix assigned to several Routers |> themselves |>> assigning /64 prefixes to their links) then I think we |> should not |>> strive to respect aggregation. Address aggregation |> wouldn't make |>> sense if we talk host-based routes either. |>> |> |>>>>> Well, to me it did sound very negative. Moreover, I think it |> |>>>>> is just fine to pass around subnet prefixes, if you have |> |>>>>> subnets. |>>>> Charles, yes - the subnets are there first, |> before IP. |>> Once the link |>>>> is up the subnet is the set of |> nodes on it. In this sense |>> I agree it |>>>> is just fine to pass |> subnet prefixes around. |>>> This is wrong*2. First, there is IP, |> which fixes the |>> address format |>>> and address modes. Then |> there are subnets. Some people |>> here probably |>>> remember when |> the word "subnet" starting coming into more |>> active use. |>>> |>>> |> Second, just because nodes are reachable over the air as |>>> |> neighbors, does not imply they are on the same IP subnet. Trying |> |>>> to maintain otherwise leads to madness. |>>> |>>> Surely you |> will agree. A subnet is an abstraction to support |>>> more |> efficient routing. It is not a wire or a piece of plastic |>>> or a |> contiguous region of space. |>> I can live with that. |>> |>> |> However, I think the simplest cases we have to deal with have very |> |>> simple subnet structure that we should take advantage of. |>> |>> |> Alex |>> |>> _______________________________________________ Autoconf |> mailing |>> list Autoconf@ietf.org |>> |> https://www.ietf.org/mailman/listinfo/autoconf |>> |> | | |> |_______________________________________________ |Autoconf mailing |> list |Autoconf@ietf.org |> |https://www.ietf.org/mailman/listinfo/autoconf |> |> From ulrich@herberg.name Wed Mar 4 11:50:55 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FB5C28C481; Wed, 4 Mar 2009 11:50:55 -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 KUEG4tdKiUOu; Wed, 4 Mar 2009 11:50:54 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 46E2428C489; Wed, 4 Mar 2009 11:50:52 -0800 (PST) Received: by bwz26 with SMTP id 26so2973167bwz.37 for ; Wed, 04 Mar 2009 11:51:20 -0800 (PST) Received: by 10.223.126.66 with SMTP id b2mr214427fas.67.1236196280421; Wed, 04 Mar 2009 11:51:20 -0800 (PST) Received: from phoenix-mac.home (AMontsouris-753-1-16-228.w90-2.abo.wanadoo.fr [90.2.199.228]) by mx.google.com with ESMTPS id h2sm18590611fkh.29.2009.03.04.11.51.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Mar 2009 11:51:20 -0800 (PST) Sender: Ulrich Herberg Message-ID: <49AEDBB5.8090408@polytechnique.edu> Date: Wed, 04 Mar 2009 20:51:17 +0100 From: Ulrich Herberg Organization: Ecole Polytechnique User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Teco Boot References: <20090304163257.82E843A6B2E@core3.amsl.com> <49AEBBEA.7020400@gmail.com> <000001c99cfe$0d927ca0$28b775e0$@nl> In-Reply-To: <000001c99cfe$0d927ca0$28b775e0$@nl> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, iesg@ietf.org, T.Clausen@computer.org Subject: Re: [Autoconf] WG Review: Recharter of Ad-Hoc Network Autoconfiguration (autoconf) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 19:50:55 -0000 Inline Teco Boot wrote: > Inline. > > |-----Oorspronkelijk bericht----- > |Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens > |Alexandru Petrescu > |Verzonden: woensdag 4 maart 2009 18:36 > |CC: autoconf@ietf.org; iesg@ietf.org; T.Clausen@computer.org > |Onderwerp: Re: [Autoconf] WG Review: Recharter of Ad-Hoc Network > |Autoconfiguration (autoconf) > | > |I would like to suggest: add explicitely that the practical addressing > |model should work at least with manual and static routes. And that the > |practical addressing model should not be preconditioned by the use of > |OLSR nor DYMO in the ad-hoc network. > > I think the addressing model has little to do with the method how to assign > and configure the addresses. This is a next step. I wonder if any model > exclude what you are asking for. Worried for some reason??? > I don't see why the charter should explicitly mention that the addressing model should work with manual and static routes. As Teco said, this would be part of the solution space, i.e. it could be part of a draft that describes an autoconf mechanism. > I would not suggest working with static routes in a mobile ad hoc network. > Well, as said, I don't think that's part of the discussion we lead here concerning the charter. > I agree on the last one, the model should apply to other MANET Routing > Protocols as well. OSPF-MANET is an important one, not forgetting others, > including multicast. > Yes, but I don't think it should be mentioned in the charter. The charter does not say anything that the addressing model should have any preconditions for a particular MANET routing protocol. Otherwise, it would need to list a large number of routing protocols (OLSR, OLSRv2, OSPF, AODV,....) > > |Also suggest: specifically mention which link-layers are being > |considered for ad-hoc networks. I personally consider 802.11, 802.15.4, > |wired Ethernet, USB and eventually 802.16. If anybody else considers > |other link-layers please mention them. > > I consider other link layers, but I will not mention them. I do not know all > details or even a complete list. And if I would, it doesn't help. I think it > is sufficient and more useful to describe the MANET link characteristics. > I agree with Teco. MANETs can run on a number of different L2 technologies with certain characteristics. These characteristics should be mentioned in the document to be written, but not in the charter. In my opinion, no specific L2 should be mentioned. Ulrich > Teco. > > > | > |Alex > | > |IESG Secretary a écrit : > |> A modified charter has been submitted for the Ad-Hoc Network > |> Autoconfiguration working group in the Internet Area of the IETF. The > |> IESG has not made any determination as yet. The modified charter is > |> provided below for informational purposes only. Please send your > |comments > |> to the IESG mailing list (iesg@ietf.org) by Wednesday, March 11, 2009. > |> > |> Ad-Hoc Network Autoconfiguration (autoconf) > |> ------------------------------------------------------------- > |> Last Modified: 2009-02-18 > |> > |> Current Status: Active Working Group > |> > |> Additional information is available at tools.ietf.org/wg/autoconf > |> > |> Chair(s): > |> Ryuji Wakikawa [ryuji.wakikawa@gmail.com] > |> Thomas Clausen [T.Clausen@computer.org] > |> > |> Internet Area Director(s): > |> Jari Arkko [jari.arkko@piuha.net] > |> Mark Townsley [townsley@cisco.com] > |> > |> Internet Area Advisor: > |> Jari Arkko [jari.arkko@piuha.net] > |> > |> Mailing Lists: > |> General Discussion: autoconf@ietf.org > |> To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf > |> Archive: > |> http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html > |> > |> Description of Working Group: > |> > |> In order to communicate among themselves, ad hoc nodes (refer to RFC > |> 2501) need to configure their network interface(s) with local > |addresses > |> that are valid within an ad hoc network. Ad hoc nodes may also need to > |> configure globally routable addresses, in order to communicate with > |> devices on the Internet. From the IP layer perspective, an ad hoc > |> network presents itself as a L3 multi-hop network formed over a > |> collection of links. > |> > |> The main purpose of the AUTOCONF WG is to describe the addressing > |model > |> for ad hoc networks and how nodes in these networks configure their > |> addresses. It is required that such models do not cause problems for > |ad > |> hoc-unaware parts of the system, such as standard applications running > |> on an ad hoc node or regular Internet nodes attached to the ad hoc > |> nodes. This group's effort may include the development of new protocol > |> mechanisms, should the existing IP autoconfiguration mechanisms be > |found > |> inadequate. However, the first task of the working group is to > |describe > |> one practical addressing model for ad hoc networks. > |> > |> Once this sole work item is completed, the group can be rechartered to > |> work on additional issues. > |> > |> Goals and Milestones: > |> > |> Apr 2009 Submit initial draft on address configuration in ad hoc > |networks > |> Sep 2009 Submit address configuration draft to IESG as Informational > |or > |> close WG > |> > |> _______________________________________________ > |> 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 sratliff@cisco.com Wed Mar 4 13:10:24 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6403C28C421; Wed, 4 Mar 2009 13:10:24 -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 tmW24moRDkX5; Wed, 4 Mar 2009 13:10:22 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 278C128C456; Wed, 4 Mar 2009 13:10:22 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,302,1233532800"; d="scan'208";a="261425369" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-6.cisco.com with ESMTP; 04 Mar 2009 21:10:50 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n24LAoCf019630; Wed, 4 Mar 2009 16:10:50 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n24LAoHE014866; Wed, 4 Mar 2009 21:10:50 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Mar 2009 16:10:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Mar 2009 16:10:49 -0500 Message-ID: <7FB7EE0A621BA44B8B69E5F0A09DC76407B5DB01@xmb-rtp-208.amer.cisco.com> In-Reply-To: <49AEDBB5.8090408@polytechnique.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] WG Review: Recharter of Ad-Hoc Network Autoconfiguration (autoconf) Thread-Index: AcmdAqDv3MwjcY+KRUKU6uCPv6EUBAACtl6g References: <20090304163257.82E843A6B2E@core3.amsl.com> <49AEBBEA.7020400@gmail.com><000001c99cfe$0d927ca0$28b775e0$@nl> <49AEDBB5.8090408@polytechnique.edu> From: "Stan Ratliff (sratliff)" To: "Ulrich Herberg" , "Teco Boot" X-OriginalArrivalTime: 04 Mar 2009 21:10:50.0123 (UTC) FILETIME=[B1E12DB0:01C99D0D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7283; t=1236201050; x=1237065050; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20=22Stan=20Ratliff=20(sratliff)=22=20 |Subject:=20RE=3A=20[Autoconf]=20WG=20Review=3A=20Recharter =20of=20Ad-Hoc=20Network=20Autoconfiguration=20(autoconf) |Sender:=20 |To:=20=22Ulrich=20Herberg=22=20,=0A=20=20=20=20=20=20=20=20=22Teco=20Boot=22=20; bh=ipzdyH6Jz55Vwt4YIX1e4R5zMab82DsRsSw/EcUAm0I=; b=ghZbrFntBexuypJ93X2z9LDvDhDkf9oWSweEyJ9Ab57y9vaPUjjwQsG8t4 oKaGaNDr3PAQtckbUiQ9xrDZAdgx6TYjBIGosymUFbtpQ9gdrv9C6KyDXwe4 DASKpw8v+M; Authentication-Results: rtp-dkim-1; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: autoconf@ietf.org, iesg@ietf.org, T.Clausen@computer.org Subject: Re: [Autoconf] WG Review: Recharter of Ad-Hoc Network Autoconfiguration (autoconf) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 21:10:24 -0000 Inline=20 > -----Original Message----- > From: autoconf-bounces@ietf.org=20 > [mailto:autoconf-bounces@ietf.org] On Behalf Of Ulrich Herberg > Sent: Wednesday, March 04, 2009 2:51 PM > To: Teco Boot > Cc: autoconf@ietf.org; iesg@ietf.org; T.Clausen@computer.org > Subject: Re: [Autoconf] WG Review: Recharter of Ad-Hoc=20 > Network Autoconfiguration (autoconf) >=20 > Inline >=20 > Teco Boot wrote: > > Inline. > > > > |-----Oorspronkelijk bericht----- > > |Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org]=20 > > |Namens Alexandru Petrescu > > |Verzonden: woensdag 4 maart 2009 18:36 > > |CC: autoconf@ietf.org; iesg@ietf.org; T.Clausen@computer.org > > |Onderwerp: Re: [Autoconf] WG Review: Recharter of Ad-Hoc Network=20 > > |Autoconfiguration (autoconf) > > | > > |I would like to suggest: add explicitely that the practical=20 > > |addressing model should work at least with manual and=20 > static routes. =20 > > |And that the practical addressing model should not be=20 > preconditioned=20 > > |by the use of OLSR nor DYMO in the ad-hoc network. > > > > I think the addressing model has little to do with the=20 > method how to=20 > > assign and configure the addresses. This is a next step. I=20 > wonder if=20 > > any model exclude what you are asking for. Worried for some=20 > reason??? > > =20 > I don't see why the charter should explicitly mention that=20 > the addressing model should work with manual and static=20 > routes. As Teco said, this would be part of the solution=20 > space, i.e. it could be part of a draft that describes an=20 > autoconf mechanism. >=20 > > I would not suggest working with static routes in a mobile=20 > ad hoc network. > > =20 > Well, as said, I don't think that's part of the discussion we=20 > lead here concerning the charter. > > I agree on the last one, the model should apply to other=20 > MANET Routing=20 > > Protocols as well. OSPF-MANET is an important one, not forgetting=20 > > others, including multicast. > > =20 > Yes, but I don't think it should be mentioned in the charter.=20 > The charter does not say anything that the addressing model=20 > should have any preconditions for a particular MANET routing=20 > protocol. Otherwise, it would need to list a large number of=20 > routing protocols (OLSR, OLSRv2, OSPF, AODV,....) > > =20 > > |Also suggest: specifically mention which link-layers are being=20 > > |considered for ad-hoc networks. I personally consider 802.11,=20 > > |802.15.4, wired Ethernet, USB and eventually 802.16. If=20 > anybody else=20 > > |considers other link-layers please mention them. > > > > I consider other link layers, but I will not mention them. I do not=20 > > know all details or even a complete list. And if I would,=20 > it doesn't=20 > > help. I think it is sufficient and more useful to describe=20 > the MANET link characteristics. > > =20 >=20 > I agree with Teco. MANETs can run on a number of different L2=20 > technologies with certain characteristics. These=20 > characteristics should be mentioned in the document to be=20 > written, but not in the charter. In my opinion, no specific=20 > L2 should be mentioned. >=20 > Ulrich Ditto what Ulrich says. I fail to understand why the selection of a = Layer 2 technology should impact the assignmnet of Layer 3 addresses, = therefore, I see no need to call out any specific L2. Regards, Stan > > Teco. > > > > > > | > > |Alex > > | > > |IESG Secretary a =E9crit : > > |> A modified charter has been submitted for the Ad-Hoc Network=20 > > |> Autoconfiguration working group in the Internet Area of=20 > the IETF. =20 > > |> The IESG has not made any determination as yet. The modified=20 > > |> charter is provided below for informational purposes=20 > only. Please=20 > > |> send your > > |comments > > |> to the IESG mailing list (iesg@ietf.org) by Wednesday,=20 > March 11, 2009. > > |> > > |> Ad-Hoc Network Autoconfiguration (autoconf) > > |> ------------------------------------------------------------- > > |> Last Modified: 2009-02-18 > > |> > > |> Current Status: Active Working Group > > |> > > |> Additional information is available at tools.ietf.org/wg/autoconf > > |> > > |> Chair(s): > > |> Ryuji Wakikawa [ryuji.wakikawa@gmail.com] Thomas Clausen=20 > > |> [T.Clausen@computer.org] > > |> > > |> Internet Area Director(s): > > |> Jari Arkko [jari.arkko@piuha.net] > > |> Mark Townsley [townsley@cisco.com] > > |> > > |> Internet Area Advisor: > > |> Jari Arkko [jari.arkko@piuha.net] > > |> > > |> Mailing Lists: > > |> General Discussion: autoconf@ietf.org To Subscribe:=20 > > |> https://www.ietf.org/mailman/listinfo/autoconf > > |> Archive: > > |>=20 > http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html > > |> > > |> Description of Working Group: > > |> > > |> In order to communicate among themselves, ad hoc nodes (refer to=20 > > |> RFC > > |> 2501) need to configure their network interface(s) with local > > |addresses > > |> that are valid within an ad hoc network. Ad hoc nodes=20 > may also need=20 > > |> to configure globally routable addresses, in order to=20 > communicate=20 > > |> with devices on the Internet. From the IP layer=20 > perspective, an ad=20 > > |> hoc network presents itself as a L3 multi-hop network=20 > formed over a=20 > > |> collection of links. > > |> > > |> The main purpose of the AUTOCONF WG is to describe the addressing > > |model > > |> for ad hoc networks and how nodes in these networks=20 > configure their=20 > > |> addresses. It is required that such models do not cause problems=20 > > |> for > > |ad > > |> hoc-unaware parts of the system, such as standard applications=20 > > |> running on an ad hoc node or regular Internet nodes=20 > attached to the=20 > > |> ad hoc nodes. This group's effort may include the development of=20 > > |> new protocol mechanisms, should the existing IP=20 > autoconfiguration=20 > > |> mechanisms be > > |found > > |> inadequate. However, the first task of the working group is to > > |describe > > |> one practical addressing model for ad hoc networks. > > |> > > |> Once this sole work item is completed, the group can be=20 > rechartered=20 > > |> to work on additional issues. > > |> > > |> Goals and Milestones: > > |> > > |> Apr 2009 Submit initial draft on address configuration in ad hoc > > |networks > > |> Sep 2009 Submit address configuration draft to IESG as=20 > > |> Informational > > |or > > |> close WG > > |> > > |> _______________________________________________ > > |> 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 > > =20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf >=20 From sratliff@cisco.com Wed Mar 4 13:35:00 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8E923A6A63 for ; Wed, 4 Mar 2009 13:35:00 -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 NMseHtYOYgKi for ; Wed, 4 Mar 2009 13:34:55 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 7E9423A6A90 for ; Wed, 4 Mar 2009 13:34:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,303,1233532800"; d="scan'208";a="139472971" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 04 Mar 2009 21:35:23 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n24LZNfE012276; Wed, 4 Mar 2009 13:35:23 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n24LZNKk008546; Wed, 4 Mar 2009 21:35:23 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Mar 2009 16:35:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Mar 2009 16:35:22 -0500 Message-ID: <7FB7EE0A621BA44B8B69E5F0A09DC76407B5DB1F@xmb-rtp-208.amer.cisco.com> In-Reply-To: <49AEBA6D.7030903@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Autoconf addressing model Thread-Index: Acmc7tiiUEclImn0SFW37TI7C6NxiAAHwq4g References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com><000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com><1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl><49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl><49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl><49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl><49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl><49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net> <49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D803@xmb-rtp-208.amer.cisco.com> <49AEBA6D.7030903@gmail.com> From: "Stan Ratliff (sratliff)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 04 Mar 2009 21:35:23.0426 (UTC) FILETIME=[20096020:01C99D11] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3870; t=1236202523; x=1237066523; c=relaxed/simple; s=sjdkim2002; 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]=20Autoconf=20addressing=20mo del |Sender:=20; bh=DhlwT0DjRdVM2aMNZtRCkbcmqn5dLltNpIvzrRx5tk0=; b=unRPZddmSm1JQPA8BJQrmT/fXny7q/QJgvxLRw6/NEPpLF6p9p3lZ+bIOG auVxR11NVnilmrbDqf/kokmhV2mVYwSiH2ZJe8mD87uTFoKM/zdRVSI+hV56 1/Zz0C73CI; Authentication-Results: sj-dkim-2; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Wed, 04 Mar 2009 21:35:01 -0000 =20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Wednesday, March 04, 2009 12:29 PM > To: Stan Ratliff (sratliff) > Cc: Charles E. Perkins; autoconf@ietf.org > Subject: Re: [Autoconf] Autoconf addressing model >=20 > Stan Ratliff (sratliff) a =E9crit : > > First off, you *can't* arbitrarily limit subnets to 25m. 25m from=20 > > what? The center? >=20 > Yes, an area of 25meters with a wifi access point in the center. *By definition*, what you describe is not a MANET. As you state, that's = just a WiFi access point. That's already solved -- 802.11 clients can = roam from access point to access point. But again, this should not be an = 802.11-centric discussion.=20 >=20 > > And, how do you designate the center? Do you constantly=20 > re-calculate =20 > > the center based on movement? >=20 > No, not constantly re-computed. But have a fixed view at a=20 > point in time. Saying everything varies isn't helpful either. >=20 It may not be helpful, but it's reality. You can't rely on a fixed view = of a dynamic network; again, by definition, there's movement in a MANET. = Links come and go, and link quality varies from moment to moment. > > Also, from a radio perspective, how do you tell how far=20 > apart you are =20 > > in the first place? Do you suppose that all radios have=20 > GPS? That's a=20 > > non-starter, because GPS signals aren't always available. >=20 > No I didn't suppose GPS is available on each device, it=20 > wouldn't work well under foliage. Just a rough evaluation of=20 > a specific link-layer radio range, correspondign to widely=20 > used networks. >=20 > > And what about the wired MANET case brought up by Christopher=20 > > Dearlove? Should we limit the cable runs? >=20 > YEs, certainly. All cabled link-layers have specific=20 > limitations on their lengths: 2m USB, 50m Ethernet Category6=20 > (IIRC) and so on. >=20 > > I could understand (but > > wouldn't really like) the notion of limiting the discussion=20 > to links=20 > > that are transitive; but placing some arbitrary distance=20 > limit that's=20 > > based on 802.11 just doesn't cut it for me. >=20 > 802.11 is being used widely, no reason to ignore. I'm not advocating we "ignore" 802.11, or any other L2 technology, for = that matter. I'm advocating that we remain Layer 2 agnostic. As Teco = mentioned in another email, there are people in this WG that don't = deploy MANET networks based on 802.11, or 802.16, or 802.15.4. >=20 > I'd happily accept to add another specific limitation, from=20 > the link-layer of your choice. And be speecifically=20 > addressing these two link layers. And maybe three. No more=20 > than three. >=20 > I find addressing them all to be difficult for me. I don't understand why the Layer 3 addressing scheme needs to be = predicated on a specific Layer 2 technology, or set of technologies. The = Layer 3 addressing scheme should be totally independent of Layer 2 -- = isn't that what layering is all about? >=20 > (about single point of failure being destroyed by a falling tree: > problem could be addressed at its layer: don't move the=20 > command center > under trees risking falling); or maybe have two command centers, but > specificllay two, not an arbitrary large unknown number. >=20 That essentially boils down to "if it hurts, don't do it", and it = doesn't work for my customers. Their environments are dynamic, and they = need the ability to respond to ever-changing realities on the ground.=20 At this point, I feel that we're in a discussion that is becoming more = and more circular, and therefore, dysfunctional. And that, IMO, has been = the unfortunate reality of this WG since its inception.=20 Regards, Stan > Alex >=20 From teco@inf-net.nl Wed Mar 4 14:19:45 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20B633A6A48; Wed, 4 Mar 2009 14:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.377, 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 2wiCJ8rcoDJ6; Wed, 4 Mar 2009 14:19:44 -0800 (PST) Received: from hpsmtp-eml18.kpnxchange.com (hpsmtp-eml18.KPNXCHANGE.COM [213.75.38.118]) by core3.amsl.com (Postfix) with ESMTP id 9849A3A6874; Wed, 4 Mar 2009 14:19:42 -0800 (PST) Received: from cpsmtp-eml101.kpnxchange.com ([213.75.84.101]) by hpsmtp-eml18.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 23:20:10 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml101.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 23:20:10 +0100 From: "Teco Boot" To: "'Ulrich Herberg'" References: <20090304163257.82E843A6B2E@core3.amsl.com> <49AEBBEA.7020400@gmail.com> <000001c99cfe$0d927ca0$28b775e0$@nl> <49AEDBB5.8090408@polytechnique.edu> In-Reply-To: <49AEDBB5.8090408@polytechnique.edu> Date: Wed, 4 Mar 2009 23:20:10 +0100 Message-ID: <000801c99d17$61b350c0$2519f240$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmdApfbCzIfIZ8GRbeHTr+OUZ8kJQAFEyVg Content-Language: nl X-OriginalArrivalTime: 04 Mar 2009 22:20:10.0595 (UTC) FILETIME=[61B6D330:01C99D17] Cc: autoconf@ietf.org, iesg@ietf.org, T.Clausen@computer.org Subject: Re: [Autoconf] WG Review: Recharter of Ad-Hoc Network Autoconfiguration (autoconf) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 22:19:45 -0000 I agree on not mentioning an endless list of routing protocols. I was not precise in my reply, I agreed on not rely on OLSR or DYMO. I forgot to mention the list should not be in the charter. Being independent on routing protocols was in the previous charter, that = was OK for me. Teco. |-----Oorspronkelijk bericht----- |Van: Ulrich Herberg [mailto:ulrich@herberg.name] Namens Ulrich Herberg |Verzonden: woensdag 4 maart 2009 20:51 |Aan: Teco Boot |CC: 'Alexandru Petrescu'; autoconf@ietf.org; iesg@ietf.org; |T.Clausen@computer.org |Onderwerp: Re: [Autoconf] WG Review: Recharter of Ad-Hoc Network |Autoconfiguration (autoconf) | |Inline | |Teco Boot wrote: |> Inline. |> |> |-----Oorspronkelijk bericht----- |> |Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] |Namens |> |Alexandru Petrescu |> |Verzonden: woensdag 4 maart 2009 18:36 |> |CC: autoconf@ietf.org; iesg@ietf.org; T.Clausen@computer.org |> |Onderwerp: Re: [Autoconf] WG Review: Recharter of Ad-Hoc Network |> |Autoconfiguration (autoconf) |> | |> |I would like to suggest: add explicitely that the practical |addressing |> |model should work at least with manual and static routes. And that |the |> |practical addressing model should not be preconditioned by the use = of |> |OLSR nor DYMO in the ad-hoc network. |> |> I think the addressing model has little to do with the method how to |assign |> and configure the addresses. This is a next step. I wonder if any |model |> exclude what you are asking for. Worried for some reason??? |> |I don't see why the charter should explicitly mention that the |addressing model should work with manual and static routes. As Teco |said, this would be part of the solution space, i.e. it could be part = of |a draft that describes an autoconf mechanism. | |> I would not suggest working with static routes in a mobile ad hoc |network. |> |Well, as said, I don't think that's part of the discussion we lead here |concerning the charter. |> I agree on the last one, the model should apply to other MANET = Routing |> Protocols as well. OSPF-MANET is an important one, not forgetting |others, |> including multicast. |> |Yes, but I don't think it should be mentioned in the charter. The |charter does not say anything that the addressing model should have any |preconditions for a particular MANET routing protocol. Otherwise, it |would need to list a large number of routing protocols (OLSR, OLSRv2, |OSPF, AODV,....) |> |> |Also suggest: specifically mention which link-layers are being |> |considered for ad-hoc networks. I personally consider 802.11, |802.15.4, |> |wired Ethernet, USB and eventually 802.16. If anybody else = considers |> |other link-layers please mention them. |> |> I consider other link layers, but I will not mention them. I do not |know all |> details or even a complete list. And if I would, it doesn't help. I |think it |> is sufficient and more useful to describe the MANET link |characteristics. |> | |I agree with Teco. MANETs can run on a number of different L2 |technologies with certain characteristics. These characteristics should |be mentioned in the document to be written, but not in the charter. In |my opinion, no specific L2 should be mentioned. | |Ulrich |> Teco. |> |> |> | |> |Alex |> | |> |IESG Secretary a =E9crit : |> |> A modified charter has been submitted for the Ad-Hoc Network |> |> Autoconfiguration working group in the Internet Area of the IETF. |The |> |> IESG has not made any determination as yet. The modified charter |is |> |> provided below for informational purposes only. Please send your |> |comments |> |> to the IESG mailing list (iesg@ietf.org) by Wednesday, March 11, |2009. |> |> |> |> Ad-Hoc Network Autoconfiguration (autoconf) |> |> ------------------------------------------------------------- |> |> Last Modified: 2009-02-18 |> |> |> |> Current Status: Active Working Group |> |> |> |> Additional information is available at tools.ietf.org/wg/autoconf |> |> |> |> Chair(s): |> |> Ryuji Wakikawa [ryuji.wakikawa@gmail.com] |> |> Thomas Clausen [T.Clausen@computer.org] |> |> |> |> Internet Area Director(s): |> |> Jari Arkko [jari.arkko@piuha.net] |> |> Mark Townsley [townsley@cisco.com] |> |> |> |> Internet Area Advisor: |> |> Jari Arkko [jari.arkko@piuha.net] |> |> |> |> Mailing Lists: |> |> General Discussion: autoconf@ietf.org |> |> To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf |> |> Archive: |> |> = http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html |> |> |> |> Description of Working Group: |> |> |> |> In order to communicate among themselves, ad hoc nodes (refer to |RFC |> |> 2501) need to configure their network interface(s) with local |> |addresses |> |> that are valid within an ad hoc network. Ad hoc nodes may also = need |to |> |> configure globally routable addresses, in order to communicate = with |> |> devices on the Internet. From the IP layer perspective, an ad hoc |> |> network presents itself as a L3 multi-hop network formed over a |> |> collection of links. |> |> |> |> The main purpose of the AUTOCONF WG is to describe the addressing |> |model |> |> for ad hoc networks and how nodes in these networks configure = their |> |> addresses. It is required that such models do not cause problems |for |> |ad |> |> hoc-unaware parts of the system, such as standard applications |running |> |> on an ad hoc node or regular Internet nodes attached to the ad hoc |> |> nodes. This group's effort may include the development of new |protocol |> |> mechanisms, should the existing IP autoconfiguration mechanisms be |> |found |> |> inadequate. However, the first task of the working group is to |> |describe |> |> one practical addressing model for ad hoc networks. |> |> |> |> Once this sole work item is completed, the group can be = rechartered |to |> |> work on additional issues. |> |> |> |> Goals and Milestones: |> |> |> |> Apr 2009 Submit initial draft on address configuration in ad hoc |> |networks |> |> Sep 2009 Submit address configuration draft to IESG as |Informational |> |or |> |> close WG |> |> |> |> _______________________________________________ |> |> 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 teco@inf-net.nl Wed Mar 4 14:57:21 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6A8C28C12C for ; Wed, 4 Mar 2009 14:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.683 X-Spam-Level: X-Spam-Status: No, score=-1.683 tagged_above=-999 required=5 tests=[AWL=0.363, 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 azGt6ZGVcIAh for ; Wed, 4 Mar 2009 14:57:20 -0800 (PST) Received: from hpsmtp-eml20.kpnxchange.com (hpsmtp-eml20.KPNXCHANGE.COM [213.75.38.85]) by core3.amsl.com (Postfix) with ESMTP id 4A0883A68DA for ; Wed, 4 Mar 2009 14:57:20 -0800 (PST) Received: from cpsmtp-eml110.kpnxchange.com ([10.94.168.110]) by hpsmtp-eml20.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 23:57:47 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml110.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 23:57:46 +0100 From: "Teco Boot" To: "'Charles E. Perkins'" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl> <49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl> <49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl> <49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl> <49AD90D9.5040100@earthlink.net> <000c01c99c4f$d1ab1750$750145f0$@nl> <49ADBCD8.9040301@earthlink.net> In-Reply-To: <49ADBCD8.9040301@earthlink.net> Date: Wed, 4 Mar 2009 23:57:47 +0100 Message-ID: <000901c99d1c$a2d939c0$e88bad40$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmcV5tlk+ckocSzSGSdnilki1aSFgAqPI/Q Content-Language: nl X-OriginalArrivalTime: 04 Mar 2009 22:57:47.0039 (UTC) FILETIME=[A2A8DAF0:01C99D1C] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Wed, 04 Mar 2009 22:57:21 -0000 Hi Charlie, Yes, I think the issues in this thread touch our basic problems. Here some follow-up: - on little wireless nodes that have a single interface: The scope of MANETs is quite large, e.g. from aircraft carriers to smart dust. For the most tiny devices, I am not sure we should deal with these. There are other WGs working on PAN / sensor networks, maybe we could focus on the somewhat larger stuff. And were a device type have a single interface, new versions in this category may have more. Example: my 8 years old phone has 2 wireless interfaces, 1 wired and one IR. Only one is IP enabled. Maybe I'll buy a new one some time, I think this one would have almost all interfaces IP enabled and it would have more than 4 interfaces. - on guideline for using router loopback interface for management: I think this is a no-brainer for ISP / enterprise network engineers. Many documents provide this advice, but I was looking for something that has not a logo from a certain company. The problem here is, this company has a high market share in this arena and also publish a lot of guidelines. Here some refs, I hope this will convince you this is a well accepted practice. http://www.apnic.net/training/download/irm-1/irm1-7-addrplan.pdf http://ws.edu.isoc.org/data/2004/604610702427ef01785c49/loopback-6up.pdf ftp://ftp.hp.com/pub/networking/software/ProCurve-SR-BGP-Config-Guide-08-05. pdf http://www.juniper.net/techpubs/software/junos-es/junos-es92/junos-es-swconf ig-interfaces-and-routing/special-interfaces.html#loopback-interface-section http://www.apnic.net/meetings/26/program/apops/transcript.html#yoshinobu-arc hitecture - on status of address / interface; socket api for this: I discussed this with some colleagues, on what the requirements are. We came to the conclusion that applications should be able to select an address that belongs to a stable (ifup) interface, e.g. the loopback interface. Applications should also be able to select an address that belongs to a physical interface. Multicast applications can take benefits here. Having different options could make defining default behavior somewhat complex. Shim mechanisms (MIP/MIP6, Shim6, HIP) and socket interfaces based on names hide addressing details from the applications. But such an approach may affect applications for high availability, and in my environment this is important. == back to the addressing model: After some more thoughts, I come to the conclusion that MANET Routers should advertize as little as possible, for reducing overhead. This is about routing prefixes. The advertized prefix should "belong" to the indivisible "mobile object", this means the summary prefix must not split and sub-prefixes (subnets??) shall be interconnected within the "mobile object". Single router "mobile object" has this behavior by nature. Addresses assigned to interfaces come from the advertized prefix and may have any prefix-length equal or longer than the advertized prefix-length. Loopback interfaces should have /128 (or /32), as defined in RFCs for this. Ethernet typically have /64, this is specified in std track RFC and it is a MUST if SLAAC is used. Still the question on using /128, /64 or other for globally unique address-prefixes that are assigned to MANET interfaces of this "mobile object". Maybe we do not need to restrict this. Mentioning the options and the consequences is good enough, I think. Some consequences with /127 are described in RFC3627. This RFC also mentions /128: Using two /128 addresses is also one, though often cumbersome, approach. Naturally, not much would be lost if even a shorter prefix was used, e.g., /112 or /120. The diagram in MANET-ARCH 5.1 could be adjusted to reflect my thoughts. Below, it is more an example and less a "model". <~~~~~~+~~~~~~> | Assigned Prefix | =================== 2001:db8:0::EUI-64/64| <=== 2001:db8:0::/64 = FE80::EUI-64/64| =================== MANET Interface| Delegated Prefix +-----------------------+ /-------------\ | | <<<<<<<<<<<<| 2001:db8::/60 | | MANET | \-------------/ | Router | | | | ................... | Assigned Prefix | !Loopback ! | ===================== | !2001:db8:F::0/128! | <=== 2001:db8:F::0/128 = | ''''''''''''''''''' | ===================== +---------------+-------+ Ethernet Interface: Assigned Prefix FE80::EUI-64/64: =================== 2001:db8:1::EUI-64/64: <======== 2001:db8:1::/64 = : =================== .............. : : FE80::EUI-64/64: :FE80::EUI-64/64 2001:db8:1::dhcp/64: :2001:db8:1::EUI-64/64 +--------------+-+ +--+--------------+ | Host with DHCP | * * * | Host with SLAAC | +----------------+ +-----------------+ In a table format: Delegated summary prefix: 2001:db8::/60 15 x /64: MANET Interface: 2001:db8:0::/64 Ethernet Interface: 2001:db8:1::/64 " " " " " " " up to: 2001:db8:E::/64 Block for longer prefix lengths: 2001:db8:F::/64 Loopback Interface #0: 2001:db8:F::0/128 (others, e.g. P2P) " " " This model provides RFC4862 SLAAC service for nearby hosts, also useful for MANET Router (or NEMO Router) bootstrapping. For getting a delegated prefix, the a SLAAC address could be used for communication with a DHCP server, using unicast (to be verified). Important: the /64 prefix that corresponds with the SLAAC address-prefix MUST NOT be advertized in the MANET Routing Protocol. Advertizing this as a host prefix is allowed, but getting an own /60 or whatsoever summary is advised. The result here is a MANET Routing Protocol requirement (not advertizing /64 SLAAC prefixes). The MANET Router may act as DHCP Server (or relay agent) for its Delegated Prefix(es). SLAAC is also supported. On dec 2007 I posted similar thoughts (http://www.ietf.org/mail-archive/web/autoconf/current/msg00901.html). Are we making progress? I think: yes! Teco. |-----Oorspronkelijk bericht----- |Van: Charles E. Perkins [mailto:charles.perkins@earthlink.net] |Verzonden: woensdag 4 maart 2009 0:27 |Aan: Teco Boot |CC: autoconf@ietf.org |Onderwerp: Re: [Autoconf] Autoconf addressing model | | |Hello Teco, | |You raise interesting questions, but I think mostly |not definitive for the questions at hand. I don't know |if I have any good answers, but here are some comments. | |Teco Boot wrote: |> As long as I designed and maintained network infrastructures, I worked |with |> "/32 management addresses" on loopback interfaces. Still, I have |annoying |> experiences with routers that select the outgoing interface address as |> default source address. Shutting down an interface could have |unintended bad |> impact on your terminal session. Same for link flapping due to other |causes. |> | |I guess this is relevant for packet forwarders with more than one |network interface. For our little wireless nodes that have a single |interface, I don't imagine we'd see that kind of interface aggravation. | |> For this reason, many routers on the Internet use the loopback |interface for |> "management". "Management" is the host application on routers. There |are |> lots of design guidelines for this. My proposal is using the "Internet |> lessons learned" in the MANET. Nothing wrong with this, agreed? |> | |I know only a small bit about this. Do you have a favorite |document that I could read to learn more? | |> |> With MobileIP, we are discussing a host (could be NEMO Router, but |then it |> acts as host on the visiting link). The MobileIP stack is interested |in the |> status of the visiting link, but does it propagate this to the |applications? |> Or use the applications some kind of virtual interface (e.g. a |loopback |> interface)? Or spoof ifup for interface to home link? |> | |Whether or not applications have access to link information is |something not closely related to Mobile IP. Whether or not |the care-of address is available to applications is a surprisingly |complicated question, which in my opinion opens the door to |many interesting questions and indicates the insufficiency of |today's typical application socket interface. | |I've had a lot of ideas about how to fix this, but never been |able to initiate a project to supply a finished proposal. | | |Regards, |Charlie P. From alexandru.petrescu@gmail.com Wed Mar 4 15:40:50 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C68A528C19C for ; Wed, 4 Mar 2009 15:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=0.151, 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 wsbUbbcpie1P for ; Wed, 4 Mar 2009 15:40:49 -0800 (PST) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by core3.amsl.com (Postfix) with ESMTP id C8DC83A6B14 for ; Wed, 4 Mar 2009 15:40:47 -0800 (PST) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id 72DB74C8079; Thu, 5 Mar 2009 00:41:11 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp4-g21.free.fr (Postfix) with ESMTP id 2A9494C809B; Thu, 5 Mar 2009 00:41:09 +0100 (CET) Message-ID: <49AF1191.1080307@gmail.com> Date: Thu, 05 Mar 2009 00:41:05 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Teco Boot References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl> <49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl> <49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl> <49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl> <49AD90D9.5040100@earthlink.net> <000c01c99c4f$d1ab1750$750145f0$@nl> <49ADBCD8.9040301@earthlink.net> <000901c99d1c$a2d939c0$e88bad40$@nl> In-Reply-To: <000901c99d1c$a2d939c0$e88bad40$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090303-2, 04/03/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Wed, 04 Mar 2009 23:40:50 -0000 Teco Boot a écrit : > Hi Charlie, > > Yes, I think the issues in this thread touch our basic problems. Here some > follow-up: > > - on little wireless nodes that have a single interface: > The scope of MANETs is quite large, e.g. from aircraft carriers to smart > dust. For the most tiny devices, I am not sure we should deal with these. > There are other WGs working on PAN / sensor networks, maybe we could focus > on the somewhat larger stuff. And were a device type have a single > interface, new versions in this category may have more. > Example: my 8 years old phone has 2 wireless interfaces, 1 wired and one IR. > Only one is IP enabled. Maybe I'll buy a new one some time, I think this one > would have almost all interfaces IP enabled and it would have more than 4 > interfaces. > > > - on guideline for using router loopback interface for management: > I think this is a no-brainer for ISP / enterprise network engineers. Many > documents provide this advice, but I was looking for something that has not > a logo from a certain company. The problem here is, this company has a high > market share in this arena and also publish a lot of guidelines. > Here some refs, I hope this will convince you this is a well accepted > practice. > http://www.apnic.net/training/download/irm-1/irm1-7-addrplan.pdf > http://ws.edu.isoc.org/data/2004/604610702427ef01785c49/loopback-6up.pdf > ftp://ftp.hp.com/pub/networking/software/ProCurve-SR-BGP-Config-Guide-08-05. > pdf > http://www.juniper.net/techpubs/software/junos-es/junos-es92/junos-es-swconf > ig-interfaces-and-routing/special-interfaces.html#loopback-interface-section > http://www.apnic.net/meetings/26/program/apops/transcript.html#yoshinobu-arc > hitecture > > > - on status of address / interface; socket api for this: > I discussed this with some colleagues, on what the requirements are. We came > to the conclusion that applications should be able to select an address that > belongs to a stable (ifup) interface, e.g. the loopback interface. > Applications should also be able to select an address that belongs to a > physical interface. Multicast applications can take benefits here. Having > different options could make defining default behavior somewhat complex. > Shim mechanisms (MIP/MIP6, Shim6, HIP) and socket interfaces based on names > hide addressing details from the applications. But such an approach may > affect applications for high availability, and in my environment this is > important. > > > > == back to the addressing model: > After some more thoughts, I come to the conclusion that MANET Routers should > advertize as little as possible, for reducing overhead. This is about > routing prefixes. The advertized prefix should "belong" to the indivisible > "mobile object", this means the summary prefix must not split and > sub-prefixes (subnets??) shall be interconnected within the "mobile object". > Single router "mobile object" has this behavior by nature. > Addresses assigned to interfaces come from the advertized prefix and may > have any prefix-length equal or longer than the advertized prefix-length. > Loopback interfaces should have /128 (or /32), as defined in RFCs for this. > Ethernet typically have /64, this is specified in std track RFC and it is a > MUST if SLAAC is used. > Still the question on using /128, /64 or other for globally unique > address-prefixes that are assigned to MANET interfaces of this "mobile > object". Maybe we do not need to restrict this. Mentioning the options and > the consequences is good enough, I think. > Some consequences with /127 are described in RFC3627. This RFC also mentions > /128: > Using two /128 addresses is also one, though often cumbersome, > approach. Naturally, not much would be lost if even a shorter > prefix was used, e.g., /112 or /120. > > > The diagram in MANET-ARCH 5.1 could be adjusted to reflect my thoughts. > Below, it is more an example and less a "model". > > > <~~~~~~+~~~~~~> > | Assigned Prefix > | =================== > 2001:db8:0::EUI-64/64| <=== 2001:db8:0::/64 = > FE80::EUI-64/64| =================== > MANET Interface| Delegated Prefix > +-----------------------+ /-------------\ > | | <<<<<<<<<<<<| 2001:db8::/60 | > | MANET | \-------------/ > | Router | > | | > | ................... | Assigned Prefix > | !Loopback ! | ===================== > | !2001:db8:F::0/128! | <=== 2001:db8:F::0/128 = > | ''''''''''''''''''' | ===================== > +---------------+-------+ > Ethernet Interface: Assigned Prefix > FE80::EUI-64/64: =================== > 2001:db8:1::EUI-64/64: <======== 2001:db8:1::/64 = > : =================== > .............. > : : > FE80::EUI-64/64: :FE80::EUI-64/64 > 2001:db8:1::dhcp/64: :2001:db8:1::EUI-64/64 > +--------------+-+ +--+--------------+ > | Host with DHCP | * * * | Host with SLAAC | > +----------------+ +-----------------+ In the above figure: I agree with many points that I won't mention. But I don't agree using the loopback interface for this. And I don't understand why there's a "MANET Interface" and a "Ethernet interface". I really don't see the need for any virtual interface. Let me give my take on virtual interfaces... Some routing protocols use virtual interfaces because at least the following problem: it has been shown in practice that when a e.g. wifi interface gets disassociated from the AP the interface may go down, and in some implementations it may SIGKILL (or worse) the app using that socket. And if the app is the routing protocol the net effect is very bad: routing protocol crashes. This was very bad. It also meant that whenever I would disconnect the Ethernet cable (on some implementations, again), the routing protocol implementation would crash; or when my bluetooth interface gets down. Or similar 'mobility' event which would never previously appear in the fixed-router-Internet, because people wouldn't consciously disconnect Ethernet cables whereas phone lines would still get jammed (a modem line being overloaded wouldn't SIGKILL the app running on that kernel, because modem separated from computer by rs-232 and rs-232 no interface structure). To cope with that, put up a virtual interface and add routes between that virtual interface and the wifi interface. And run the routing protocol on top of _that_ virtual interface instead of the wifi interface. Since it is virtual it never gets down (unless maybe a tree falls), the routing protocol implementation will crash less. It was thus shown that the routing protocol running on a virtual interface is advantageous, dealing better with mobility events - at least it could be deterministic! However, there exist also implementations of wifi drivers which won't put the interface down when the interface gets dissasociated. Also there exist kernels which won't SIGKILL the app, and there exist also protocols implementations who'd deal with that SIGKILL more gently if it popped up. Also there exist implementations of routing protocols who would not deal at all with any particular interface structure (be that real or virtual) - they're independent on the kernel's interface structures being up or down or whatever state, but use directly the card's buffers to send or receive data. I agree though these implementations are less widespread. Overall, I think a safe bet is somewhere in the middle: to not talk about virtual interfaces (neither loopback, nor others) but only about real interfaces and of specific types. And to consider the virtual interfaces to be a detail of _some_ implementations. Alex > > In a table format: > > Delegated summary prefix: 2001:db8::/60 > 15 x /64: MANET Interface: 2001:db8:0::/64 > Ethernet Interface: 2001:db8:1::/64 > " " " " " " " > up to: 2001:db8:E::/64 > Block for longer prefix lengths: 2001:db8:F::/64 > Loopback Interface #0: 2001:db8:F::0/128 > (others, e.g. P2P) " " " > > > This model provides RFC4862 SLAAC service for nearby hosts, also useful for > MANET Router (or NEMO Router) bootstrapping. For getting a delegated prefix, > the a SLAAC address could be used for communication with a DHCP server, > using unicast (to be verified). Important: the /64 prefix that corresponds > with the SLAAC address-prefix MUST NOT be advertized in the MANET Routing > Protocol. Advertizing this as a host prefix is allowed, but getting an own > /60 or whatsoever summary is advised. The result here is a MANET Routing > Protocol requirement (not advertizing /64 SLAAC prefixes). > The MANET Router may act as DHCP Server (or relay agent) for its Delegated > Prefix(es). SLAAC is also supported. > > > > On dec 2007 I posted similar thoughts > (http://www.ietf.org/mail-archive/web/autoconf/current/msg00901.html). > Are we making progress? I think: yes! > > > Teco. > > > > > > |-----Oorspronkelijk bericht----- > |Van: Charles E. Perkins [mailto:charles.perkins@earthlink.net] > |Verzonden: woensdag 4 maart 2009 0:27 > |Aan: Teco Boot > |CC: autoconf@ietf.org > |Onderwerp: Re: [Autoconf] Autoconf addressing model > | > | > |Hello Teco, > | > |You raise interesting questions, but I think mostly > |not definitive for the questions at hand. I don't know > |if I have any good answers, but here are some comments. > | > |Teco Boot wrote: > |> As long as I designed and maintained network infrastructures, I worked > |with > |> "/32 management addresses" on loopback interfaces. Still, I have > |annoying > |> experiences with routers that select the outgoing interface address as > |> default source address. Shutting down an interface could have > |unintended bad > |> impact on your terminal session. Same for link flapping due to other > |causes. > |> > | > |I guess this is relevant for packet forwarders with more than one > |network interface. For our little wireless nodes that have a single > |interface, I don't imagine we'd see that kind of interface aggravation. > | > |> For this reason, many routers on the Internet use the loopback > |interface for > |> "management". "Management" is the host application on routers. There > |are > |> lots of design guidelines for this. My proposal is using the "Internet > |> lessons learned" in the MANET. Nothing wrong with this, agreed? > |> > | > |I know only a small bit about this. Do you have a favorite > |document that I could read to learn more? > | > |> > |> With MobileIP, we are discussing a host (could be NEMO Router, but > |then it > |> acts as host on the visiting link). The MobileIP stack is interested > |in the > |> status of the visiting link, but does it propagate this to the > |applications? > |> Or use the applications some kind of virtual interface (e.g. a > |loopback > |> interface)? Or spoof ifup for interface to home link? > |> > | > |Whether or not applications have access to link information is > |something not closely related to Mobile IP. Whether or not > |the care-of address is available to applications is a surprisingly > |complicated question, which in my opinion opens the door to > |many interesting questions and indicates the insufficiency of > |today's typical application socket interface. > | > |I've had a lot of ideas about how to fix this, but never been > |able to initiate a project to supply a finished proposal. > | > | > |Regards, > |Charlie P. > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From alexandru.petrescu@gmail.com Wed Mar 4 15:45:08 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 413843A684E for ; Wed, 4 Mar 2009 15:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[AWL=0.147, 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 uRYUEMt49kq8 for ; Wed, 4 Mar 2009 15:45:06 -0800 (PST) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by core3.amsl.com (Postfix) with ESMTP id 9BBB83A6988 for ; Wed, 4 Mar 2009 15:45:05 -0800 (PST) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id 8FFAC4C8020; Thu, 5 Mar 2009 00:45:28 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp4-g21.free.fr (Postfix) with ESMTP id 42B8A4C808E; Thu, 5 Mar 2009 00:45:26 +0100 (CET) Message-ID: <49AF1292.3050208@gmail.com> Date: Thu, 05 Mar 2009 00:45:22 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Teco Boot References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com><000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com><1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl><49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl><49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl><49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl><49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl><49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net> <49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com> <000c01c99ce9$e09bf500$a1d3df00$@nl> <49AEB846.5020103@gmail.com> <000101c99d00$664c7f60$32e57e20$@nl> In-Reply-To: <000101c99d00$664c7f60$32e57e20$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090303-2, 04/03/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Wed, 04 Mar 2009 23:45:08 -0000 Teco Boot a écrit : > Inline. > > |-----Oorspronkelijk bericht----- > |Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > |Verzonden: woensdag 4 maart 2009 18:20 > |Aan: Teco Boot > |CC: 'Alexandru Petrescu'; 'Stan Ratliff (sratliff)'; autoconf@ietf.org > |Onderwerp: Re: [Autoconf] Autoconf addressing model > | > |Teco Boot a écrit : > |> Alex, > |> > |> It happen to be I am working on the customer side, not the equipment > |> vendor / supplier side. I can say your limitations for 25meter and a > |> requirement for relay nodes with multiple interfaces are far, far > |> from acceptable. I go for what Stan says. Sorry, I cannot go into > |> details on what the specs are. I am not in the position to say you, > |> this is not the medium to publish and moreover, there is no need for > |> these details. We in IETF never went in this before (e.g. there is no > |> range limitation for ICMP messages). > | > |I meant to say to explicitely consider the characteristics of the > |link-layers you consider for AUTOCONF ad-hoc networks. These all have > |specifications about their physical lengths (for wired), for dbm > |powerlevels and range in meters (wireless). > > The problem with this is that it is of almost no use for an ad hoc network. > Ad hoc means "to this", "for this purpose". It refers to dealing with > special situations as they occur rather than functions that are repeated on > a regular basis. (http://www.answers.com/topic/ad-hoc). Or "created on the > spur of the moment, impromptu" (http://en.wiktionary.org/wiki/ad_hoc). Along these lines, an interpretation of 'ad-hoc' is a happening which hasn't been planned, spontaneous, etc. This would contradict the goal of planning an addressing architecture for it, unless the limits of movement and the characteristics of the underlying link-layers are noted. Alex From dream.hjlim@gmail.com Wed Mar 4 15:51:40 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A9053A68AA; Wed, 4 Mar 2009 15:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.404 X-Spam-Level: X-Spam-Status: No, score=-2.404 tagged_above=-999 required=5 tests=[AWL=0.194, 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 trTX7bXxIj8h; Wed, 4 Mar 2009 15:51:39 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.185]) by core3.amsl.com (Postfix) with ESMTP id B9B583A684E; Wed, 4 Mar 2009 15:51:38 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id 11so3455894tim.25 for ; Wed, 04 Mar 2009 15:52:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=B4dEyZzQIwT/bpfCTKHtD/smJlvq+uJMumBPLeWE9MY=; b=hINSaV451lOkSagUjCns0CMjdOFY1c87gi7+nRh0XbBO/tdGoj8tdh3t0AZyOliffW Np/3IT7+elRWEtM63bqWXQVIbgbZubUlTODt7AwOHahDPtVG10OiglMSpvp+swurtoWj DZ1Y3fITloVHLtyOMYW3BYXaw26lm2dDIVft8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ns3xHwxdwpbZq8pytALxjaIHzFXVpEQ2+JhoNOkwCvkWMQkfAb4xhpIx094CoX+1mv 3PftpJfBQ1l/1glowKmAts/N4tSjrDV+9zbWsXtTShCFNV+X+K9wDTwkWBNU/CfHlG5f 7nuGF2ue5VIUdpJ954s9LNiZObMlIDQrH9zAY= MIME-Version: 1.0 Received: by 10.110.57.5 with SMTP id f5mr663479tia.49.1236210726589; Wed, 04 Mar 2009 15:52:06 -0800 (PST) In-Reply-To: <20090304163257.82E843A6B2E@core3.amsl.com> References: <20090304163257.82E843A6B2E@core3.amsl.com> Date: Thu, 5 Mar 2009 08:52:06 +0900 Message-ID: <7e8d02d40903041552r5a38bd1dp59ab865c0f463c@mail.gmail.com> From: HyungJin Lim To: iesg@ietf.org Content-Type: multipart/alternative; boundary=001485f01d6039f76a046453bd37 Cc: autoconf@ietf.org Subject: Re: [Autoconf] WG Review: Recharter of Ad-Hoc Network Autoconfiguration (autoconf) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 23:51:40 -0000 --001485f01d6039f76a046453bd37 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Inline... 2009/3/5 IESG Secretary > A modified charter has been submitted for the Ad-Hoc Network > Autoconfiguration working group in the Internet Area of the IETF. The > IESG has not made any determination as yet. The modified charter is > provided below for informational purposes only. Please send your comments > to the IESG mailing list (iesg@ietf.org) by Wednesday, March 11, 2009. > > Ad-Hoc Network Autoconfiguration (autoconf) > ------------------------------------------------------------- > Last Modified: 2009-02-18 > > Current Status: Active Working Group > > Additional information is available at tools.ietf.org/wg/autoconf > > Chair(s): > Ryuji Wakikawa [ryuji.wakikawa@gmail.com] > Thomas Clausen [T.Clausen@computer.org] > > Internet Area Director(s): > Jari Arkko [jari.arkko@piuha.net] > Mark Townsley [townsley@cisco.com] > > Internet Area Advisor: > Jari Arkko [jari.arkko@piuha.net] > > Mailing Lists: > General Discussion: autoconf@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf > Archive: > http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html > > Description of Working Group: > > In order to communicate among themselves, ad hoc nodes (refer to RFC > 2501) need to configure their network interface(s) with local addresses > that are valid within an ad hoc network. Ad hoc nodes may also need to > configure globally routable addresses, in order to communicate with > devices on the Internet. From the IP layer perspective, an ad hoc > network presents itself as a L3 multi-hop network formed over a > collection of links. > In here, I have a question ! What's meaning of globally routable addresses ? I think globally routable addresses should include topologically correct address and topologically incorrect address. The reason I address this is that the NEMO basic support should configure topologically incorrect address in nested NEMO. But topologically incorrect address is also globally routable addresses if it a packet forwarding mechanism (e.g., tunneling) is supported, not packet routing(e.g. OLSR, DYMO, etc.). > > The main purpose of the AUTOCONF WG is to describe the addressing model > for ad hoc networks and how nodes in these networks configure their > addresses. It is required that such models do not cause problems for ad > hoc-unaware parts of the system, such as standard applications running > on an ad hoc node or regular Internet nodes attached to the ad hoc > nodes. This group's effort may include the development of new protocol > mechanisms, should the existing IP autoconfiguration mechanisms be found > inadequate. However, the first task of the working group is to describe > one practical addressing model for ad hoc networks. > What's meaning of practical addressing model ? Should we consider practical scenarios for practical addressing model in real world ? The only simplest scenario can satisfy requirements and other aspects in more complex scenario which include Internet connectivity, nested pattern, group mobility, wireless coverage, and so on. I would like suggest to define some requirements for practical scenarios. Then, the simplest scenario also can be considered as a base topic I think. Hyung-Jin, Lim > > Once this sole work item is completed, the group can be rechartered to > work on additional issues. > > Goals and Milestones: > > Apr 2009 Submit initial draft on address configuration in ad hoc networks > Sep 2009 Submit address configuration draft to IESG as Informational or > close WG > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > --001485f01d6039f76a046453bd37 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Inline...

2009/3/5 IESG Secretary <iesg-secretary@ietf.org>
A modified charter has been subm= itted for the Ad-Hoc Network
Autoconfiguration working group in the Inte= rnet Area of the IETF. =A0The
IESG has not made any determination as yet. =A0The modified charter is
p= rovided below for informational purposes only. =A0Please send your comments=
to the IESG mailing list (iesg@ietf.or= g) by Wednesday, March 11, 2009.

Ad-Hoc Network Autoconfiguration (autoconf)
------------------------= -------------------------------------
Last Modified: 2009-02-18

C= urrent Status: Active Working Group

Additional information is availa= ble at tool= s.ietf.org/wg/autoconf

Chair(s):
Ryuji Wakikawa [ryuji.wakikawa@gmail.com]
Thomas Clausen [T.Clausen@computer.org]

Internet Area Director= (s):
Jari Arkko [jari.arkko@piuha.net]
Mark Townsley [townsley@cisco.c= om]

Internet Area Advisor:
Jari Arkko [jari.arkko@piuha.net]

Mailing Lists:
General Discussion: autoconf@ietf.org
To Subscribe: https://www.ietf.org/mailman/l= istinfo/autoconf
Archive:
http://www.ietf.org/mail-archive/web/aut= oconf/current/maillist.html

Description of Working Group:
In order to communicate among themselves, ad hoc nodes (refer to RFC
250= 1) need to configure their network interface(s) with local addresses
tha= t are valid within an ad hoc network. Ad hoc nodes may also need to
configure globally routable addresses, in order to communicate with
devi= ces on the Internet. From the IP layer perspective, an ad hoc
network pr= esents itself as a L3 multi-hop network formed over a
collection of link= s.
=A0
In here, I have a question !
What's meaning of globally routable addresses ?
I think globally routable addresses should include topologically corre= ct address and topologically incorrect address.
The reason I address this is that the NEMO basic support should config= ure topologically incorrect address in nested NEMO.
But topologically incorrect address is also globally routable addresse= s if it=A0a packet forwarding mechanism (e.g., tunneling)=A0is supported, n= ot packet routing(e.g. OLSR, DYMO, etc.).
=A0

The mai= n purpose of the AUTOCONF WG is to describe the addressing model
for ad = hoc networks and how nodes in these networks configure their
addresses. It is required that such models do not cause problems for ad
= hoc-unaware parts of the system, such as standard applications running
o= n an ad hoc node or regular Internet nodes attached to the ad hoc
nodes.= This group's effort may include the development of new protocol
mechanisms, should the existing IP autoconfiguration mechanisms be foundinadequate. However, the first task of the working group is to describeone practical addressing model for ad hoc networks.
=A0
What's meaning of practical addressing model ?
Should we consider practical scenarios for practical addressing model = in real world ?
The only simplest scenario can satisfy requirements and other aspects = in more complex scenario which include Internet connectivity, nested patter= n, group mobility, wireless coverage, and so on.
=A0
I would like suggest to define some requirements for practical scenari= os.
Then, the simplest scenario also can be considered as a base topic I t= hink.
=A0
Hyung-Jin, Lim

Once th= is sole work item is completed, the group can be rechartered to
work on = additional issues.

Goals and Milestones:

Apr 2009 Submit initial draft on address c= onfiguration in ad hoc networks
Sep 2009 Submit address configuration dr= aft to IESG as Informational or
close WG

________________________= _______________________
Autoconf mailing list
Autoconf@ietf= .org
https://www.ietf.org/mailman/listinfo/autoconf

--001485f01d6039f76a046453bd37-- From teco@inf-net.nl Wed Mar 4 23:50:32 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07D1D28C11E for ; Wed, 4 Mar 2009 23:50:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.695 X-Spam-Level: X-Spam-Status: No, score=-1.695 tagged_above=-999 required=5 tests=[AWL=0.351, 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 vY2Ej1e8k3GD for ; Wed, 4 Mar 2009 23:50:25 -0800 (PST) Received: from hpsmtp-eml19.kpnxchange.com (hpsmtp-eml19.KPNXCHANGE.COM [213.75.38.84]) by core3.amsl.com (Postfix) with ESMTP id EB9B228C106 for ; Wed, 4 Mar 2009 23:50:24 -0800 (PST) Received: from cpsmtp-eml104.kpnxchange.com ([213.75.84.104]) by hpsmtp-eml19.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 08:50:52 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml104.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 08:50:52 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com><000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com><1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl><49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl><49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl><49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl><49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl><49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net> <49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com> <000c01c99ce9$e09bf500$a1d3df00$@nl> <49AEB846.5020103@gmail.com> <000101c99d00$664c7f60$32e57e20$@nl> <49A F1292.3050208@gmail.co m> In-Reply-To: <49AF1292.3050208@gmail.com> Date: Thu, 5 Mar 2009 08:50:52 +0100 Message-ID: <001701c99d67$1bb4b5f0$531e21d0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmdI0+AYp+eHSrVRZewbth4ppMY1AAQQbbQ Content-Language: nl X-OriginalArrivalTime: 05 Mar 2009 07:50:52.0761 (UTC) FILETIME=[1BA2B490:01C99D67] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Thu, 05 Mar 2009 07:50:32 -0000 |-----Oorspronkelijk bericht----- |Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] |Verzonden: donderdag 5 maart 2009 0:45 |Aan: Teco Boot |CC: 'Alexandru Petrescu'; 'Stan Ratliff (sratliff)'; autoconf@ietf.org |Onderwerp: Re: [Autoconf] Autoconf addressing model | |Teco Boot a =E9crit : |> Inline. |> |> |-----Oorspronkelijk bericht----- |> |Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] |> |Verzonden: woensdag 4 maart 2009 18:20 |> |Aan: Teco Boot |> |CC: 'Alexandru Petrescu'; 'Stan Ratliff (sratliff)'; |autoconf@ietf.org |> |Onderwerp: Re: [Autoconf] Autoconf addressing model |> | |> |Teco Boot a =E9crit : |> |> Alex, |> |> |> |> It happen to be I am working on the customer side, not the |equipment |> |> vendor / supplier side. I can say your limitations for 25meter and |a |> |> requirement for relay nodes with multiple interfaces are far, far |> |> from acceptable. I go for what Stan says. Sorry, I cannot go into |> |> details on what the specs are. I am not in the position to say = you, |> |> this is not the medium to publish and moreover, there is no need |for |> |> these details. We in IETF never went in this before (e.g. there is |no |> |> range limitation for ICMP messages). |> | |> |I meant to say to explicitely consider the characteristics of the |> |link-layers you consider for AUTOCONF ad-hoc networks. These all |have |> |specifications about their physical lengths (for wired), for dbm |> |powerlevels and range in meters (wireless). |> |> The problem with this is that it is of almost no use for an ad hoc |network. |> Ad hoc means "to this", "for this purpose". It refers to dealing with |> special situations as they occur rather than functions that are |repeated on |> a regular basis. (http://www.answers.com/topic/ad-hoc). Or "created = on |the |> spur of the moment, impromptu" = (http://en.wiktionary.org/wiki/ad_hoc). | |Along these lines, an interpretation of 'ad-hoc' is a happening which |hasn't been planned, spontaneous, etc. This would contradict the goal |of planning an addressing architecture for it, unless the limits of |movement and the characteristics of the underlying link-layers are |noted. There is a difference in a) designing and building a network, ready for deployment and b) planning for actual deployment. In military, actual deployment does not occur quite often (luckily!), but it is exercised repeatedly. For public safety / disaster relief, the network is often in = use for normal conditions (no disaster), here we may have restrictions as = you suggest. But as soon as there is a disaster (small, large), the = conditions may no longer be true. Here also, the large disasters do not occur frequently. But if it occurs, damage can be huge.=20 For both use cases (military and disaster relief), the requirement is = that the network provides as much connectivity as technically possible, also = in unforeseen conditions. Sorry to bother you with one of the major requirements I am facing, and I am sure I am not the only one. As said, MANET is being worked on for many years and actually being deployed. I described the difference in designing and planning deployment. For designing the network, we need components that have certain = characteristics, e.g. working well in an ad hoc (unplanned) fashion. IMHO this means, = that when a radio link works well over 25 meter, and it is being used in 30 = meter or an obstacle breaks the link or makes it uni-directional (see my = diagrams for details), the network may not melt down. Connectivity should = restored using alternative paths if available and feasible. Let's go on with refinement an address model for MANETs. This is more important than quarreling on 25m or analyzing wording, I think. Teco. | |Alex From dream.hjlim@gmail.com Thu Mar 5 00:13:57 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40EA328C0F9; Thu, 5 Mar 2009 00:13:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.175, 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 5RZaZow6ewTC; Thu, 5 Mar 2009 00:13:56 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.184]) by core3.amsl.com (Postfix) with ESMTP id 55BFF3A67DB; Thu, 5 Mar 2009 00:13:55 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id 11so3590586tim.25 for ; Thu, 05 Mar 2009 00:14:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=dZn2eSB5aH55nMV20OaTWkAdg9tr0h+LktZXQFA8w+8=; b=CAb3GAk/m3qkfBRNcU5k3bZ7YYax1i/KkEDR+eCyNcAobBcEaoN4VcGv5t2RGDxIQ7 AoRfax3/ICh2iUeJBXs63JASKtNnHMMlmMNao3AddG9lo8B0WAmRsotO2OyXvCXIrZCx 1ZEnTrSo+jq43p5b10eUIP9/8BV78PoobyxEU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=e5IwZSEEYgifKt9J15hsg5yOsOxkv3sJFYQiSWbN0kIQOCRsnzl0CS2gWHpanS+fCN NtKu6trNnPFzID93w2K3rJC656UNXi4F1HxgxOhMNvPK8z1BDa1EaLyB5ZrrZfx37cq6 i/XDU3e9Mj0iai2GqGSJ7JSCgxV4PKZEnlWB4= MIME-Version: 1.0 Received: by 10.110.15.19 with SMTP id 19mr1425937tio.9.1236240862235; Thu, 05 Mar 2009 00:14:22 -0800 (PST) In-Reply-To: <7e8d02d40903041552r5a38bd1dp59ab865c0f463c@mail.gmail.com> References: <20090304163257.82E843A6B2E@core3.amsl.com> <7e8d02d40903041552r5a38bd1dp59ab865c0f463c@mail.gmail.com> Date: Thu, 5 Mar 2009 17:14:22 +0900 Message-ID: <7e8d02d40903050014u556bd7cbof6d7ec2d54901dd4@mail.gmail.com> From: HyungJin Lim To: iesg@ietf.org Content-Type: multipart/alternative; boundary=0016e64e92f0734f1e04645ac146 Cc: autoconf@ietf.org Subject: Re: [Autoconf] WG Review: Recharter of Ad-Hoc Network Autoconfiguration (autoconf) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 08:13:57 -0000 --0016e64e92f0734f1e04645ac146 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I'm sorry for correction about the following comment and duplicate comments. My first language is not English. ---------- Forwarded message ---------- From: HyungJin Lim Date: 2009/3/5 Subject: Re: [Autoconf] WG Review: Recharter of Ad-Hoc Network Autoconfiguration (autoconf) To: iesg@ietf.org Cc: autoconf@ietf.org, alexandru.petrescu@gmail.com Inline... 2009/3/5 IESG Secretary A modified charter has been submitted for the Ad-Hoc Network > Autoconfiguration working group in the Internet Area of the IETF. The > IESG has not made any determination as yet. The modified charter is > provided below for informational purposes only. Please send your comments > to the IESG mailing list (iesg@ietf.org) by Wednesday, March 11, 2009. > > Ad-Hoc Network Autoconfiguration (autoconf) > ------------------------------------------------------------- > Last Modified: 2009-02-18 > > Current Status: Active Working Group > > Additional information is available at tools.ietf.org/wg/autoconf > > Chair(s): > Ryuji Wakikawa [ryuji.wakikawa@gmail.com] > Thomas Clausen [T.Clausen@computer.org] > > Internet Area Director(s): > Jari Arkko [jari.arkko@piuha.net] > Mark Townsley [townsley@cisco.com] > > Internet Area Advisor: > Jari Arkko [jari.arkko@piuha.net] > > Mailing Lists: > General Discussion: autoconf@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf > Archive: > http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html > > Description of Working Group: > > In order to communicate among themselves, ad hoc nodes (refer to RFC > 2501) need to configure their network interface(s) with local addresses > that are valid within an ad hoc network. Ad hoc nodes may also need to > configure globally routable addresses, in order to communicate with > devices on the Internet. From the IP layer perspective, an ad hoc > network presents itself as a L3 multi-hop network formed over a > collection of links. > In here, I have a question ! What's meaning of globally routable addresses ? I think globally routable addresses should include topologically correct address and topologically incorrect address. The reason I address this is that the NEMO basic support should configure topologically incorrect address in nested NEMO. But topologically incorrect address is also globally routable addresses if it a packet forwarding mechanism (e.g., tunneling) is supported, not packet routing(e.g. OLSR, DYMO, etc.). > > The main purpose of the AUTOCONF WG is to describe the addressing model > for ad hoc networks and how nodes in these networks configure their > addresses. It is required that such models do not cause problems for ad > hoc-unaware parts of the system, such as standard applications running > on an ad hoc node or regular Internet nodes attached to the ad hoc > nodes. This group's effort may include the development of new protocol > mechanisms, should the existing IP autoconfiguration mechanisms be found > inadequate. However, the first task of the working group is to describe > one practical addressing model for ad hoc networks. > What's meaning of practical addressing model ? *Although we already discussed this issue in MANEMO BoF,* *we should *consider practical scenarios for practical addressing model in real world I think. The only simplest scenario *can not* satisfy requirements and other aspects in more complex scenario which include Internet connectivity, nested pattern, group mobility, wireless coverage, and so on. I would like suggest to define some requirements for practical scenarios. Then, the simplest scenario also can be considered as a base topic of them I think. Hyung-Jin, Lim > > Once this sole work item is completed, the group can be rechartered to > work on additional issues. > > Goals and Milestones: > > Apr 2009 Submit initial draft on address configuration in ad hoc networks > Sep 2009 Submit address configuration draft to IESG as Informational or > close WG > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > --0016e64e92f0734f1e04645ac146 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm sorry=A0for correction=A0about the following comment and dupli= cate comments.
My first language is not English.

---------- Forwarded message ----------
From:= HyungJin Lim <dream.hjlim@gmail.com>Date: 2009/3/5
Subject: Re: [Autoconf] WG Review: Recharter of Ad-Hoc Network Autoconfigur= ation (autoconf)
To: iesg@ietf.org<= br>Cc: autoconf@ietf.org, alexandru.petrescu@gmail.com

Inline...

2009/3/5 IESG Secretary <iesg-secretary@i= etf.org>=20

A modified charter has been subm= itted for the Ad-Hoc Network
Autoconfiguration working group in the Inte= rnet Area of the IETF. =A0The
IESG has not made any determination as yet. =A0The modified charter is
p= rovided below for informational purposes only. =A0Please send your comments=
to the IESG mailing list (iesg@ietf.org) by Wednesday, March 11, 2009.

Ad-Hoc Network Autoconfiguration (autoconf)
------------------------= -------------------------------------
Last Modified: 2009-02-18

C= urrent Status: Active Working Group

Additional information is availa= ble at tool= s.ietf.org/wg/autoconf

Chair(s):
Ryuji Wakikawa [ryuji.wakikawa@gmail.com]
Thomas Clausen [T.Clausen@computer.or= g]

Internet Area Director(s):
Jari Arkko [jari.arkko@piuha.net]
Mark Townsley [townsley@cisco.com]

Internet Area Advisor:
Jari Arkko [jari.arkko@piuha.net]

Mailing Lists:General Discussion: autoconf@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf
Archi= ve:
http://www.ietf.org/mail-archive/web/autoconf= /current/maillist.html

Description of Working Group:

In order to communicate among them= selves, ad hoc nodes (refer to RFC
2501) need to configure their network= interface(s) with local addresses
that are valid within an ad hoc netwo= rk. Ad hoc nodes may also need to
configure globally routable addresses, in order to communicate with
devi= ces on the Internet. From the IP layer perspective, an ad hoc
network pr= esents itself as a L3 multi-hop network formed over a
collection of link= s.
=A0
In here, I have a question !
What's meaning of globally routable addresses ?
I think globally routable addresses should include topologically corre= ct address and topologically incorrect address.
The reason I address this is that the NEMO basic support should config= ure topologically incorrect address in nested NEMO.
But topologically incorrect address is also globally routable addresse= s if it=A0a packet forwarding mechanism (e.g., tunneling)=A0is supported, n= ot packet routing(e.g. OLSR, DYMO, etc.).
=A0

The main purpos= e of the AUTOCONF WG is to describe the addressing model
for ad hoc netw= orks and how nodes in these networks configure their
addresses. It is required that such models do not cause problems for ad
= hoc-unaware parts of the system, such as standard applications running
o= n an ad hoc node or regular Internet nodes attached to the ad hoc
nodes.= This group's effort may include the development of new protocol
mechanisms, should the existing IP autoconfiguration mechanisms be foundinadequate. However, the first task of the working group is to describeone practical addressing model for ad hoc networks.
=A0
What's meaning of practical addressing model ?
Although we already discussed this issue in MANEMO BoF, we should consider practical scenarios for practical ad= dressing model in real world I think.
The only simplest scenario can not=A0satisfy requirem= ents and other aspects in more complex scenario which include Internet conn= ectivity, nested pattern, group mobility, wireless coverage, and so on.
=A0
I would like suggest to define some requirements for practical scenari= os.
Then, the simplest scenario also can be considered as a base=A0 topic = of them I think.
=A0
Hyung-Jin, Lim

Once this sole = work item is completed, the group can be rechartered to
work on addition= al issues.

Goals and Milestones:

Apr 2009 Submit initial draft on address c= onfiguration in ad hoc networks
Sep 2009 Submit address configuration dr= aft to IESG as Informational or
close WG

________________________= _______________________
Autoconf mailing list
Autoconf@ietf.org
https://www.ietf.org/mailman/listinfo/autoc= onf


--0016e64e92f0734f1e04645ac146-- From teco@inf-net.nl Thu Mar 5 00:42:37 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 090123A690A for ; Thu, 5 Mar 2009 00:42:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.707 X-Spam-Level: X-Spam-Status: No, score=-1.707 tagged_above=-999 required=5 tests=[AWL=0.339, 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 dENWn7pzSrWX for ; Thu, 5 Mar 2009 00:42:34 -0800 (PST) Received: from cpsmtpo-eml03.kpnxchange.com (cpsmtpo-eml03.KPNXCHANGE.COM [213.75.38.152]) by core3.amsl.com (Postfix) with ESMTP id 351B83A67DB for ; Thu, 5 Mar 2009 00:42:34 -0800 (PST) Received: from cpsmtp-eml103.kpnxchange.com ([213.75.84.103]) by cpsmtpo-eml03.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 09:43:02 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml103.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 09:43:01 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl> <49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl> <49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl> <49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl> <49AD90D9.5040100@earthlink.net> <000c01c99c4f$d1ab1750$750145f0$@nl> <49ADBCD8.9040301@earthlink.net> <000901c99d1c$a2d939c0$e88bad40$@nl> <49AF1191.1080307@gmail.com> In-Reply-To: <49AF1191.1080307@gmail.com> Date: Thu, 5 Mar 2009 09:43:02 +0100 Message-ID: <001e01c99d6e$64f7e1e0$2ee7a5a0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmdIrZR3d7/fKNuR7ecLwC2IlTsvwARGwCQ Content-Language: nl X-OriginalArrivalTime: 05 Mar 2009 08:43:01.0761 (UTC) FILETIME=[64AA3710:01C99D6E] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Thu, 05 Mar 2009 08:42:37 -0000 |-----Oorspronkelijk bericht----- |Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] |Verzonden: donderdag 5 maart 2009 0:41 |Aan: Teco Boot |CC: autoconf@ietf.org |Onderwerp: Re: [Autoconf] Autoconf addressing model | |Teco Boot a =E9crit : |> =3D=3D back to the addressing model: |> After some more thoughts, I come to the conclusion that MANET Routers |should |> advertize as little as possible, for reducing overhead. This is about |> routing prefixes. The advertized prefix should "belong" to the |indivisible |> "mobile object", this means the summary prefix must not split and |> sub-prefixes (subnets??) shall be interconnected within the "mobile |object". |> Single router "mobile object" has this behavior by nature. |> Addresses assigned to interfaces come from the advertized prefix and |may |> have any prefix-length equal or longer than the advertized prefix- |length. |> Loopback interfaces should have /128 (or /32), as defined in RFCs for |this. |> Ethernet typically have /64, this is specified in std track RFC and = it |is a |> MUST if SLAAC is used. |> Still the question on using /128, /64 or other for globally unique |> address-prefixes that are assigned to MANET interfaces of this = "mobile |> object". Maybe we do not need to restrict this. Mentioning the = options |and |> the consequences is good enough, I think. |> Some consequences with /127 are described in RFC3627. This RFC also |mentions |> /128: |> Using two /128 addresses is also one, though often cumbersome, |> approach. Naturally, not much would be lost if even a shorter |> prefix was used, e.g., /112 or /120. |> |> |> The diagram in MANET-ARCH 5.1 could be adjusted to reflect my |thoughts. |> Below, it is more an example and less a "model". |> |> |> <~~~~~~+~~~~~~> |> | Assigned Prefix |> | = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |> 2001:db8:0::EUI-64/64| <=3D=3D=3D 2001:db8:0::/64 =3D |> FE80::EUI-64/64| = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |> MANET Interface| Delegated Prefix |> +-----------------------+ /-------------\ |> | | <<<<<<<<<<<<| 2001:db8::/60 | |> | MANET | \-------------/ |> | Router | |> | | |> | ................... | Assigned Prefix |> | !Loopback ! | = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |> | !2001:db8:F::0/128! | <=3D=3D=3D 2001:db8:F::0/128 =3D |> | ''''''''''''''''''' | = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |> +---------------+-------+ |> Ethernet Interface: Assigned Prefix |> FE80::EUI-64/64: = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |> 2001:db8:1::EUI-64/64: <=3D=3D=3D=3D=3D=3D=3D=3D = 2001:db8:1::/64 =3D |> : = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |> .............. |> : : |> FE80::EUI-64/64: :FE80::EUI-64/64 |> 2001:db8:1::dhcp/64: :2001:db8:1::EUI-64/64 |> +--------------+-+ +--+--------------+ |> | Host with DHCP | * * * | Host with SLAAC | |> +----------------+ +-----------------+ | |In the above figure: I agree with many points that I won't mention. Thanks. |But I don't agree using the loopback interface for this. You don't have to. I mean by this, I will not enforce using a loopback. = I only lists the advantages, which you didn't agree on. I posted reference = to some material that proves using loopback interfaces is BCP in ISP and enterprise, and I think every addressing model MUST support loopback interfaces. Please reply [ agree | not agree ]. Please take some time to understand the consequence of your answer, you may lock-out yourself = being not compatible with many others. I think: we in IETF do your utmost to = be compatible. Having said this, I will be compatible with you if you do not use = loopback interfaces (open door for me). I would not use loopback interfaces in = every case myself (posted before, example was applications for high = availability that manage interface state themselves). I also strive to reduce host = routes to the maximum extend, for efficiency (ales posted before). In this case = my loopback is hidden for you. If not hidden by summarization, I publish a = host prefix.=20 |And I don't understand why there's a "MANET Interface" and a "Ethernet |interface". I really don't see the need for any virtual interface. Hey, this is just an example. |Let me give my take on virtual interfaces... | |Some routing protocols use virtual interfaces because at least the |following problem: it has been shown in practice that when a e.g. wifi |interface gets disassociated from the AP the interface may go down, and |in some implementations it may SIGKILL (or worse) the app using that |socket. And if the app is the routing protocol the net effect is very |bad: routing protocol crashes. This was very bad. =20 I understand this condition very well. But I have very, very different result. My routing protocol does not crash (if so, I'll have repaired = it). My routing protocol automatically provides an alternative path for me. For other applications, the effect could harm end user experience. For example, a terminal session would disconnect. The user may set up a new connection via alternative paths, using other addresses. We need a = solution for this problem, agreed? |It also meant that |whenever I would disconnect the Ethernet cable (on some = implementations, |again), the routing protocol implementation would crash; or when my |bluetooth interface gets down. =20 Again, not in my network. |Or similar 'mobility' event which would |never previously appear in the fixed-router-Internet, because people |wouldn't consciously disconnect Ethernet cables whereas phone lines |would still get jammed (a modem line being overloaded wouldn't SIGKILL |the app running on that kernel, because modem separated from computer = by |rs-232 and rs-232 no interface structure). RS-232 (and many other serial line technologies) have interface state. I designed networks with fast rerouting (sub-second) using serials. And for sure, the routing protocol did not crash!!! |To cope with that, put up a virtual interface and add routes between |that virtual interface and the wifi interface. And run the routing |protocol on top of _that_ virtual interface instead of the wifi |interface. =20 I think you mean here a bridge interface. You suggested this before. You still own me your test results with 802.11 (IBSS mode) interface and Ethernet interface in a bridge. |Since it is virtual it never gets down Are you sure on this? What if the bridge interface have no ports in up = state in it? I know equipment where the bridge interface goes down as soon as there is no port in up state anymore. Maybe I use the more enhanced = stuff (I can configure this behavior). |(unless maybe a tree |falls), the routing protocol implementation will crash less. My routing protocol implementation will not crash as trees falls. |It was |thus shown that the routing protocol running on a virtual interface is |advantageous, dealing better with mobility events - at least it could = be |deterministic! It would take another 100 pages to explain when to use the loopback interface and when the physical interface for the routing protocol. = Please read some books on IGP and EGP, after that iBGP and eBGP. Or ask some = folks that build BGP networks. The issue here is, do we use the loopback interface or physical = interface for our host applications running on the MANET Router? Maybe we want to = use loopback for our terminal session, and physical for our wonderful ping = tool. |However, there exist also implementations of wifi drivers which won't |put the interface down when the interface gets dissasociated. Also |there exist kernels which won't SIGKILL the app, and there exist also |protocols implementations who'd deal with that SIGKILL more gently if = it |popped up. Such implementations will introduce problems for our routing protocols = for fast rerouting. And yes, I prefer not bothering end users with messages due to SIGKILL. = I have a reconnect button on my terminal emulation application, and = automatic login. I can even configure automatic relogin. However, this will not restore my state on the other host and my work-in-progress would get = lost. Or even worse, the command ifup cannot be given in anymore. I spoke to persons traveled a whole day because destroying their own terminal = session, to give the ifup on a console interface. I would not say loopback = interfaces solves everything, but is helpful in many, many cases. |Also there exist implementations of routing protocols who would not = deal |at all with any particular interface structure (be that real or = virtual) |- they're independent on the kernel's interface structures being up or |down or whatever state, but use directly the card's buffers to send or |receive data. I agree though these implementations are less = widespread. I can't follow what you mean here. Aren't we mix up control plane and = data plane here? I would stay far away from this, and if many of us do so, it = is indeed not widespread. |Overall, I think a safe bet is somewhere in the middle: to not talk |about virtual interfaces (neither loopback, nor others) but only about |real interfaces and of specific types. And to consider the virtual |interfaces to be a detail of _some_ implementations. Because you might be not compatible with what I am doing, I want to have this included in the addressing model. Then we know the state of compatibility. No problem with specifying using virtual interfaces (loopback or others) = is optional. And I prefer writing down when virtual interfaces (loopback or others) is useful and when not. For example, 802.1D specifies using a = bridge interface with a 802.11 port in IBSS mode is NOT allowed. You suggested = this scenario repeatedly and I responded over and over: it doesn't work (poor performance) and it is against the spec. Please come up with responses that we can agree on. We might be not far = from this. Teco. | |Alex | |> |> In a table format: |> |> Delegated summary prefix: 2001:db8::/60 |> 15 x /64: MANET Interface: 2001:db8:0::/64 |> Ethernet Interface: 2001:db8:1::/64 |> " " " " " " " |> up to: 2001:db8:E::/64 |> Block for longer prefix lengths: 2001:db8:F::/64 |> Loopback Interface #0: 2001:db8:F::0/128 |> (others, e.g. P2P) " " " |> |> |> This model provides RFC4862 SLAAC service for nearby hosts, also |useful for |> MANET Router (or NEMO Router) bootstrapping. For getting a delegated |prefix, |> the a SLAAC address could be used for communication with a DHCP |server, |> using unicast (to be verified). Important: the /64 prefix that |corresponds |> with the SLAAC address-prefix MUST NOT be advertized in the MANET |Routing |> Protocol. Advertizing this as a host prefix is allowed, but getting = an |own |> /60 or whatsoever summary is advised. The result here is a MANET |Routing |> Protocol requirement (not advertizing /64 SLAAC prefixes). |> The MANET Router may act as DHCP Server (or relay agent) for its |Delegated |> Prefix(es). SLAAC is also supported. |> |> |> |> On dec 2007 I posted similar thoughts |> = (http://www.ietf.org/mail-archive/web/autoconf/current/msg00901.html). |> Are we making progress? I think: yes! |> |> |> Teco. |> |> |> |> |> |> |-----Oorspronkelijk bericht----- |> |Van: Charles E. Perkins [mailto:charles.perkins@earthlink.net] |> |Verzonden: woensdag 4 maart 2009 0:27 |> |Aan: Teco Boot |> |CC: autoconf@ietf.org |> |Onderwerp: Re: [Autoconf] Autoconf addressing model |> | |> | |> |Hello Teco, |> | |> |You raise interesting questions, but I think mostly |> |not definitive for the questions at hand. I don't know |> |if I have any good answers, but here are some comments. |> | |> |Teco Boot wrote: |> |> As long as I designed and maintained network infrastructures, I |worked |> |with |> |> "/32 management addresses" on loopback interfaces. Still, I have |> |annoying |> |> experiences with routers that select the outgoing interface = address |as |> |> default source address. Shutting down an interface could have |> |unintended bad |> |> impact on your terminal session. Same for link flapping due to |other |> |causes. |> |> |> | |> |I guess this is relevant for packet forwarders with more than one |> |network interface. For our little wireless nodes that have a single |> |interface, I don't imagine we'd see that kind of interface |aggravation. |> | |> |> For this reason, many routers on the Internet use the loopback |> |interface for |> |> "management". "Management" is the host application on routers. |There |> |are |> |> lots of design guidelines for this. My proposal is using the |"Internet |> |> lessons learned" in the MANET. Nothing wrong with this, agreed? |> |> |> | |> |I know only a small bit about this. Do you have a favorite |> |document that I could read to learn more? |> | |> |> |> |> With MobileIP, we are discussing a host (could be NEMO Router, but |> |then it |> |> acts as host on the visiting link). The MobileIP stack is |interested |> |in the |> |> status of the visiting link, but does it propagate this to the |> |applications? |> |> Or use the applications some kind of virtual interface (e.g. a |> |loopback |> |> interface)? Or spoof ifup for interface to home link? |> |> |> | |> |Whether or not applications have access to link information is |> |something not closely related to Mobile IP. Whether or not |> |the care-of address is available to applications is a surprisingly |> |complicated question, which in my opinion opens the door to |> |many interesting questions and indicates the insufficiency of |> |today's typical application socket interface. |> | |> |I've had a lot of ideas about how to fix this, but never been |> |able to initiate a project to supply a finished proposal. |> | |> | |> |Regards, |> |Charlie P. |> |> _______________________________________________ |> Autoconf mailing list |> Autoconf@ietf.org |> https://www.ietf.org/mailman/listinfo/autoconf |> From alexandru.petrescu@gmail.com Thu Mar 5 01:14:23 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C720828C1C3 for ; Thu, 5 Mar 2009 01:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=0.142, 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 0k88sUg6AEH8 for ; Thu, 5 Mar 2009 01:14:22 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 7D7F628C132 for ; Thu, 5 Mar 2009 01:14:20 -0800 (PST) Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id 7A53B9401E3; Thu, 5 Mar 2009 10:14:44 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 90A6094001B; Thu, 5 Mar 2009 10:14:41 +0100 (CET) Message-ID: <49AF97FA.7020007@gmail.com> Date: Thu, 05 Mar 2009 10:14:34 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Stan Ratliff (sratliff)" References: <499F0BA7.90501@piuha.net> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com><1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl><49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl><49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl><49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl><49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl><49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net> <49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D803@xmb-rtp-208.amer.cisco.com> <49AEBA6D.7030903@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5DB1F@xmb-rtp-208.amer.cisco.com> In-Reply-To: <7FB7EE0A621BA44B8B69E5F0A09DC76407B5DB1F@xmb-rtp-208.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090305-0, 05/03/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Thu, 05 Mar 2009 09:14:23 -0000 I wanted to clarify better myself because I think I'm misunderstood, sorry for insisting on what may appear as circles but I don't want to be understood so. Stan Ratliff (sratliff) a écrit : >> Stan Ratliff (sratliff) a écrit : >>> First off, you *can't* arbitrarily limit subnets to 25m. 25m from >>> what? The center? >> Yes, an area of 25meters with a wifi access point in the center. > > *By definition*, what you describe is not a MANET. As you state, > that's just a WiFi access point. Ok, I said AP because in a hurry. I also meant AP-free wifi adhoc mode gatherings of ad-hoc interfaces. The coverage is also about 25meter. This is dictated by the max power levels (a number of milliwatts) which says how strong can 2.5GHz emit in unlicensed spectrum. If all such ad-hoc interfaces of that IPv6 subnet stay within 25meter range then they're all fully exposed (no hidden terminals). And I also mean that larger networks could be made out of building blocks of 25m (because of powerlevel-limited because unlicensed-spectrum), by using Routers. And still keeping the IPv6 subnet to be as small at the safe area in which there are all exposed terminals, no hidden terminals. I hope I'm clearer. > That's already solved -- 802.11 clients can roam from access point to > access point. Well yes and no, depends how it's deployed. If the APs are bridging into a backbone then yes, terminals keep their addresses. But if the APs route then it's not solved. (Proxy) Mobile IP may be a solution for it, but it has its inconvenients in path lengths (RO) and tunnels. > But again, this should not be an 802.11-centric discussion. I agree to have it on more than 802.11. I've been told recently it's not good for link layer characteristics to control the link-layers to IP addressing. Yes, put that way I agree with it - I don't want link-layers to control IP, rather vice-versa. But it's also true that an IPv6 link-local address on Ethernet depends directly on the MAC addres (a link-layer ID), that an IPv6 subnet on 802.16 is a prefix-per-mobile model, and that IPv6 auto-configuration on 802.15.4 may use a form of address assigned in RA. That's what I wanted to say about AUTOCONF addressing architecture and specific link-layers. I hope I'm clearer. Alex >>> And, how do you designate the center? Do you constantly >> re-calculate >>> the center based on movement? >> No, not constantly re-computed. But have a fixed view at a point >> in time. Saying everything varies isn't helpful either. >> > > It may not be helpful, but it's reality. You can't rely on a fixed > view of a dynamic network; again, by definition, there's movement in > a MANET. Links come and go, and link quality varies from moment to > moment. > > >>> Also, from a radio perspective, how do you tell how far >> apart you are >>> in the first place? Do you suppose that all radios have >> GPS? That's a >>> non-starter, because GPS signals aren't always available. >> No I didn't suppose GPS is available on each device, it wouldn't >> work well under foliage. Just a rough evaluation of a specific >> link-layer radio range, correspondign to widely used networks. >> >>> And what about the wired MANET case brought up by Christopher >>> Dearlove? Should we limit the cable runs? >> YEs, certainly. All cabled link-layers have specific limitations >> on their lengths: 2m USB, 50m Ethernet Category6 (IIRC) and so on. >> >>> I could understand (but wouldn't really like) the notion of >>> limiting the discussion >> to links >>> that are transitive; but placing some arbitrary distance >> limit that's >>> based on 802.11 just doesn't cut it for me. >> 802.11 is being used widely, no reason to ignore. > > I'm not advocating we "ignore" 802.11, or any other L2 technology, > for that matter. I'm advocating that we remain Layer 2 agnostic. As > Teco mentioned in another email, there are people in this WG that > don't deploy MANET networks based on 802.11, or 802.16, or 802.15.4. > >> I'd happily accept to add another specific limitation, from the >> link-layer of your choice. And be speecifically addressing these >> two link layers. And maybe three. No more than three. >> >> I find addressing them all to be difficult for me. > > I don't understand why the Layer 3 addressing scheme needs to be > predicated on a specific Layer 2 technology, or set of technologies. > The Layer 3 addressing scheme should be totally independent of Layer > 2 -- isn't that what layering is all about? > >> (about single point of failure being destroyed by a falling tree: >> problem could be addressed at its layer: don't move the command >> center under trees risking falling); or maybe have two command >> centers, but specificllay two, not an arbitrary large unknown >> number. >> > > That essentially boils down to "if it hurts, don't do it", and it > doesn't work for my customers. Their environments are dynamic, and > they need the ability to respond to ever-changing realities on the > ground. > > At this point, I feel that we're in a discussion that is becoming > more and more circular, and therefore, dysfunctional. And that, IMO, > has been the unfortunate reality of this WG since its inception. > > Regards, Stan > > >> Alex >> > From teco@inf-net.nl Thu Mar 5 01:37:08 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD1C728C297 for ; Thu, 5 Mar 2009 01:37:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[AWL=0.328, 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 gpZEkvQf8IJM for ; Thu, 5 Mar 2009 01:37:07 -0800 (PST) Received: from hpsmtp-eml18.kpnxchange.com (hpsmtp-eml18.KPNXCHANGE.COM [213.75.38.118]) by core3.amsl.com (Postfix) with ESMTP id 4A1F228C168 for ; Thu, 5 Mar 2009 01:37:06 -0800 (PST) Received: from cpsmtp-eml103.kpnxchange.com ([213.75.84.103]) by hpsmtp-eml18.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 10:37:31 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml103.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 10:37:30 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" , "'Stan Ratliff \(sratliff\)'" References: <499F0BA7.90501@piuha.net> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com><1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl><49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl><49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl><49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl><49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl><49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net> <49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D803@xmb-rtp-208.amer.cisco.com> <49AEBA6D.7030903@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5DB1F@xmb-rtp-208.amer.cisco.com> <49AF97FA.702000 7@gmail.com> In-Reply-To: <49AF97FA.7020007@gmail.com> Date: Thu, 5 Mar 2009 10:37:31 +0100 Message-ID: <002201c99d76$017d4b20$0477e160$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmdctttjdWQ/4HCSNqdk2eYiDukiwAALBDQ Content-Language: nl X-OriginalArrivalTime: 05 Mar 2009 09:37:30.0829 (UTC) FILETIME=[012E67D0:01C99D76] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Thu, 05 Mar 2009 09:37:08 -0000 Inline. |-----Oorspronkelijk bericht----- |Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] = Namens |Alexandru Petrescu |Verzonden: donderdag 5 maart 2009 10:15 |Aan: Stan Ratliff (sratliff) |CC: autoconf@ietf.org |Onderwerp: Re: [Autoconf] Autoconf addressing model | |I wanted to clarify better myself because I think I'm misunderstood, |sorry for insisting on what may appear as circles but I don't want to = be |understood so. | |Stan Ratliff (sratliff) a =E9crit : |>> Stan Ratliff (sratliff) a =E9crit : |>>> First off, you *can't* arbitrarily limit subnets to 25m. 25m from |>>> what? The center? |>> Yes, an area of 25meters with a wifi access point in the center. |> |> *By definition*, what you describe is not a MANET. As you state, |> that's just a WiFi access point. | |Ok, I said AP because in a hurry. I also meant AP-free wifi adhoc mode |gatherings of ad-hoc interfaces. The coverage is also about 25meter. |This is dictated by the max power levels (a number of milliwatts) which |says how strong can 2.5GHz emit in unlicensed spectrum. | |If all such ad-hoc interfaces of that IPv6 subnet stay within 25meter |range then they're all fully exposed (no hidden terminals). Not true. Maybe in a lab environment, there is no condition where it = fails. In other circumstances, some iron would be enough for limited range (few meters). Think of (closed) workplace shelters (EMC or ABC protected). There are also stories on wlan and micro-wave ovens.=20 This is mentioned over and over. |And I also mean that larger networks could be made out of building |blocks of 25m (because of powerlevel-limited because |unlicensed-spectrum), by using Routers. And still keeping the IPv6 |subnet to be as small at the safe area in which there are all exposed |terminals, no hidden terminals. No. There is a limit on spectrum and not all segments can use their own. This introduces hidden terminal in your scenario. Moreover, you might be familiar with planning WiFi infrastructures. Do you think this is ad = hoc? |I hope I'm clearer. I don't think so. You came up with scenario's that are against the = 802.11 standards and have serious problems when used in ad hoc fashion. Just my opinion. |> That's already solved -- 802.11 clients can roam from access point to |> access point. | |Well yes and no, depends how it's deployed. If the APs are bridging |into a backbone then yes, terminals keep their addresses. But if the |APs route then it's not solved. (Proxy) Mobile IP may be a solution = for |it, but it has its inconvenients in path lengths (RO) and tunnels. No problems if the APs route and the stations run a MANET protocol. I am aware of other solutions also, where stations stay hosts (e.g. inject ND/ARP/other info in routing). |> But again, this should not be an 802.11-centric discussion. | |I agree to have it on more than 802.11. | |I've been told recently it's not good for link layer characteristics to | control the link-layers to IP addressing. Yes, put that way I agree |with it - I don't want link-layers to control IP, rather vice-versa. | |But it's also true that an IPv6 link-local address on Ethernet depends |directly on the MAC addres (a link-layer ID), Not by definition and not directly. Nodes are free to use any other Interface ID. Teco. | that an IPv6 subnet on |802.16 is a prefix-per-mobile model, and that IPv6 auto-configuration = on |802.15.4 may use a form of address assigned in RA. | |That's what I wanted to say about AUTOCONF addressing architecture and |specific link-layers. | |I hope I'm clearer. | |Alex | |>>> And, how do you designate the center? Do you constantly |>> re-calculate |>>> the center based on movement? |>> No, not constantly re-computed. But have a fixed view at a point |>> in time. Saying everything varies isn't helpful either. |>> |> |> It may not be helpful, but it's reality. You can't rely on a fixed |> view of a dynamic network; again, by definition, there's movement in |> a MANET. Links come and go, and link quality varies from moment to |> moment. |> |> |>>> Also, from a radio perspective, how do you tell how far |>> apart you are |>>> in the first place? Do you suppose that all radios have |>> GPS? That's a |>>> non-starter, because GPS signals aren't always available. |>> No I didn't suppose GPS is available on each device, it wouldn't |>> work well under foliage. Just a rough evaluation of a specific |>> link-layer radio range, correspondign to widely used networks. |>> |>>> And what about the wired MANET case brought up by Christopher |>>> Dearlove? Should we limit the cable runs? |>> YEs, certainly. All cabled link-layers have specific limitations |>> on their lengths: 2m USB, 50m Ethernet Category6 (IIRC) and so on. |>> |>>> I could understand (but wouldn't really like) the notion of |>>> limiting the discussion |>> to links |>>> that are transitive; but placing some arbitrary distance |>> limit that's |>>> based on 802.11 just doesn't cut it for me. |>> 802.11 is being used widely, no reason to ignore. |> |> I'm not advocating we "ignore" 802.11, or any other L2 technology, |> for that matter. I'm advocating that we remain Layer 2 agnostic. As |> Teco mentioned in another email, there are people in this WG that |> don't deploy MANET networks based on 802.11, or 802.16, or 802.15.4. |> |>> I'd happily accept to add another specific limitation, from the |>> link-layer of your choice. And be speecifically addressing these |>> two link layers. And maybe three. No more than three. |>> |>> I find addressing them all to be difficult for me. |> |> I don't understand why the Layer 3 addressing scheme needs to be |> predicated on a specific Layer 2 technology, or set of technologies. |> The Layer 3 addressing scheme should be totally independent of Layer |> 2 -- isn't that what layering is all about? |> |>> (about single point of failure being destroyed by a falling tree: |>> problem could be addressed at its layer: don't move the command |>> center under trees risking falling); or maybe have two command |>> centers, but specificllay two, not an arbitrary large unknown |>> number. |>> |> |> That essentially boils down to "if it hurts, don't do it", and it |> doesn't work for my customers. Their environments are dynamic, and |> they need the ability to respond to ever-changing realities on the |> ground. |> |> At this point, I feel that we're in a discussion that is becoming |> more and more circular, and therefore, dysfunctional. And that, IMO, |> has been the unfortunate reality of this WG since its inception. |> |> Regards, Stan |> |> |>> Alex |>> |> | |_______________________________________________ |Autoconf mailing list |Autoconf@ietf.org |https://www.ietf.org/mailman/listinfo/autoconf From alexandru.petrescu@gmail.com Thu Mar 5 02:31:24 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D533A28C3DD for ; Thu, 5 Mar 2009 02:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.075, 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 2MxlZCamE0AH for ; Thu, 5 Mar 2009 02:31:24 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id B5BFD28C36B for ; Thu, 5 Mar 2009 02:31:23 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n25AU3mg002103; Thu, 5 Mar 2009 11:30:03 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n25AVndA012825; Thu, 5 Mar 2009 11:31:49 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n25AVnpN029164; Thu, 5 Mar 2009 11:31:49 +0100 Message-ID: <49AFAA15.9060905@gmail.com> Date: Thu, 05 Mar 2009 11:31:49 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Teco Boot References: <499F0BA7.90501@piuha.net> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl><49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl><49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl><49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl><49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl><49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net> <49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D803@xmb-rtp-208.amer.cisco.com> <49AEBA6D.7030903@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5DB1F@xmb-rtp-208.amer.cisco.com> <49AF97FA.70200! 07@gmail.com> <002201c99d76$017d4b20$0477e160$@nl> In-Reply-To: <002201c99d76$017d4b20$0477e160$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Thu, 05 Mar 2009 10:31:24 -0000 Teco Boot a écrit : [...] > |If all such ad-hoc interfaces of that IPv6 subnet stay within 25meter > |range then they're all fully exposed (no hidden terminals). > > Not true. Maybe in a lab environment, there is no condition where it fails. > In other circumstances, some iron would be enough for limited range (few > meters). Think of (closed) workplace shelters (EMC or ABC protected). Ok I agree there could be such a situation. What if we came up with an object name which doesn't have hidden terminal problems when EMC cages are used, and on which an IPv6 subnet could be deployed safely. > There are also stories on wlan and micro-wave ovens. YEs, rather exaggerated. Maybe true some years ago but less true nowadays. > This is mentioned over and over. Yes, I agree, but we should mention also the wifi deployments which work, are deterministic. These also exist. > |And I also mean that larger networks could be made out of building > |blocks of 25m (because of powerlevel-limited because > |unlicensed-spectrum), by using Routers. And still keeping the IPv6 > |subnet to be as small at the safe area in which there are all exposed > |terminals, no hidden terminals. > > No. There is a limit on spectrum and not all segments can use their own. > This introduces hidden terminal in your scenario. Well if each subnet is 25meter wide and they don't mix with each other then there are no interferences on the spectrum, because power levels are diminishing with distance. > Moreover, you might be > familiar with planning WiFi infrastructures. Do you think this is ad hoc? It's as much ad-hoc as the name ad-hoc is used in the 802.11 specs and iwconfig implementations. > |I hope I'm clearer. > > I don't think so. You came up with scenario's that are against the 802.11 > standards and have serious problems when used in ad hoc fashion. Just my > opinion. Well since you seem so confident about how wrong I am then please come up with descriptions of wireless systems which work, and which don't risk hidden-terminal problems, no electro-magnetic cages, no obstacles, no spectrum interference, etc. > |> That's already solved -- 802.11 clients can roam from access point to > |> access point. > | > |Well yes and no, depends how it's deployed. If the APs are bridging > |into a backbone then yes, terminals keep their addresses. But if the > |APs route then it's not solved. (Proxy) Mobile IP may be a solution for > |it, but it has its inconvenients in path lengths (RO) and tunnels. > > No problems if the APs route and the stations run a MANET protocol. I am > aware of other solutions also, where stations stay hosts (e.g. inject > ND/ARP/other info in routing). IPv6 ND over 802.15.4 draft seems to specify that too. > |> But again, this should not be an 802.11-centric discussion. > | > |I agree to have it on more than 802.11. > | > |I've been told recently it's not good for link layer characteristics to > | control the link-layers to IP addressing. Yes, put that way I agree > |with it - I don't want link-layers to control IP, rather vice-versa. > | > |But it's also true that an IPv6 link-local address on Ethernet depends > |directly on the MAC addres (a link-layer ID), > > Not by definition and not directly. Nodes are free to use any other > Interface ID. Well ok, but I haven't seen much a fe80::1 address on an Ethernet interface. You may, and then I'll wonder why. Alex From alexandru.petrescu@gmail.com Thu Mar 5 02:38:02 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B60028C45F; Thu, 5 Mar 2009 02:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.175 X-Spam-Level: X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=0.074, 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 PNedFNNZWjYF; Thu, 5 Mar 2009 02:37:58 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id DC91F28C2FA; Thu, 5 Mar 2009 02:37:57 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n25AabuI006628; Thu, 5 Mar 2009 11:36:37 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n25AcNPS021385; Thu, 5 Mar 2009 11:38:23 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n25AcNQr031749; Thu, 5 Mar 2009 11:38:23 +0100 Message-ID: <49AFAB9F.3050704@gmail.com> Date: Thu, 05 Mar 2009 11:38:23 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: HyungJin Lim References: <20090304163257.82E843A6B2E@core3.amsl.com> <7e8d02d40903041552r5a38bd1dp59ab865c0f463c@mail.gmail.com> <7e8d02d40903050014u556bd7cbof6d7ec2d54901dd4@mail.gmail.com> In-Reply-To: <7e8d02d40903050014u556bd7cbof6d7ec2d54901dd4@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, iesg@ietf.org Subject: Re: [Autoconf] WG Review: Recharter of Ad-Hoc Network Autoconfiguration (autoconf) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 10:38:02 -0000 HyungJin Lim a écrit : > I'm sorry for correction about the following comment and duplicate comments. > My first language is not English. > > ---------- Forwarded message ---------- > From: *HyungJin Lim* > > Date: 2009/3/5 > Subject: Re: [Autoconf] WG Review: Recharter of Ad-Hoc Network > Autoconfiguration (autoconf) > To: iesg@ietf.org > Cc: autoconf@ietf.org , > alexandru.petrescu@gmail.com > > > Inline... > > 2009/3/5 IESG Secretary > > > A modified charter has been submitted for the Ad-Hoc Network > Autoconfiguration working group in the Internet Area of the IETF. The > IESG has not made any determination as yet. The modified charter is > provided below for informational purposes only. Please send your > comments > to the IESG mailing list (iesg@ietf.org ) by > Wednesday, March 11, 2009. > > Ad-Hoc Network Autoconfiguration (autoconf) > ------------------------------------------------------------- > Last Modified: 2009-02-18 > > Current Status: Active Working Group > > Additional information is available at tools.ietf.org/wg/autoconf > > > Chair(s): > Ryuji Wakikawa [ryuji.wakikawa@gmail.com > ] > Thomas Clausen [T.Clausen@computer.org ] > > Internet Area Director(s): > Jari Arkko [jari.arkko@piuha.net ] > Mark Townsley [townsley@cisco.com ] > > Internet Area Advisor: > Jari Arkko [jari.arkko@piuha.net ] > > Mailing Lists: > General Discussion: autoconf@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf > Archive: > http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html > > Description of Working Group: > > In order to communicate among themselves, ad hoc nodes (refer to RFC > 2501) need to configure their network interface(s) with local addresses > that are valid within an ad hoc network. Ad hoc nodes may also need to > configure globally routable addresses, in order to communicate with > devices on the Internet. From the IP layer perspective, an ad hoc > network presents itself as a L3 multi-hop network formed over a > collection of links. > > > In here, I have a question ! > What's meaning of globally routable addresses ? I think it's a commonly agreed term, in the IPv6 Addressing Architecture RFC. > I think globally routable addresses should include topologically correct > address and topologically incorrect address. Correct relative to what? > The reason I address this is that the NEMO basic support should > configure topologically incorrect address in nested NEMO. I agree: addresses configured within a nested NEMO moving network are probably topologically incorrect with respect to the CoA and subnet assigned to the top-level Mobile Router egress interface of a parent NEMO moving network. > But topologically incorrect address is also globally routable addresses > if it a packet forwarding mechanism (e.g., tunneling) is supported, not > packet routing(e.g. OLSR, DYMO, etc.). I agree. > The main purpose of the AUTOCONF WG is to describe the addressing model > for ad hoc networks and how nodes in these networks configure their > addresses. It is required that such models do not cause problems for ad > hoc-unaware parts of the system, such as standard applications running > on an ad hoc node or regular Internet nodes attached to the ad hoc > nodes. This group's effort may include the development of new protocol > mechanisms, should the existing IP autoconfiguration mechanisms be found > inadequate. However, the first task of the working group is to describe > one practical addressing model for ad hoc networks. > > > What's meaning of practical addressing model ? > *Although we already discussed this issue in MANEMO BoF,* *we should > *consider practical scenarios for practical addressing model in real > world I think. > The only simplest scenario *can not* satisfy requirements and other > aspects in more complex scenario which include Internet connectivity, > nested pattern, group mobility, wireless coverage, and so on. > > I would like suggest to define some requirements for practical scenarios. > Then, the simplest scenario also can be considered as a base topic of > them I think. I tend to agree with the approach I'm just afraid that defining new requirements may lengthen the process of coming up with a practical addressing model. I think the word practical is there to just mean that in practice many of us may write an addressing model in a very straightforward manner, which would work in each one's particular case. Maybe we could find the practical and easiest simplest most convenient way of a common denominator addressing models for some very simple dynamic networks. Alex From alexandru.petrescu@gmail.com Thu Mar 5 03:23:43 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99C9128C4A6; Thu, 5 Mar 2009 03:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.070, 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 d8C+7ROiu0QC; Thu, 5 Mar 2009 03:23:42 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 4763528C26F; Thu, 5 Mar 2009 03:23:42 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n25BO8IR025582; Thu, 5 Mar 2009 12:24:08 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n25BO7Ei030971; Thu, 5 Mar 2009 12:24:08 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n25BO7Tt014878; Thu, 5 Mar 2009 12:24:07 +0100 Message-ID: <49AFB657.9020407@gmail.com> Date: Thu, 05 Mar 2009 12:24:07 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Alexandru Petrescu References: <20090304163257.82E843A6B2E@core3.amsl.com> <7e8d02d40903041552r5a38bd1dp59ab865c0f463c@mail.gmail.com> <7e8d02d40903050014u556bd7cbof6d7ec2d54901dd4@mail.gmail.com> <49AFAB9F.3050704@gmail.com> In-Reply-To: <49AFAB9F.3050704@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, iesg@ietf.org Subject: Re: [Autoconf] WG Review: Recharter of Ad-Hoc Network Autoconfiguration (autoconf) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 11:23:43 -0000 Alexandru Petrescu a écrit : > HyungJin Lim a écrit : >> I'm sorry for correction about the following comment and duplicate >> comments. >> My first language is not English. >> >> ---------- Forwarded message ---------- >> From: *HyungJin Lim* > > >> Date: 2009/3/5 >> Subject: Re: [Autoconf] WG Review: Recharter of Ad-Hoc Network >> Autoconfiguration (autoconf) >> To: iesg@ietf.org >> Cc: autoconf@ietf.org , >> alexandru.petrescu@gmail.com >> >> >> Inline... >> >> 2009/3/5 IESG Secretary > > >> >> A modified charter has been submitted for the Ad-Hoc Network >> Autoconfiguration working group in the Internet Area of the IETF. >> The >> IESG has not made any determination as yet. The modified charter is >> provided below for informational purposes only. Please send your >> comments >> to the IESG mailing list (iesg@ietf.org ) by >> Wednesday, March 11, 2009. >> >> Ad-Hoc Network Autoconfiguration (autoconf) >> ------------------------------------------------------------- >> Last Modified: 2009-02-18 >> >> Current Status: Active Working Group >> >> Additional information is available at tools.ietf.org/wg/autoconf >> >> >> Chair(s): >> Ryuji Wakikawa [ryuji.wakikawa@gmail.com >> ] >> Thomas Clausen [T.Clausen@computer.org >> ] >> >> Internet Area Director(s): >> Jari Arkko [jari.arkko@piuha.net ] >> Mark Townsley [townsley@cisco.com ] >> >> Internet Area Advisor: >> Jari Arkko [jari.arkko@piuha.net ] >> >> Mailing Lists: >> General Discussion: autoconf@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf >> Archive: >> http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html >> >> Description of Working Group: >> >> In order to communicate among themselves, ad hoc nodes (refer to RFC >> 2501) need to configure their network interface(s) with local >> addresses >> that are valid within an ad hoc network. Ad hoc nodes may also >> need to >> configure globally routable addresses, in order to communicate with >> devices on the Internet. From the IP layer perspective, an ad hoc >> network presents itself as a L3 multi-hop network formed over a >> collection of links. >> >> >> In here, I have a question ! >> What's meaning of globally routable addresses ? > > I think it's a commonly agreed term, in the IPv6 Addressing Architecture > RFC. > >> I think globally routable addresses should include topologically >> correct address and topologically incorrect address. > > Correct relative to what? > >> The reason I address this is that the NEMO basic support should >> configure topologically incorrect address in nested NEMO. > > I agree: addresses configured within a nested NEMO moving network are > probably topologically incorrect with respect to the CoA and subnet > assigned to the top-level Mobile Router egress interface of a parent > NEMO moving network. > >> But topologically incorrect address is also globally routable >> addresses if it a packet forwarding mechanism (e.g., tunneling) is >> supported, not packet routing(e.g. OLSR, DYMO, etc.). > > I agree. > >> The main purpose of the AUTOCONF WG is to describe the addressing >> model >> for ad hoc networks and how nodes in these networks configure their >> addresses. It is required that such models do not cause problems >> for ad >> hoc-unaware parts of the system, such as standard applications >> running >> on an ad hoc node or regular Internet nodes attached to the ad hoc >> nodes. This group's effort may include the development of new >> protocol >> mechanisms, should the existing IP autoconfiguration mechanisms be >> found >> inadequate. However, the first task of the working group is to >> describe >> one practical addressing model for ad hoc networks. >> >> >> What's meaning of practical addressing model ? >> *Although we already discussed this issue in MANEMO BoF,* *we should >> *consider practical scenarios for practical addressing model in real >> world I think. >> The only simplest scenario *can not* satisfy requirements and other >> aspects in more complex scenario which include Internet connectivity, >> nested pattern, group mobility, wireless coverage, and so on. >> >> I would like suggest to define some requirements for practical scenarios. >> Then, the simplest scenario also can be considered as a base topic of >> them I think. > > I tend to agree with the approach > > I'm just afraid that defining new requirements may lengthen the process > of coming up with a practical addressing model. I think the word > practical is there to just mean that in practice many of us may write an > addressing model in a very straightforward manner, which would work in > each one's particular case. > > Maybe we could find the practical and easiest simplest most convenient > way of a common denominator addressing models for some very simple > dynamic networks. But yes, I agree with you on the necessity to come up with the simplest scenario as a base topic for more complex. Alex From emmanuel.baccelli@gmail.com Thu Mar 5 03:48:31 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CA5A28C215 for ; Thu, 5 Mar 2009 03:48:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[AWL=0.069, 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 Tk2vhTiWoV0r for ; Thu, 5 Mar 2009 03:48:30 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 580193A68DE for ; Thu, 5 Mar 2009 03:48:30 -0800 (PST) Received: by bwz26 with SMTP id 26so3214744bwz.37 for ; Thu, 05 Mar 2009 03:48:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=lCN5NEX2Lixu9UMedRcjqoX5tO5R6J4m31/aSyuEY94=; b=MtiVlZszR3tfRzsW4ut2weKiDYd8H41/VZGpU+vDxyTBE0dHpxwSfUE2roGXkfrzuq 4RZ19Qr5J9/QooYKmm+NajaLq91nANw04JuRJUJZEijtw5rTV/J65Fp1zoRmFhWdYeC6 JBnHnwGTpBTbwsphcewTC1HrDxvKG5yWVKybw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=GAefGgJOGqRFjDHb6Sz/WsOX/vP2k6r5C8G06/EYztERKXko3xd/mjKRQsY5k1Q62H aUDuv4F4axZJ1r9iOEtgGkyTVBQy6PJlel6fZeX6c3g1hzHJzD6gefFceJkUuc7xAgLD T98I688uiIoawdm58KPW3H+Q3z4uxnk6IK9FE= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.103.244.10 with SMTP id w10mr498757mur.71.1236253738713; Thu, 05 Mar 2009 03:48:58 -0800 (PST) Date: Thu, 5 Mar 2009 12:48:58 +0100 X-Google-Sender-Auth: f4b9d36ac499268d Message-ID: From: Emmanuel Baccelli To: "autoconf@ietf.org" Content-Type: multipart/alternative; boundary=00504502dccff2c3e304645dc0ee Subject: [Autoconf] revised draft on aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 11:48:31 -0000 --00504502dccff2c3e304645dc0ee Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all, Here is a revision of the draft, tentatively taking on board most of the latest comments by Teco, Ryuji, Alex, Paul and Rex. It is still a very short document, so don't hesitate to review and comment further! http://www.ietf.org/internet-drafts/draft-baccelli-multi-hop-wireless-communication-02.txt Cheers Emmanuel --00504502dccff2c3e304645dc0ee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,


Here is a revision of the draft, = tentatively taking on board most of the latest comments by Teco, Ryuji, Ale= x, Paul and Rex.=A0

It is still a very short docum= ent, so don't hesitate to review and comment further!

http://www.ietf.org/interne= t-drafts/draft-baccelli-multi-hop-wireless-communication-02.txt


Cheers

Emmanuel=
--00504502dccff2c3e304645dc0ee-- From chris.dearlove@baesystems.com Thu Mar 5 04:02:17 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D99C3A6945 for ; Thu, 5 Mar 2009 04:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.67 X-Spam-Level: X-Spam-Status: No, score=-6.67 tagged_above=-999 required=5 tests=[AWL=-0.071, 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 XcgI7JBzBvn0 for ; Thu, 5 Mar 2009 04:02:16 -0800 (PST) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id 7E2BA28C1AE for ; Thu, 5 Mar 2009 04:02:16 -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 n25C2h5D022756 for ; Thu, 5 Mar 2009 12:02:43 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 n25C2hcl026418 for ; Thu, 5 Mar 2009 12:02:43 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Thu, 05 Mar 2009 12:02:42 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Thu, 5 Mar 2009 12:02:42 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 5 Mar 2009 12:02:40 -0000 Message-ID: In-Reply-To: <7FB7EE0A621BA44B8B69E5F0A09DC76407B5DB1F@xmb-rtp-208.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Autoconf addressing model thread-index: Acmc7tiiUEclImn0SFW37TI7C6NxiAAHwq4gAB5mMPA= References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com><000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com><1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl><49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl><49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl><49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl><49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl><49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com><49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com><49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com><49ADB9FB.6050600@earthlink.net> <49AE3A3A.5000305@gmail.com><7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com><49AE9827.5090309@gmail.com><7FB7EE0A621BA44B8B69E5F0A09DC76407B5D803@xmb-rtp-208.amer.cisco.com><49AEBA6D.7030903@gmail.com> <7FB7EE0A621BA! 44B8B69E5 F0A09DC76407B5DB1F@xmb-rtp-208.amer.cisco.com> From: "Dearlove, Christopher (UK)" To: "Stan Ratliff (sratliff)" , "Alexandru Petrescu" X-OriginalArrivalTime: 05 Mar 2009 12:02:42.0638 (UTC) FILETIME=[49D2F6E0:01C99D8A] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Thu, 05 Mar 2009 12:02:17 -0000 Stan Ratliff > At this point, I feel that we're in a discussion that > is becoming more and more circular, and therefore, > dysfunctional. This discussion has certainly derailed. My last posting agreeing with everything Stan said in an earlier posting than the one I'm quoting unfortunately got lost (at my end). I think there's a need to cut a lot of the chaff away. While there are details that are still open for discussion (otherwise this would have all happened long ago) I think it should be possible to agree on some ground rules, especially with regard to L2, that have rough consensus, and unless multiple people (not just one person) come back wanting to discuss the issue, we just don't. Obviously I can't specify a list of such details, as I'm just one contributor. But I think that such a list would include - L2 agnostic, within the limitations of the following points. Thus although systems such as IEEE 802.11 are important examples, they have no privileged place. - Wireless systems are the reason for MANETs. But MANETs can also use wired links, and some wireless links that are much better behaved, while still allowing for the more difficult cases also to be covered. - The differing characteristics of those wireless links compared to e.g. an Ethernet have to be allowed for. The characteristics that MANET routing protocols are designed to handle need to be part of the design. This includes non-transitive links and non-symmetric local broadcast transmissions at the least. Those aren't carefully thought out wordings, and they certainly aren't complete (the more we can add and retain rough consensus the better). But they would mean, if we can come to such a consensus, that we just don't get trapped down cul-de-sacs like only 802.11, listing specific L2 technologies, and 25m ranges, and spend our effort usefully elsewhere. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From chris.dearlove@baesystems.com Thu Mar 5 04:10:09 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B4523A6B99 for ; Thu, 5 Mar 2009 04:10:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.666 X-Spam-Level: X-Spam-Status: No, score=-6.666 tagged_above=-999 required=5 tests=[AWL=-0.067, 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 T+eioY52bEGK for ; Thu, 5 Mar 2009 04:10:07 -0800 (PST) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id 07D6728C0D9 for ; Thu, 5 Mar 2009 04:10:04 -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 n25CAVKk013666 for ; Thu, 5 Mar 2009 12:10:31 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 n25CAVFA031535 for ; Thu, 5 Mar 2009 12:10:31 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Thu, 05 Mar 2009 12:10:31 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Thu, 5 Mar 2009 12:10:30 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 5 Mar 2009 12:10:28 -0000 Message-ID: In-Reply-To: <49AF1292.3050208@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Autoconf addressing model thread-index: AcmdI1O5bovQKRycQgGOO7OZ37rV5gAZx51w References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com><000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com><1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl><49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl><49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl><49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl><49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl><49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net><49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com><49AE9827.5090309@gmail.com> <000c01c99ce9$e09bf500$a1d3df00$@nl><49AEB846.5020103@gmail.com> <000101c99d00$664c7f60$32e57e20$@nl> <49AF1! 292.30502 08@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" , "Teco Boot" X-OriginalArrivalTime: 05 Mar 2009 12:10:30.0969 (UTC) FILETIME=[60F89A90:01C99D8B] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Thu, 05 Mar 2009 12:10:09 -0000 > Along these lines, an interpretation of 'ad-hoc' is a happening which=20 > hasn't been planned, spontaneous, etc. That is the dictionary definition of ad hoc. But "ad hoc network" has become a term of art, whose fundamentals are about decentralised, cooperative, multi-hop routing. (I'm not sure if RFC 2501 attempts a definition, I haven't checked it recently.) "ad hoc" got attached to such networks because they often were/are ad hoc in the dictionary sense. But often ad hoc networks are not completely unplanned, but still retain that label. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From chris.dearlove@baesystems.com Thu Mar 5 04:13:37 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D08E73A6BB0; Thu, 5 Mar 2009 04:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.661 X-Spam-Level: X-Spam-Status: No, score=-6.661 tagged_above=-999 required=5 tests=[AWL=-0.062, 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 yII04tnJm5hM; Thu, 5 Mar 2009 04:13:37 -0800 (PST) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id E1AF63A6BAC; Thu, 5 Mar 2009 04:13:36 -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 n25CE3Mn027364; Thu, 5 Mar 2009 12:14:03 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 n25CE3QE019486; Thu, 5 Mar 2009 12:14:03 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Thu, 05 Mar 2009 12:14:03 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Thu, 5 Mar 2009 12:14:02 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 5 Mar 2009 12:14:01 -0000 Message-ID: In-Reply-To: <49AEBBEA.7020400@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] WG Review: Recharter of Ad-Hoc NetworkAutoconfiguration (autoconf) thread-index: Acmc79PHlRThfBhJT4W0T8igdUhcVQAm/aDA References: <20090304163257.82E843A6B2E@core3.amsl.com> <49AEBBEA.7020400@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 05 Mar 2009 12:14:03.0087 (UTC) FILETIME=[DF673DF0:01C99D8B] Cc: autoconf@ietf.org, iesg@ietf.org, T.Clausen@computer.org Subject: Re: [Autoconf] WG Review: Recharter of Ad-Hoc NetworkAutoconfiguration (autoconf) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 12:13:37 -0000 > Also suggest: specifically mention which link-layers are being=20 > considered for ad-hoc networks. Definitely not. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From dream.hjlim@gmail.com Thu Mar 5 04:29:37 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3BE63A6A5D; Thu, 5 Mar 2009 04:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.159, 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 KV6hknxQaZ3O; Thu, 5 Mar 2009 04:29:36 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.189]) by core3.amsl.com (Postfix) with ESMTP id 19A2F3A692D; Thu, 5 Mar 2009 04:29:34 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id 11so3663986tim.25 for ; Thu, 05 Mar 2009 04:30:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=cGkbAJoIuyFlI4sUwRxCIH/2MibY1OvHW3MuZG1U+Ok=; b=kMPDtZSXvjceOb8tp0OhCilB8P+Q9mmeWVsirSsvF0b/oHPaBFKBQEERXspgC/8u5Z tZ61E4pvfnt+VFCdwq7H/JmDNEgClFQvLxAB70Ek2inRnd7i03JzSvU6gvQ8CGAWzBFH MBPUFY2FQ+UM5LNf0c9dl/PDrvaK5e/81/hAQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=LjWw3MiJaevs9K9MunjgKU6gYux9pRsfboAFjZAlPqGjzoJVsbhXU9a3zpTBjG00ZY Li6fCEyWFe4gPaGIM24K1omgQJEUSh4mrDeUPJyQU1BwCVzobGiXD9AaFvOelhSwtUZU xBBzCBFRM65PzS0l9m0J2oyR8I4i6bbI6iphw= MIME-Version: 1.0 Received: by 10.110.47.9 with SMTP id u9mr1716576tiu.39.1236256203390; Thu, 05 Mar 2009 04:30:03 -0800 (PST) In-Reply-To: <49AFB657.9020407@gmail.com> References: <20090304163257.82E843A6B2E@core3.amsl.com> <7e8d02d40903041552r5a38bd1dp59ab865c0f463c@mail.gmail.com> <7e8d02d40903050014u556bd7cbof6d7ec2d54901dd4@mail.gmail.com> <49AFAB9F.3050704@gmail.com> <49AFB657.9020407@gmail.com> Date: Thu, 5 Mar 2009 21:30:03 +0900 Message-ID: <7e8d02d40903050430w6595a651g9e271332915e8383@mail.gmail.com> From: HyungJin Lim To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=0016e6520602dadb7a04645e53a1 Cc: autoconf@ietf.org, iesg@ietf.org Subject: Re: [Autoconf] WG Review: Recharter of Ad-Hoc Network Autoconfiguration (autoconf) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 12:29:38 -0000 --0016e6520602dadb7a04645e53a1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Alex, Inline... 2009/3/5 Alexandru Petrescu > Alexandru Petrescu a =E9crit : > > HyungJin Lim a =E9crit : >> >>> I'm sorry for correction about the following comment and duplicate >>> comments. >>> My first language is not English. >>> >>> ---------- Forwarded message ---------- >>> From: *HyungJin Lim* >> dream.hjlim@gmail.com>> >>> Date: 2009/3/5 >>> Subject: Re: [Autoconf] WG Review: Recharter of Ad-Hoc Network >>> Autoconfiguration (autoconf) >>> To: iesg@ietf.org >>> Cc: autoconf@ietf.org , >>> alexandru.petrescu@gmail.com >>> >>> >>> Inline... >>> >>> 2009/3/5 IESG Secretary >> iesg-secretary@ietf.org>> >>> >>> A modified charter has been submitted for the Ad-Hoc Network >>> Autoconfiguration working group in the Internet Area of the IETF. T= he >>> IESG has not made any determination as yet. The modified charter is >>> provided below for informational purposes only. Please send your >>> comments >>> to the IESG mailing list (iesg@ietf.org ) by >>> Wednesday, March 11, 2009. >>> >>> Ad-Hoc Network Autoconfiguration (autoconf) >>> ------------------------------------------------------------- >>> Last Modified: 2009-02-18 >>> >>> Current Status: Active Working Group >>> >>> Additional information is available at tools.ietf.org/wg/autoconf >>> >>> >>> Chair(s): >>> Ryuji Wakikawa [ryuji.wakikawa@gmail.com >>> ] >>> Thomas Clausen [T.Clausen@computer.org >> >] >>> >>> Internet Area Director(s): >>> Jari Arkko [jari.arkko@piuha.net ] >>> Mark Townsley [townsley@cisco.com ] >>> >>> Internet Area Advisor: >>> Jari Arkko [jari.arkko@piuha.net ] >>> >>> Mailing Lists: >>> General Discussion: autoconf@ietf.org >>> To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf >>> Archive: >>> http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html >>> >>> Description of Working Group: >>> >>> In order to communicate among themselves, ad hoc nodes (refer to RFC >>> 2501) need to configure their network interface(s) with local >>> addresses >>> that are valid within an ad hoc network. Ad hoc nodes may also need = to >>> configure globally routable addresses, in order to communicate with >>> devices on the Internet. From the IP layer perspective, an ad hoc >>> network presents itself as a L3 multi-hop network formed over a >>> collection of links. >>> >>> In here, I have a question ! >>> What's meaning of globally routable addresses ? >>> >> >> I think it's a commonly agreed term, in the IPv6 Addressing Architecture >> RFC. >> >> I think globally routable addresses should include topologically correct >>> address and topologically incorrect address. >>> >> >> Correct relative to what? >> >> The reason I address this is that the NEMO basic support should configur= e >>> topologically incorrect address in nested NEMO. >>> >> >> I agree: addresses configured within a nested NEMO moving network are >> probably topologically incorrect with respect to the CoA and subnet assi= gned >> to the top-level Mobile Router egress interface of a parent NEMO moving >> network. >> >> But topologically incorrect address is also globally routable addresses = if >>> it a packet forwarding mechanism (e.g., tunneling) is supported, not pa= cket >>> routing(e.g. OLSR, DYMO, etc.). >>> >> >> I agree. >> >> The main purpose of the AUTOCONF WG is to describe the addressing mod= el >>> for ad hoc networks and how nodes in these networks configure their >>> addresses. It is required that such models do not cause problems for >>> ad >>> hoc-unaware parts of the system, such as standard applications runni= ng >>> on an ad hoc node or regular Internet nodes attached to the ad hoc >>> nodes. This group's effort may include the development of new protoc= ol >>> mechanisms, should the existing IP autoconfiguration mechanisms be >>> found >>> inadequate. However, the first task of the working group is to >>> describe >>> one practical addressing model for ad hoc networks. >>> >>> What's meaning of practical addressing model ? >>> *Although we already discussed this issue in MANEMO BoF,* *we should >>> *consider practical scenarios for practical addressing model in real wo= rld I >>> think. >>> The only simplest scenario *can not* satisfy requirements and other >>> aspects in more complex scenario which include Internet connectivity, n= ested >>> pattern, group mobility, wireless coverage, and so on. >>> I would like suggest to define some requirements for practical >>> scenarios. >>> Then, the simplest scenario also can be considered as a base topic of >>> them I think. >>> >> >> I tend to agree with the approach >> >> I'm just afraid that defining new requirements may lengthen the process = of >> coming up with a practical addressing model. I think the word practical= is >> there to just mean that in practice many of us may write an addressing m= odel >> in a very straightforward manner, which would work in each one's particu= lar >> case. >> >> Maybe we could find the practical and easiest simplest most convenient w= ay >> of a common denominator addressing models for some very simple dynamic >> networks. >> > If the simplest scenario can cover various aspects from some scenarios including more complex situations, it's OK. > But yes, I agree with you on the necessity to come up with the simplest > scenario as a base topic for more complex. In some scenarios Teco addressed in previous comment, we can meet situations that the simplest scenario do not cover. How about considering from the simples scenario to meaningful complex scenario. After defining their requirements such as address configuration models= , some impacts from them, possible situation we will meet due to wireless coverage, some impacts from group mobility pattern and dynamic topology change, we can suggest the addressing model for ad hoc networks and for future Internet I think. The following URL shows a representative scenario we can meet for example. We already have discussed about the practical scenario several times in NEMO. and MANEMO. This is not a new issue but we did not define this I think. http://tools.ietf.org/html/draft-wakikawa-manemoarch-00 Is it right that MANET includes MANEMO ? Hyung-Jin, Lim > > > Alex > > > --0016e6520602dadb7a04645e53a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Alex,
=A0
Inline...

2009/3/5 Alexandru Petrescu &l= t;alexandru.petrescu@gmail.= com>
Alexandru Petrescu a =E9crit := =20

HyungJin Lim a =E9crit :
I'm sorry for correction abo= ut the following comment and duplicate comments.
My first language is no= t English.

---------- Forwarded message ----------
From: *HyungJin Lim* <dream.hjlim@gmail.c= om <mailto:dream.hjlim@gmail.com>>
Date: 2009/3/5
Subject: Re: [Autoconf] WG Review: Recharter of Ad-Hoc Ne= twork Autoconfiguration (autoconf)
To: iesg@ietf.org <mailto:iesg@ietf.org>
Cc: autoconf@ietf.or= g <mailto:aut= oconf@ietf.org>, alexandru.petrescu@gmail.com <mailto:alexandru.petrescu@gmail.= com>


Inline...

2009/3/5 IESG Secretary <iesg-secretary@ietf.org <mail= to:iesg-secret= ary@ietf.org>>

=A0 =A0A modified charter has been submitted for the Ad-Hoc Network
= =A0 =A0Autoconfiguration working group in the Internet Area of the IETF. = =A0The
=A0 =A0IESG has not made any determination as yet. =A0The modifie= d charter is
=A0 =A0provided below for informational purposes only. =A0Please send your<= br>=A0 =A0comments
=A0 =A0to the IESG mailing list (iesg@ietf.org <mailto:iesg@ietf.org>) by
=A0 =A0Wednesday, March 11, 2009.

=A0 =A0Ad-Hoc Network Autoconfigur= ation (autoconf)
=A0 =A0------------------------------------------------= -------------
=A0 =A0Last Modified: 2009-02-18

=A0 =A0Current Sta= tus: Active Working Group

=A0 =A0Additional information is available at tools.ietf.org/wg/autoconf
= =A0 =A0<= http://tools.ietf.org/wg/autoconf>

=A0 =A0Chair(s):
=A0 =A0Ryuji Wakikawa [ryuji.wakikawa@gmail.com
=A0 =A0&l= t;mailto:ryuj= i.wakikawa@gmail.com>]
=A0 =A0Thomas Clausen [T.Clausen@computer.org <mailto:T.Clausen@computer.org>]

=A0 = =A0Internet Area Director(s):
=A0 =A0Jari Arkko [jari.arkko@piuha.net <mailto:jari.arkko@piuha.net>]
=A0 =A0Mark Townsley = [townsley@cisco.com= <mailto:tow= nsley@cisco.com>]

=A0 =A0Internet Area Advisor:
=A0 =A0Jari Arkko [jari.arkko@piuha.net <mailto:= jari.arkko@piuha.= net>]

=A0 =A0Mailing Lists:
=A0 =A0General Discussion: autoconf@ietf.org <mailto:autoconf@ietf.org><= br>=A0 =A0To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf
=A0 =A0Archive:
=A0 =A0http://www.ietf.org/mail-a= rchive/web/autoconf/current/maillist.html

=A0 =A0Description of = Working Group:

=A0 =A0In order to communicate among themselves, ad hoc nodes (refer to= RFC
=A0 =A02501) need to configure their network interface(s) with loca= l addresses
=A0 =A0that are valid within an ad hoc network. Ad hoc nodes= may also need to
=A0 =A0configure globally routable addresses, in order to communicate with<= br>=A0 =A0devices on the Internet. From the IP layer perspective, an ad hoc=
=A0 =A0network presents itself as a L3 multi-hop network formed over a<= br>=A0 =A0collection of links.

=A0In here, I have a question !
What's meaning of globally routa= ble addresses ?

I think it's a commonly agreed term= , in the IPv6 Addressing Architecture =A0RFC.

I think globally routable addres= ses should include topologically correct address and topologically incorrec= t address.

Correct relative to what?

The reason I address this is tha= t the NEMO basic support should configure topologically incorrect address i= n nested NEMO.

I agree: addresses configured within a nested NEMO moving = network are probably topologically incorrect with respect to the CoA and su= bnet assigned to the top-level Mobile Router egress interface of a parent N= EMO moving network.

But topologically incorrect addr= ess is also globally routable addresses if it a packet forwarding mechanism= (e.g., tunneling) is supported, not packet routing(e.g. OLSR, DYMO, etc.).=

I agree.

=A0 =A0The main purpose of the A= UTOCONF WG is to describe the addressing model
=A0 =A0for ad hoc network= s and how nodes in these networks configure their
=A0 =A0addresses. It is required that such models do not cause problems for= ad
=A0 =A0hoc-unaware parts of the system, such as standard application= s running
=A0 =A0on an ad hoc node or regular Internet nodes attached to= the ad hoc
=A0 =A0nodes. This group's effort may include the development of new pr= otocol
=A0 =A0mechanisms, should the existing IP autoconfiguration mecha= nisms be found
=A0 =A0inadequate. However, the first task of the working= group is to describe
=A0 =A0one practical addressing model for ad hoc networks.

=A0What&#= 39;s meaning of practical addressing model ?
*Although we already discus= sed this issue in MANEMO BoF,* *we should *consider practical scenarios for= practical addressing model in real world I think.
The only simplest scenario *can not* satisfy requirements and other aspects= in more complex scenario which include Internet connectivity, nested patte= rn, group mobility, wireless coverage, and so on.
=A0I would like sugges= t to define some requirements for practical scenarios.
Then, the simplest scenario also can be considered as a base =A0topic of th= em I think.

I tend to agree with the approach

I&= #39;m just afraid that defining new requirements may lengthen the process o= f coming up with a practical addressing model. =A0I think the word practica= l is there to just mean that in practice many of us may write an addressing= model in a very straightforward manner, which would work in each one's= particular case.

Maybe we could find the practical and easiest simplest most convenient = way of a common denominator addressing models for some very simple dynamic = networks.
=A0
=A0
=A0If the simplest scenario can cover various aspects from some scenar= ios including more complex situations, it's OK.
=A0
But yes, I = agree with you on the necessity to come up with the simplest scenario as a = base topic for more complex.
=A0
=A0
=A0=A0=A0=A0=A0=A0=A0In some scenarios Teco addressed in previous comm= ent, we can meet=A0situations=A0that the simplest scenario do not=A0cover.<= /div>
=A0=A0=A0=A0 How about considering from the simples scenario to meanin= gful complex scenario.
=A0=A0=A0=A0 After defining their requirements such as address configu= ration models, some impacts from them,=A0possible situation we will meet du= e to wireless=A0coverage, some impacts from group mobility pattern and dyna= mic topology change,=A0 we can suggest the addressing model=A0for ad hoc ne= tworks=A0and for future Internet I think.
=A0
The following URL shows=A0a = representative scenario we can meet for example.
=A0=A0
We already have discussed about the practical scenario several times i= n NEMO. and=A0MANEMO. This is not=A0a new issue but we did not define this = I think.
=A0
Is it right that MANET includes MANEMO ?
=A0
Hyung-Jin, Lim


Ale= x



--0016e6520602dadb7a04645e53a1-- From teco@inf-net.nl Thu Mar 5 04:35:43 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D1973A6BB3 for ; Thu, 5 Mar 2009 04:35:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.728 X-Spam-Level: X-Spam-Status: No, score=-1.728 tagged_above=-999 required=5 tests=[AWL=0.318, 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 2WNQ4EnZiqbb for ; Thu, 5 Mar 2009 04:35:42 -0800 (PST) Received: from hpsmtp-eml18.kpnxchange.com (hpsmtp-eml18.KPNXCHANGE.COM [213.75.38.118]) by core3.amsl.com (Postfix) with ESMTP id BC0A03A6BAC for ; Thu, 5 Mar 2009 04:35:41 -0800 (PST) Received: from cpsmtp-eml101.kpnxchange.com ([213.75.84.101]) by hpsmtp-eml18.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 13:36:06 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml101.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 13:36:06 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <499F0BA7.90501@piuha.net> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl><49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl><49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl><49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl><49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl><49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net> <49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D803@xmb-rtp-208.amer.cisco.com> <49AEBA6D.7030903@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5DB1F@xmb-rtp-208.amer.cisco.com> <49AF97FA.70200! 07@gmail.com> <002201c99d76$017d4b20$0477e160$@nl> <49AFAA15.90 60905@gmail.com> In-Reply-To: <49AFAA15.9060905@gmail.com> Date: Thu, 5 Mar 2009 13:36:06 +0100 Message-ID: <003a01c99d8e$f47ba2f0$dd72e8d0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmdfZtfl2cSE9SrQ+m8mQENYhi63wAAxAAQ Content-Language: nl X-OriginalArrivalTime: 05 Mar 2009 12:36:06.0152 (UTC) FILETIME=[F402F080:01C99D8E] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Thu, 05 Mar 2009 12:35:43 -0000 Inline. |-----Oorspronkelijk bericht----- |Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] |Verzonden: donderdag 5 maart 2009 11:32 |Aan: Teco Boot |CC: 'Alexandru Petrescu'; 'Stan Ratliff (sratliff)'; autoconf@ietf.org |Onderwerp: Re: [Autoconf] Autoconf addressing model | |Teco Boot a =E9crit : |[...] |> |If all such ad-hoc interfaces of that IPv6 subnet stay within = 25meter |> |range then they're all fully exposed (no hidden terminals). |> |> Not true. Maybe in a lab environment, there is no condition where it |fails. |> In other circumstances, some iron would be enough for limited range |(few |> meters). Think of (closed) workplace shelters (EMC or ABC protected). | |Ok I agree there could be such a situation. What if we came up with an |object name which doesn't have hidden terminal problems when EMC cages |are used, and on which an IPv6 subnet could be deployed safely. Wires? TDMA? (or other media access technologies) But this is of no help. The MANET link characters occur in real life. = Why do you suggest denying this? By the way, hidden terminal problem has nothing to do with totally unreachability, as in the EMC cage. The opposite is true, EMC cages (or turning off the radio) solves the hidden terminal problem. Connectivity = gets hurt. Every improvement may have some disadvantages. |> There are also stories on wlan and micro-wave ovens. | |YEs, rather exaggerated. Maybe true some years ago but less true |nowadays. | |> This is mentioned over and over. | |Yes, I agree, but we should mention also the wifi deployments which |work, are deterministic. These also exist. No one had any doubt about this, I think. Why mentioning an endless list = on things that work? Let's focus on what urgently needs improvements. |> |And I also mean that larger networks could be made out of building |> |blocks of 25m (because of powerlevel-limited because |> |unlicensed-spectrum), by using Routers. And still keeping the IPv6 |> |subnet to be as small at the safe area in which there are all = exposed |> |terminals, no hidden terminals. |> |> No. There is a limit on spectrum and not all segments can use their |own. |> This introduces hidden terminal in your scenario. | |Well if each subnet is 25meter wide and they don't mix with each other |then there are no interferences on the spectrum, because power levels |are diminishing with distance. Again and again and again. This may be true in a well planned network. = It fails when nodes move. So it does NOT apply to a MANET. | |> Moreover, you might be |> familiar with planning WiFi infrastructures. Do you think this is ad |hoc? | |It's as much ad-hoc as the name ad-hoc is used in the 802.11 specs and |iwconfig implementations. I think you absolutely don't know where you are talking about. Sorry to = say so. |> |I hope I'm clearer. |> |> I don't think so. You came up with scenario's that are against the |802.11 |> standards and have serious problems when used in ad hoc fashion. Just |my |> opinion. | |Well since you seem so confident about how wrong I am then please come |up with descriptions of wireless systems which work, and which don't |risk hidden-terminal problems, no electro-magnetic cages, no obstacles, |no spectrum interference, etc. You missed the point MANET works even in the circumstances you = described. MANET Routing provides the best available paths to users (tries to ...). = Of course: no path available, no communication. |> |> That's already solved -- 802.11 clients can roam from access point |to |> |> access point. |> | |> |Well yes and no, depends how it's deployed. If the APs are bridging |> |into a backbone then yes, terminals keep their addresses. But if = the |> |APs route then it's not solved. (Proxy) Mobile IP may be a solution |for |> |it, but it has its inconvenients in path lengths (RO) and tunnels. |> |> No problems if the APs route and the stations run a MANET protocol. I |am |> aware of other solutions also, where stations stay hosts (e.g. inject |> ND/ARP/other info in routing). | |IPv6 ND over 802.15.4 draft seems to specify that too. | |> |> But again, this should not be an 802.11-centric discussion. |> | |> |I agree to have it on more than 802.11. |> | |> |I've been told recently it's not good for link layer characteristics |to |> | control the link-layers to IP addressing. Yes, put that way I |agree |> |with it - I don't want link-layers to control IP, rather vice-versa. |> | |> |But it's also true that an IPv6 link-local address on Ethernet |depends |> |directly on the MAC addres (a link-layer ID), |> |> Not by definition and not directly. Nodes are free to use any other |> Interface ID. | |Well ok, but I haven't seen much a fe80::1 address on an Ethernet |interface. You may, and then I'll wonder why. Why can't I configure it? Of course I can. debian-fs1:~# ip -6 addr =20 2: eth0: mtu 1500 qlen 1000 inet6 2001:db8:1:0:20c:29ff:fee3:bdf5/64 scope global dynamic=20 valid_lft 2592000sec preferred_lft 604800sec inet6 fe80::1/64 scope link=20 valid_lft forever preferred_lft forever inet6 fe80::20c:29ff:fee3:bdf5/64 scope link=20 valid_lft forever preferred_lft forever nbs3725#sh ipv int fa0/0.22 FastEthernet0/0.22 is up, line protocol is up IPv6 is enabled, link-local address is FE80::2 No problem either with configuring this on each and every interface of a node. As long as the LL is unique on the link. So the following topology is valid: +----------+ +----------+ | |fe80::1/64 | | | = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= + | | router 1 | fe80::2/64| router 2 | | |fe80::1/64 | | | = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= + | | | fe80::2/64| | +----------+ +----------+ Agreed on this? Maybe the OLSR / NHDP design team needs to verify their design on this topology. Due to lack of a RouterID, topology databases may lack = sufficient information to distinguish the two links. When fixed, let's check also = the following: +----------+ +----------+ | |fe80::1/64 | | | = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= + | | router x | fe80::2/64| router y | | |fe80::2/64 | | | = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= + | | | fe80::1/64| | +----------+ +----------+ I tested the loopback interface advantage (router 11 & 12): +------------+ +------------+ | |fe80::11/64 | | | Router-11 = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D+ Router-12 | | | fe80::12/64| | | loopback0 |fe80::11/64 | loopback0 | | FD::11/128 = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D+ FD::12/128 | | | fe80::12/64| | +------------+ +------------+ I turned on OSPFv3 and set up a terminal connection from Router-11 to Router-12, using the loopback interfaces. Then I shut down and brought = up again the interfaces (ifdown/ifup, if you like), remotely, one at a = time. I experienced no problems with my terminal session. I repeated the test with the link local addresses. Here also, I = experienced no problems. This is because there are two links with exactly the same address pairs (an advantage to use same LL addresses on all interfaces). With a multi-hop path, this will not work. Teco. |Alex From super.ismiti@gmail.com Thu Mar 5 05:02:17 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC10F28C2A2; Thu, 5 Mar 2009 05:02:17 -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 jsT6gQgZsq8A; Thu, 5 Mar 2009 05:02:17 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id DFC2728C1C5; Thu, 5 Mar 2009 05:02:16 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so4406539wfd.31 for ; Thu, 05 Mar 2009 05:02:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=XQfxq2B2CJk9/qoU6INl+nnDURkK+NLW+hIK89gW/SE=; b=w48FsSV2eRlD2a/W0lMKVMJzEsNre3BseFWwJWCw7GFJrfcIvlJecdKe1x5WZIosB4 7Gf8OI4ixC7bgdZ41yByCxPhuD5YXpb2BGHqPhy/YeNNGlVAcGyRQrFBd+e3buxANWbN 70fEhJktL6ml+3clSeneZWL1OhADNXPdsmHlI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; b=SoGwoyp0xP1km+873b7sgowtD6RQK59qAr2DEBGEYkUoa6AV6TqrXLJ3+1U2xwZJln vt9F+Ye2leqmM9ndOeLSbYrmeCMfXydjZLIAWiF7tQ7jROL/ClQUbqO/VpcAwZU9KuB6 7j4K7ofjuFwdIs/iHiw0dSEhluFUbnfj8W5Lw= MIME-Version: 1.0 Sender: super.ismiti@gmail.com Received: by 10.142.162.9 with SMTP id k9mr510927wfe.309.1236258165998; Thu, 05 Mar 2009 05:02:45 -0800 (PST) Date: Thu, 5 Mar 2009 10:02:45 -0300 X-Google-Sender-Auth: f734f2aad6b3c0bd Message-ID: From: Ricardo Schmidt To: autoconf@ietf.org, manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Autoconf] DAD implementation for Linux X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 13:02:18 -0000 Hello all, I am searching for implementation of the DAD protocol for Linux (the simplest one - ). I know that it is a simple implementation, but if I found one I would save a little time to my project. Thanks in advance, -- Ricardo From chris.dearlove@baesystems.com Thu Mar 5 05:09:21 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 741843A692D for ; Thu, 5 Mar 2009 05:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.658 X-Spam-Level: X-Spam-Status: No, score=-6.658 tagged_above=-999 required=5 tests=[AWL=-0.059, 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 fhUT24Oi17Ij for ; Thu, 5 Mar 2009 05:09:20 -0800 (PST) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id 4F9EA3A67D1 for ; Thu, 5 Mar 2009 05:09:18 -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 n25D9jOv018063 for ; Thu, 5 Mar 2009 13:09:45 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 n25D9jOG031197 for ; Thu, 5 Mar 2009 13:09:45 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Thu, 05 Mar 2009 13:09:43 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Thu, 5 Mar 2009 13:09:43 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 5 Mar 2009 13:09:41 -0000 Message-ID: In-Reply-To: <003a01c99d8e$f47ba2f0$dd72e8d0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Autoconf addressing model thread-index: AcmdfZtfl2cSE9SrQ+m8mQENYhi63wAAxAAQAASRqcA= References: <499F0BA7.90501@piuha.net> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl><49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl><49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl><49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl><49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl><49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net><49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D803@xmb-rtp-208.amer.cisco.com> <49AEBA6D.7030903@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5DB1F@xmb-rtp-208.amer.cisco.com><49AF97FA.70200! 07@gmail.com><002201c99d76$017d4b20$0477e160$@nl> <49AFAA15.90 6! 0905@gmai l.com> <003a01c99d8e$f47ba2f0$dd72e8d0$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Alexandru Petrescu" X-OriginalArrivalTime: 05 Mar 2009 13:09:43.0216 (UTC) FILETIME=[A6467B00:01C99D93] Cc: autoconf@ietf.org, Thomas Heide Clausen Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Thu, 05 Mar 2009 13:09:21 -0000 > No problem either with configuring this on each and every interface of a > node. As long as the LL is unique on the link. > So the following topology is valid: > +----------+ +----------+ > | |fe80::1/64 | | > | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D+ | > | router 1 | fe80::2/64| router 2 | > | |fe80::1/64 | | > | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D+ | > | | fe80::2/64| | > +----------+ +----------+ > Agreed on this? I'm withholding any judgement on that. > Maybe the OLSR / NHDP design team needs to verify their design on this > topology. That is a problem for OLSR / NHDP which assumes (one or more) distinct IP addresses on separate interfaces. > Due to lack of a RouterID, topology databases may lack sufficient > information to distinguish the two links. When fixed, let's check also the > following: > +----------+ +----------+ > | |fe80::1/64 | | > | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D+ | > | router x | fe80::2/64| router y | > | |fe80::2/64 | | > | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D+ | > | | fe80::1/64| | > +----------+ +----------+ That is not a problem. --=20 Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From super.ismiti@gmail.com Thu Mar 5 05:31:51 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CF813A692D; Thu, 5 Mar 2009 05:31:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 GE2u0sFK7ehT; Thu, 5 Mar 2009 05:31:50 -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 ADE4628C435; Thu, 5 Mar 2009 05:31:50 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so4419004wfd.31 for ; Thu, 05 Mar 2009 05:32:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=XQfxq2B2CJk9/qoU6INl+nnDURkK+NLW+hIK89gW/SE=; b=JhJMJF2rh6sr9v2YtPQZpUEXEU/QWgSCFqbEZVGxxo6SWqTKjthDorfHt6otxD/L9y j7UJO2DXDQLO/Gee82mYi+H0AWbc0d2FQSI79GOSmqR/ayM/FUVNisl6HsOWa+p9uyWY T3+5AdMw4dUell63J/UIolAczWPX0unEc7KQE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=Yjq7ywh5eFGDv3ZLxhUdmST63guZY5nl05knfkWtemoLxcTPqjOnbhSfE8aHMjjIvz 7Tuqe1kFOzmNQDd+O+tuAorBWW+5EElXfKH9aSMAw/oACUq2mBNI8Lbjkim42xrdGm/b jtf36U2RKMpZc2NPOso5Y6CQ2MIuvSAUkGNok= MIME-Version: 1.0 Received: by 10.143.162.8 with SMTP id p8mr538997wfo.34.1236259940103; Thu, 05 Mar 2009 05:32:20 -0800 (PST) Date: Thu, 5 Mar 2009 10:32:20 -0300 Message-ID: From: Ricardo Schmidt To: autoconf@ietf.org, manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Autoconf] DAD implementation for Linux X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 13:31:51 -0000 Hello all, I am searching for implementation of the DAD protocol for Linux (the simplest one - ). I know that it is a simple implementation, but if I found one I would save a little time to my project. Thanks in advance, -- Ricardo From teco@inf-net.nl Thu Mar 5 05:43:26 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A69A93A6ACC for ; Thu, 5 Mar 2009 05:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[AWL=0.308, 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 o3B4oTuEEof2 for ; Thu, 5 Mar 2009 05:43:26 -0800 (PST) Received: from hpsmtp-eml18.kpnxchange.com (hpsmtp-eml18.KPNXCHANGE.COM [213.75.38.118]) by core3.amsl.com (Postfix) with ESMTP id 1261228C33A for ; Thu, 5 Mar 2009 05:42:45 -0800 (PST) Received: from cpsmtp-eml102.kpnxchange.com ([213.75.84.102]) by hpsmtp-eml18.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 14:43:14 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml102.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 14:43:14 +0100 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" References: <499F0BA7.90501@piuha.net> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl><49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl><49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl><49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl><49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl><49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net><49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D803@xmb-rtp-208.amer.cisco.com> <49AEBA6D.7030903@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5DB1F@xmb-rtp-208.amer.cisco.com><49AF97FA.70200! 07@gmail.com><002201c99d76$017d4b20$0477e160$@nl> <49AFAA15.90 6! 0905@gmai l.com> <00 3a01c99d8e$f47ba2f0$dd72e8d0$@nl> In-Reply-To: Date: Thu, 5 Mar 2009 14:43:14 +0100 Message-ID: <004901c99d98$55754b70$005fe250$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmdfZtfl2cSE9SrQ+m8mQENYhi63wAAxAAQAASRqcAAALfewA== Content-Language: nl X-OriginalArrivalTime: 05 Mar 2009 13:43:14.0411 (UTC) FILETIME=[550A7BB0:01C99D98] Cc: autoconf@ietf.org, 'Thomas Heide Clausen' Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Thu, 05 Mar 2009 13:43:26 -0000 |> As long as the LL is unique on the link. |> So the following topology is valid: | |> +----------+ +----------+ |> | |fe80::1/64 | | |> | +========================+ | |> | router 1 | fe80::2/64| router 2 | |> | |fe80::1/64 | | |> | +========================+ | |> | | fe80::2/64| | |> +----------+ +----------+ | |> Agreed on this? | |I'm withholding any judgement on that. | |> Maybe the OLSR / NHDP design team needs to verify their design on this |> topology. | |That is a problem for OLSR / NHDP which assumes (one or more) |distinct IP addresses on separate interfaces. This scenario is not uncommon, where VLANs are used. Questions are: Do we want OLSR / NHDP to support VLANs? I think so. Do we want to introduce a new requirement for MAC addresses for VLANs, being unique? I don't think so. Or deprecate EUI-64 used as InterfaceID, e.g. use randomized addresses? This last one is a bit black/white. NHDP could check uniqueness of local interface addresses, and generate and configure other addresses if needed. Not sure on going that way. Use NHDP_InterfaceIDs that are not configured addresses ? (like OSPF) I don't prefer a requirement using globally unique addresses for all transit links being used by OLSR / NHDP. Teco. From alexandru.petrescu@gmail.com Thu Mar 5 05:48:52 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 352233A6BC0 for ; Thu, 5 Mar 2009 05:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=0.069, 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 kNsClCLPEYJr for ; Thu, 5 Mar 2009 05:48:51 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id DD2F03A6BBB for ; Thu, 5 Mar 2009 05:48:50 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n25DnJwB021987; Thu, 5 Mar 2009 14:49:19 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n25DnJEk032022; Thu, 5 Mar 2009 14:49:19 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n25DnI6v018202; Thu, 5 Mar 2009 14:49:18 +0100 Message-ID: <49AFD85E.5040301@gmail.com> Date: Thu, 05 Mar 2009 14:49:18 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Teco Boot References: <499F0BA7.90501@piuha.net> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl><49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl><49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl><49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl><49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net> <49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D803@xmb-rtp-208.amer.cisco.com> <49AEBA6D.7030903@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5DB1F@xmb-rtp-208.amer.cisco.com> <49AF97FA.70200! 07@gmail.com> <002201c99d76$017d4b20$0477e160$@nl> <49AFAA15.9! 060905@gmail.com> <003a01c99d8e$f47ba2f0$dd72e8d0$@nl> In-Reply-To: <003a01c99d8e$f47ba2f0$dd72e8d0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Thu, 05 Mar 2009 13:48:52 -0000 Teco Boot a écrit : [...] > You missed the point MANET works even in the circumstances you described. > MANET Routing provides the best available paths to users (tries to ...). Of > course: no path available, no communication. I agree with the last part: the risk is that even the best designed MANET protocol will not work when trees fall, cages shield and obstacles get in the way. These are goals which can't be addressed. [...] > |> Not by definition and not directly. Nodes are free to use any other > |> Interface ID. > | > |Well ok, but I haven't seen much a fe80::1 address on an Ethernet > |interface. You may, and then I'll wonder why. > > Why can't I configure it? Of course I can. > > debian-fs1:~# ip -6 addr > 2: eth0: mtu 1500 qlen 1000 > inet6 2001:db8:1:0:20c:29ff:fee3:bdf5/64 scope global dynamic > valid_lft 2592000sec preferred_lft 604800sec > inet6 fe80::1/64 scope link > valid_lft forever preferred_lft forever > inet6 fe80::20c:29ff:fee3:bdf5/64 scope link > valid_lft forever preferred_lft forever > > nbs3725#sh ipv int fa0/0.22 > FastEthernet0/0.22 is up, line protocol is up > IPv6 is enabled, link-local address is FE80::2 > > No problem either with configuring this on each and every interface of a > node. As long as the LL is unique on the link. Yes, I agree it can. I don't understand why would one do it. When over Ethernet there's the MAC address deriving into IID, helping ensuring uniqueness. When over point-to-point links PPP with IPv6 could be used negotiating the link layer ID, again ensuring uniqueness. But I agree an administrator may want to plan all the link-local addresses and assign them manually, for some links which don't have MAC addresses, are not 802.16 and are not used. > So the following topology is valid: > > +----------+ +----------+ > | |fe80::1/64 | | > | +========================+ | > | router 1 | fe80::2/64| router 2 | > | |fe80::1/64 | | > | +========================+ | > | | fe80::2/64| | > +----------+ +----------+ > > Agreed on this? Agreed. But why /64? An address is /128, and the link-local address' prefix is /10. > Maybe the OLSR / NHDP design team needs to verify their design on this > topology. Due to lack of a RouterID, topology databases may lack sufficient > information to distinguish the two links. I agree this should be checked for all routing protocols, to find out whether loops form. > When fixed, let's check also the > following: > > > +----------+ +----------+ > | |fe80::1/64 | | > | +========================+ | > | router x | fe80::2/64| router y | > | |fe80::2/64 | | > | +========================+ | > | | fe80::1/64| | > +----------+ +----------+ > > > I tested the loopback interface advantage (router 11 & 12): > > +------------+ +------------+ > | |fe80::11/64 | | > | Router-11 +=========================+ Router-12 | > | | fe80::12/64| | > | loopback0 |fe80::11/64 | loopback0 | > | FD::11/128 +=========================+ FD::12/128 | > | | fe80::12/64| | > +------------+ +------------+ > > I turned on OSPFv3 and set up a terminal connection from Router-11 to > Router-12, using the loopback interfaces. Then I shut down and > brought up again the interfaces (ifdown/ifup, if you like), remotely, > one at a time. I experienced no problems with my terminal session. I agree. > I repeated the test with the link local addresses. Here also, I > experienced no problems. This is because there are two links with > exactly the same address pairs (an advantage to use same LL addresses > on all interfaces). Demonstrating the advantage of loopback0 vs eth0 would have implied that you start OSPFv3 on eth0 instead of loopback0 and that it would have crashed. But even then, I'm sure there may exist OSPFv3 implementation which would not crash when running over eth0 and ifconfig down eth0. In this sense, if the loopback0 interface is a solution to crashing OSPFv3-over-eth0, then it is an implementation solution. Some implementations do, others don't. > With a multi-hop path, this will not work. In my sense, you already pictured a multi-hop network in the first topology, so it should work. > +----------+ +----------+ > | |fe80::1/64 | | > | +========================+ | > | router 1 | fe80::2/64| router 2 | > | |fe80::1/64 | | > | +========================+ | > | | fe80::2/64| | > +----------+ +----------+ Alex From alexandru.petrescu@gmail.com Thu Mar 5 06:03:02 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACF993A6971; Thu, 5 Mar 2009 06:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.068, 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 PfAIc7JDYxsc; Thu, 5 Mar 2009 06:03:01 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 1574B3A684B; Thu, 5 Mar 2009 06:03:00 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n25E1fx1026750; Thu, 5 Mar 2009 15:01:41 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n25E3QPP017400; Thu, 5 Mar 2009 15:03:27 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n25E3Q90024462; Thu, 5 Mar 2009 15:03:26 +0100 Message-ID: <49AFDBAE.7020304@gmail.com> Date: Thu, 05 Mar 2009 15:03:26 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: HyungJin Lim References: <20090304163257.82E843A6B2E@core3.amsl.com> <7e8d02d40903041552r5a38bd1dp59ab865c0f463c@mail.gmail.com> <7e8d02d40903050014u556bd7cbof6d7ec2d54901dd4@mail.gmail.com> <49AFAB9F.3050704@gmail.com> <49AFB657.9020407@gmail.com> <7e8d02d40903050430w6595a651g9e271332915e8383@mail.gmail.com> In-Reply-To: <7e8d02d40903050430w6595a651g9e271332915e8383@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, iesg@ietf.org Subject: Re: [Autoconf] WG Review: Recharter of Ad-Hoc Network Autoconfiguration (autoconf) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 14:03:02 -0000 HyungJin Lim a écrit : > Hi, Alex, > > Inline... > > 2009/3/5 Alexandru Petrescu > > > Alexandru Petrescu a écrit : > > HyungJin Lim a écrit : > > I'm sorry for correction about the following comment and > duplicate comments. > My first language is not English. > > ---------- Forwarded message ---------- > From: *HyungJin Lim* >> > Date: 2009/3/5 > Subject: Re: [Autoconf] WG Review: Recharter of Ad-Hoc > Network Autoconfiguration (autoconf) > To: iesg@ietf.org > > > Cc: autoconf@ietf.org > >, > alexandru.petrescu@gmail.com > > > > > > Inline... > > 2009/3/5 IESG Secretary > >> > > A modified charter has been submitted for the Ad-Hoc Network > Autoconfiguration working group in the Internet Area of > the IETF. The > IESG has not made any determination as yet. The modified > charter is > provided below for informational purposes only. Please > send your > comments > to the IESG mailing list (iesg@ietf.org > >) by > Wednesday, March 11, 2009. > > Ad-Hoc Network Autoconfiguration (autoconf) > ------------------------------------------------------------- > Last Modified: 2009-02-18 > > Current Status: Active Working Group > > Additional information is available at > tools.ietf.org/wg/autoconf > > > Chair(s): > Ryuji Wakikawa [ryuji.wakikawa@gmail.com > > >] > Thomas Clausen [T.Clausen@computer.org > > >] > > Internet Area Director(s): > Jari Arkko [jari.arkko@piuha.net > >] > Mark Townsley [townsley@cisco.com > >] > > Internet Area Advisor: > Jari Arkko [jari.arkko@piuha.net > >] > > Mailing Lists: > General Discussion: autoconf@ietf.org > > > To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf > Archive: > > http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html > > Description of Working Group: > > In order to communicate among themselves, ad hoc nodes > (refer to RFC > 2501) need to configure their network interface(s) with > local addresses > that are valid within an ad hoc network. Ad hoc nodes may > also need to > configure globally routable addresses, in order to > communicate with > devices on the Internet. From the IP layer perspective, > an ad hoc > network presents itself as a L3 multi-hop network formed > over a > collection of links. > > In here, I have a question ! > What's meaning of globally routable addresses ? > > > I think it's a commonly agreed term, in the IPv6 Addressing > Architecture RFC. > > I think globally routable addresses should include > topologically correct address and topologically incorrect > address. > > > Correct relative to what? > > The reason I address this is that the NEMO basic support > should configure topologically incorrect address in nested NEMO. > > > I agree: addresses configured within a nested NEMO moving > network are probably topologically incorrect with respect to the > CoA and subnet assigned to the top-level Mobile Router egress > interface of a parent NEMO moving network. > > But topologically incorrect address is also globally > routable addresses if it a packet forwarding mechanism > (e.g., tunneling) is supported, not packet routing(e.g. > OLSR, DYMO, etc.). > > > I agree. > > The main purpose of the AUTOCONF WG is to describe the > addressing model > for ad hoc networks and how nodes in these networks > configure their > addresses. It is required that such models do not cause > problems for ad > hoc-unaware parts of the system, such as standard > applications running > on an ad hoc node or regular Internet nodes attached to > the ad hoc > nodes. This group's effort may include the development of > new protocol > mechanisms, should the existing IP autoconfiguration > mechanisms be found > inadequate. However, the first task of the working group > is to describe > one practical addressing model for ad hoc networks. > > What's meaning of practical addressing model ? > *Although we already discussed this issue in MANEMO BoF,* > *we should *consider practical scenarios for practical > addressing model in real world I think. > The only simplest scenario *can not* satisfy requirements > and other aspects in more complex scenario which include > Internet connectivity, nested pattern, group mobility, > wireless coverage, and so on. > I would like suggest to define some requirements for > practical scenarios. > Then, the simplest scenario also can be considered as a base > topic of them I think. > > > I tend to agree with the approach > > I'm just afraid that defining new requirements may lengthen the > process of coming up with a practical addressing model. I think > the word practical is there to just mean that in practice many > of us may write an addressing model in a very straightforward > manner, which would work in each one's particular case. > > Maybe we could find the practical and easiest simplest most > convenient way of a common denominator addressing models for > some very simple dynamic networks. > > > > If the simplest scenario can cover various aspects from some scenarios > including more complex situations, it's OK. > > > But yes, I agree with you on the necessity to come up with the > simplest scenario as a base topic for more complex. > > > > In some scenarios Teco addressed in previous comment, we can > meet situations that the simplest scenario do not cover. > How about considering from the simples scenario to meaningful > complex scenario. > After defining their requirements such as address configuration > models, some impacts from them, possible situation we will meet due to > wireless coverage, some impacts from group mobility pattern and dynamic > topology change, we can suggest the addressing model for ad hoc > networks and for future Internet I think. Well yes I tend to agree but I currently can't understand the requirements as stated until now. > The following URL shows a representative scenario we can meet for example. But the URL shows several scenarios :-) Which one do you think? I myself prefer the left diagram in Figure 5 (egress-to-egress). > We already have discussed about the practical scenario several times in > NEMO. and MANEMO. I agree. > This is not a new issue but we did not define this I > think. > http://tools.ietf.org/html/draft-wakikawa-manemoarch-00 > > Is it right that MANET includes MANEMO ? Well if the answer were yes, and said so in the Charter, then I'd certainly have a higher interest in AUTOCONF. Ever since the MANEMO BoF was re-directed to AUTOCONF never was there any sign of "NEMO" neither in the old nor new Charter. Whereas previous Charter was saying "MANET" the current proposal only says "ad-hoc network" and "ad-hoc unaware" - is this freedom to interpret it as including NEMO? Alex From teco@inf-net.nl Thu Mar 5 06:04:13 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A3B328C285 for ; Thu, 5 Mar 2009 06:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[AWL=0.299, 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 fB++IGMw9758 for ; Thu, 5 Mar 2009 06:04:12 -0800 (PST) Received: from cpsmtpo-eml05.kpnxchange.com (cpsmtpo-eml05.KPNXCHANGE.COM [213.75.38.154]) by core3.amsl.com (Postfix) with ESMTP id 435B728C297 for ; Thu, 5 Mar 2009 06:04:12 -0800 (PST) Received: from cpsmtp-eml104.kpnxchange.com ([213.75.84.104]) by cpsmtpo-eml05.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 15:04:40 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml104.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 15:04:40 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <499F0BA7.90501@piuha.net> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl><49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl><49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl><49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl><49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net> <49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D803@xmb-rtp-208.amer.cisco.com> <49AEBA6D.7030903@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5DB1F@xmb-rtp-208.amer.cisco.com> <49AF97FA.70200! 07@gmail.com> <002201c99d76$017d4b20$0477e160$@nl> <49AFAA15.9! 060905@gmail.com> <003a01c99d8e$f47ba2f0$dd72e8d0$@nl> <49AFD85E.504030 1@gmail.com> In-Reply-To: <49AFD85E.5040301@gmail.com> Date: Thu, 5 Mar 2009 15:04:41 +0100 Message-ID: <004a01c99d9b$542e1e10$fc8a5a30$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmdmTFVTbvru92PSDSXjNMq4KbBrAAAQzQQ Content-Language: nl X-OriginalArrivalTime: 05 Mar 2009 14:04:40.0749 (UTC) FILETIME=[53C215D0:01C99D9B] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Thu, 05 Mar 2009 14:04:13 -0000 Hi Alex, |> So the following topology is valid: |> |> +----------+ +----------+ |> | |fe80::1/64 | | |> | +========================+ | |> | router 1 | fe80::2/64| router 2 | |> | |fe80::1/64 | | |> | +========================+ | |> | | fe80::2/64| | |> +----------+ +----------+ |> |> Agreed on this? | |Agreed. But why /64? An address is /128, and the link-local address' |prefix is /10. I used address-prefix format (RFC4291). And RFC2464: 5. Link-Local Addresses The IPv6 link-local address [AARCH] for an Ethernet interface is formed by appending the Interface Identifier, as defined above, to the prefix FE80::/64. The 54 bits following 1111111011 are zero. There is little difference between FE80::/10 and FE80::/64. On Ethernet, it is the latter. |> I repeated the test with the link local addresses. Here also, I |> experienced no problems. This is because there are two links with |> exactly the same address pairs (an advantage to use same LL addresses |> on all interfaces). | |Demonstrating the advantage of loopback0 vs eth0 would have implied that |you start OSPFv3 on eth0 instead of loopback0 and that it would have |crashed. My routing protocols do not crash. I told you before. |But even then, I'm sure there may exist OSPFv3 implementation which |would not crash when running over eth0 and ifconfig down eth0. | |In this sense, if the loopback0 interface is a solution to crashing |OSPFv3-over-eth0, then it is an implementation solution. Some |implementations do, others don't. You totally missed the point. Teco. From alexandru.petrescu@gmail.com Thu Mar 5 06:15:24 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B8C628C42F for ; Thu, 5 Mar 2009 06:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.067, 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 vt5LtUS8S5Aw for ; Thu, 5 Mar 2009 06:15:23 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 54C1A28C39C for ; Thu, 5 Mar 2009 06:15:19 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n25EFmkc023145; Thu, 5 Mar 2009 15:15:48 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n25EFl8c001286; Thu, 5 Mar 2009 15:15:47 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n25EFlAv012347; Thu, 5 Mar 2009 15:15:47 +0100 Message-ID: <49AFDE93.60904@gmail.com> Date: Thu, 05 Mar 2009 15:15:47 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Teco Boot References: <499F0BA7.90501@piuha.net> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl><49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl><49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl><49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net> <49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D803@xmb-rtp-208.amer.cisco.com> <49AEBA6D.7030903@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5DB1F@xmb-rtp-208.amer.cisco.com> <49AF97FA.70200! 07@gmail.com> <002201c99d76$017d4b20$0477e160$@nl> <49AFAA15.9! 060905@gmail.com> <003a01c99d8e$f47ba2f0$dd72e8d0$@nl> <49AFD85E.50403! 01@gmail.com> <004a01c99d9b$542e1e10$fc8a5a30$@nl> In-Reply-To: <004a01c99d9b$542e1e10$fc8a5a30$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Thu, 05 Mar 2009 14:15:24 -0000 Teco Boot a écrit : > Hi Alex, > > > |> So the following topology is valid: > |> > |> +----------+ +----------+ > |> | |fe80::1/64 | | > |> | +========================+ | > |> | router 1 | fe80::2/64| router 2 | > |> | |fe80::1/64 | | > |> | +========================+ | > |> | | fe80::2/64| | > |> +----------+ +----------+ > |> > |> Agreed on this? > | > |Agreed. But why /64? An address is /128, and the link-local address' > |prefix is /10. > > I used address-prefix format (RFC4291). > > And RFC2464: > > 5. Link-Local Addresses > The IPv6 link-local address [AARCH] for an Ethernet interface is > formed by appending the Interface Identifier, as defined above, to > the prefix FE80::/64. Ah! > The 54 bits following 1111111011 are zero. There is little difference > between FE80::/10 and FE80::/64. On Ethernet, it is the latter. Which one should we picture on the AUTOCONF practical addressing scheme? The /10 or the /64? In a picture like that I'd definitely put an address and the prefix like this, in the simplest case: ---\ \ fe80::1/128 (the address) --------- / 2001:db8::/64 (the prefix of the subnet on which this interface is ---/ attached) > |> I repeated the test with the link local addresses. Here also, I > |> experienced no problems. This is because there are two links with > |> exactly the same address pairs (an advantage to use same LL addresses > |> on all interfaces). > | > |Demonstrating the advantage of loopback0 vs eth0 would have implied that > |you start OSPFv3 on eth0 instead of loopback0 and that it would have > |crashed. > > My routing protocols do not crash. I told you before. Sorry, I don't remember. So then they could work without loopback0 interface, only over the Ethernet interface, right? (they wouldn't crash when the interface goes down and then up). > |But even then, I'm sure there may exist OSPFv3 implementation which > |would not crash when running over eth0 and ifconfig down eth0. > | > |In this sense, if the loopback0 interface is a solution to crashing > |OSPFv3-over-eth0, then it is an implementation solution. Some > |implementations do, others don't. > > You totally missed the point. Your point seemed to motivate the use of loopback0 interface. And so, because presumably the physical interfaces are not enough. Am I catching your point? Alex From alexandru.petrescu@gmail.com Thu Mar 5 06:19:07 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D13403A68DD for ; Thu, 5 Mar 2009 06:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.066, 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 nrGhBifMRQev for ; Thu, 5 Mar 2009 06:19:07 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id D28953A69A7 for ; Thu, 5 Mar 2009 06:19:06 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n25EJY3Z025054; Thu, 5 Mar 2009 15:19:34 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n25EJXJY006794; Thu, 5 Mar 2009 15:19:33 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n25EJXNn013777; Thu, 5 Mar 2009 15:19:33 +0100 Message-ID: <49AFDF74.7020406@gmail.com> Date: Thu, 05 Mar 2009 15:19:32 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Alexandru Petrescu References: <499F0BA7.90501@piuha.net> <007b01c99911$907facf0$b17f06d0$@nl><49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl><49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl><49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net> <49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D803@xmb-rtp-208.amer.cisco.com> <49AEBA6D.7030903@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5DB1F@xmb-rtp-208.amer.cisco.com> <49AF97FA.70200! 07@gmail.com> <002201c99d76$017d4b20$0477e160$@nl> <49AFAA15.9! 060905@gmail.com> <003a01c99d8e$f47ba2f0$dd72e8d0$@nl> <49AFD85E.50403! 01@gmail.com> <004a01c99d9b$542e1e10$fc8a5a30$@nl> <49AFDE93.60904@gmail.com> In-Reply-To: <49AFDE93.60904@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Thu, 05 Mar 2009 14:19:07 -0000 Alexandru Petrescu a écrit : > Teco Boot a écrit : >> Hi Alex, >> >> >> |> So the following topology is valid: >> |> >> |> +----------+ +----------+ >> |> | |fe80::1/64 | | >> |> | +========================+ | >> |> | router 1 | fe80::2/64| router 2 | >> |> | |fe80::1/64 | | >> |> | +========================+ | >> |> | | fe80::2/64| | >> |> +----------+ +----------+ >> |> >> |> Agreed on this? >> | >> |Agreed. But why /64? An address is /128, and the link-local address' >> |prefix is /10. >> >> I used address-prefix format (RFC4291). >> >> And RFC2464: >> >> 5. Link-Local Addresses >> The IPv6 link-local address [AARCH] for an Ethernet interface is >> formed by appending the Interface Identifier, as defined above, to >> the prefix FE80::/64. > > Ah! > >> The 54 bits following 1111111011 are zero. There is little difference >> between FE80::/10 and FE80::/64. On Ethernet, it is the latter. > > Which one should we picture on the AUTOCONF practical addressing scheme? > The /10 or the /64? > > In a picture like that I'd definitely put an address and the prefix like > this, in the simplest case: > > ---\ > \ fe80::1/128 (the address) > --------- > / 2001:db8::/64 (the prefix of the subnet on which this interface is > ---/ attached) For clarification, I meant this: /------\ / \ fe80::1/128 (the address) | Router |-------------- \ / 2001:db8::/64 (the prefix of the subnet on which \------/ this interface is attached) Alex From teco@inf-net.nl Thu Mar 5 06:51:04 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACA6E3A67F5 for ; Thu, 5 Mar 2009 06:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.755 X-Spam-Level: X-Spam-Status: No, score=-1.755 tagged_above=-999 required=5 tests=[AWL=0.291, 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 f4IOZy9oSRh4 for ; Thu, 5 Mar 2009 06:51:04 -0800 (PST) Received: from cpsmtpo-eml03.kpnxchange.com (cpsmtpo-eml03.KPNXCHANGE.COM [213.75.38.152]) by core3.amsl.com (Postfix) with ESMTP id AF0D13A6809 for ; Thu, 5 Mar 2009 06:51:03 -0800 (PST) Received: from cpsmtp-eml102.kpnxchange.com ([213.75.84.102]) by cpsmtpo-eml03.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 15:51:25 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml102.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 15:51:26 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <499F0BA7.90501@piuha.net> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl><49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl><49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl><49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net> <49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D803@xmb-rtp-208.amer.cisco.com> <49AEBA6D.7030903@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5DB1F@xmb-rtp-208.amer.cisco.com> <49AF97FA.70200! 07@gmail.com> <002201c99d76$017d4b20$0477e160$@nl> <49AFAA15.9! 060905@gmail.com> <003a01c99d8e$f47ba2f0$dd72e8d0$@nl> <49AFD85E.50403! 01@gmail.com> <004a01c99d9b$542e1e10$fc8a5a30$@nl> <49AFDE93.609 04@gmail.com> In-Reply-To: <49AFDE93.60904@gmail.com> Date: Thu, 5 Mar 2009 15:51:26 +0100 Message-ID: <004b01c99da1$dc4ab9b0$94e02d10$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmdnONCHiOkeTlzT+mpjtL1LHF8CAAAhanA Content-Language: nl X-OriginalArrivalTime: 05 Mar 2009 14:51:26.0084 (UTC) FILETIME=[DBDE3C40:01C99DA1] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Thu, 05 Mar 2009 14:51:04 -0000 Hi Alex, |> The 54 bits following 1111111011 are zero. There is little difference |> between FE80::/10 and FE80::/64. On Ethernet, it is the latter. | |Which one should we picture on the AUTOCONF practical addressing scheme? | The /10 or the /64? It depends. With Ethernet (and related 802 addressing), it is /64. For other interfaces, there is more freedom. But there is RFC4291: For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. | |In a picture like that I'd definitely put an address and the prefix like |this, in the simplest case: | |---\ | \ fe80::1/128 (the address) | --------- | / 2001:db8::/64 (the prefix of the subnet on which this interface |is |---/ attached) | Why? Please read RFC4291 section 2.3 (Address Prefixes) This "fe80::1/128" is an invalid address prefix. Address fe80::1 is OK, Address prefixes fe80::1/64 and 2001:db8::1/64 are also OK. |> |> I repeated the test with the link local addresses. Here also, I |> |> experienced no problems. This is because there are two links with |> |> exactly the same address pairs (an advantage to use same LL |addresses |> |> on all interfaces). |> | |> |Demonstrating the advantage of loopback0 vs eth0 would have implied |that |> |you start OSPFv3 on eth0 instead of loopback0 and that it would have |> |crashed. |> |> My routing protocols do not crash. I told you before. | |Sorry, I don't remember. So then they could work without loopback0 |interface, only over the Ethernet interface, right? (they wouldn't crash |when the interface goes down and then up). | |> |But even then, I'm sure there may exist OSPFv3 implementation which |> |would not crash when running over eth0 and ifconfig down eth0. |> | |> |In this sense, if the loopback0 interface is a solution to crashing |> |OSPFv3-over-eth0, then it is an implementation solution. Some |> |implementations do, others don't. |> |> You totally missed the point. | |Your point seemed to motivate the use of loopback0 interface. And so, |because presumably the physical interfaces are not enough. Am I |catching your point? You are free using loopback interfaces or not. I explain why I have an advantage. This is not crashing protocols, it is eliminating unneeded terminated sessions. I do not accept a comment that I have no advantage. I have also different scenarios, some have benefits from a loopback interface, some have not. I am waiting on an answer from you, on your standpoint to be interoperable with me or not. I hope your routing protocol doesn't crash when receiving a host prefix. If so, I do not want to be compatible with you. Teco. |Alex From alexandru.petrescu@gmail.com Thu Mar 5 07:09:22 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 639173A67F5 for ; Thu, 5 Mar 2009 07:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=0.065, 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 0K4AzFKjdfhY for ; Thu, 5 Mar 2009 07:09:21 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 3AC1A3A67D1 for ; Thu, 5 Mar 2009 07:09:20 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n25F9oZJ023801; Thu, 5 Mar 2009 16:09:50 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n25F9n11010638; Thu, 5 Mar 2009 16:09:49 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n25F9mI6001852; Thu, 5 Mar 2009 16:09:49 +0100 Message-ID: <49AFEB3C.8010703@gmail.com> Date: Thu, 05 Mar 2009 16:09:48 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Teco Boot References: <499F0BA7.90501@piuha.net> <49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl><49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl><49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net> <49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D803@xmb-rtp-208.amer.cisco.com> <49AEBA6D.7030903@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5DB1F@xmb-rtp-208.amer.cisco.com> <49AF97FA.70200! 07@gmail.com> <002201c99d76$017d4b20$0477e160$@nl> <49AFAA15.9! 060905@gmail.com> <003a01c99d8e$f47ba2f0$dd72e8d0$@nl> <49AFD85E.50403! 01@gmail.com> <004a01c99d9b$542e1e10$fc8a5a30$@nl> <49AFDE93.60! 904@gmail.com> <004b01c99da1$dc4ab9b0$94e02d10$@nl> In-Reply-To: <004b01c99da1$dc4ab9b0$94e02d10$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Thu, 05 Mar 2009 15:09:22 -0000 Teco Boot a écrit : > Hi Alex, > > |> The 54 bits following 1111111011 are zero. There is little difference > |> between FE80::/10 and FE80::/64. On Ethernet, it is the latter. > | > |Which one should we picture on the AUTOCONF practical addressing scheme? > | The /10 or the /64? > > It depends. > With Ethernet (and related 802 addressing), it is /64. > For other interfaces, there is more freedom. But there is RFC4291: > For all unicast addresses, except those that start with the binary > value 000, Interface IDs are required to be 64 bits long and to be > constructed in Modified EUI-64 format. I agree. > |In a picture like that I'd definitely put an address and the prefix like > |this, in the simplest case: > | > |---\ > | \ fe80::1/128 (the address) > | --------- > | / 2001:db8::/64 (the prefix of the subnet on which this interface > |---/ attached) > | > > Why? > Please read RFC4291 section 2.3 (Address Prefixes) > > This "fe80::1/128" is an invalid address prefix. > Address fe80::1 is OK, Address prefixes fe80::1/64 and 2001:db8::1/64 are > also OK. Ah ok! I'd normally picture what are the parameters I need to set up the network you illustrated on linux. So would this be ok:? /------\ / \ fe80::1 (the address) | Router |-------------- \ / 2001:db8::/64 (the prefix of the subnet on which \------/ this interface is attached) For me, whereas the 2001:db8::/64 information is enough to add in radvd.conf, or to add with ifconfig, the problem is that I can't just say "ifconfig eth0 add fe80::1" and I must say "ifconfig eth0 add fe80::1/10", otherwise error. > |> |> I repeated the test with the link local addresses. Here also, I > |> |> experienced no problems. This is because there are two links with > |> |> exactly the same address pairs (an advantage to use same LL > |addresses > |> |> on all interfaces). > |> | > |> |Demonstrating the advantage of loopback0 vs eth0 would have implied > |that > |> |you start OSPFv3 on eth0 instead of loopback0 and that it would have > |> |crashed. > |> > |> My routing protocols do not crash. I told you before. > | > |Sorry, I don't remember. So then they could work without loopback0 > |interface, only over the Ethernet interface, right? (they wouldn't crash > |when the interface goes down and then up). > | > |> |But even then, I'm sure there may exist OSPFv3 implementation which > |> |would not crash when running over eth0 and ifconfig down eth0. > |> | > |> |In this sense, if the loopback0 interface is a solution to crashing > |> |OSPFv3-over-eth0, then it is an implementation solution. Some > |> |implementations do, others don't. > |> > |> You totally missed the point. > | > |Your point seemed to motivate the use of loopback0 interface. And so, > |because presumably the physical interfaces are not enough. Am I > |catching your point? > > You are free using loopback interfaces or not. > I explain why I have an advantage. This is not crashing protocols, it is > eliminating unneeded terminated sessions. > > I do not accept a comment that I have no advantage. I have also different > scenarios, some have benefits from a loopback interface, some have not. I am > waiting on an answer from you, on your standpoint to be interoperable with > me or not. I hope your routing protocol doesn't crash when receiving a host > prefix. If so, I do not want to be compatible with you. Well my answer is that as of now I don't use any routing protocol, and only put manual prefixes in the routing tables. Alex From teco@inf-net.nl Thu Mar 5 07:34:29 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ACDF3A6899 for ; Thu, 5 Mar 2009 07:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.763 X-Spam-Level: X-Spam-Status: No, score=-1.763 tagged_above=-999 required=5 tests=[AWL=0.283, 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 muTgRXMLQhvb for ; Thu, 5 Mar 2009 07:34:28 -0800 (PST) Received: from cpsmtpo-eml03.kpnxchange.com (cpsmtpo-eml03.KPNXCHANGE.COM [213.75.38.152]) by core3.amsl.com (Postfix) with ESMTP id 4BD3D3A6809 for ; Thu, 5 Mar 2009 07:34:27 -0800 (PST) Received: from cpsmtp-eml110.kpnxchange.com ([10.94.168.110]) by cpsmtpo-eml03.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 16:34:53 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml110.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 16:34:52 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <499F0BA7.90501@piuha.net> <49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl><49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl><49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net> <49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D803@xmb-rtp-208.amer.cisco.com> <49AEBA6D.7030903@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5DB1F@xmb-rtp-208.amer.cisco.com> <49AF97FA.70200! 07@gmail.com> <002201c99d76$017d4b20$0477e160$@nl> <49AFAA15.9! 060905@gmail.com> <003a01c99d8e$f47ba2f0$dd72e8d0$@nl> <49AFD85E.50403! 01@gmail.com> <004a01c99d9b$542e1e10$fc8a5a30$@nl> <49AFDE93.60! 904@gmail.com> <004b01c99da1$dc4ab9b0$94e02d10$@nl> <49AFEB3C. 8010703@gmail.com> In-Reply-To: <49AFEB3C.8010703@gmail.com> Date: Thu, 5 Mar 2009 16:34:53 +0100 Message-ID: <004c01c99da7$ee315700$ca940500$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmdpHFtJNvd3EF0T6y8m0+ihhl/5QAAVtyw Content-Language: nl X-OriginalArrivalTime: 05 Mar 2009 15:34:52.0644 (UTC) FILETIME=[ED7FBA40:01C99DA7] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Thu, 05 Mar 2009 15:34:29 -0000 Hi Alex, |> This "fe80::1/128" is an invalid address prefix. |> Address fe80::1 is OK, Address prefixes fe80::1/64 and 2001:db8::1/64 |are |> also OK. | |Ah ok! I'd normally picture what are the parameters I need to set up |the network you illustrated on linux. So would this be ok:? | | /------\ |/ \ fe80::1 (the address) || Router |-------------- |\ / 2001:db8::/64 (the prefix of the subnet on which | \------/ this interface is attached) | Now you don't depict the address in subnet 2001:db8::/64. |For me, whereas the 2001:db8::/64 information is enough to add in |radvd.conf, or to add with ifconfig, the problem is that I can't just |say "ifconfig eth0 add fe80::1" and I must say "ifconfig eth0 add |fe80::1/10", otherwise error. Try ifconfig eth0 inet6 add fe80::1/64 Or ip -6 addr add fe80::1/64 dev eth0 I think you tried to add an IPv4 address, with failing DNS lookup. |> You are free using loopback interfaces or not. |> I explain why I have an advantage. This is not crashing protocols, it |is |> eliminating unneeded terminated sessions. |> |> I do not accept a comment that I have no advantage. I have also |different |> scenarios, some have benefits from a loopback interface, some have |not. I am |> waiting on an answer from you, on your standpoint to be interoperable |with |> me or not. I hope your routing protocol doesn't crash when receiving a |host |> prefix. If so, I do not want to be compatible with you. | |Well my answer is that as of now I don't use any routing protocol, and |only put manual prefixes in the routing tables. OK for me. I hope you can live with different settings, preferred by others. Teco. |Alex From alexandru.petrescu@gmail.com Thu Mar 5 07:41:18 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07B1128C187 for ; Thu, 5 Mar 2009 07:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.064, 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 LY0laNVhZhrC for ; Thu, 5 Mar 2009 07:41:17 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id F056B3A6899 for ; Thu, 5 Mar 2009 07:41:16 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n25Fdxsn024958; Thu, 5 Mar 2009 16:39:59 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n25FfiX8020057; Thu, 5 Mar 2009 16:41:44 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n25FfhQo014731; Thu, 5 Mar 2009 16:41:43 +0100 Message-ID: <49AFF2B7.2060600@gmail.com> Date: Thu, 05 Mar 2009 16:41:43 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Teco Boot References: <499F0BA7.90501@piuha.net> <49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl><49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net> <49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D803@xmb-rtp-208.amer.cisco.com> <49AEBA6D.7030903@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5DB1F@xmb-rtp-208.amer.cisco.com> <49AF97FA.70200! 07@gmail.com> <002201c99d76$017d4b20$0477e160$@nl> <49AFAA15.9! 060905@gmail.com> <003a01c99d8e$f47ba2f0$dd72e8d0$@nl> <49AFD85E.50403! 01@gmail.com> <004a01c99d9b$542e1e10$fc8a5a30$@nl> <49AFDE93.60! 904@gmail.com> <004b01c99da1$dc4ab9b0$94e02d10$@nl> <49AFEB3C! .8010703@gmail.com> <004c01c99da7$ee315700$ca940500$@nl> In-Reply-To: <004c01c99da7$ee315700$ca940500$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Thu, 05 Mar 2009 15:41:18 -0000 Teco Boot a écrit : > Hi Alex, > > |> This "fe80::1/128" is an invalid address prefix. > |> Address fe80::1 is OK, Address prefixes fe80::1/64 and 2001:db8::1/64 > |are > |> also OK. > | > |Ah ok! I'd normally picture what are the parameters I need to set up > |the network you illustrated on linux. So would this be ok:? > | > | /------\ > |/ \ fe80::1 (the address) > || Router |-------------- > |\ / 2001:db8::/64 (the prefix of the subnet on which > | \------/ this interface is attached) > | > > Now you don't depict the address in subnet 2001:db8::/64. Right, I didn't, and I should have had. How would you depict a Router with one interface, a global subnet prefix, an address within that prefix, and a link-local address? Without indulging any confusion. If you don't want then I can depict it. > |For me, whereas the 2001:db8::/64 information is enough to add in > |radvd.conf, or to add with ifconfig, the problem is that I can't just > |say "ifconfig eth0 add fe80::1" and I must say "ifconfig eth0 add > |fe80::1/10", otherwise error. > > Try ifconfig eth0 inet6 add fe80::1/64 > Or ip -6 addr add fe80::1/64 dev eth0 > > I think you tried to add an IPv4 address, with failing DNS lookup. No, it wasn't DNS lookup error, but I avoid saying ifconfig fe80::1/64 because the prefix fe80::/64 is not an on-link prefix (even though fe80::1 is an address on that link). If I write ifconfig 2001:db8::1/64 then the 2001:db8::/64 becomes an on-link prefix. > |> You are free using loopback interfaces or not. > |> I explain why I have an advantage. This is not crashing protocols, it > |is > |> eliminating unneeded terminated sessions. > |> > |> I do not accept a comment that I have no advantage. I have also > |different > |> scenarios, some have benefits from a loopback interface, some have > |not. I am > |> waiting on an answer from you, on your standpoint to be interoperable > |with > |> me or not. I hope your routing protocol doesn't crash when receiving a > |host > |> prefix. If so, I do not want to be compatible with you. > | > |Well my answer is that as of now I don't use any routing protocol, and > |only put manual prefixes in the routing tables. > > OK for me. > I hope you can live with different settings, preferred by others. Well yes but let's first find the most common common settings. Alex From teco@inf-net.nl Thu Mar 5 08:37:10 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 216B63A6861 for ; Thu, 5 Mar 2009 08:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.771 X-Spam-Level: X-Spam-Status: No, score=-1.771 tagged_above=-999 required=5 tests=[AWL=0.275, 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 MwXxPhXSX6pG for ; Thu, 5 Mar 2009 08:37:09 -0800 (PST) Received: from cpsmtpo-eml03.kpnxchange.com (cpsmtpo-eml03.KPNXCHANGE.COM [213.75.38.152]) by core3.amsl.com (Postfix) with ESMTP id 33D1A3A69F3 for ; Thu, 5 Mar 2009 08:37:09 -0800 (PST) Received: from cpsmtp-eml101.kpnxchange.com ([213.75.84.101]) by cpsmtpo-eml03.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 17:37:30 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml101.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 17:37:30 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <499F0BA7.90501@piuha.net> <49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl><49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net> <49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D803@xmb-rtp-208.amer.cisco.com> <49AEBA6D.7030903@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5DB1F@xmb-rtp-208.amer.cisco.com> <49AF97FA.70200! 07@gmail.com> <002201c99d76$017d4b20$0477e160$@nl> <49AFAA15.9! 060905@gmail.com> <003a01c99d8e$f47ba2f0$dd72e8d0$@nl> <49AFD85E.50403! 01@gmail.com> <004a01c99d9b$542e1e10$fc8a5a30$@nl> <49AFDE93.60! 904@gmail.com> <004b01c99da1$dc4ab9b0$94e02d10$@nl> <49AFEB3C! .8010703@gmail.com> <004c01c99da7$ee315700$ca940500$@nl> <49AFF2 B7.2060600@gmail.com> In-Reply-To: <49AFF2B7.2060600@gmail.com> Date: Thu, 5 Mar 2009 17:37:31 +0100 Message-ID: <005701c99db0$adbc6620$09353260$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmdqOWqZpQFBSyhSZK714QxH+6IfgAAzuow Content-Language: nl X-OriginalArrivalTime: 05 Mar 2009 16:37:30.0147 (UTC) FILETIME=[AD252F30:01C99DB0] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Thu, 05 Mar 2009 16:37:10 -0000 |> | /------\ |> |/ \ fe80::1 (the address) |> || Router |-------------- |> |\ / 2001:db8::/64 (the prefix of the subnet on which |> | \------/ this interface is attached) |> | |> |> Now you don't depict the address in subnet 2001:db8::/64. | |Right, I didn't, and I should have had. How would you depict a Router |with one interface, a global subnet prefix, an address within that |prefix, and a link-local address? Without indulging any confusion. OK, this is a basic setup. Just depict what you have: +--------+ | | fe80::1/64 (the LL address-prefix) | Router +-------------- | | 2001:db8::1/64 (the address prefix configured on +--------+ this interface) Maybe use ll::1 as short presentation for fe80::1/64 And p::1/64 for the address prefix, and define the prefix p:: somewhere in the diagram. |If you don't want then I can depict it. | |> |For me, whereas the 2001:db8::/64 information is enough to add in |> |radvd.conf, or to add with ifconfig, the problem is that I can't |just |> |say "ifconfig eth0 add fe80::1" and I must say "ifconfig eth0 add |> |fe80::1/10", otherwise error. |> |> Try ifconfig eth0 inet6 add fe80::1/64 |> Or ip -6 addr add fe80::1/64 dev eth0 |> |> I think you tried to add an IPv4 address, with failing DNS lookup. | |No, it wasn't DNS lookup error, but I avoid saying ifconfig fe80::1/64 |because the prefix fe80::/64 is not an on-link prefix (even though |fe80::1 is an address on that link). If I write ifconfig 2001:db8::1/64 |then the 2001:db8::/64 becomes an on-link prefix. I would say it is mandatory for interfaces to have a link-local address (RFC 4291). And I think they are on-link by definition. Or are you interested in a less common or a rare setup? Teco. From joseph.macker@nrl.navy.mil Thu Mar 5 08:45:03 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51F6D28C360 for ; Thu, 5 Mar 2009 08:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.15 X-Spam-Level: X-Spam-Status: No, score=-5.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, 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 tNzF7TlmF323 for ; Thu, 5 Mar 2009 08:45:01 -0800 (PST) Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by core3.amsl.com (Postfix) with ESMTP id 9CB9F28C31C for ; Thu, 5 Mar 2009 08:45:01 -0800 (PST) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id n25Giv8O029056; Thu, 5 Mar 2009 11:45:06 -0500 Received: (from sextant [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2009030511450422724 ; Thu, 05 Mar 2009 11:45:04 -0500 From: "Joe Macker" To: "'Dearlove, Christopher \(UK\)'" , "'Alexandru Petrescu'" , "'Teco Boot'" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com><000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com><1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl><49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl><49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl><49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl><49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl><49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net><49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com><49AE9827.5090309@gmail.com> <000c01c99ce9$e09bf500$a1d3df00$@nl><49AEB846.5020103@gmail.com> <000101c99d00$664c7f60$32e57e20$@nl> <49AF1! ! 292.30502 08@gmail.co m> In-Reply-To: Date: Thu, 5 Mar 2009 11:44:58 -0500 Message-ID: <001901c99db1$b8989770$29c9c650$@macker@nrl.navy.mil> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmdI1O5bovQKRycQgGOO7OZ37rV5gAZx51wAAmiN0A= Content-Language: en-us Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Thu, 05 Mar 2009 16:45:03 -0000 IMHO, many successful manet networks are often partially planned. Chris RFC 2501 attempts to tip its hat in this direction -------- The technology of Mobile Ad hoc Networking is somewhat synonymous with Mobile Packet Radio Networking (a term coined via during early military research in the 70's and 80's), Mobile Mesh Networking (a term that appeared in an article in The Economist regarding the structure of future military networks) and Mobile, Multihop, Wireless Networking (perhaps the most accurate term, although a bit cumbersome). --------- > -----Original Message----- > From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On Behalf Of Dearlove, Christopher (UK) > Sent: Thursday, March 05, 2009 7:10 AM > To: Alexandru Petrescu; Teco Boot > Cc: autoconf@ietf.org > Subject: Re: [Autoconf] Autoconf addressing model > > > > Along these lines, an interpretation of 'ad-hoc' is a happening which > > hasn't been planned, spontaneous, etc. > > That is the dictionary definition of ad hoc. But "ad hoc network" > has become a term of art, whose fundamentals are about decentralised, > cooperative, multi-hop routing. (I'm not sure if RFC 2501 attempts > a definition, I haven't checked it recently.) "ad hoc" got attached > to such networks because they often were/are ad hoc in the dictionary > sense. But often ad hoc networks are not completely unplanned, but > still retain that label. > > ******************************************************************** > 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 alexandru.petrescu@gmail.com Thu Mar 5 08:48:20 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8981428C210 for ; Thu, 5 Mar 2009 08:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.063, 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 jYn9fVa2qZjW for ; Thu, 5 Mar 2009 08:48:19 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 6F66C3A6A79 for ; Thu, 5 Mar 2009 08:48:19 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n25Gl10A008352; Thu, 5 Mar 2009 17:47:01 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n25GmlYD010481; Thu, 5 Mar 2009 17:48:47 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n25GmlGT022513; Thu, 5 Mar 2009 17:48:47 +0100 Message-ID: <49B0026F.5070905@gmail.com> Date: Thu, 05 Mar 2009 17:48:47 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Teco Boot References: <499F0BA7.90501@piuha.net> <49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net> <49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D803@xmb-rtp-208.amer.cisco.com> <49AEBA6D.7030903@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5DB1F@xmb-rtp-208.amer.cisco.com> <49AF97FA.70200! 07@gmail.com> <002201c99d76$017d4b20$0477e160$@nl> <49AFAA15.9! 060905@gmail.com> <003a01c99d8e$f47ba2f0$dd72e8d0$@nl> <49AFD85E.50403! 01@gmail.com> <004a01c99d9b$542e1e10$fc8a5a30$@nl> <49AFDE93.60! 904@gmail.com> <004b01c99da1$dc4ab9b0$94e02d10$@nl> <49AFEB3C! .8010703@gmail.com> <004c01c99da7$ee315700$ca940500$@nl> <49AFF! 2B7.2060600@gmail.com> <005701c99db0$adbc6620$09353260$@nl> In-Reply-To: <005701c99db0$adbc6620$09353260$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Thu, 05 Mar 2009 16:48:20 -0000 Teco Boot a écrit : [...] > OK, this is a basic setup. > Just depict what you have: > +--------+ > | | fe80::1/64 (the LL address-prefix) > | Router +-------------- > | | 2001:db8::1/64 (the address prefix configured on > +--------+ this interface) I agree with this starting point. I'm wondering what others in the WG think about this starting point in depicting a practical addressing architecture for AUTOCONF. I would really appreciate to have some oppinions about this. > Maybe use ll::1 as short presentation for fe80::1/64 > And p::1/64 for the address prefix, and define the prefix p:: somewhere in > the diagram. No, not for the moment. > |If you don't want then I can depict it. > | > |> |For me, whereas the 2001:db8::/64 information is enough to add in > |> |radvd.conf, or to add with ifconfig, the problem is that I can't > |just > |> |say "ifconfig eth0 add fe80::1" and I must say "ifconfig eth0 add > |> |fe80::1/10", otherwise error. > |> > |> Try ifconfig eth0 inet6 add fe80::1/64 > |> Or ip -6 addr add fe80::1/64 dev eth0 > |> > |> I think you tried to add an IPv4 address, with failing DNS lookup. > | > |No, it wasn't DNS lookup error, but I avoid saying ifconfig fe80::1/64 > |because the prefix fe80::/64 is not an on-link prefix (even though > |fe80::1 is an address on that link). If I write ifconfig 2001:db8::1/64 > |then the 2001:db8::/64 becomes an on-link prefix. > > I would say it is mandatory for interfaces to have a link-local address (RFC > 4291). And I think they are on-link by definition. > Or are you interested in a less common or a rare setup? Right, I agree with you. Have a link-local address on every physical interface. I'm not yet interested in less common setup. Alex From joseph.macker@nrl.navy.mil Thu Mar 5 08:55:22 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5A9928C0DD for ; Thu, 5 Mar 2009 08:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.15 X-Spam-Level: X-Spam-Status: No, score=-5.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, 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 pqo6vWaixb0p for ; Thu, 5 Mar 2009 08:55:21 -0800 (PST) Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by core3.amsl.com (Postfix) with ESMTP id 8EC063A6A41 for ; Thu, 5 Mar 2009 08:55:21 -0800 (PST) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id n25Gtdic029873; Thu, 5 Mar 2009 11:55:40 -0500 Received: (from sextant [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2009030511554022790 ; Thu, 05 Mar 2009 11:55:40 -0500 From: "Joe Macker" To: "'Stan Ratliff \(sratliff\)'" , "'Alexandru Petrescu'" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com><000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com><1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl><49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl><49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl><49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl><49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl><49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net> <49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D803@xmb-rtp-208.amer.cisco.com> <49AEBA6D.7030903@gmail.com> <7FB7EE! 0A621BA44B8B69E5F0A09DC 76407B5DB1F@xmb-rtp-208.amer.cisco.com> In-Reply-To: <7FB7EE0A621BA44B8B69E5F0A09DC76407B5DB1F@xmb-rtp-208.amer.cisco.com> Date: Thu, 5 Mar 2009 11:55:34 -0500 Message-ID: <001a01c99db3$33407960$99c16c20$@macker@nrl.navy.mil> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acmc7tiiUEclImn0SFW37TI7C6NxiAAHwq4gAClNdZA= Content-Language: en-us Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Thu, 05 Mar 2009 16:55:22 -0000 Ditto what Stan says... for what its worth. > -----Original Message----- > From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On = Behalf Of Stan Ratliff (sratliff) > Sent: Wednesday, March 04, 2009 4:35 PM > To: Alexandru Petrescu > Cc: autoconf@ietf.org > Subject: Re: [Autoconf] Autoconf addressing model >=20 >=20 >=20 > > -----Original Message----- > > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > > Sent: Wednesday, March 04, 2009 12:29 PM > > To: Stan Ratliff (sratliff) > > Cc: Charles E. Perkins; autoconf@ietf.org > > Subject: Re: [Autoconf] Autoconf addressing model > > > > Stan Ratliff (sratliff) a =E9crit : > > > First off, you *can't* arbitrarily limit subnets to 25m. 25m from > > > what? The center? > > > > Yes, an area of 25meters with a wifi access point in the center. >=20 > *By definition*, what you describe is not a MANET. As you state, = that's just a WiFi access point. That's > already solved -- 802.11 clients can roam from access point to access = point. But again, this should not be > an 802.11-centric discussion. >=20 > > > > > And, how do you designate the center? Do you constantly > > re-calculate > > > the center based on movement? > > > > No, not constantly re-computed. But have a fixed view at a > > point in time. Saying everything varies isn't helpful either. > > >=20 > It may not be helpful, but it's reality. You can't rely on a fixed = view of a dynamic network; again, by > definition, there's movement in a MANET. Links come and go, and link = quality varies from moment to moment. >=20 >=20 > > > Also, from a radio perspective, how do you tell how far > > apart you are > > > in the first place? Do you suppose that all radios have > > GPS? That's a > > > non-starter, because GPS signals aren't always available. > > > > No I didn't suppose GPS is available on each device, it > > wouldn't work well under foliage. Just a rough evaluation of > > a specific link-layer radio range, correspondign to widely > > used networks. > > > > > And what about the wired MANET case brought up by Christopher > > > Dearlove? Should we limit the cable runs? > > > > YEs, certainly. All cabled link-layers have specific > > limitations on their lengths: 2m USB, 50m Ethernet Category6 > > (IIRC) and so on. > > > > > I could understand (but > > > wouldn't really like) the notion of limiting the discussion > > to links > > > that are transitive; but placing some arbitrary distance > > limit that's > > > based on 802.11 just doesn't cut it for me. > > > > 802.11 is being used widely, no reason to ignore. >=20 > I'm not advocating we "ignore" 802.11, or any other L2 technology, for = that matter. I'm advocating that we > remain Layer 2 agnostic. As Teco mentioned in another email, there are = people in this WG that don't deploy > MANET networks based on 802.11, or 802.16, or 802.15.4. >=20 > > > > I'd happily accept to add another specific limitation, from > > the link-layer of your choice. And be speecifically > > addressing these two link layers. And maybe three. No more > > than three. > > > > I find addressing them all to be difficult for me. >=20 > I don't understand why the Layer 3 addressing scheme needs to be = predicated on a specific Layer 2 > technology, or set of technologies. The Layer 3 addressing scheme = should be totally independent of Layer 2 - > - isn't that what layering is all about? >=20 > > > > (about single point of failure being destroyed by a falling tree: > > problem could be addressed at its layer: don't move the > > command center > > under trees risking falling); or maybe have two command centers, = but > > specificllay two, not an arbitrary large unknown number. > > >=20 > That essentially boils down to "if it hurts, don't do it", and it = doesn't work for my customers. Their > environments are dynamic, and they need the ability to respond to = ever-changing realities on the ground. >=20 > At this point, I feel that we're in a discussion that is becoming more = and more circular, and therefore, > dysfunctional. And that, IMO, has been the unfortunate reality of this = WG since its inception. >=20 > Regards, > Stan >=20 >=20 > > Alex > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From teco@inf-net.nl Thu Mar 5 09:13:38 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8E3928C40B for ; Thu, 5 Mar 2009 09:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.778 X-Spam-Level: X-Spam-Status: No, score=-1.778 tagged_above=-999 required=5 tests=[AWL=0.268, 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 oTC80IRQh4uJ for ; Thu, 5 Mar 2009 09:13:38 -0800 (PST) Received: from hpsmtp-eml17.kpnxchange.com (hpsmtp-eml17.KPNXCHANGE.COM [213.75.38.117]) by core3.amsl.com (Postfix) with ESMTP id F177828C405 for ; Thu, 5 Mar 2009 09:13:37 -0800 (PST) Received: from cpsmtp-eml104.kpnxchange.com ([213.75.84.104]) by hpsmtp-eml17.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 18:14:06 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml104.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 18:14:06 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <499F0BA7.90501@piuha.net> <49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net> <49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D803@xmb-rtp-208.amer.cisco.com> <49AEBA6D.7030903@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5DB1F@xmb-rtp-208.amer.cisco.com> <49AF97FA.70200! 07@gmail.com> <002201c99d76$017d4b20$0477e160$@nl> <49AFAA15.9! 060905@gmail.com> <003a01c99d8e$f47ba2f0$dd72e8d0$@nl> <49AFD85E.50403! 01@gmail.com> <004a01c99d9b$542e1e10$fc8a5a30$@nl> <49AFDE93.60! 904@gmail.com> <004b01c99da1$dc4ab9b0$94e02d10$@nl> <49AFEB3C! .8010703@gmail.com> <004c01c99da7$ee315700$ca940500$@nl> <49AFF! 2B7.2060600@gmail.com> <005701c99db0$adbc6620$09353260$@nl> <49B 0026F.5070905@gmail.co m> In-Reply-To: <49B0026F.5070905@gmail.com> Date: Thu, 5 Mar 2009 18:14:07 +0100 Message-ID: <006401c99db5$cad6dc90$608495b0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmdskVZSJJpFDLNSjiyXnScCr9J0QAAfZ5g Content-Language: nl X-OriginalArrivalTime: 05 Mar 2009 17:14:06.0785 (UTC) FILETIME=[CA718B10:01C99DB5] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Thu, 05 Mar 2009 17:13:39 -0000 OK, we can start with a single interface setup: Agreed on the starting point with three nodes, and non-transitivity solved by MANET Routing? <-------------------------v--------> <------v--------------------------> | <---|----------------------v----------------------|---> | | | |2001:db8:1::1/64 |2001:db8:2::2/64 |2001:db8:3::3/64 |fe80::1/64 |fe80::2/64 |fe80::3/64 +---+---+ +---+---+ +---+---+ |Router1| |Router2| |Router3| +-------+ +-------+ +-------+ Routing table Router1: Destination Next-hop Hops =============== ======== ==== 2001:db8:2::/64 fe80::2 1 2001:db8:3::/64 fe80::2 2 Routing table Router2: Destination Next-hop Hops =============== ======== ==== 2001:db8:1::/64 fe80::1 1 2001:db8:3::/64 fe80::3 1 Routing table Router3: Destination Next-hop Hops =============== ======== ==== 2001:db8:1::/64 fe80::2 2 2001:db8:2::/64 fe80::2 1 I see a problem with this, who has assigned the globally unique prefixes? Manually configured? Is it intended to connect to the Internet? Is the Access Router known on forehand? Maybe it is better to start with ULA as the most basic setup. Teco. From chris.dearlove@baesystems.com Thu Mar 5 09:18:40 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66A0728C1DE for ; Thu, 5 Mar 2009 09:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.655 X-Spam-Level: X-Spam-Status: No, score=-6.655 tagged_above=-999 required=5 tests=[AWL=-0.055, 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 EVhT1KFnKjqp for ; Thu, 5 Mar 2009 09:18:39 -0800 (PST) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id 67E2028C17F for ; Thu, 5 Mar 2009 09:18:39 -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 n25HJ78X022010 for ; Thu, 5 Mar 2009 17:19:07 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 n25HJ7st023005 for ; Thu, 5 Mar 2009 17:19:07 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Thu, 05 Mar 2009 17:19:06 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Thu, 5 Mar 2009 17:19:06 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 5 Mar 2009 17:19:04 -0000 Message-ID: In-Reply-To: <006401c99db5$cad6dc90$608495b0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Autoconf addressing model thread-index: AcmdskVZSJJpFDLNSjiyXnScCr9J0QAAfZ5gAABwngA= References: <499F0BA7.90501@piuha.net> <49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net><49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D803@xmb-rtp-208.amer.cisco.com> <49AEBA6D.7030903@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5DB1F@xmb-rtp-208.amer.cisco.com><49AF97FA.70200! 07@gmail.com><002201c99d76$017d4b20$0477e160$@nl> <49AFAA15.9!060905@gmail.com> <003a01c99d8e$f47ba2f0$dd72e8d0$@nl><49AFD85E.50403! 01@gmail.com><004a01c99d9b$542e1e10$fc8a5a30$@nl> <49AFDE93.60!904@gmail.com> <004b01c99da1$dc4ab9b0$94e02d10$@nl> <49AFEB3C!.8010703@gmail.com> <004c01c99da7$ee315700$ca940500$@nl><49AFF! 2B7.2060600@gmail.com><005701c99db0$adbc6620$09353260$@nl> <49B 0026F.50! 70905@gma il.co m> <006401c99db5$cad6dc90$608495b0$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Alexandru Petrescu" X-OriginalArrivalTime: 05 Mar 2009 17:19:06.0637 (UTC) FILETIME=[7D2B53D0:01C99DB6] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Thu, 05 Mar 2009 17:18:40 -0000 > I see a problem with this, who has assigned the globally unique prefixes? Isn't that (part of) the problem this group is to address? At this point we are specifying a requirement that (assuming that model, which I'm not commenting on) such prefixes are to be assigned. How it happens (as long as it's possible, and manual configuration, though not the required solution, is presumably an existence proof for that) is not the issue right now. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From teco@inf-net.nl Thu Mar 5 09:29:30 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D779C28C4D9 for ; Thu, 5 Mar 2009 09:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.785 X-Spam-Level: X-Spam-Status: No, score=-1.785 tagged_above=-999 required=5 tests=[AWL=0.261, 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 DT4mGLNSUnaI for ; Thu, 5 Mar 2009 09:29:30 -0800 (PST) Received: from cpsmtpo-eml06.kpnxchange.com (cpsmtpo-eml06.KPNXCHANGE.COM [213.75.38.155]) by core3.amsl.com (Postfix) with ESMTP id CE3AA28C4D8 for ; Thu, 5 Mar 2009 09:29:29 -0800 (PST) Received: from cpsmtp-eml102.kpnxchange.com ([213.75.84.102]) by cpsmtpo-eml06.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 18:29:58 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml102.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 18:29:58 +0100 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" , "'Alexandru Petrescu'" References: <499F0BA7.90501@piuha.net> <49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net><49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D803@xmb-rtp-208.amer.cisco.com> <49AEBA6D.7030903@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5DB1F@xmb-rtp-208.amer.cisco.com><49AF97FA.70200! 07@gmail.com><002201c99d76$017d4b20$0477e160$@nl> <49AFAA15.9!060905@gmail.com> <003a01c99d8e$f47ba2f0$dd72e8d0$@nl><49AFD85E.50403! 01@gmail.com><004a01c99d9b$542e1e10$fc8a5a30$@nl> <49AFDE93.60!904@gmail.com> <004b01c99da1$dc4ab9b0$94e02d10$@nl> <49AFEB3C!.8010703@gmail.com> <004c01c99da7$ee315700$ca940500$@nl><49AFF! 2B7.2060600@gmail.com><005701c99db0$adbc6620$09353260$@nl> <49B 0026F.50! 70905@gma il.co m> < 006401c99db5$cad6dc90$608495b0$@nl> In-Reply-To: Date: Thu, 5 Mar 2009 18:29:59 +0100 Message-ID: <006b01c99db8$022f7e20$068e7a60$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmdskVZSJJpFDLNSjiyXnScCr9J0QAAfZ5gAABwngAAADLCkA== Content-Language: nl X-OriginalArrivalTime: 05 Mar 2009 17:29:58.0579 (UTC) FILETIME=[01C1C830:01C99DB8] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Thu, 05 Mar 2009 17:29:30 -0000 OK, I can agree. My point was verifying that we had the basic setup. Assume a bootstrapping setup of a disconnected network, then we would not have the 2001: prefix. A self-generated ULA prefix can be used. As a next step, the globally unique addresses can be added or may replace the ULA. Teco. |-----Oorspronkelijk bericht----- |Van: Dearlove, Christopher (UK) [mailto:chris.dearlove@baesystems.com] |Verzonden: donderdag 5 maart 2009 18:19 |Aan: Teco Boot; Alexandru Petrescu |CC: autoconf@ietf.org |Onderwerp: RE: [Autoconf] Autoconf addressing model | | |> I see a problem with this, who has assigned the globally unique |prefixes? | |Isn't that (part of) the problem this group is to address? |At this point we are specifying a requirement that (assuming |that model, which I'm not commenting on) such prefixes are |to be assigned. How it happens (as long as it's possible, and |manual configuration, though not the required solution, is |presumably an existence proof for that) is not the issue |right now. | | |******************************************************************** |This email and any attachments are confidential to the intended |recipient and may also be privileged. If you are not the intended |recipient please delete it from your system and notify the sender. |You should not copy it or use it for any purpose nor disclose or |distribute its contents to any other person. |******************************************************************** From alexandru.petrescu@gmail.com Thu Mar 5 09:53:41 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D061528C3BF for ; Thu, 5 Mar 2009 09:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[AWL=0.138, 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 dwOWtB5E0bQd for ; Thu, 5 Mar 2009 09:53:41 -0800 (PST) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by core3.amsl.com (Postfix) with ESMTP id CBA3528C288 for ; Thu, 5 Mar 2009 09:53:39 -0800 (PST) Received: from smtp2-g21.free.fr (localhost [127.0.0.1]) by smtp2-g21.free.fr (Postfix) with ESMTP id 160E64B0156; Thu, 5 Mar 2009 18:54:04 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp2-g21.free.fr (Postfix) with ESMTP id A34BF4B01C3; Thu, 5 Mar 2009 18:54:01 +0100 (CET) Message-ID: <49B011B2.600@gmail.com> Date: Thu, 05 Mar 2009 18:53:54 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Teco Boot References: <499F0BA7.90501@piuha.net> <49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net> <49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D803@xmb-rtp-208.amer.cisco.com> <49AEBA6D.7030903@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5DB1F@xmb-rtp-208.amer.cisco.com> <49AF97FA.70200! 07@gmail.com> <002201c99d76$017d4b20$0477e160$@nl> <49AFAA15.9! 060905@gmail.com> <003a01c99d8e$f47ba2f0$dd72e8d0$@nl> <49AFD85E.50403! 01@gmail.com> <004a01c99d9b$542e1e10$fc8a5a30$@nl> <49AFDE93.60! 904@gmail.com> <004b01c99da1$dc4ab9b0$94e02d10$@nl> <49AFEB3C! .8010703@gmail.com> <004c01c99da7$ee315700$ca940500$@nl> <49AFF! 2B7.2060600@gmail.com> <005701c99db0$adbc6620$09353260$@nl> <49B0026F.5070905@gmail.co m> <006401c99db5$cad6dc90$608495b0$@nl> In-Reply-To: <006401c99db5$cad6dc90$608495b0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090305-0, 05/03/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing 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: , X-List-Received-Date: Thu, 05 Mar 2009 17:53:41 -0000 Teco Boot a écrit : > OK, we can start with a single interface setup: > Agreed on the starting point with three nodes, and non-transitivity solved > by MANET Routing? > > > <-------------------------v--------> > <------v--------------------------> | > <---|----------------------v----------------------|---> > | | | > |2001:db8:1::1/64 |2001:db8:2::2/64 |2001:db8:3::3/64 > |fe80::1/64 |fe80::2/64 |fe80::3/64 > +---+---+ +---+---+ +---+---+ > |Router1| |Router2| |Router3| > +-------+ +-------+ +-------+ Teco I don't agree with this setup. It's a significant leap of faith from the initial starting point. I need first to listen to what others think about the initial starting point. Alex > > > Routing table Router1: > Destination Next-hop Hops > =============== ======== ==== > 2001:db8:2::/64 fe80::2 1 > 2001:db8:3::/64 fe80::2 2 > > Routing table Router2: > Destination Next-hop Hops > =============== ======== ==== > 2001:db8:1::/64 fe80::1 1 > 2001:db8:3::/64 fe80::3 1 > > Routing table Router3: > Destination Next-hop Hops > =============== ======== ==== > 2001:db8:1::/64 fe80::2 2 > 2001:db8:2::/64 fe80::2 1 > > I see a problem with this, who has assigned the globally unique prefixes? > Manually configured? Is it intended to connect to the Internet? Is the > Access Router known on forehand? > Maybe it is better to start with ULA as the most basic setup. > > > Teco. > > > > > > From alexandru.petrescu@gmail.com Thu Mar 5 09:58:11 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 762D328C3FD for ; Thu, 5 Mar 2009 09:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.815 X-Spam-Level: X-Spam-Status: No, score=-0.815 tagged_above=-999 required=5 tests=[AWL=-1.165, BAYES_50=0.001, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYzor+8NpYnz for ; Thu, 5 Mar 2009 09:58:10 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 884E428C373 for ; Thu, 5 Mar 2009 09:58:08 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 78840E081DD for ; Thu, 5 Mar 2009 18:58:34 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp6-g21.free.fr (Postfix) with ESMTP id 7688BE080D6 for ; Thu, 5 Mar 2009 18:58:32 +0100 (CET) Message-ID: <49B012C1.4030502@gmail.com> Date: Thu, 05 Mar 2009 18:58:25 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: autoconf@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 090305-0, 05/03/2009), Outbound message X-Antivirus-Status: Clean Subject: [Autoconf] Comments on an initial starting point? X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 17:58:11 -0000 Dear AUTOCONFers, I would like to know your oppinion on the initial starting point for a practical addressing architecture: +--------+ | | fe80::1/64 (the LL address-prefix) | Router +-------------- | | 2001:db8::1/64 (the address prefix configured on +--------+ this interface) Teco and myself came up with this picture, thinking it may represent a good starting point for planning a practical IPv6 addressing scheme for ad-hoc networks. I am interested to listen any kind of oppinion on this - is this good? Can this lead to something good? How? Thanks in advance, Alex From teco@inf-net.nl Fri Mar 6 00:31:43 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 247AF3A6BE6 for ; Fri, 6 Mar 2009 00:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[AWL=0.254, 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 fWx3aZwfvR75 for ; Fri, 6 Mar 2009 00:31:42 -0800 (PST) Received: from hpsmtp-eml18.kpnxchange.com (hpsmtp-eml18.KPNXCHANGE.COM [213.75.38.118]) by core3.amsl.com (Postfix) with ESMTP id 121983A6BD9 for ; Fri, 6 Mar 2009 00:31:41 -0800 (PST) Received: from cpsmtp-eml102.kpnxchange.com ([213.75.84.102]) by hpsmtp-eml18.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Mar 2009 09:32:07 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml102.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Mar 2009 09:32:07 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" , References: <49B012C1.4030502@gmail.com> In-Reply-To: <49B012C1.4030502@gmail.com> Date: Fri, 6 Mar 2009 09:32:07 +0100 Message-ID: <008d01c99e36$095f8f90$1c1eaeb0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmdvAdhUtCHiGXAQqm2Bp7z5KITWAAdD/9Q Content-Language: nl X-OriginalArrivalTime: 06 Mar 2009 08:32:07.0192 (UTC) FILETIME=[08ECA980:01C99E36] Subject: Re: [Autoconf] Comments on an initial starting point? X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 08:31:43 -0000 Hi Alex, I am an AUTOCONFer, so I respond. As in the previous two postings, we may easy have different opinions on the semantics / context of the diagram. The syntax is correct, and agreed on. So what may be the difference? 1) What is the delegated prefix to this router? 2001:db8::/128? 2001:db8::/64? 2001:db8::/60? 2) Is the prefix-length on the interfaces limited to /64? 3) Is it mandatory to use the same prefix-length for all addresses on an interface? My opinion so far: 1) This is unknown, but 2001:db8::/64 at a minimum. No other router SHOULD advertize sub-prefixes out of this delegated prefix. 2) It depends. If the interface is Ethernet or look-alike, and SLAAC is supported, the answer is yes. If EUI-64 is being used as InterfaceID, the answer is yes. If SLAAC and privacy extensions are used, the answer would be yes. When cryptographically generated addresses are used, the answer should be yes. But still, someone may say, the answer is no. Ask Thomas Narten? 3) Not mandatory at all. But it may be "practical". Here two "practical" examples of the same starting point: 2001:db8::/60 (the delegated prefix) | V +--------+ | | fe80::1/64 (the LL address-prefix) | Router +-------------- | | 2001:db8::1/64 (the address prefix configured on +--------+ this interface) 2001:db8::1/128 (the delegated prefix) | V +--------+ | | fe80::1/64 (the LL address-prefix) | Router +-------------- | | 2001:db8::1/128 (the address prefix configured on +--------+ this interface) I am not quite happy with the last one. As I mentioned before, I am not sure on configuring a host prefix on an interface to a multi-access link. And the LL InterfaceID is the same as the last 64 bits of the delegated prefix. This is an extreme rare coincidence and very confusing. So we better not use this in our examples. I think this one is invalid: 2001:db8::1/128 (the delegated prefix) | V +--------+ | | fe80::1/64 (the LL address-prefix) | Router +-------------- | | 2001:db8::1/64 (the address prefix configured on +--------+ this interface) Here, a prefix is configured that is larger than the delegated prefix. Teco. |-----Oorspronkelijk bericht----- |Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens |Alexandru Petrescu |Verzonden: donderdag 5 maart 2009 18:58 |Aan: autoconf@ietf.org |Onderwerp: [Autoconf] Comments on an initial starting point? | |Dear AUTOCONFers, | |I would like to know your oppinion on the initial starting point for a |practical addressing architecture: | |+--------+ || | fe80::1/64 (the LL address-prefix) || Router +-------------- || | 2001:db8::1/64 (the address prefix configured on |+--------+ this interface) | |Teco and myself came up with this picture, thinking it may represent a |good starting point for planning a practical IPv6 addressing scheme for |ad-hoc networks. | |I am interested to listen any kind of oppinion on this - is this good? |Can this lead to something good? How? | |Thanks in advance, | |Alex |_______________________________________________ |Autoconf mailing list |Autoconf@ietf.org |https://www.ietf.org/mailman/listinfo/autoconf From ryuji.wakikawa@gmail.com Thu Mar 12 17:43:53 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CE363A67FA for ; Thu, 12 Mar 2009 17:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5x2oNrjTrI-A for ; Thu, 12 Mar 2009 17:43:52 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 3481B3A69F4 for ; Thu, 12 Mar 2009 17:43:52 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so1427750wfd.31 for ; Thu, 12 Mar 2009 17:44:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:subject:mime-version:date :x-mailer; bh=T0KgeJWHVv4JG3ds8UF50T4JjuZ3Nrw+xvYaPyVR/AU=; b=uwL8lFOMcBLNkUAu+hoyPHPXG0uiKcw36jdNOq9TOhhn0ohOkfEsfiuXrCHd/G0cxG vPsUFTwfKeJ4jELa5FGJng69RkHo11EU1Sh0rYsB9wMaLDqHTRmh1S46wTjsLmgx7AUI ymi8ThPltWfM/k3hcFXAdhoauyUL2mOihJcws= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding:subject :mime-version:date:x-mailer; b=LkgnyjztbLzy1o10po0KDgSkDCfSfi6NjOt5SY+NBv5UHM/7PIN6gaboMbLAYTkHhI ApeA1RabVd52nUs67JY6qbuw0dqyiHgsF8aj0JdkliaTy5CWerHptlB0vzabGlrIltFh 6yESMPc6X+z+Dl1syEPfHZn2PDpOk9OeHHOsA= Received: by 10.115.18.3 with SMTP id v3mr412840wai.178.1236905070016; Thu, 12 Mar 2009 17:44:30 -0700 (PDT) Received: from EM114-48-41-0.pool.e-mobile.ne.jp (EM114-48-41-0.pool.e-mobile.ne.jp [114.48.41.0]) by mx.google.com with ESMTPS id l37sm1115824waf.3.2009.03.12.17.44.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 12 Mar 2009 17:44:29 -0700 (PDT) Message-Id: <1FC7B157-B1AC-41FB-B20A-B2A2EF37845E@gmail.com> From: Ryuji Wakikawa To: autoconf@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 13 Mar 2009 09:44:25 +0900 X-Mailer: Apple Mail (2.930.3) Subject: [Autoconf] Forming DT for the first WG deliverable, "address configuration in ad hoc networks" X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 00:43:53 -0000 Dear all, As Jari mentioned in the new plan for the AUTOCONF WG, we have decided to form a design team to rapidly produce a -00 strawman of the first working group deliverable, discussing (citing Jari) "a practical way of configuring MANET networks". The WG milestones in the new charter are - Apr 2009 Submit initial draft on address configuration in ad hoc networks - Sep 2009 Submit address configuration draft to IESG as Informational or close WG. In forming this design team, our goal has been to get a balance between strong IP/INT experts and strong MANET experts on board. The current composition of the design team is: o Charles E. Perkins o Thomas Narten o Mark Townsley o Emmanuel Baccelli o Teco Boot We're hoping and aiming for this design team to be able to produce a -00 strawman before SF, as well as to have identified issues (if any) where further discussion is required. The design team is charged with producing a -00 strawman and to, once the WG has decided to adopt this as a wg document, hold the pen in the editorial process that follows. In view of the very short time until SF, we've set up a mailing list for the design team to conduct its initial business. Here's the announcement, as sent upon establishing the design team and the list The list is closed for public subscriptions, as it is intended only for "initial exercises" on getting a -00 I-D produced. Once a -00 is produced, we'd want to take subsequent discussions on autoconf@ietf.org and shut this list down. However, the archives of this list are public, and at this URL: > http://lists.thomasclausen.net/pipermail/autoconf-dt/ Notice that the design team produces a strawman -00 in order to kick-start the process -- and that we all need to get on board with that document and help develop it once a -00 strawman is out. Over the past month or so, a long list of folks have contacted the chairs and offered their help for contributing text, reviewing etc. (Thanks!) Considering the tight schedule, we're going to be needing all the help we can get, as soon as the strawman is out and we know where work is required -- so stay tuned. Thomas & Ryuji From ryuji.wakikawa@gmail.com Mon Mar 23 16:41:26 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF7F628C12E for ; Mon, 23 Mar 2009 16:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxHFYLb7-8BV for ; Mon, 23 Mar 2009 16:41:26 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id 3720E28C0DF for ; Mon, 23 Mar 2009 16:41:26 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so1950789rvb.49 for ; Mon, 23 Mar 2009 16:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:subject:mime-version:date :references:x-mailer; bh=tdu8Tej8lOgCWlJN2vLtFOLQpZWfITZ05JRtcxqOTCY=; b=SzbP0iMrBmbh7cjiIofpN7buncT7a3BfA6HmVCjbXLWTslK74+FJtk74beinD/9KLL L7hZcK3zAo8w5/FCwnwqAeh/xuF8a22WryoD84yLrCAILrbXlb1dXzIWzFuoIE1BguTe t/GY5Srq7H2gIxj+fs1QqYQ1XO6tyxnXm8ehk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding:subject :mime-version:date:references:x-mailer; b=k1VjUoPivcTKuOnFHXK5Z+tdBTjDqIe5sf/Ioa01TH3cd7a60V9gLhAPcYP2SpSlVd qRx0QU08PHWJe1/gURRy3LdrNoPgkrbS67InKnTJqvQPrMKg4OsjPD3YwKfc49UMRyCM tjtes/7Y8zaLNVaoRAewVYzU+LoNGWLk565B4= Received: by 10.142.81.7 with SMTP id e7mr3096603wfb.158.1237851736613; Mon, 23 Mar 2009 16:42:16 -0700 (PDT) Received: from dhcp-52e0.meeting.ietf.org ([130.129.82.224]) by mx.google.com with ESMTPS id 9sm12347451wfc.20.2009.03.23.16.42.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Mar 2009 16:42:15 -0700 (PDT) Message-Id: <2AAF296B-A472-4CA4-8B58-DB1D6A994BE1@gmail.com> From: Ryuji Wakikawa To: autoconf@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 23 Mar 2009 16:42:14 -0700 References: <20090323225821.ED2A03A6C09@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) Subject: [Autoconf] Reschedule AUTOCONF 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: , X-List-Received-Date: Mon, 23 Mar 2009 23:41:27 -0000 Hi all, We have decided to re-schedule the AUTOCONF meeting from Tuesday to Thursday. AUTOCONF takes over the MEXT second slot which was canceled. Here is the new meeting info. > AUTOCONF Session 1 (2 hours) > Thursday, Afternoon Session II 1510-1610 > Room Name: Continental 6 If you conflicts schedules or other working group, we are really sorry for this. We also apologize this reschedule happened in this last minutes. The agenda will be presentations about DT update only. No presentations other than the addressing model is scheduled at this AUTOCONF meeting. regards, Thomas and Ryuji Begin forwarded message: > From: IETF Secretariat > Date: 2009/03/23 15:58:21:PDT > To: T.Clausen@computer.org > Cc: ryuji.wakikawa@gmail.com,T.Clausen@computer.org,rdroms@cisco.com,jari.arkko@piuha.net > ,townsley@cisco.com,session-request@ietf.org > Subject: AUTOCONF - Requested session has been scheduled for IETF 74 > > Dear Thomas Heide Clausen, > > The sessions that you have requested have been scheduled. > Below is the scheduled session information followed by > the information of sessions that you have requested. > > AUTOCONF Session 1 (2 hours) > Thursday, Afternoon Session II 1510-1610 > Room Name: Continental 6 > ---------------------------------------------- > > Special Note: moved from Tuesday 0900, replaced MEXT's slot From Ronald.intVelt@tno.nl Mon Mar 23 21:27:14 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D6713A6952 for ; Mon, 23 Mar 2009 21:27:14 -0700 (PDT) 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_64=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 v8f5EAYJLwTe for ; Mon, 23 Mar 2009 21:27:12 -0700 (PDT) Received: from mailouta.tno.nl (mailouta.tno.nl [134.221.1.16]) by core3.amsl.com (Postfix) with ESMTP id 1B3FB3A6783 for ; Mon, 23 Mar 2009 21:27:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,411,1233529200"; d="scan'208";a="17820491" Received: from ms-dt01thalia.tno.nl (HELO ms-dt01thalia.tsn.tno.nl) ([134.221.225.157]) by mailhost1a.tno.nl with ESMTP; 24 Mar 2009 05:28:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Mar 2009 05:28:01 +0100 Message-ID: <7877C5C0B5CC894AB26113CF06CF886301238D30@ms-dt01thalia.tsn.tno.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-clausen-manet-autoconf-recommendations-00 Thread-Index: AcmsOOqOPrq0smnpSVCmRVatUq53Gw== From: "Velt, R. (Ronald) in 't" To: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Subject: [Autoconf] Comments on draft-clausen-manet-autoconf-recommendations-00 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 04:27:14 -0000 Thomas, Ulrich, all, Please find below some comments on draft-clausen-manet-autoconf-recommendations-00.txt Regards, Ronald in 't Velt Comments on I-D title, abstract and introduction: ------------------------------------------------- It is not entirely clear to me what the intention behind this I-D is. Is the goal that it evolves into the "one practical addressing model" that=20 the proposed new WG charter calls for? Is it merely a description of one (tried and tested) way in which MANET addresses could be configured? If=20 the latter, why is the the word "Recommendations" in the title? The=20 specified "intended status" of the I-D is "informational". RFC2026, sec. 4.2.2. says: > An "Informational" specification is published for the general > information of the Internet community, and does not represent an > Internet community consensus or recommendation. Of course, this does not rule out that this I-D contains recommendations from the authors. However, it seems to me that "recommendations" is a=20 slightly awkward term. Some additional words of explanation might help. Also, the I-D mentions several times that the presented approach is supported by an "existence proof", i.e. its viability has been proven by succesfully=20 deploying MANETs this way. At the same time, the addressing examples given in=20 the document all seem to be based on IPv4. (Even though the text frequently=20 says "/32 or /128"). This begs the question whether the "existence proof" extends to real-world IPv6 MANETs. Perhaps it would be useful to add an appendix to the document, which provides details like platform / OS (version),=20 IPv4 or IPv6, etc. on some of the networks that the authors have gained=20 experience with and based their "recommendations" on. Comment on section 2.1, MANET "Node" Morphology ----------------------------------------------- The I-D says: | 2.1. MANET "Node" Morphology -- Hosts and Routers | | Each "independent node" in a MANET can functionally be described | according to Figure 1, with the "MANET node" being composed of a | "MANET router" (R) with one or more "MANET interfaces" -- i.e. the | interface which is to be used for establishing connectivity between | MANET routers -- as well as zero or more interfaces towards other | networks or hosts on classic IP links. | | \|/ | MANET interface | | +-----------|---------------------+ | | +--+------+ | | | | R | MANET router| | | +---------+ | | | | | | | | +---+ | Classical IP | | | | H | | links with | | | +---+ | hosts | | | _______|______ | | | | | | | | | +---+ +---+ +---+ | | | | H |...| H | | H | | | | +---+ +---+ +---+ | | | | | +---------------------------------+ | MANET node | | Figure 1: MANET "node" morphology | Terminology: What is shown in Fig. 1 is not a node, but a collection of nodes: one router and several hosts. Comment on section 2.2, MANET Interface Configuration: ------------------------------------------------------ The I-D says: | 2.2. MANET Interface Configuration | | The following summarizes the configuration constraints for MANET | interfaces of a MANET router: | | o Each MANET interface on a MANET router MUST be configured with an | IP address which is unique, at least within the MANET. | | o Each MANET interface MUST be configured with a prefix length of | /32 (for IPv4) or /128 (for IPv6). | What is, conspicuously, missing here, is a "recommendation" on what IPv4 broadcast address should be configured on the MANET interface. I think=20 this should be added, along with a subsequent "rationale and justification"=20 in Section 4. Comment on Section 3.1, MANET Router and Single Host ---------------------------------------------------- The I-D says: | 3.1. MANET Router and Single Host | | Figure 3 illustrates a MANET node consisting of a MANET router with a | single MANET interface and a single host. This is the typical case, | for example, when one has a laptop, PDA or smartphone participating | in the MANET: the "router" and the "host" are in that case logical | components within the same device, and with a single physical | interface. | | The MANET node is assigned a single IPv4 address, in this case | 192.168.1.1. This IP address is to identify both the MANET interface | of the MANET router as well as the host. Logically, this is | accomplished by configuring the interface of the MANET router as an | Shouldn't that read: "the interface of the host?" | | "unnumbered interface", by assigning 192.168.1.1/32 to the MANET | interface of the router. Traffic to the logical component that is | the router will typically be addressed to a well-known multicast | address, thus the router can distinguish between traffic to itself | and traffic to the logical host. This seems to contradict a previous interpretation of the (now dead, but not forgotten) MANET Architecture I-D, which was that a host, even if=20 co-located with / internal to the MANET Router, could not adopt the IP=20 address of the MANET interface. I recall asking this specifically at the=20 microphone during the Autoconf session in Vancouver (IETF-70), saying that=20 is was common practice and being told that people had been doing it wrong=20 for years (by none other than one of the authors of this I-D :-) Comment on Section 3.2, MANET Router and Attached Network w. Prefix Delegation ------------------------------------------------------------------------ ------ The I-D says: ------------- | 3.2. MANET Router and Attached Network w. Prefix Delegation | | Figure 5 illustrates a MANET router with a single MANET interface and | an interface towards a classic IP link such as an Ethernet. The | MANET router is delegated the IPv4 prefix 192.168.1.0/24. That | prefix is assigned to the non-MANET link, on which interfaces are | assigned addresses such as 192.168.1.1/24, 192.168.1.2/24, | 192.168.1.3/24 etc. Note that the interfaces on that classic IP link | are configured with a prefix length of /24, indicating that the | interfaces with addresses from within that IP prefix are all | reachable within a single IP hop. | | The MANET interface is configured as an "unnumbered interface" by | "borrowing" the address (192.168.1.1) from its interface towards the | classic IP link - but is configured with the prefix length /32. The | MANET interface is, specifically, not configured with a prefix length | of /24, even though that prefix is delegated to the MANET router, as | the MANET interface is not able to reach all other interfaces with | addresses from within 192.168.1.0./24 in a single IP hop. | | | | 192.168.1.1/32 \|/ | +------------|------------+ | | | | | | +-+-----+ | | | | R | 192.168.1.0/24 | | +-------+ | | |192.168.1.1/24 | | | | | | | +---------------+---------+ | | | ,----------+-----------. | | | | | +---+ +---+ +---+ | 192.168.1.2/24 | H | | H | | H | 192.168.1.4/24 | +---+ +---+ +---+ | 192.168.1.3/24 | | Figure 5: MANET router (R) with an attached network and a delegated | subnet prefix. Notice that the prefix 192.168.1.0/24 is assigned to | the non-MANET link, where interfaces are configured with that prefix, | e.g. 192.168.1.3/24. The MANET interface "borrows" the IP address | from that link, however is configured with a prefix length of /32. | | Traffic to the MANET interface with the IP address 192.168.1.1 can be | distinguished from traffic to the non-MANET interface with the same | address since traffic destined to the MANET interface of the router | typically will be addressed to a well-known multicast address. Wouldn't it be convenient if the MANET Router had an address for e.g. remote management? Comment on Section 3.3, MANET Router and Attached Network w/o Prefix Delegation ------------------------------------------------------------------------ ------- The I-D says: | 3.3. MANET Router and Attached Network w/o Prefix Delegation | | Figure 6 shows a situation similar to that of Section 3.2 except that | the MANET router, for whatever reason, is not delegated any prefix. | | As no prefix has been delegated to the MANET router, the MANET router | can not simply "borrow" an IP address from within a delegated prefix | for its MANET interface and know this IP address to be unique -- but | has to rely on some other mechanism for acquiring an IP address. | Whichever mechanism is used for acquiring this IP address, is shall | ensure that this IP address is unique, at least within the MANET. If I understand Section 2.2 correctly, IP address unicity is a necessary, but not a sufficient condition. Its prefix should be unique within the=20 MANET as well. Comment on Section 4.2, /32 and /128 Prefix Lengths --------------------------------------------------- The I-D says: | 4.2. /32 and /128 Prefix Lengths | | In early MANET deployments, a common occurrence was to configure a | MANET as "a subnet" and configure it as indicated in Figure 9: the | MANET would have a subnet prefix, say 192.168.1.0/24 and MANET | interfaces would be configured with this subnet prefix, e.g. | 192.168.1.3/24. | | Communication | Range | <~~~~~~~~~~~~+~~~~~~~~~~~~> <~~~~~~~~~~~~+~~~~~~~~~~~~~> | |<~~~~~~~~~~~~+~~~~~~~~~~~~>| | +--------+ +--------+ +--------+ | |192.168.| |192.168.| |192.168.| | | 1.1/24 | | 1.2/24 | | 1.3/24 | | +--------+ +--------+ +--------+ | | Data packet: --------------> | dest 192.168.1.3 | next-hop 192.168.1.2 | | ICMP Redirect <-------------- | | | Figure 9: Misconfigured MANET: MANET interfaces configured with a | shared /24 prefix, causing the central router to produce an ICMP | redirect when forwarding packets from 192.126.1.1 to 192.168.1.3. | | If, for example, a data packet was transmitted by the MANET router | 192.168.1.1 to be received by 192.168.1.3, then this would -- with | reference to Figure 9 -- have to be forwarded by the MANET router | 192.168.1.2. With the MANET interfaces in this MANET being | configured with the subnet prefix 192.168.1 and the prefix length | /24, it was observed that this produced ICMP redirects by | 192.168.1.2. | | An early, and often suggested, solution was to "treat the symptoms | rather than cure the disease" by disabling ICMP redirects on MANET | routers -- i.e. to require modifications to the IP stack operation in | order that it can be supporting MANETs. | | The ICMP redirect is intended to be used to inform a source to send | packets using an alternative, more direct, route -- e.g. if a source, | s wishes to send a data packet to a destination node d via the path | s-R1-R2-d, and if R1 knows that a direct path s-R2-d is available, | then the ICMP redirect from R1 will inform s of this route. | | Two interfaces, configured with addresses from within the same subnet | prefix, and with the same prefix length are defined to be reachable | from each other within a single IP hop. More precisely, it is | assumed that all interfaces with IP addresses within that subnet | prefix and configured with the same prefix length are directly | reachable from each other without forwarding by an intermediate | router. Hence, a way for R1 to know that a direct path may exist | between h and R2 is if h, R1 and R2 are configured with IP addresses | from within the same subnet prefix and within the same subnet prefix. | | Returning to the MANET scenario in Figure 9, with all MANET | interfaces being configured with the same subnet prefix and the same | prefix length, it follows from the discussion above that all these | MANET interfaces are expected to be directly reachable from each | other within a single IP hop. When, in this configuration, the | router 192.168.1.2 is requested to forward a data packet from | 192.168.1.1 to 192.168.1.3, it is expected that it generates an ICMP | redirect to 192.168.1.1 suggesting that a direct path exists from | 192.168.1.1 to 192.168.1.3 -- as this is what the configuration | suggests. | | Rather than "treating the symptoms" and disabling ICMP redirects, | requiring /32 and /128 prefix lengths on MANET interfaces "cures the | disease". An interface so configured will not make any assumptions | about other interfaces being within a single IP hop, and so will not | generate ICMP redirects when forwarding traffic. It may cure (or rather prevent) this disease, but it could introduce other ailments. For instance, Linux has an "rp_filter" kernel parameter,=20 described as follows in the kernel documentation (networking/ip-sysctl.txt): > rp_filter - BOOLEAN > 1 - do source validation by reversed path, as specified in RFC1812 > Recommended option for single homed hosts and stub network > routers. Could cause troubles for complicated (not loop free) > networks running a slow unreliable protocol (sort of RIP), > or using static routes. > > 0 - No source validation. > > conf/all/rp_filter must also be set to TRUE to do source validation > on the interface > > Default value is 0. Note that some distributions enable it > in startup scripts. Debian is among the distributions that set rp_filter on start-up by default, being non-compliant with RFC1812, section 5.3.8. in this respect. The effect=20 is, that e.g. MANET protocol HELLO's are discarded, because they fail the=20 reverse path check. Of course, this can be fixed through a modification of a=20 configuration file. In practice, though, this is just as much work as turning=20 off the generation of ICMP redirects. Furthermore, the use of /32's (/128's) appears to exclude a configuration as depicted below: <------------------> <-----------------> \|/ \|/ \|/ | | | +-+-+ +-+-+ +-+-+ \|/ | R | \|/ | R | \|/ | R | \|/ | +---+ | +---+ | +---+ | +-+-+ +-+-+ +-+-+ +-+-+ | H | | H | | H | | H | +---+ +---+ +---+ +---+ H =3D host R =3D router Here, all nodes just have a single radio interface. Some are configured to be=20 hosts, wheras others are routers. Hosts can be considered as "satellites" of=20 routers, in the sense that each of them is associated with a particular router=20 and travels with it. Each host has a default route, with its associated router as the next hop. This can be made to work by assigning e.g. /24's from different "subnets" to the routers. For instance, in the picture above, the leftmost router gets=20 192.168.1.254, the middle one 192.168.2.254 and the rightmost router=20 192.168.3.254. The broadcast address on the routers should be set to have a wider=20 "scope" (shorter prefix)than their unicast addresses, e.g. 192.168.255.255 or even=20 255.255.255.255. This ensures that any protocols that rely on broadcast still work=20 between routers. (Autoconfiguration protocols could potentially fall into this=20 category, as do some older implementations of MANET routing protocols). Hosts are configured with addresses from the same subnet as their associated router. The=20 hosts in the leftmost cluster in the picture above would e.g. be 192.168.1.1 and=20 192.168.1.2. It could be argued that for this scenario, separate virtual interfaces should be configured on top of the radio interface. One virtual interface would then serve=20 as MANET interface, while the other(s) would be used for communication with local hosts. However, depending on the L2 technology / implementation used, this may not=20 be readily achievable. The above may not be a very common case and therefore we could agree to not support it. However, in my opinion this should be a conscious and documented=20 decision. Comment on Section 4.3, IP Hop Isolation ---------------------------------------- I-D says: | 4.3. IP Hop Isolation | There are, essentially, four potential ways of addressing this | problem: requiring all upper-layer applications and protocols to | become "MANET aware", inventing mechanisms for presenting a MANET | as-if it was an Ethernet, pushing the problem to layer 2, or | encapsulating any MANET specific behavior in a way such that it is | only exposed to explicitly MANET aware applications and protocols. I only count three ways here (?) (End of comments) This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/disclaimer/email.html From ryuji.wakikawa@gmail.com Wed Mar 25 18:49:37 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6D6B28C1E7 for ; Wed, 25 Mar 2009 18:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_72=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 i1ouPjo0Zrn7 for ; Wed, 25 Mar 2009 18:49:36 -0700 (PDT) Received: from mail-bw0-f169.google.com (mail-bw0-f169.google.com [209.85.218.169]) by core3.amsl.com (Postfix) with ESMTP id 6789928C170 for ; Wed, 25 Mar 2009 18:49:36 -0700 (PDT) Received: by bwz17 with SMTP id 17so324622bwz.37 for ; Wed, 25 Mar 2009 18:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=kViaTqdy8508uUrHot8JALH9MAKVGniG16ZwTlnlY4E=; b=nxjHL4DZA2SPTvAQb+w3LvACVfmfTAkpSnk9QBfVIYxDGN/M4kctMgS4PIRro0y97n 2aM8HQ7TqxHsmBExWfMnlr7yePYdbvuU8Eb7JW93VY87g4fHJNw67nMxXQaDnnAHZYfl oBtzi9Bp0JY79GgMEYs5+x+YGSjL1UrgrKn0g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=g7pcd1rg0WcZ7GNRQjjUaEjYxLQ1kI9wEPFtjjUly8BIaTDE37cPnTGvbOQFgWwi7p krBe8AC+uZcp4Y7Lrb8Av63WEt4+q+1TEHUIJRH0WA/MCkE186wkVijlwe3+lQ1FYDfz /OyNXxw1kbOulHZYDkEsk73T93kvzHqFOa2pM= MIME-Version: 1.0 Received: by 10.103.249.19 with SMTP id b19mr120361mus.86.1238032228253; Wed, 25 Mar 2009 18:50:28 -0700 (PDT) Date: Wed, 25 Mar 2009 18:50:28 -0700 Message-ID: <84840efa0903251850w494042a1s33dffdf31f786ce@mail.gmail.com> From: Ryuji Wakikawa To: autoconf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Autoconf] Meeting Agenda (Thursday 1510-1610 Afternoon Session II) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ryuji@sfc.wide.ad.jp List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 01:49:37 -0000 Hi all, Here is the agenda of the AUTOCONF meeting on Thursday. We apologize our delay. regards, Thomas & ryuji http://www.ietf.org/proceedings/09mar/agenda/autoconf.txt --------------------------------------------------------------------------- Ad-Hoc Network Autoconfiguration (autoconf) ---------------------------------------------------------------------------- Thursday, March 23, 2009 1510-1610 Afternoon Session II Room Name: Continental 6 ---------------------------------------------------------------------------- - Notes takers, blue sheets, agenda bash 5 min, Chairs - WG status update 5 min, Chairs - New Charter 10 min, Chairs - Status Update from Design Team 30 min, Design Team ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- The modified charter(WG Review Completed) Ad-Hoc Network Autoconfiguration (autoconf) Last Modified: 2009-02-18 Additional information is available at tools.ietf.org/wg/autoconf Chair(s): Ryuji Wakikawa Thomas Clausen Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: autoconf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf Archive: http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html Description of Working Group: In order to communicate among themselves, ad hoc nodes (refer to RFC 2501) need to configure their network interface(s) with local addresses that are valid within an ad hoc network. Ad hoc nodes may also need to configure globally routable addresses, in order to communicate with devices on the Internet. From the IP layer perspective, an ad hoc network presents itself as a L3 multi-hop network formed over a collection of links. The main purpose of the AUTOCONF WG is to describe the addressing model for ad hoc networks and how nodes in these networks configure their addresses. It is required that such models do not cause problems for ad hoc-unaware parts of the system, such as standard applications running on an ad hoc node or regular Internet nodes attached to the ad hoc nodes. This group's effort may include the development of new protocol mechanisms, should the existing IP autoconfiguration mechanisms be found inadequate. However, the first task of the working group is to describe one practical addressing model for ad hoc networks. Once this sole work item is completed, the group can be rechartered to work on additional issues. Goals and Milestones: Apr 2009 Submit initial draft on address configuration in ad hoc networks Sep 2009 Submit address configuration draft to IESG as Informational or close WG. ---------------------------------------------------------------------------- From Fred.L.Templin@boeing.com Thu Mar 26 10:05:57 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 748963A6803 for ; Thu, 26 Mar 2009 10:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.985 X-Spam-Level: X-Spam-Status: No, score=-5.985 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, 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 WZM6R9hzpnQP for ; Thu, 26 Mar 2009 10:05:56 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 78F943A67E3 for ; Thu, 26 Mar 2009 10:05:56 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n2QH6iNF008132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 26 Mar 2009 12:06:49 -0500 (CDT) 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 n2QH6iqU023824 for ; Thu, 26 Mar 2009 10:06:44 -0700 (PDT) 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 n2QH6h9g023737 for ; Thu, 26 Mar 2009 10:06:44 -0700 (PDT) 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, 26 Mar 2009 10:06:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Mar 2009 10:06:42 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105BB549C@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Comments ondraft-clausen-manet-autoconf-recommendations-00 Thread-Index: AcmsOOqOPrq0smnpSVCmRVatUq53GwAlxlJwAFk0UnA= From: "Templin, Fred L" To: X-OriginalArrivalTime: 26 Mar 2009 17:06:44.0148 (UTC) FILETIME=[3D493F40:01C9AE35] Subject: [Autoconf] FW: Comments ondraft-clausen-manet-autoconf-recommendations-00 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 17:05:57 -0000 Ronald, I thought this might be of general interest to the list (below): Fred fred.l.templin@boeing.com -----Original Message----- From: Templin, Fred L=20 Sent: Tuesday, March 24, 2009 3:48 PM To: 'Velt, R. (Ronald) in 't' Subject: RE: [Autoconf] Comments ondraft-clausen-manet-autoconf-recommendations-00 Ronald, (off-list) see below: =20 > Furthermore, the use of /32's (/128's) appears to exclude a > configuration > as depicted below: >=20 > <------------------> <-----------------> > \|/ \|/ \|/ > | | | > +-+-+ +-+-+ +-+-+ > \|/ | R | \|/ | R | \|/ | R | \|/ > | +---+ | +---+ | +---+ | > +-+-+ +-+-+ +-+-+ +-+-+ > | H | | H | | H | | H | > +---+ +---+ +---+ +---+ >=20 > H =3D host > R =3D router >=20 > Here, all nodes just have a single radio interface. Some are configured > to be > hosts, wheras others are routers. Hosts can be considered as > "satellites" of > routers, in the sense that each of them is associated with a particular > router > and travels with it. Each host has a default route, with its associated > router > as the next hop. >=20 > This can be made to work by assigning e.g. /24's from different > "subnets" > to the routers. For instance, in the picture above, the leftmost router > gets > 192.168.1.254, the middle one 192.168.2.254 and the rightmost router > 192.168.3.254. The broadcast address on the routers should be set to > have a wider > "scope" (shorter prefix)than their unicast addresses, e.g. > 192.168.255.255 or even > 255.255.255.255. This ensures that any protocols that rely on broadcast > still work > between routers. (Autoconfiguration protocols could potentially fall > into this > category, as do some older implementations of MANET routing protocols). > Hosts > are configured with addresses from the same subnet as their associated > router. The > hosts in the leftmost cluster in the picture above would e.g. be > 192.168.1.1 and > 192.168.1.2. >=20 > It could be argued that for this scenario, separate virtual interfaces > should > be configured on top of the radio interface. One virtual interface would > then serve > as MANET interface, while the other(s) would be used for communication > with local > hosts. However, depending on the L2 technology / implementation used, > this may not > be readily achievable. >=20 > The above may not be a very common case and therefore we could agree to > not > support it. However, in my opinion this should be a conscious and > documented > decision. If we are willing to let the "tethered" hosts be IPv6-only, I think this is not such a difficult challenge. As long as the router 'R' has a spare IPv6 prefix 'P', it can send RAs over the MANET interface with a router lifetime, with a PIO containing 'P' and with 'A'=3D1, 'L'=3D0. Note that 'R' assigns an IPv6 link-local only to the MANET interface; it does *not* assign an IPv6 global. The reason for 'L'=3D0 is that two hosts 'H1' and 'H2' may be tethered to 'R' but for some reason not able to reach each other directly. So, to avoid communications failures and neighbor cache pollution it is important that 'H1' and 'H2' send all packets through 'R' as a default router. The reason for 'A'=3D1 is that we want to use SLAAC per RFC4862 to autoconfigure the addresses. But with 'L'=3D0, that would mean a /128, and not a /64, etc. From ulrich@herberg.name Thu Mar 26 11:13:16 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EB323A6C47 for ; Thu, 26 Mar 2009 11:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_64=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 rDzJaxfGZ2L6 for ; Thu, 26 Mar 2009 11:13:13 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id 5CFB93A6DF2 for ; Thu, 26 Mar 2009 11:13:00 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so816438wfg.31 for ; Thu, 26 Mar 2009 11:13:53 -0700 (PDT) Received: by 10.142.68.5 with SMTP id q5mr483910wfa.12.1238091233807; Thu, 26 Mar 2009 11:13:53 -0700 (PDT) Received: from dhcp-43c2.meeting.ietf.org (dhcp-43c2.meeting.ietf.org [130.129.67.194]) by mx.google.com with ESMTPS id 32sm663940wfc.9.2009.03.26.11.13.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Mar 2009 11:13:52 -0700 (PDT) Sender: Ulrich Herberg Message-ID: <49CBC5DC.2010700@polytechnique.edu> Date: Thu, 26 Mar 2009 11:13:48 -0700 From: Ulrich Herberg Organization: Ecole Polytechnique User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Velt, R. (Ronald) in 't" References: <7877C5C0B5CC894AB26113CF06CF886301238D30@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <7877C5C0B5CC894AB26113CF06CF886301238D30@ms-dt01thalia.tsn.tno.nl> X-Enigmail-Version: 0.95.7 Content-Type: multipart/alternative; boundary="------------000101040005010703000706" Cc: autoconf@ietf.org Subject: Re: [Autoconf] Comments on draft-clausen-manet-autoconf-recommendations-00 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 18:13:16 -0000 This is a multi-part message in MIME format. --------------000101040005010703000706 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Ronald, comments inline... Velt, R. (Ronald) in 't wrote: > Thomas, Ulrich, all, > > Please find below some comments on > draft-clausen-manet-autoconf-recommendations-00.txt > > Regards, > Ronald in 't Velt > > > Comments on I-D title, abstract and introduction: > ------------------------------------------------- > > It is not entirely clear to me what the intention behind this I-D is. Is > the goal that it evolves into the "one practical addressing model" that > the proposed new WG charter calls for? Is it merely a description of one > > (tried and tested) way in which MANET addresses could be configured? If > the latter, why is the the word "Recommendations" in the title? The > specified "intended status" of the I-D is "informational". RFC2026, > sec. 4.2.2. says: > > >> An "Informational" specification is published for the general >> information of the Internet community, and does not represent an >> Internet community consensus or recommendation. >> > > Of course, this does not rule out that this I-D contains recommendations > from the authors. However, it seems to me that "recommendations" is a > slightly awkward term. Some additional words of explanation might help. > I am not against adding a few additional words explaining the purpose of this document if this is felt to be necessary. As you suggested, these recommendations reflect *our* experience of how to configure a MANET, in a way that (i) works and (ii) does not break the IP model. Of course, there may be other ways of doing so. > Also, the I-D mentions several times that the presented approach is > supported > by an "existence proof", i.e. its viability has been proven by > succesfully > deploying MANETs this way. At the same time, the addressing examples > given in > the document all seem to be based on IPv4. (Even though the text > frequently > says "/32 or /128"). This begs the question whether the "existence > proof" > extends to real-world IPv6 MANETs. Perhaps it would be useful to add an > appendix to the document, which provides details like platform / OS > (version), > IPv4 or IPv6, etc. on some of the networks that the authors have gained > experience with and based their "recommendations" on. > Again, I am not against adding IPv6 examples in the appendix if it is considered to be useful. The original intention was to keep the draft short. > > Comment on section 2.1, MANET "Node" Morphology > ----------------------------------------------- > > The I-D says: > > | 2.1. MANET "Node" Morphology -- Hosts and Routers > | > | Each "independent node" in a MANET can functionally be described > | according to Figure 1, with the "MANET node" being composed of a > | "MANET router" (R) with one or more "MANET interfaces" -- i.e. the > | interface which is to be used for establishing connectivity between > | MANET routers -- as well as zero or more interfaces towards other > | networks or hosts on classic IP links. > | > | \|/ > | MANET interface | > | +-----------|---------------------+ > | | +--+------+ | > | | | R | MANET router| > | | +---------+ | > | | | | | > | | +---+ | Classical IP | > | | | H | | links with | > | | +---+ | hosts | > | | _______|______ | > | | | | | | > | | +---+ +---+ +---+ | > | | | H |...| H | | H | | > | | +---+ +---+ +---+ | > | | | > | +---------------------------------+ > | MANET node > | > | Figure 1: MANET "node" morphology > | > > Terminology: What is shown in Fig. 1 is not a node, but a collection of > nodes: > one router and several hosts. > I am tempting to remove or replace the term MANET "node" as it could be ambiguous. Thomas, would do you think? > > Comment on section 2.2, MANET Interface Configuration: > ------------------------------------------------------ > > The I-D says: > > | 2.2. MANET Interface Configuration > | > | The following summarizes the configuration constraints for MANET > | interfaces of a MANET router: > | > | o Each MANET interface on a MANET router MUST be configured with > an > | IP address which is unique, at least within the MANET. > | > | o Each MANET interface MUST be configured with a prefix length of > | /32 (for IPv4) or /128 (for IPv6). > | > > What is, conspicuously, missing here, is a "recommendation" on what IPv4 > broadcast address should be configured on the MANET interface. I think > this should be added, along with a subsequent "rationale and > justification" > in Section 4. > MANET protocols will use the newly allocated LL-MANET-Routers multicast address specified in RFC 5498 for broadcasts within the local neighborhood. > Comment on Section 3.1, MANET Router and Single Host > ---------------------------------------------------- > > The I-D says: > > | 3.1. MANET Router and Single Host > | > | Figure 3 illustrates a MANET node consisting of a MANET router with > a > | single MANET interface and a single host. This is the typical > case, > | for example, when one has a laptop, PDA or smartphone participating > | in the MANET: the "router" and the "host" are in that case logical > | components within the same device, and with a single physical > | interface. > | > | The MANET node is assigned a single IPv4 address, in this case > | 192.168.1.1. This IP address is to identify both the MANET > interface > | of the MANET router as well as the host. Logically, this is > | accomplished by configuring the interface of the MANET router as an > | > Shouldn't that read: "the interface of the host?" > | > | "unnumbered interface", by assigning 192.168.1.1/32 to the MANET > | interface of the router. Traffic to the logical component that is > | the router will typically be addressed to a well-known multicast > | address, thus the router can distinguish between traffic to itself > | and traffic to the logical host. > > This seems to contradict a previous interpretation of the (now dead, but > not forgotten) MANET Architecture I-D, which was that a host, even if > co-located with / internal to the MANET Router, could not adopt the IP > address of the MANET interface. I recall asking this specifically at > the > microphone during the Autoconf session in Vancouver (IETF-70), saying > that > is was common practice and being told that people had been doing it > wrong > for years (by none other than one of the authors of this I-D :-) > I let the other author reply to this as I figure it was him in Vancouver ;-) > > Comment on Section 3.2, MANET Router and Attached Network w. Prefix > Delegation > ------------------------------------------------------------------------ > ------ > > The I-D says: > ------------- > > | 3.2. MANET Router and Attached Network w. Prefix Delegation > | > | Figure 5 illustrates a MANET router with a single MANET interface > and > | an interface towards a classic IP link such as an Ethernet. The > | MANET router is delegated the IPv4 prefix 192.168.1.0/24. That > | prefix is assigned to the non-MANET link, on which interfaces are > | assigned addresses such as 192.168.1.1/24, 192.168.1.2/24, > | 192.168.1.3/24 etc. Note that the interfaces on that classic IP > link > | are configured with a prefix length of /24, indicating that the > | interfaces with addresses from within that IP prefix are all > | reachable within a single IP hop. > | > | The MANET interface is configured as an "unnumbered interface" by > | "borrowing" the address (192.168.1.1) from its interface towards > the > | classic IP link - but is configured with the prefix length /32. > The > | MANET interface is, specifically, not configured with a prefix > length > | of /24, even though that prefix is delegated to the MANET router, > as > | the MANET interface is not able to reach all other interfaces with > | addresses from within 192.168.1.0./24 in a single IP hop. > | > | > | > | 192.168.1.1/32 \|/ > | +------------|------------+ > | | | | > | | +-+-----+ | > | | | R | 192.168.1.0/24 > | | +-------+ | > | |192.168.1.1/24 | | > | | | | > | +---------------+---------+ > | | > | ,----------+-----------. > | | | | > | +---+ +---+ +---+ > | 192.168.1.2/24 | H | | H | | H | 192.168.1.4/24 > | +---+ +---+ +---+ > | 192.168.1.3/24 > | > | Figure 5: MANET router (R) with an attached network and a > delegated > | subnet prefix. Notice that the prefix 192.168.1.0/24 is assigned > to > | the non-MANET link, where interfaces are configured with that > prefix, > | e.g. 192.168.1.3/24. The MANET interface "borrows" the IP address > | from that link, however is configured with a prefix length of /32. > | > | Traffic to the MANET interface with the IP address 192.168.1.1 can > be > | distinguished from traffic to the non-MANET interface with the same > | address since traffic destined to the MANET interface of the router > | typically will be addressed to a well-known multicast address. > > Wouldn't it be convenient if the MANET Router had an address for e.g. > remote > management? > Indeed, it might be convenient. In the draft, we only specify that MANET interfaces MUST be configured with a /32 or /128 host prefix. Using unnumbered interfaces is described in the examples and worked for our settings. You can still follow the draft by assigning a /32 (/128) prefix in a different way than using unnumbered interfaces. > > Comment on Section 3.3, MANET Router and Attached Network w/o Prefix > Delegation > ------------------------------------------------------------------------ > ------- > > The I-D says: > > | 3.3. MANET Router and Attached Network w/o Prefix Delegation > | > | Figure 6 shows a situation similar to that of Section 3.2 except > that > | the MANET router, for whatever reason, is not delegated any prefix. > | > | As no prefix has been delegated to the MANET router, the MANET > router > | can not simply "borrow" an IP address from within a delegated > prefix > | for its MANET interface and know this IP address to be unique -- > but > | has to rely on some other mechanism for acquiring an IP address. > | Whichever mechanism is used for acquiring this IP address, is shall > | ensure that this IP address is unique, at least within the MANET. > > If I understand Section 2.2 correctly, IP address unicity is a > necessary, > but not a sufficient condition. Its prefix should be unique within the > MANET as well. > I don't understand your question here. In the example in section 3.3, it is said that this address (which is a /32 address) is unique at least within the MANET, so it is conform with section 2.2. What would you like to change or get explained here in addition? > Comment on Section 4.2, /32 and /128 Prefix Lengths > --------------------------------------------------- > > The I-D says: > > | 4.2. /32 and /128 Prefix Lengths > | > | In early MANET deployments, a common occurrence was to configure a > | MANET as "a subnet" and configure it as indicated in Figure 9: the > | MANET would have a subnet prefix, say 192.168.1.0/24 and MANET > | interfaces would be configured with this subnet prefix, e.g. > | 192.168.1.3/24. > | > | Communication > | Range > | <~~~~~~~~~~~~+~~~~~~~~~~~~> <~~~~~~~~~~~~+~~~~~~~~~~~~~> > | |<~~~~~~~~~~~~+~~~~~~~~~~~~>| > | +--------+ +--------+ +--------+ > | |192.168.| |192.168.| |192.168.| > | | 1.1/24 | | 1.2/24 | | 1.3/24 | > | +--------+ +--------+ +--------+ > | > | Data packet: --------------> > | dest 192.168.1.3 > | next-hop 192.168.1.2 > | > | ICMP Redirect <-------------- > | > | > | Figure 9: Misconfigured MANET: MANET interfaces configured with a > | shared /24 prefix, causing the central router to produce an ICMP > | redirect when forwarding packets from 192.126.1.1 to 192.168.1.3. > | > | If, for example, a data packet was transmitted by the MANET router > | 192.168.1.1 to be received by 192.168.1.3, then this would -- with > | reference to Figure 9 -- have to be forwarded by the MANET router > | 192.168.1.2. With the MANET interfaces in this MANET being > | configured with the subnet prefix 192.168.1 and the prefix length > | /24, it was observed that this produced ICMP redirects by > | 192.168.1.2. > | > | An early, and often suggested, solution was to "treat the symptoms > | rather than cure the disease" by disabling ICMP redirects on MANET > | routers -- i.e. to require modifications to the IP stack operation > in > | order that it can be supporting MANETs. > | > | The ICMP redirect is intended to be used to inform a source to send > | packets using an alternative, more direct, route -- e.g. if a > source, > | s wishes to send a data packet to a destination node d via the path > | s-R1-R2-d, and if R1 knows that a direct path s-R2-d is available, > | then the ICMP redirect from R1 will inform s of this route. > | > | Two interfaces, configured with addresses from within the same > subnet > | prefix, and with the same prefix length are defined to be reachable > | from each other within a single IP hop. More precisely, it is > | assumed that all interfaces with IP addresses within that subnet > | prefix and configured with the same prefix length are directly > | reachable from each other without forwarding by an intermediate > | router. Hence, a way for R1 to know that a direct path may exist > | between h and R2 is if h, R1 and R2 are configured with IP > addresses > | from within the same subnet prefix and within the same subnet > prefix. > | > | Returning to the MANET scenario in Figure 9, with all MANET > | interfaces being configured with the same subnet prefix and the > same > | prefix length, it follows from the discussion above that all these > | MANET interfaces are expected to be directly reachable from each > | other within a single IP hop. When, in this configuration, the > | router 192.168.1.2 is requested to forward a data packet from > | 192.168.1.1 to 192.168.1.3, it is expected that it generates an > ICMP > | redirect to 192.168.1.1 suggesting that a direct path exists from > | 192.168.1.1 to 192.168.1.3 -- as this is what the configuration > | suggests. > | > | Rather than "treating the symptoms" and disabling ICMP redirects, > | requiring /32 and /128 prefix lengths on MANET interfaces "cures > the > | disease". An interface so configured will not make any assumptions > | about other interfaces being within a single IP hop, and so will > not > | generate ICMP redirects when forwarding traffic. > > It may cure (or rather prevent) this disease, but it could introduce > other > ailments. For instance, Linux has an "rp_filter" kernel parameter, > described as follows in the kernel documentation > (networking/ip-sysctl.txt): > > >> rp_filter - BOOLEAN >> 1 - do source validation by reversed path, as specified in >> > RFC1812 > >> Recommended option for single homed hosts and stub network >> routers. Could cause troubles for complicated (not loop >> > free) > >> networks running a slow unreliable protocol (sort of RIP), >> or using static routes. >> >> 0 - No source validation. >> >> conf/all/rp_filter must also be set to TRUE to do source >> > validation > >> on the interface >> >> Default value is 0. Note that some distributions enable it >> in startup scripts. >> > > Debian is among the distributions that set rp_filter on start-up by > default, > being non-compliant with RFC1812, section 5.3.8. in this respect. The > effect > is, that e.g. MANET protocol HELLO's are discarded, because they fail > the > reverse path check. Of course, this can be fixed through a modification > of a > configuration file. In practice, though, this is just as much work as > turning > off the generation of ICMP redirects. > It's a bad thing if a software breaks an RFC ;-) Anyway, the ICMP redirects are just a "symptom" of a broken network configuration. So while you could simply "treat" the symptom by suppressing ICMP redirects, you could as well respect the IP model instead of breaking it. > Furthermore, the use of /32's (/128's) appears to exclude a > configuration > as depicted below: > > <------------------> <-----------------> > \|/ \|/ \|/ > | | | > +-+-+ +-+-+ +-+-+ > \|/ | R | \|/ | R | \|/ | R | \|/ > | +---+ | +---+ | +---+ | > +-+-+ +-+-+ +-+-+ +-+-+ > | H | | H | | H | | H | > +---+ +---+ +---+ +---+ > > H = host > R = router > > Here, all nodes just have a single radio interface. Some are configured > to be > hosts, wheras others are routers. Hosts can be considered as > "satellites" of > routers, in the sense that each of them is associated with a particular > router > and travels with it. Each host has a default route, with its associated > router > as the next hop. > > This can be made to work by assigning e.g. /24's from different > "subnets" > to the routers. For instance, in the picture above, the leftmost router > gets > 192.168.1.254, the middle one 192.168.2.254 and the rightmost router > 192.168.3.254. The broadcast address on the routers should be set to > have a wider > "scope" (shorter prefix)than their unicast addresses, e.g. > 192.168.255.255 or even > 255.255.255.255. This ensures that any protocols that rely on broadcast > still work > between routers. (Autoconfiguration protocols could potentially fall > into this > category, as do some older implementations of MANET routing protocols). > Hosts > are configured with addresses from the same subnet as their associated > router. The > hosts in the leftmost cluster in the picture above would e.g. be > 192.168.1.1 and > 192.168.1.2. > > It could be argued that for this scenario, separate virtual interfaces > should > be configured on top of the radio interface. One virtual interface would > then serve > as MANET interface, while the other(s) would be used for communication > with local > hosts. However, depending on the L2 technology / implementation used, > this may not > be readily achievable. > > The above may not be a very common case and therefore we could agree to > not > support it. However, in my opinion this should be a conscious and > documented > decision. > Yes, this seems to be a valid configuration for me. As you said, it might not be a common case and in particular it gets dangerous if there pops up a new router in your example with, say, 192.168.2.253/24. As we say in section 1: "Caveat lector: Other configurations and deployment approaches for MANETs are likely possible, and should not be disregarded or excluded. This document, however, describes a set of configuration and deployment recommendations, which practical experience and real- world deployments have shown to be feasible." So while we could enumerate all other possible configurations, we prefer to present one that works for us and that does not break IP. There probably are other ways of doing so. For the broadcast, you would rather use LL-MANET-Routers than the broadcast address 255.255.255.255. > > Comment on Section 4.3, IP Hop Isolation > ---------------------------------------- > > I-D says: > > | 4.3. IP Hop Isolation > > > > | There are, essentially, four potential ways of addressing this > | problem: requiring all upper-layer applications and protocols to > | become "MANET aware", inventing mechanisms for presenting a MANET > | as-if it was an Ethernet, pushing the problem to layer 2, or > | encapsulating any MANET specific behavior in a way such that it is > | only exposed to explicitly MANET aware applications and protocols. > > I only count three ways here (?) > Thanks! :-) > (End of comments) > 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 > Cheers, Ulrich --------------000101040005010703000706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Ronald,

comments inline...

Velt, R. (Ronald) in 't wrote: 
Thomas, Ulrich, all,

Please find below some comments on
draft-clausen-manet-autoconf-recommendations-00.txt

Regards,
Ronald in 't Velt


Comments on I-D title, abstract and introduction:
-------------------------------------------------

It is not entirely clear to me what the intention behind this I-D is. Is
the goal that it evolves into the "one practical addressing model" that 
the proposed new WG charter calls for? Is it merely a description of one

(tried and tested) way in which MANET addresses could be configured? If 
the latter, why is the the word "Recommendations" in the title? The 
specified "intended status" of the I-D is "informational". RFC2026,
sec. 4.2.2. says:

  
An "Informational" specification is published for the general
information of the Internet community, and does not represent an
Internet community consensus or recommendation.
    

Of course, this does not rule out that this I-D contains recommendations
from the authors. However, it seems to me that "recommendations" is a 
slightly awkward term. Some additional words of explanation might help.

I am not against adding a few additional words explaining the purpose of this document if this is felt to be necessary. As you suggested, these recommendations reflect *our* experience of how to configure a MANET, in a way that (i) works and (ii) does not break the IP model. Of course, there may be other ways of doing so.
Also, the I-D mentions several times that the presented approach is
supported
by an "existence proof", i.e. its viability has been proven by
succesfully 
deploying MANETs this way. At the same time, the addressing examples
given in 
the document all seem to be based on IPv4. (Even though the text
frequently 
says "/32 or /128"). This begs the question whether the "existence
proof"
extends to real-world IPv6 MANETs. Perhaps it would be useful to add an
appendix to the document, which provides details like platform / OS
(version), 
IPv4 or IPv6, etc. on some of the networks that the authors have gained 
experience with and based their "recommendations" on.
Again, I am not against adding IPv6 examples in the appendix if it is considered to be useful. The original intention was to keep the draft short.


Comment on section 2.1, MANET "Node" Morphology
-----------------------------------------------

The I-D says:

| 2.1.  MANET "Node" Morphology -- Hosts and Routers
|
|    Each "independent node" in a MANET can functionally be described
|    according to Figure 1, with the "MANET node" being composed of a
|    "MANET router" (R) with one or more "MANET interfaces" -- i.e. the
|    interface which is to be used for establishing connectivity between
|    MANET routers -- as well as zero or more interfaces towards other
|    networks or hosts on classic IP links.
|
|                                   \|/
|                   MANET interface  |
|                        +-----------|---------------------+
|                        |        +--+------+              |
|                        |        |    R    |  MANET router|
|                        |        +---------+              |
|                        |         |      |                |
|                        |      +---+     | Classical IP   |
|                        |      | H |     | links with     |
|                        |      +---+     | hosts          |
|                        |         _______|______          |
|                        |        |       |      |         |
|                        |      +---+   +---+  +---+       |
|                        |      | H |...| H |  | H |       |
|                        |      +---+   +---+  +---+       |
|                        |                                 |
|                        +---------------------------------+
|                                    MANET node
|
|                      Figure 1: MANET "node" morphology
|

Terminology: What is shown in Fig. 1 is not a node, but a collection of
nodes:
one router and several hosts.

I am tempting to remove or replace the term MANET "node" as it could be ambiguous. Thomas, would do you think?  


Comment on section 2.2, MANET Interface Configuration:
------------------------------------------------------

The I-D says:

| 2.2.  MANET Interface Configuration
|
|    The following summarizes the configuration constraints for MANET
|    interfaces of a MANET router:
|
|    o  Each MANET interface on a MANET router MUST be configured with
an
|       IP address which is unique, at least within the MANET.
|
|    o  Each MANET interface MUST be configured with a prefix length of
|       /32 (for IPv4) or /128 (for IPv6).
|

What is, conspicuously, missing here, is a "recommendation" on what IPv4
broadcast address should be configured on the MANET interface. I think 
this should be added, along with a subsequent "rationale and
justification" 
in Section 4.

MANET protocols will use the newly allocated LL-MANET-Routers multicast address specified in RFC 5498 for broadcasts within the local neighborhood. 
Comment on Section 3.1, MANET Router and Single Host
----------------------------------------------------

The I-D says:

| 3.1.  MANET Router and Single Host
|
|    Figure 3 illustrates a MANET node consisting of a MANET router with
a
|    single MANET interface and a single host.  This is the typical
case,
|    for example, when one has a laptop, PDA or smartphone participating
|    in the MANET: the "router" and the "host" are in that case logical
|    components within the same device, and with a single physical
|    interface.
|
|    The MANET node is assigned a single IPv4 address, in this case
|    192.168.1.1.  This IP address is to identify both the MANET
interface
|    of the MANET router as well as the host.  Logically, this is
|    accomplished by configuring the interface of the MANET router as an
|
Shouldn't that read: "the interface of the host?"
|
|    "unnumbered interface", by assigning 192.168.1.1/32 to the MANET
|    interface of the router.  Traffic to the logical component that is
|    the router will typically be addressed to a well-known multicast
|    address, thus the router can distinguish between traffic to itself
|    and traffic to the logical host.

This seems to contradict a previous interpretation of the (now dead, but
not forgotten) MANET Architecture I-D, which was that a host, even if 
co-located with / internal to the MANET Router, could not adopt the IP 
address of the MANET interface.  I recall asking this specifically at
the 
microphone during the Autoconf session in Vancouver (IETF-70), saying
that 
is was common practice and being told that people had been doing it
wrong 
for years (by none other than one of the authors of this I-D :-)

I let the other author reply to this as I figure it was him in Vancouver ;-)


Comment on Section 3.2, MANET Router and Attached Network w. Prefix
Delegation
------------------------------------------------------------------------
------

The I-D says:
-------------

| 3.2.  MANET Router and Attached Network w. Prefix Delegation
|
|    Figure 5 illustrates a MANET router with a single MANET interface
and
|    an interface towards a classic IP link such as an Ethernet.  The
|    MANET router is delegated the IPv4 prefix 192.168.1.0/24.  That
|    prefix is assigned to the non-MANET link, on which interfaces are
|    assigned addresses such as 192.168.1.1/24, 192.168.1.2/24,
|    192.168.1.3/24 etc.  Note that the interfaces on that classic IP
link
|    are configured with a prefix length of /24, indicating that the
|    interfaces with addresses from within that IP prefix are all
|    reachable within a single IP hop.
|
|    The MANET interface is configured as an "unnumbered interface" by
|    "borrowing" the address (192.168.1.1) from its interface towards
the
|    classic IP link - but is configured with the prefix length /32.
The
|    MANET interface is, specifically, not configured with a prefix
length
|    of /24, even though that prefix is delegated to the MANET router,
as
|    the MANET interface is not able to reach all other interfaces with
|    addresses from within 192.168.1.0./24 in a single IP hop.
|
|
|
|                  192.168.1.1/32  \|/
|                      +------------|------------+
|                      |            |            |
|                      |          +-+-----+      |
|                      |          |   R   | 192.168.1.0/24
|                      |          +-------+      |
|                      |192.168.1.1/24 |         |
|                      |               |         |
|                      +---------------+---------+
|                                      |
|                           ,----------+-----------.
|                           |          |           |
|                         +---+      +---+       +---+
|          192.168.1.2/24 | H |      | H |       | H | 192.168.1.4/24
|                         +---+      +---+       +---+
|                               192.168.1.3/24
|
|     Figure 5: MANET router (R) with an attached network and a
delegated
|     subnet prefix. Notice that the prefix 192.168.1.0/24 is assigned
to
|    the non-MANET link, where interfaces are configured with that
prefix,
|      e.g. 192.168.1.3/24. The MANET interface "borrows" the IP address
|     from that link, however is configured with a prefix length of /32.
|
|    Traffic to the MANET interface with the IP address 192.168.1.1 can
be
|    distinguished from traffic to the non-MANET interface with the same
|    address since traffic destined to the MANET interface of the router
|    typically will be addressed to a well-known multicast address.

Wouldn't it be convenient if the MANET Router had an address for e.g.
remote
management?

Indeed, it might be convenient. In the draft, we only specify that MANET interfaces MUST be configured with a /32 or /128 host prefix. Using unnumbered interfaces is described in the examples and worked for our settings. You can still follow the draft by assigning a /32 (/128) prefix in a different way than using unnumbered interfaces. 


Comment on Section 3.3, MANET Router and Attached Network w/o Prefix
Delegation
------------------------------------------------------------------------
-------

The I-D says:

| 3.3.  MANET Router and Attached Network w/o Prefix Delegation
|
|    Figure 6 shows a situation similar to that of Section 3.2 except
that
|    the MANET router, for whatever reason, is not delegated any prefix.
|
|    As no prefix has been delegated to the MANET router, the MANET
router
|    can not simply "borrow" an IP address from within a delegated
prefix
|    for its MANET interface and know this IP address to be unique --
but
|    has to rely on some other mechanism for acquiring an IP address.
|    Whichever mechanism is used for acquiring this IP address, is shall
|    ensure that this IP address is unique, at least within the MANET.

If I understand Section 2.2 correctly, IP address unicity is a
necessary,
but not a sufficient condition. Its prefix should be unique within the 
MANET as well.

I don't understand your question here. In the example in section 3.3, it is said that this address (which is a /32 address) is unique at least within the MANET, so it is conform with section 2.2. What would you like to change or get explained here in addition?


Comment on Section 4.2, /32 and /128 Prefix Lengths
---------------------------------------------------

The I-D says:

| 4.2.  /32 and /128 Prefix Lengths
|
|    In early MANET deployments, a common occurrence was to configure a
|    MANET as "a subnet" and configure it as indicated in Figure 9: the
|    MANET would have a subnet prefix, say 192.168.1.0/24 and MANET
|    interfaces would be configured with this subnet prefix, e.g.
|    192.168.1.3/24.
|
|                    Communication
|                        Range
|             <~~~~~~~~~~~~+~~~~~~~~~~~~> <~~~~~~~~~~~~+~~~~~~~~~~~~~>
|                          |<~~~~~~~~~~~~+~~~~~~~~~~~~>|
|                      +--------+    +--------+    +--------+
|                      |192.168.|    |192.168.|    |192.168.|
|                      | 1.1/24 |    | 1.2/24 |    | 1.3/24 |
|                      +--------+    +--------+    +--------+
|
|         Data packet:     -------------->
|          dest     192.168.1.3
|          next-hop 192.168.1.2
|
|           ICMP Redirect  <--------------
|
|
|      Figure 9: Misconfigured MANET: MANET interfaces configured with a
|      shared /24 prefix, causing the central router to produce an ICMP
|      redirect when forwarding packets from 192.126.1.1 to 192.168.1.3.
|
|    If, for example, a data packet was transmitted by the MANET router
|    192.168.1.1 to be received by 192.168.1.3, then this would -- with
|    reference to Figure 9 -- have to be forwarded by the MANET router
|    192.168.1.2.  With the MANET interfaces in this MANET being
|    configured with the subnet prefix 192.168.1 and the prefix length
|    /24, it was observed that this produced ICMP redirects by
|    192.168.1.2.
|
|    An early, and often suggested, solution was to "treat the symptoms
|    rather than cure the disease" by disabling ICMP redirects on MANET
|    routers -- i.e. to require modifications to the IP stack operation
in
|    order that it can be supporting MANETs.
|
|    The ICMP redirect is intended to be used to inform a source to send
|    packets using an alternative, more direct, route -- e.g. if a
source,
|    s wishes to send a data packet to a destination node d via the path
|    s-R1-R2-d, and if R1 knows that a direct path s-R2-d is available,
|    then the ICMP redirect from R1 will inform s of this route.
|
|    Two interfaces, configured with addresses from within the same
subnet
|    prefix, and with the same prefix length are defined to be reachable
|    from each other within a single IP hop.  More precisely, it is
|    assumed that all interfaces with IP addresses within that subnet
|    prefix and configured with the same prefix length are directly
|    reachable from each other without forwarding by an intermediate
|    router.  Hence, a way for R1 to know that a direct path may exist
|    between h and R2 is if h, R1 and R2 are configured with IP
addresses
|    from within the same subnet prefix and within the same subnet
prefix.
|
|    Returning to the MANET scenario in Figure 9, with all MANET
|    interfaces being configured with the same subnet prefix and the
same
|    prefix length, it follows from the discussion above that all these
|    MANET interfaces are expected to be directly reachable from each
|    other within a single IP hop.  When, in this configuration, the
|    router 192.168.1.2 is requested to forward a data packet from
|    192.168.1.1 to 192.168.1.3, it is expected that it generates an
ICMP
|    redirect to 192.168.1.1 suggesting that a direct path exists from
|    192.168.1.1 to 192.168.1.3 -- as this is what the configuration
|    suggests.
|
|    Rather than "treating the symptoms" and disabling ICMP redirects,
|    requiring /32 and /128 prefix lengths on MANET interfaces "cures
the
|    disease".  An interface so configured will not make any assumptions
|    about other interfaces being within a single IP hop, and so will
not
|    generate ICMP redirects when forwarding traffic.

It may cure (or rather prevent) this disease, but it could introduce
other
ailments.  For instance, Linux has an "rp_filter" kernel parameter, 
described as follows in the kernel documentation
(networking/ip-sysctl.txt):

  
rp_filter - BOOLEAN
	1 - do source validation by reversed path, as specified in
    
RFC1812
  
	    Recommended option for single homed hosts and stub network
	    routers. Could cause troubles for complicated (not loop
    
free)
  
	    networks running a slow unreliable protocol (sort of RIP),
	    or using static routes.

	0 - No source validation.

	conf/all/rp_filter must also be set to TRUE to do source
    
validation
  
	on the interface

	Default value is 0. Note that some distributions enable it
	in startup scripts.
    

Debian is among the distributions that set rp_filter on start-up by
default,
being non-compliant with RFC1812, section 5.3.8. in this respect. The
effect 
is, that e.g. MANET protocol HELLO's are discarded, because they fail
the 
reverse path check. Of course, this can be fixed through a modification
of a 
configuration file.  In practice, though, this is just as much work as
turning 
off the generation of ICMP redirects.

It's a bad thing if a software breaks an RFC ;-) Anyway, the ICMP redirects are just a "symptom" of a broken network configuration. So while you could simply "treat" the symptom by suppressing ICMP redirects, you could as well respect the IP model instead of breaking it. 

Furthermore, the use of /32's (/128's) appears to exclude a
configuration
as depicted below:

		 <------------------>	<----------------->
          \|/		         \|/                   \|/
           |			    |                     |
         +-+-+                  +-+-+                 +-+-+
   \|/   | R |   \|/            | R |          \|/    | R |	  \|/
    |	   +---+    |             +---+           |     +---+	   |
  +-+-+         +-+-+	                      +-+-+          +-+-+
  | H |         | H |                         | H |          | H |
  +---+         +---+                         +---+          +---+

  H = host
  R = router

Here, all nodes just have a single radio interface. Some are configured
to be 
hosts, wheras others are routers. Hosts can be considered as
"satellites" of 
routers, in the sense that each of them is associated with a particular
router 
and travels with it. Each host has a default route, with its associated
router
as the next hop.

This can be made to work by assigning e.g. /24's from different
"subnets"
to the routers. For instance, in the picture above, the leftmost router
gets 
192.168.1.254, the middle one 192.168.2.254 and the rightmost router 
192.168.3.254. The broadcast address on the routers should be set to
have a wider 
"scope" (shorter prefix)than their unicast addresses, e.g.
192.168.255.255 or even 
255.255.255.255. This ensures that any protocols that rely on broadcast
still work 
between routers. (Autoconfiguration protocols could potentially fall
into this 
category, as do some older implementations of MANET routing protocols).
Hosts
are configured with addresses from the same subnet as their associated
router. The 
hosts in the leftmost cluster in the picture above would e.g. be
192.168.1.1 and 
192.168.1.2.

It could be argued that for this scenario, separate virtual interfaces
should
be configured on top of the radio interface. One virtual interface would
then serve 
as MANET interface, while the other(s) would be used for communication
with local
hosts. However, depending on the L2 technology / implementation used,
this may not 
be readily achievable.

The above may not be a very common case and therefore we could agree to
not
support it. However, in my opinion this should be a conscious and
documented 
decision.

Yes, this seems to be a valid configuration for me. As you said, it might not be a common case and in particular it gets dangerous if there pops up a new router in your example with, say, 192.168.2.253/24. As we say in section 1:

    "Caveat lector: Other configurations and deployment approaches for
   MANETs are likely possible, and should not be disregarded or
   excluded.  This document, however, describes a set of configuration
   and deployment recommendations, which practical experience and real-
   world deployments have shown to be feasible."

So while we could enumerate all other possible configurations, we prefer to present one that works for us and that does not break IP. There probably are other ways of doing so.

For the broadcast, you would rather use LL-MANET-Routers than the broadcast address 255.255.255.255.


Comment on Section 4.3, IP Hop Isolation
----------------------------------------

I-D says:

| 4.3.	IP Hop Isolation

     <snip>

|    There are, essentially, four potential ways of addressing this
|    problem: requiring all upper-layer applications and protocols to
|    become "MANET aware", inventing mechanisms for presenting a MANET
|    as-if it was an Ethernet, pushing the problem to layer 2, or
|    encapsulating any MANET specific behavior in a way such that it is
|    only exposed to explicitly MANET aware applications and protocols.

I only count three ways here (?)
Thanks! :-)

(End of comments)
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

Cheers,
Ulrich

--------------000101040005010703000706-- From alexandru.petrescu@gmail.com Thu Mar 26 14:24:24 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51A083A6884 for ; Thu, 26 Mar 2009 14:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.711 X-Spam-Level: X-Spam-Status: No, score=-1.711 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_72=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 hVOJncAFCG-z for ; Thu, 26 Mar 2009 14:24:23 -0700 (PDT) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by core3.amsl.com (Postfix) with ESMTP id 4F1C23A676A for ; Thu, 26 Mar 2009 14:24:21 -0700 (PDT) Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by smtp3-g21.free.fr (Postfix) with ESMTP id 81972818098; Thu, 26 Mar 2009 22:25:11 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp3-g21.free.fr (Postfix) with ESMTP id 4E3DF81810F; Thu, 26 Mar 2009 22:25:08 +0100 (CET) Message-ID: <49CBF2A8.1010801@gmail.com> Date: Thu, 26 Mar 2009 22:24:56 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: ryuji@sfc.wide.ad.jp References: <84840efa0903251850w494042a1s33dffdf31f786ce@mail.gmail.com> In-Reply-To: <84840efa0903251850w494042a1s33dffdf31f786ce@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090325-0, 25/03/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] Meeting Agenda (Thursday 1510-1610 Afternoon Session II) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 21:24:24 -0000 Is this going to use the mext chat room? Or the autoconf chat room? Alex Ryuji Wakikawa a écrit : > Hi all, > > Here is the agenda of the AUTOCONF meeting on Thursday. > We apologize our delay. > > regards, > Thomas & ryuji > > http://www.ietf.org/proceedings/09mar/agenda/autoconf.txt > > --------------------------------------------------------------------------- > Ad-Hoc Network Autoconfiguration (autoconf) > ---------------------------------------------------------------------------- > Thursday, March 23, 2009 > 1510-1610 Afternoon Session II > Room Name: Continental 6 > ---------------------------------------------------------------------------- > - Notes takers, blue sheets, agenda bash > 5 min, Chairs > - WG status update > 5 min, Chairs > - New Charter > 10 min, Chairs > > - Status Update from Design Team > 30 min, Design Team > ---------------------------------------------------------------------------- > > ---------------------------------------------------------------------------- > The modified charter(WG Review Completed) > > Ad-Hoc Network Autoconfiguration (autoconf) > > Last Modified: 2009-02-18 > > Additional information is available at tools.ietf.org/wg/autoconf > > Chair(s): > Ryuji Wakikawa > Thomas Clausen > > Internet Area Director(s): > Jari Arkko > Mark Townsley > > Internet Area Advisor: > Jari Arkko > > Mailing Lists: > General Discussion: autoconf@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf > Archive: http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html > > Description of Working Group: > > In order to communicate among themselves, ad hoc nodes (refer to RFC > 2501) need to configure their network interface(s) with local > addresses that are valid within an ad hoc network. Ad hoc nodes may > also need to configure globally routable addresses, in order to > communicate with devices on the Internet. From the IP layer > perspective, an ad hoc network presents itself as a L3 multi-hop > network formed over a collection of links. > > The main purpose of the AUTOCONF WG is to describe the addressing > model for ad hoc networks and how nodes in these networks configure > their addresses. It is required that such models do not cause problems > for ad hoc-unaware parts of the system, such as standard applications > running on an ad hoc node or regular Internet nodes attached to the ad > hoc nodes. This group's effort may include the development of new > protocol mechanisms, should the existing IP autoconfiguration > mechanisms be found inadequate. However, the first task of the working > group is to describe one practical addressing model for ad hoc > networks. > > Once this sole work item is completed, the group can be rechartered to > work on additional issues. > > Goals and Milestones: > > Apr 2009 Submit initial draft on address configuration in ad hoc networks > Sep 2009 Submit address configuration draft to IESG as Informational > or close WG. > ---------------------------------------------------------------------------- > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From alexandru.petrescu@gmail.com Thu Mar 26 17:33:28 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A20A628C1B7 for ; Thu, 26 Mar 2009 17:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.266 X-Spam-Level: X-Spam-Status: No, score=-1.266 tagged_above=-999 required=5 tests=[AWL=-0.506, BAYES_05=-1.11, 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 PrRt-kocew2r for ; Thu, 26 Mar 2009 17:33:27 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 9011828C1B9 for ; Thu, 26 Mar 2009 17:33:25 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 18E79D48037 for ; Fri, 27 Mar 2009 01:34:16 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 109D9D4807D for ; Fri, 27 Mar 2009 01:34:13 +0100 (CET) Message-ID: <49CC1EFF.4020801@gmail.com> Date: Fri, 27 Mar 2009 01:34:07 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: autoconf@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 090326-0, 26/03/2009), Outbound message X-Antivirus-Status: Clean Subject: [Autoconf] Unnumbered interfaces X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 00:33:28 -0000 During the meeting there was talk about unnumbered interfaces. Trying to understand them leads to the posted informal Cisco pointer: http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080094e8d.shtml And a search at tools.ietf.org leads to RFCs: CR-LDP, RSVP, ptp-over-LAN link-state, RIPv2 MIB, OSPF/FrameRelay, OSPF multi-area adjacency, GMPLS. One wouldn't make the AUTOCONF ad-hoc addressing architecture dependent on e.g. OSPF/FrameRelay. But that's just an opinion of course, and technical advantage could be discussed... e.g. the change of src address was discussed - why is this feature needed? If we need that feature of change of src address - how could that be achieved without unnumbered interfaces? Alex From ryuji.wakikawa@gmail.com Thu Mar 26 17:50:52 2009 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5626E28C1FE for ; Thu, 26 Mar 2009 17:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1nPoBofP5yZ for ; Thu, 26 Mar 2009 17:50:51 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id 4F1003A6A66 for ; Thu, 26 Mar 2009 17:50:51 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so998628wfg.31 for ; Thu, 26 Mar 2009 17:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=Za9Qbl4uxdpsiU47NDBJzkHeO8pF56lBzve8QJdLCv0=; b=IKB1upUUPFKdg9KQL98LMIie/NHrwuRG4wX0Fi9PUfxmhSiMw3MxMA4r9BqHoomnGk O+pn9R6YXmJBeF2C2+MGs/Q4F5v1hJQyB3i750mVoQVmqfLX0W9gm7diN6LNhQvhT1Hb g6Y05IFxt6+8Kz4T8CKJdM9tccp6Gdbspr1Ho= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=I4rRUeRxcJic11UVxL0suT1FhYTrav5uT81EYleyE6qNFz4q9ajxhz1KyCFy8d+qqC DaXs2tCgixcjIIaMlp5T5FjgIwbiIHW/jDbDKjV4sGlPOSnrO3HIj+upKDuHpNPvXg8x x/BBna1gM3UfZXvKTMoDtiQ0QJhh9sRV9GCnA= Received: by 10.142.12.14 with SMTP id 14mr618391wfl.120.1238115105323; Thu, 26 Mar 2009 17:51:45 -0700 (PDT) Received: from ?172.28.177.218? ([67.99.198.2]) by mx.google.com with ESMTPS id 30sm1408233wfg.34.2009.03.26.17.51.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Mar 2009 17:51:44 -0700 (PDT) From: Ryuji Wakikawa To: Alexandru Petrescu In-Reply-To: <49CC1EFF.4020801@gmail.com> References: <49CC1EFF.4020801@gmail.com> Message-Id: <011506FA-2726-405F-B366-7FB873E7104F@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 26 Mar 2009 17:51:40 -0700 X-Mailer: Apple Mail (2.930.3) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Unnumbered interfaces X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 00:50:52 -0000 Hi Alex, First of all, Thanks a lot for taking jabber notes over audio streaming!!! If WG agree to have a new MANET specific usage of an unnumbered interface without breaking any IP addressing model, it should be ok. Of course, only if there is advantage to go for this. ryuji On 2009/03/26, at 17:34, Alexandru Petrescu wrote: > During the meeting there was talk about unnumbered interfaces. > Trying to understand them leads to the posted informal Cisco pointer: > http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080094e8d.shtml > > And a search at tools.ietf.org leads to RFCs: > > CR-LDP, RSVP, ptp-over-LAN link-state, RIPv2 MIB, OSPF/FrameRelay, > OSPF multi-area adjacency, GMPLS. One wouldn't make the AUTOCONF ad- > hoc addressing architecture dependent on e.g. OSPF/FrameRelay. > > But that's just an opinion of course, and technical advantage could > be discussed... e.g. the change of src address was discussed - why > is this feature needed? > > If we need that feature of change of src address - how could that be > achieved without unnumbered interfaces? > > Alex > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf