Re: [Autoconf] Autoconf addressing model
"Teco Boot" <teco@inf-net.nl> Mon, 02 March 2009 09:11 UTC
Return-Path: <teco@inf-net.nl>
X-Original-To: autoconf@core3.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 <autoconf@core3.amsl.com>; 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 <autoconf@core3.amsl.com>; 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 <autoconf@ietf.org>; 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 <teco@inf-net.nl>
To: cjbc@it.uc3m.es
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, 02 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 <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 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). 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ú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/ |++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
- 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