Re: [Autoconf] Autoconf addressing model
Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Sat, 28 February 2009 13:43 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 688613A6A18 for <autoconf@core3.amsl.com>; Sat, 28 Feb 2009 05:43:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.966
X-Spam-Level:
X-Spam-Status: No, score=-3.966 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=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 dG-A9FNdGMra for <autoconf@core3.amsl.com>; Sat, 28 Feb 2009 05:43:27 -0800 (PST)
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 632413A69E0 for <autoconf@ietf.org>; Sat, 28 Feb 2009 05:43:27 -0800 (PST)
Received: from [192.168.1.209] (213.37.82.74.static.user.ono.com [213.37.82.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 942ED65A1F3; Sat, 28 Feb 2009 14:43:48 +0100 (CET)
From: Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es>
To: Teco Boot <teco@inf-net.nl>
In-Reply-To: <007b01c99911$907facf0$b17f06d0$@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> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-zdLy5X1gE8l+qVyIL3so"
Organization: Universidad Carlos III de Madrid
Date: Sat, 28 Feb 2009 14:43:44 +0100
Message-Id: <1235828624.6096.26.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-16490.007
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: Sat, 28 Feb 2009 13:43:29 -0000
Hi, El vie, 27-02-2009 a las 20:28 +0100, Teco Boot escribió: > Inline. > > |-----Oorspronkelijk bericht----- > |Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > |Verzonden: vrijdag 27 februari 2009 19:18 > |Aan: Teco Boot > |CC: autoconf@ietf.org > |Onderwerp: Re: Autoconf addressing model > | > |Teco Boot a écrit : > |[...] > |>>> 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). > |>> > |>> I don't agree going that way. I think loopback addresses are for > |>> self addressing not for talking to other nodes. > |> > |> See other mail also, on Linux. I think loopback addresses are often > |> used for stable connections to routers, where interfaces flap but due > |> to redundancy there are alternative paths. > | > |I think you mean a virtual interface actually, not necessarily the > |loopback interface (and yes, lo is a 'virtual' interface). > | > |Not all virtual interfaces are loopback. > > Router folks use "loopback" for what is meant here. Virtual interfaces have > a much, much broader meaning. A tunnel interface or VLAN / FR / ATM > subinterface is a virtual interface but definitely not what I intent to use. > I prefer keep using the term loopback here. Agree, I prefer that term as well. > > | > |> RFC3871: It is a common practice among operators to configure > |> "loopback" pseudo-interfaces to use as the source and destination of > |> management traffic. > | > |Well that RFC is completely wrong please someone correct it. The > |loopback address is ::1 and it can't be used to communicate outside the > |computer. Yes pseudo-interface (and maybe 'virtual') but no loopback. > > I think you mix up "host loopback" and "router loopback". These are very, > very different! Agree, don't know if the semantic difference is documented somewhere, but I share the same understanding. Regards, Carlos > > > > |And yes the interface in the routing table for the entry address/128 is > |'lo' which is yes the loopback interface but no, never will that address > |be in the src nor dst fields of any packet leaving the computer (other > |than encapsulated maybe). > > I checked this on the Linux host. I assigned another address on the lo > interface. And the Linux host is reachable on this address, as long as other > nodes has a path to this /128 prefix. > > Sorry, you are wrong. > > Detailed info: > > debian-fs1:/proc/sys/net/ipv6/neigh/eth0# ifconfig lo > lo Link encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: 2001:db8:1::3333/128 Scope:Global > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:185 errors:0 dropped:0 overruns:0 frame:0 > TX packets:185 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:13568 (13.2 KiB) TX bytes:13568 (13.2 KiB) > > Tested from IOS router: > nbs3725#ping 2001:db8:1::3333 > Type escape sequence to abort. > Sending 5, 100-byte ICMP Echos to 2001:DB8:1::3333, timeout is 2 seconds: > !!!!! > Success rate is 100 percent (5/5), round-trip min/avg/max = 0/0/4 ms > nbs3725# > > I added reachability manually: > nbs3725#show ipv6 route > IPv6 Routing Table - 4 entries > Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP > U - Per-user Static route, M - MIPv6 > I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary > O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 > ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 > D - EIGRP, EX - EIGRP external > C 2001:DB8:1::/64 [0/0] > via ::, FastEthernet0/0.22 > L 2001:DB8:1::1/128 [0/0] > via ::, FastEthernet0/0.22 > S 2001:DB8:1::3333/128 [1/0] > via FE80::20C:29FF:FEE3:BDF5, FastEthernet0/0.22 > L FF00::/8 [0/0] > via ::, Null0 > nbs3725# > > Debug info, showing that you are wrong, the IP address in interface lo is > reachable: > Feb 27 19:08:08.018: IPv6: SAS picked source 2001:DB8:1::1 for > 2001:DB8:1::3333 (FastEthernet0/0.22) > Feb 27 19:08:08.018: IPv6: nexthop FE80::20C:29FF:FEE3:BDF5, > Feb 27 19:08:08.018: IPV6: source 2001:DB8:1::1 (local) > Feb 27 19:08:08.018: dest 2001:DB8:1::3333 (FastEthernet0/0.22) > Feb 27 19:08:08.018: traffic class 0, flow 0x0, len 100+0, prot 58, > hops 64, originating > Feb 27 19:08:08.018: IPv6: Sending on FastEthernet0/0.22 > > Feb 27 19:08:08.022: IPV6: source 2001:DB8:1::3333 (FastEthernet0/0.22) > Feb 27 19:08:08.022: dest 2001:DB8:1::1 > Feb 27 19:08:08.022: traffic class 0, flow 0x0, len 100+14, prot 58, > hops 64, forward to ulp > > SSH works well also. NTP used the address automatically: > debian-fs1:~# netstat -anp | grep 3333 > tcp6 0 52 2001:db8:1::3333:22 2001:db8:1::1:61026 > ESTABLISHED 4756/5 > udp6 0 0 2001:db8:1::3333:123 :::* > 2308/ntpd > > > |>> [rfc4291 and 2464 citations] > |>>> 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 agree. > |>> > |>>> 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. > |>> > |>> I'm not sure I could agree with the MANET interface being the > |>> loopback interface. It sounds as a significant departure. > |> > |> The MANET interface is not a loopback interface! It is the interface > |> to a radio, e.g. 802.11 NIC in IBSS mode (your wifi adhoc). > | > |I agree with this. But in the immediately above text you're saying > |"using /128 for loopback interfaces fits" - I think you meant 'virtual' > |interface, not 'loopback' interface, right? > > No, absolutely not. > I provided the evidence that the loopback is perfectly usable already. > > > |>>> 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. > |>> > |>> An address assigned to an address? I think it risks many > |>> misunderstandings. > |> > |> Typo, I meant: So "host functionality" can be provided using the > |> globally (or MANET local) unique address assigned to a loopback > |> interface, or another non-MANET interface. > | > |Ok. > | > | > |> I think this model solves some problems. o The assigned address can > |> be used over whatever interface. This fulfills a requirement of "ad > |> hoc", something works without planning. > | > |I thought the unplanned aspect could be treated by IPv6 stateless > |autoconf and IPv6-over-Ethernet link-local addresses. > > Yes and no. I like SLAAC, but with SLAAC, thewre is an address per > interface. In this model, the node is reachable via the loopback address via > whatever interface. > > > > |> o Connectivity is not broken if a path swap occurs (the RFC3781 > |> loopback BCP) o It provides some scalability, as only a single > |> address is needed, even if multiple interfaces are used. o > |> Applications are not confused by "host prefixes" to a link, where > |> other nodes are reachable. I tested this with linux and IPv4 with > |> /32. > | > |Before deciding on the solution (address assigned to a virtual > |interface) I need to udnerstand how path swap occurs and why. > > Because movement. A MANET Router may have multiple interfaces, some of them > could be MANET, others wireless infrastructure mode and others MANET. When a > fire truck leaves the brigade, it looses its wired / wifi ESS connection, > but can still communicate with other vehicles nearby using MANET links. > > > > |> Problems started with ARP processing, and I swapped to another > |> addressing model immediately. > | > |>> For my clarification, what's fd01? (2001:db8:: is a prefix for > |>> documentation rfc3849, ULA is fc00 rfc4193). > |> > |> ULA prefix is FC00::/7. 8th but is L, set to 1 if locally assigned. > |> So all ULA would start with FD, the FC is for the future where a > |> registration body maintains the universal uniqueness. > |> > |> 0xFC + 0x01 = 0xFD. > | > |Ah! So a correct ULA address would be fd01::1/128? In this sense, when > |drawing pictures I have a choice between fd01::1/128 ULA and > |2001:db8::1/128 global address, it's ambiguous. > | > |>>> 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. > |>>> > |>>> > |>>> 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. > |>> > |>> Why shouldn't it be distributed with DHCP and with OSPF, for > |>> example. > |> > |> In a MANET, there are some problems with standard OSPF. OSPF-MANET is > |> perfectly fine to use in a MANET. > | > |Ok. > | > |> DHCP (with relay) can be used for "pull", but there is a problem > |> finding the best relay agent. I think there should be a mechanism > |> that informs nodes of available facilities, e.g. shortest path to a > |> DHCP server. Updating ND RA with some info for finding a DHCP server > |> looks a good idea to me, and I updated my Border Router Discovery > |> Protocol (BRDP) [Autoconf] proposal for DHCP support already. > | > |Sounds interesting. But I think normal DHCP could run ok, provided the > |Relays know the address of the Server. In a first practical step would > |be to manually configure the Server's address on each Relays. > > When many DHCP Relay Agenst are nearby, who to select? If multicast is used, > all of them will relay and this ends in a DHCP Relay storm (collisions, > loss, retry .....) > > > > |> However, there is a chicken - egg problem. In a wired network, the > |> DHCP client - DHCP relay agent relation is stable. This is certainly > |> not the case in a MANET. > | > |Well it is the case in a MANET made of 25meter IPv6 subnets. > > Voice over IP over WLAN for 25meter? Just shout!! > My requirements are over 25meter. 25km is no joke. Wifi is not usable here. > > > |> Therefore, I think a DHCP client should start with building reliable > |> communication to a DHCP server, and the MANET routing protocols can > |> provide such. But the MANET routing protocol needs a prefix that > |> corresponds to this MANET node. For this reason, I think it makes > |> sense to start with generating a prefix without DHCP, and we could > |> use a prefix "push model" here. > | > |Well I think this is indeed a very chickeneggy problem: are addresses in > |place before routing is, or vice-versa. But what would we do in > |practice? Certainly we'd manually assign some addresses - let's see > |these cases first. > > No. > MANETs are often used in workgroups, whit lack of knowledge of configuring > something. The network must be plug&play / zero-config. > > > > |>> Above, and in the following figures, I don't understand "--->, > |>> Prefix Information". Is that RA? Or OSPF? Or routing protocol? > |>> Or DHCP Prefix Delegation? > |> > |> This is under discussion, and the reason we have an [Autoconf] WG. > |> There are proposals that rely on a routing protocol, but the old > |> charter mentioned being independent of a routing protocol. > | > |I think we should consider first the practical cases. > > No. I think we have a clear picture of why MANETs are being used. > We need an [Autoconf] solution. Let's take the next steps defining an > addressing model, write down the requirements and then look for solutions. > > > Teco. > > > |Alex > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf -- 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