Re: [Autoconf] Autoconf addressing model
Alexandru Petrescu <alexandru.petrescu@gmail.com> Fri, 27 February 2009 13:07 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 83AA13A6932 for <autoconf@core3.amsl.com>; Fri, 27 Feb 2009 05:07:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.884
X-Spam-Level:
X-Spam-Status: No, score=-1.884 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 1U0bP7T33tPP for <autoconf@core3.amsl.com>; Fri, 27 Feb 2009 05:07:04 -0800 (PST)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id C6E913A6821 for <autoconf@ietf.org>; Fri, 27 Feb 2009 05:07:03 -0800 (PST)
Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1RD7P3i017632; Fri, 27 Feb 2009 14:07:25 +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 n1RD7OKu023761; Fri, 27 Feb 2009 14:07:25 +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 n1RD7OKC016064; Fri, 27 Feb 2009 14:07:24 +0100
Message-ID: <49A7E58C.2020303@gmail.com>
Date: Fri, 27 Feb 2009 14:07:24 +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>
In-Reply-To: <002f01c998bf$8f112210$ad336630$@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 13:07:05 -0000
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. [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. > 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. > 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. But, most importantly, why is there a need to add other special interfaces to the example pictured above? > 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). > 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. > > 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? > Multi-homing can easily be supported: maybe. 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