Re: [Autoconf] Autoconf addressing model
Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Mon, 02 March 2009 10:57 UTC
Return-Path: <cjbc@it.uc3m.es>
X-Original-To: autoconf@core3.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 <autoconf@core3.amsl.com>; 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 <autoconf@core3.amsl.com>; 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 <autoconf@ietf.org>; Mon, 2 Mar 2009 02:57:13 -0800 (PST)
From: Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es>
To: Teco Boot <teco@inf-net.nl>
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 <autoconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/autoconf>
List-Post: <mailto:autoconf@ietf.org>
List-Help: <mailto:autoconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Mar 2009 10:57:16 -0000
Hi Teco, El lun, 02-03-2009 a las 10:11 +0100, Teco Boot escribió: > 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". 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 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. 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. > > 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). > > 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. Fully agree. Regards, Carlos > > Regards, Teco > > > > |-----Oorspronkelijk bericht----- > |Van: Carlos Jesús 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ó: > |> 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ús 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ó: > |> |> 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ús 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ús 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ús 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/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
- Re: [Autoconf] new charter Jari Arkko
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter Paul Lambert
- [Autoconf] new charter Jari Arkko
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter Ryuji Wakikawa
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Charles E. Perkins
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter HyungJin Lim
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter HyungJin Lim
- [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter HyungJin Lim
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter HyungJin Lim
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter HyungJin Lim
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter HyungJin Lim
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] practical addressing (was: new cha… Alexandru Petrescu
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] practical addressing (was: new cha… Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] new charter Stan Ratliff (sratliff)
- Re: [Autoconf] practical addressing Alexandru Petrescu
- Re: [Autoconf] new charter Alexandru Petrescu
- [Autoconf] radio neighbors in range Alexandru Petrescu
- Re: [Autoconf] new charter Stan Ratliff (sratliff)
- Re: [Autoconf] radio neighbors in range Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model HyungJin Lim
- Re: [Autoconf] new charter Rex Buddenberg
- Re: [Autoconf] practical addressing Teco Boot
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] radio neighbors in range Teco Boot
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] radio neighbors in range Alexandru Petrescu
- Re: [Autoconf] new charter Stan Ratliff (sratliff)
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] Autoconf addressing model Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] Autoconf addressing model Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Carlos Jesús Bernardos Cano
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Carlos Jesús Bernardos Cano
- Re: [Autoconf] Autoconf addressing model Carlos Jesús Bernardos Cano
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model HyungJin Lim
- Re: [Autoconf] Autoconf addressing model HyungJin Lim
- Re: [Autoconf] new charter Dearlove, Christopher (UK)
- Re: [Autoconf] new charter Dearlove, Christopher (UK)
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Joe Macker
- Re: [Autoconf] new charter Dearlove, Christopher (UK)
- Re: [Autoconf] radio neighbors in range Dearlove, Christopher (UK)
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Dearlove, Christopher (UK)
- Re: [Autoconf] Autoconf addressing model Dearlove, Christopher (UK)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Dearlove, Christopher (UK)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Joe Macker
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Joe Macker
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Dearlove, Christopher (UK)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- [Autoconf] new charter Ryuji Wakikawa
- Re: [Autoconf] new charter Teco Boot