Re: [Autoconf] Autoconf addressing model
Alexandru Petrescu <alexandru.petrescu@gmail.com> Fri, 27 February 2009 18:17 UTC
Return-Path: <alexandru.petrescu@gmail.com>
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 BB0BE28C1BF for <autoconf@core3.amsl.com>; Fri, 27 Feb 2009 10:17:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.189
X-Spam-Level:
X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.060, 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 KQt2g1fphgrl for <autoconf@core3.amsl.com>; Fri, 27 Feb 2009 10:17:36 -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 49FB93A683E for <autoconf@ietf.org>; Fri, 27 Feb 2009 10:17:36 -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 n1RIHwW9032414; Fri, 27 Feb 2009 19:17:58 +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 n1RIHvJa001083; Fri, 27 Feb 2009 19:17:58 +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 n1RIHvJ4032531; Fri, 27 Feb 2009 19:17:57 +0100
Message-ID: <49A82E55.10208@gmail.com>
Date: Fri, 27 Feb 2009 19:17:57 +0100
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Teco Boot <teco@inf-net.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>
In-Reply-To: <007201c99903$c4182c80$4c488580$@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 <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 18:17:37 -0000
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. > 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. 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). >> [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? >>> 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. > 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. > 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. > 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. > 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. >> 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. Alex
- 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