Re: [Autoconf] Autoconf addressing model
"Teco Boot" <teco@inf-net.nl> Fri, 27 February 2009 17:49 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 C09A728C36C for <autoconf@core3.amsl.com>; Fri, 27 Feb 2009 09:49:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.454
X-Spam-Level:
X-Spam-Status: No, score=-1.454 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 FmdnT1UrtQrI for <autoconf@core3.amsl.com>; Fri, 27 Feb 2009 09:49:22 -0800 (PST)
Received: from hpsmtp-eml20.kpnxchange.com (hpsmtp-eml20.KPNXCHANGE.COM [213.75.38.85]) by core3.amsl.com (Postfix) with ESMTP id C3CA228C34D for <autoconf@ietf.org>; Fri, 27 Feb 2009 09:49:20 -0800 (PST)
Received: from cpsmtp-eml104.kpnxchange.com ([213.75.84.104]) by hpsmtp-eml20.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 18:49:42 +0100
Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml104.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 18:49:42 +0100
From: Teco Boot <teco@inf-net.nl>
To: 'Alexandru Petrescu' <alexandru.petrescu@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> <49A7E58C.2020303@gmail.com>
In-Reply-To: <49A7E58C.2020303@gmail.com>
Date: Fri, 27 Feb 2009 18:49:40 +0100
Message-ID: <007201c99903$c4182c80$4c488580$@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: AcmY3FfMqdkQoAIbSxCSbSzcti9/QgAIRi0Q
Content-Language: nl
x-cr-hashedpuzzle: A3hK A4bu D5BA GmCm Gn/g H6K9 JNRP K1+O LNCn OCi8 Obcj QO74 T2Sr U6jd U9kM WDdb; 2; YQBsAGUAeABhAG4AZAByAHUALgBwAGUAdAByAGUAcwBjAHUAQABnAG0AYQBpAGwALgBjAG8AbQA7AGEAdQB0AG8AYwBvAG4AZgBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {41593C1C-282D-4064-99A0-B3321CEBA27B}; dABlAGMAbwBAAGkAbgBmAC0AbgBlAHQALgBuAGwA; Fri, 27 Feb 2009 17:49:35 GMT; UgBFADoAIABBAHUAdABvAGMAbwBuAGYAIABhAGQAZAByAGUAcwBzAGkAbgBnACAAbQBvAGQAZQBsAA==
x-cr-puzzleid: {41593C1C-282D-4064-99A0-B3321CEBA27B}
X-OriginalArrivalTime: 27 Feb 2009 17:49:42.0231 (UTC) FILETIME=[C4CA3E70:01C99903]
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: Fri, 27 Feb 2009 17:49:23 -0000
Inline. |-----Oorspronkelijk bericht----- |Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] |Verzonden: vrijdag 27 februari 2009 14:07 |Aan: Teco Boot |CC: autoconf@ietf.org; cjbc@it.uc3m.es |Onderwerp: Re: Autoconf addressing model | |Whoa, that's text Teco :-) Let me see where can I practically agree |with you: | |Teco Boot a écrit : |[...] |> 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 fully agree with you. I find /128 prefix lengths for subnets to be a |departure from the typical less-than-64 prefix lengths for subnets. It |may even break networks. | |> 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. When addresses are used on physical interfaces, and the interface goes down, connectivity might be broken. I think using router loopback interface addresses for talking to other nodes is best current practice. It is a basic principle in my network designs. RFC3871: It is a common practice among operators to configure "loopback" pseudo-interfaces to use as the source and destination of management traffic. These are preferred to physical interfaces because they provide a stable, routable address. Services bound to the addresses of physical interface addresses might become unreachable if the associated hardware goes down, is removed, etc. I think the same arguments are valid for non-management traffic in a MANET. |[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). |> 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. |> 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. | |The MANET interface is a loopback interface? I disagree. The loopback |interface is needed for local inter-process communication, I don't want |that to go on to the network. There is some misunderstanding her, the MANET interface is NOT a loopback interface. It is an interface that enables communication to other MANET nodes. |But, most importantly, why is there a need to add other special |interfaces to the example pictured above? 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. 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. Problems started with ARP processing, and I swapped to another addressing model immediately. |> 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. | |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. |> 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. 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. 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. 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. Anyway, ND /SLAAC works with the "push model" already, so nothing new here. |> |> 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. | |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. My BRDP used ND as a transport vehicle, and prefix information was carried in "Border Router Information Option" which is a look-alike of the Prefix Information Option. PIO is single-hop, BRIO is multi-hop. |> Multi-homing can easily be supported: | |maybe. Just write some code and compile :-) The problem is border router swapping. If session continuity is required, we need something like MIP/NEMO, HIP, SHIM6 or NAT / NAT66 at the border. This is not our focus, I think. Teco. |Alex | |> |> ---+-------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. |> |> |> 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/ |> |++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |> |>
- 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